Как хранить большие JSON массивы, которые постоянно обновляются (API)?

Question

[Даниил Сидоров]

Разрабатываю сервис, который работает с API Wildberries и Ozon. Функционал простой - получил данные, посчитал и вывел на страницу. Но есть проблема - не совсем понимаю, как лучше всего организовать хранение полученных данных.

Я рассуждал так - делать запрос к API при каждом обновлении страницы нецелесообразно, к тому же попаду на "Too many requests". Значит данные надо обновлять в фоне, например каждые 15 минут, поэтому создам CRON-задание. Каждые 15 минут я буду получать JSON с 10 000+ записей. Как его лучше хранить? Не уверен, что стоит писать все эти данные в MySQL, ведь каждый раз придется полностью очищать таблицу от старых данные и записывать новые. Может тогда хранить в файлах?

Кто имел опыт разработки подобных проектов, пожалуйста подскажите как лучше сохранять большие JSON массивы.

Comments

[Zhainar]

вам точно нужно хранить? может хранить только результат вычислений?

[Макс]

А этот толстый JSON содержит в себе полный набор необходимых данных? Если да, то можно и in-memory хранением обойтись, если у приложения один инстанс.

[Даниил Сидоров]

Zhainar, Возможно так будет правильнее

Answer 1

[d-stream]

Большие объёмы данных, в особенности по которым что-то потом надо искать/агрегировать, стоит хранить в бд.
Ну и для операций с БД существуют не только операции insert, но и update.

Ну и собственно корректнее в этом случае говорить не о хранении json, а о хранении данных [полученных из json]

Answer 2

[Rsa97]

Не уверен, что стоит писать все эти данные в MySQL, ведь каждый раз придется полностью очищать таблицу от старых данные и записывать новые.

А что мешает не удалять, а менять данные?
INSERT ... ON DUPLICATE KEY UPDATE

Answer 3

[rPman]

Задать сначала вопрос нужно, как именно используются полученные данные.

Только ли для чтения или возможны изменения, или изменения только те что приходят от озона (т.е. вопрос, будут ли меняться данные после того как получены от озона)? есть ли поиск и фильтрация данных? Многопользовательский ли доступ или сервис для себя? Ожидается ли серьезная переделка в будущем с расширением функционала или это код на один раз, как часть эксперимента?

А сами данные, в формате, получаемом от озона нужны в совместимом формате (не нужна ли агрегация данных с нескольких запросов?)?

Тут конечно рекомендуют использовать базы данных, но в некоторых случаях это может оказаться оверкилом, и возможно, тебе будет достаточно хранить полученные данные прямо как есть в файлах (не объединяя их), и при запросе, просто считывать их полностью (можно сразу после получения данных, делать по ним индекс и складывать рядом тоже в файл)

Работа с файлами, в случае когда тебе сразу нужно много данных, может оказаться быстрее и на разработку не потратишь много времени.

Но стоит только этим данным начать меняться, или количество данных станет несоизмеримо больше чем однократно запрашиваемые, индексные файлы и код работы с ними станут сложнее и станет проще перенести все данные в sql базу.

p.s. я воспринимаю хранение в файлах как использование nosql база данных, тем более что это очень даже быстро, и даже если хранение данных в режиме много файлов в одной записи

p.p.s. хранение файлов в php формате (var_export) и подключение их include может оказаться самым быстрым способом из всех возможных, для readonly 'баз данных' (json или serialize медленнее в полтора два раза).
upd. мне тут подсказали что есть еще более быстрый сериализатор php - igbinary и входит в поставку того же debian/ubuntu

Answer 4

[Сергей Соколов]

NoSQL бд, например, MongoDB, подходят для хранения таких json документов.

Answer 5

[Developer]

Для хранения больших объёмов данных давно придумали базы данных