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

Здравствуйте.

Прошу совета по поводу решения такой задачи:

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

Мне поставили такую задачу и начал я с малого — написал парсеры, а именно:

— парсер продавцов

— парсер товаров каждого продавца (на вход id продавца)

— парсер отзывов каждого товара (на вход id товара)

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

В итоге у меня несколько табличек вышло: продавцы, товары, отзывы, авторы (отзывов) все.

Все это даже работает в ограниченных рамках (парсинг одной категории)

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

С такими объемами я даже близко ранее не работал, поэтому прошу помощи.

Мои основной вопрос:

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

Может я стек для хранения не тот выбрал (Mysql)

Может смотреть в строну постгрес, партицирования, шардинга и репликаци, опять же не сталкивался с этм в проде, только читал для себя и не представляю как сделать рпавильно, буду рад услышапть ваши мылси?

А может кликхаус (хотя зачем… аналитики никакой, селекты нужны с джоинами, текущие селекты за нескольк мс отдаются, инлексы помогают)

Вобщем не понимаю как дальше делать и не наломать дров.

Кратко: как вставлять по 100.000 строк в секнду при этом пресчиытвать индексы да и так чтобы select запросы не повисли

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

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

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

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

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

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

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