@mastanggt

Как правильнее заносить и хранить большой объем данных в бд?

Здравствуйте.
Имеется сайт на котором постоянно то появляются то пропадают скидки на товары.

Я создаю проект в котором должна будет храниться история цен по всем товарам.
Парсер будет запускаться каждые 4 часа.
Даже если брать не все товары а всего несколько категорий, то получается около 400 000 товаров, а в день их нужно дергать 6 раз, соответственно 2 600 000 записей в бд в день.
Вопрос в том как лучше заносить их в бд, я думаю объединять к примеру по 1000 товаров и закидывать их одним запросом чтобы уменьшить нагрузку на базу, и как и где их лучше хранить, в месяц получается около 72 000 000 записей, а статистику нужно будет собирать долгое время.
Есть еще идея вместо того чтобы собирать эту огромную базу, делать для каждого товара несколько позиций, в которых будет размещена цена и временной период, на протяжении которого стоимость товара не изменялась, и так для всех скидок/цен для каждого товара.

Подскажите каким лучше методом реализовать данную задачу, если есть свои идеи то буду только рад их выслушать, и какую бд лучше использовать для хранения и постоянной выборки таких объемов данных?
  • Вопрос задан
  • 581 просмотр
Решения вопроса 1
@entermix
Не нужно записывать в БД все цены в момент каждой проверки, Вам достаточно записать только информацию о цене, которая изменилась.

products
id, name, created, ...

product_prices
id, product_id, price, created, ...
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
darthunix
@darthunix
Знаю PostgreSQL, Ubuntu, DICOM и медицину.
Я бы использовал PostgreSQL, потому что знаю его) А детальнее - вначале создал бы собственный тип, описывающий цену в момент времени, состоящий из времени и цены. Потом просто создал бы таблицу товаров, в которой бы была колонка с массивом этого нового типа цен в момент времени. И при каждой новой загрузке информации я бы раскладывал для подходящего товара данные о времени и цене в этот массив. Ну и добавил бы первичный ключ по товарам и gin индекс по массиву временных точек цен. По идее в таком виде таблица не станет очень большой и вы сохраните возможность быстро проводить агрегацию по данным. Ну и данные будет легко шардировать, если потребуется.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы