PankovAlxndr
@PankovAlxndr
Fullstack web developer

Какую архитектуру парсинга маркетплейса выбрать?

Здравствуйте.
Прошу совета по поводу решения такой задачи:
Нужно получать и хранить у себя все отзывы с одного маркетплейса.
Мне поставили такую задачу и начал я с малого - написал парсеры, а именно
  1. парсер продавцов
  2. парсер товаров каждого продавца (на вход id продавца)
  3. парсер отзывов каждого товара (на вход id товара)

Напиcал на php (laravel) запустил джобу (которой вертит Horizon), при тестировании все ок (опустил моменты про подстановку прокси, про сохранние еще какой-то не важной сейчас информации)
В итоге у меня несколько табличек вышло: продавцы, товары, отзывы, авторы (отзывов) все.
Все это даже работает в ограниченных рамках (парсинг одной категории)

По расчетам база должны быть порядка 450ГБ и там 10+ ярдов отзывов.
С такими объемами я даже близко ранее не работал, поэтому прошу помощи.

Мои основной вопрос:
Сейчас парсер работает с одним воркером, те один долгоживущий процесс добавляет отзывы в базу, для продакшена это не годится, будет порядка 1000 воркеров, я не могу уложить в голове как 1000 процессов будут делать инсерт в базу и как будет пересчитываться индекс при этом? это же займет все время, а мне еще и селекты нужно к базе выполнять же... я вижу тут проблему и не понимаю как выйти из нее, вставлять батчами, а батчи в редисе хранить... уже какими-то костлями пахнет, как делаю взрослые дядьки?

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

Кратко: как вставлять по 100.000 строк в секнду при этом пресчиытвать индексы да и так чтобы select запросы не повисли
  • Вопрос задан
  • 265 просмотров
Пригласить эксперта
Ответы на вопрос 1
@rPman
100к событий в секунду с торговой платформы это сюр, такое практически нереально, (ну может в самый первый раз когда база пустая).

С высокой вероятностью там так - вы собираете в секунду 100к информационных единицы (отзывы, товары, ..) но в базе из них обновить и добавить считанные процент из этого, и вот в этот момент есть способы как оптимизировать, например перенести обработку из медленной базы данных (медленные они, потому что универсальные и транзакционные) в оперативную память.

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

Отсюда архитектура - отдельно дубовые парсеры-загрузчики (их можно размещать буквально где угодно, они получают команду на загрузку и молотят, выдавая json-чики пакетами в виде результата), отдельно узлы-обработчики, которые на каждый пакет данных от загрузчиков делает нужные запросы в базу данных (или заранее кеширует в памяти, но тут нужно считать, что дешевле - апгрейдить сервер базы данных или держать на дисках кеш-дампы запросов и обновлять их параллельно БД, в этом случае кстати БД остается как конечное хранилище и аналитики). Ну и про базу данных, они на запись медленные только если там индексы распиханы по максимуму, хороший способ, если загрузка в базу редкая (например раз в сутки длится час) то можно отключить на это время индексы, провести загрузку, вернуть индексы - это кратно ускоряет процесс ЗАГРУЗКИ но не проверки целостности и поиск данных, т.е. подходит именно когда анализ проводится не в БД.

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

p.s. у меня крутился сервис, годами собирающий терабайты данных на скорости 4к-10к событий в секунду (time series), хранить это в классической базе я не стал, а организовал хранилище на файлах, поверх которых в базе данных собирается аггрегированная выжимка и индексы.

Это было оправдано, так как разработка аналитического сервиса шла уже в процессе загрузки и это была суть работы, т.е. нельзя заранее определить, что из этих данных и как может понадобиться, база данных строилась каждый раз под задачу, проходом по всем данным (больше времени занимала их распаковка - json с упаковкой zstd)
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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