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

Question

[Александр Панков]

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

1. парсер продавцов
   
2. парсер товаров каждого продавца (на вход id продавца)
   
3. парсер отзывов каждого товара (на вход id товара)
   

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

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

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

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

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

Comments

[Александр Панков]

нагуглил еще про то что в кафку сохарняют, потом батчем в базу пишут, но как он омне поможет, я хз

[Антон Шаманов]

это же займет все время, а мне еще и селекты нужно к базе выполнять же...

ну для innodb это не то чтобы проблема, но всегда можно создать таблицу2, заполнить и потом поменять таблицы

[fenrir]

Александр Панков, стек для хранения выбирается под задачу, а мы о задаче ничего не знаем. Начните с вопроса заказчику нужны все отзывы ЗАЧЕМ? В частности если нужно будет делать поиск по словам, вероятно нужен эластик или скажем qdrant, если аналитика по разным полям смотрите кликхаус и т д.

[Александр Панков]

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

[Александр Панков]

Антон Шаманов, не смог понять ваше предложение, зачем создавать таблицу, где потом менять и что и зачем...

[Александр Панков]

и только что понял, что писать наде не 5.000 а 100.000 отзывов в секунду...

[Антон Шаманов]

Александр Панков, создаем аналогичную таблицу, парсим в нее данные, меняем их местами через переименование таблиц. если предполагается парсинг нонстопом, то такой вариант конечно не подойдет, если обновление раз в день, то вполне.

[fenrir]

Александр Панков, а потом ваш заказчик разорится на проксях, когда маркетплейс начнёт их банить на таких масштабах.
Так по описанию кликхаус должен хорошо подойти.
Только вот реалистичности самой задачи сомневаюсь

[Олег]

Александр Панков,
100.000 insertов в секунду.
Муська ? Легко! На VPS за 800 рублей/мес. только через консоль из csv файла.
Прайс лист поставщика на 300 тысяч позиций менее 2х секунд.
Дольше подготовка входных данных, чем сама вставка в базу.

Единичными инсертами свыше 1-2 тысяч в секунду не проинсертить.

В районе 5-10 тысяч/сек получается через insert on duplicate update пачками данных в районе 8метров. Так вставляю данные от проценки через апи.
Это внутрення CRM небольшого магазина. За сутки в табличке набирается 2-3 миллиона записей.
Так как они нафиг больше не нужны, перед бекапом таблица очищается.

Это все на основе опыта работы с официальными апи поставщиков.

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

[Дмитрий]

Мне кажется вам сначала стоит посмотреть на другие вещи, нежели Postgres, Kafka, партицирование. Вам стоит понять а какой вообще обьем вы пытаетесь впихнуть. То есть - вот у вас есть отзывы. Предположим в среднем отзыв 1кб, следовательно вам надо впихнуть 1000кб в секунду. Смотрите на диск - какова скорость работы. Ну если 100 кб/с - то собственно какая к черту разница Postgres или MySQL будет пытаться в игольное ушко верблюда пихать, и будет ли ему в этом помогать кафка или раббит, один хрен у вас не влезет? Тут уже смело можно смотреть в сторону шардирования. Если 10000 кб/с то вам вообщем то похрен как мускул будет у 1000 процессов индексы апдейтить, это проблемы MySQL. Нормально будет - ему то чего, если диск спокойно шуршит. А если батчем то даже и хорошо будет.

[iljaGolubev]

Вася это человек или нет, его отзывы релевантны или нет, он наш конкурент или нет и тд и тп

противоречит

аналитики никакой

[Александр Панков]

iljaGolubev, нет, там же написано, что НА КЛИЕНТЕ, база про аналитику ничго не знает и не должна

[Александр Панков]

Дмитрий, дак NVME быстрые, у селектела например, если доспустить что в "железной" части не будет пробелм, то как действовать дальше? пожет clickHouse?

[Дмитрий]

Александр Панков,
1. как говорит нам матушка природа скорость чего либо то ни было - конечна. И следовательно даже у NVME будет лимит по чтению и записи. И вот надо сначала смотреть упираетесь ли в этот лимит. И все эти веселья с шардированием возникли ровно потому что какую бы систему хранилища вы не выбрали - то все равно в этот лимит упретесь. Или вы думаете что Facebook по каким то религиозным причинам не может закупить себе NVME - и избавиться от тонны серверов?

2. Ну я честно говоря давно не смотрел чего там по ценам, но сильное подозрение что хранить такие данные как у вас в таком количестве на NVME - такое. Но это тоже можно посчитать - и схожим образом, у меня средняя запись весит 1кб а будет их миллиард. И обойдется это - в столько то.

3. Кликхаус бд которая хорошо работает с выборкой временных данными. А у вас оно тоже есть? Просто запрос выбери мне все отзывы у этого товара - это не работа с временными метками.

4. И еще раз. Какая хрен разница в том кто будет записывать данные на диск? Кликхаус, Постгрес или Мускул? Вы думаете они как то по разному на диск пишут? Или при использовании Clickhouse возникает сотрудник Яндекса с волшебной палочкой и дипломом хогвартса кафедра "изменения законов физики"? Или оверхед у них на сброс одной записи на диск - будет отличаться в 100 раз?

[Александр Панков]

Дмитрий, ну вообще да, я думал они по разному на диск пишут, хранят и достают (по крайне мере колоночные и строчные СУБД), затем они и придуманы были, для разных задач, странно что это не так..

[Дмитрий]

Александр Панков, они придуманы для разных задач. И если бы ваша задача сводилась бы к тому что бы посчитать какое среднее количество отзывов добавляется по дням недели - кликхаус было бы круто. Или вы для разных выборок выбирали бы фиксированное количество колонок. Но сильное подозрение что у вас немножко другие задачи. Или вы думаете что Facebook по каким то философским причинам не может заменить все бд на колоночные?
По разному на диск пишут это как? Насколько я смутно помню что в мускуле что в постгресе по умолчанию системный fsync. А структура хранения разная да, но только это мало что меняет если вам нужно тупо записать 100Тб на диск.

З.Ы. Писал и вспомнил схожий разговор. И бац внезапно мы с вами уже о подобных вещах говорили

[Дмитрий]

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

[Александр Панков]

Дмитрий, так может тогда в кафку, чтобы не велосипедить?

[Дмитрий]

Александр Панков, да как по мне так меньше посредников. Курл тащит и сохраняет. Если связь нарушится, то по проверке существования файла второй раз не пойдёт парсинг, пропустит и пойдёт далее

[Виталий Артемьев]

Может стоит взять другую бд? Clickhouse очень хорошо работает с большими объёмами данных,да и хранит он их достаточно эффективно

[Дмитрий]

Виталий Артемьев, простите, как кликхаус поможет в этом кейсе?

[Виталий Артемьев]

Дмитрий, автор боится что БД будет большого объёма.
У меня на одном из проектов был ETL (PostgreSQL -> Clickhouse), БД в Postgresql занимала чуть больше терабайта, после переливки (с некоторыми преобразованиями) в Clickhouse она занимала около 200 гб

[Виталий Артемьев]

Дмитрий, да и clickhouse отдавал данные гораздо эффективней, postgres на тех же запросах захлебнулся бы

[Дмитрий]

Виталий Артемьев,
1. Postgres умеет сжимать таблицы. Можете прописать сжатие для table space - в том числе и Lz4 как у кликхауса.
2. Сравнивать ваш кейс с таблицами и текущий кейс немножко не правильно. Ибо исходя из MVCC который в Postgres запросик вида update table set field = field; и Posgtres весело увеличит вам таблицу в 2 раза, до следующего автовакуума, не смотря на то что вроде как бы в таблице ничего не помнялось. По этому сравнивать надо не только данные, но то что вы с ними делаете - результат будет весьма различен. В этой задачи я большого количества update не вижу, поправьте меня если я не прав.
3. Почему clickhouse отдает данные быстро. Я уж лет 5 как с ним не работал, может чего поменялось, может я чего забыл, но:

a) Колоночная бд - колонки лежат в отдельных файлах. По этому запрос select field from table будет в Clickhouse быстрее чем в Postgres. Однако верно и обратное ворочать запрос вида select * from table в Postgres будет легче нежели в Clickhouse. У вас есть уверенность что первый вариант в этой задаче будет превалировать над втором? Я в этом не уверен, но с удовольствием вас выслушаю

b) Разряженный индекс вместо плотного. В Clickhouse разреженный индекс - узел индекса ссылается не на 1 запись, а на n-цать, и читает Clickhouse гранулами насколько я помню. Posgtres страницами. По этому запрос select user_id from reviews where primary between 100000 and 30000000 прекрасно отработает в Клихаусе. Верно и обратное - запрос select * from reviews where primary = 1 отработает там хуже - потому что клихаус будет искать 1 запись в грануле. Если у вас есть увереность что большая часть запросов которая в этой задаче будет соотвествовать первому варианту?

с) данные в clickhouse хранятся упорядоченно согласно первичному ключу - последовательное чтение обычно быстрее случайного. Когда вы используете clickhouse для записи каких то событий - то вообще огонь потому что события обычно идут друг за другом и использование даты в качестве первичного ключа обыденность. и запросы обычно шарашатся за даты.
Какой ключ в описанной задаче позволит нам использовать эту особенность clickhouse? И если учитывать clickhouse постоянно в фоне перестраивает таблицу какой ключ позволит кликхаусу поменьше времени тратить на сортировку?

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

[Виталий Артемьев]

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

[d'Ivan]

Александр Панков,
У меня вопросы по

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

1. 450 ГБ данных чего? Товаров, отзывов или всех моделей вместе взятых?

как вставлять по 100.000 строк в секнду

2. Строк чего и какого объёма в среднем? Отзывов или чего-то другого?
3. На основании чего было получено это требование? Какая взаимосвязь между 450 ГБ и 100к строк в секунду?
4.Требуется ли выполнить импорт данных разово или периодически, регулярно? Одинакового ли объёма, что и первоначально?

[Александр Панков]

Everything_is_not_so_bad, здравствуййте. еще раз все пересчитвл и оформил, вот тут можно почитать https://pankovalxndrpsychedelic-nose-95e.notion.si...

[d'Ivan]

Александр Панков,
в указанном документе не нашел информации о том:
1. как было получено требование о 100к строк в секунду. Оно взято "с потолка"?
2. ответ на мой 4-й вопрос.

Answer 1

[rPman]

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

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

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

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

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

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

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