Какой брокер сообщений выбрать под задачу — принять данные по api и записать в базу?

Question

[Artikul2]

Моя задача принимать через api данные в формате json, записывать их в соответствующую таблицу в зависимости от кого эти данные пришли. Каждый источник может отправлять данные любого размера, например json с 1 млн элементов, где каждый элемент имеет 30 пар ключ-значение, а может отправить один элемент в json. Таких источников может быть сотни, а общее поступление новых данных в минуту может быть в пределах 200 максимум.
На деле - все цифры в разы меньше. Пример привел на перспективу.

Я вижу краткую логистику данных:
Данные отправляются запросом post, мой сервер принимает данные. Файл Json ложится во временную папку и переименовывается. В Mysql пишем отправителя, путь к файлу, указываем метод к которому применяем эти данные и отправляем в ответ на post запрос статус 200 - загружено.
По крону раз в минуту запускаем скрипт, который получит имеющиеся данные в mysql и выполнит операцию вставки json в базу данных. Если при вставке нет проблем, то запускаем код, который обновит статус в mysql, что данная задача выполнена, а затем удалит файл данных. Готово.

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

Конечно, я бы хотел сделать все по нормальному, но у меня крайне мало времени во всем разобраться, потому ищу более простое решение под мою задачу. Я полагаю брокер сообщений может выполнять множество задач по загрузке данных за время.
1. В идеале мне нужно гарантировать, что полученные данные будут записаны (даже после reboot сервера) в конечную базу данных, а если в json отправителя есть ошибка и файл не может быть записан, например ошибка (когда ожидаем число, а пришла строка), в ответе на post запрос высылать код ошибки с описанием.
2. Также мне нужно сделать триггеры, когда в базе данных появляются новые данные, например пересчитать данные в таблице или вывести в веб-интерфейс, что появились новые данные. Но я не знаю, относится ли этот пункт к брокеру сообщений.

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

Comments

[d'Ivan]

Каков средний размер JSON?

[Artikul2]

Иерокопус Таманский, 200.000 элементов занимают 80 мегабайт в json. Можем сократить вдвое.

Answer 1

[rPman]

Миллион? В json? Передай хороший пинок архитектору...

Твоя задача упирается в 2 узких места - это парксинг больших json и запись в базу.

Паркинг делай потоковым размером, они быстрые и удобные как раз для ситуаций, когда в одном json много объектов, даже если разнородные.

Запись в базу делай тут же либо через любую очередь, особенно если работа с базой будет асинхронной.

Усложнять не советую.

Comments

[Artikul2]

Миллион? В json? Передай хороший пинок архитектору...

Не совсем понимаю, что не так. Сейчас я вставляю в mysql миллион записей за секунду,

SET @json = CONVERT(LOAD_FILE('$LOAD_FILE') using utf8mb4);
REPLACE INTO load_orders ......
from json_table(@json,'$[*]' columns......

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

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

[rPman]

php не сможет за секунду распарсить миллион записей, ну или я чего то странного не знаю

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

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

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

[Artikul2]

rPman,

php не сможет за секунду распарсить миллион записей, ну или я чего то странного не знаю

PHP ничего не парсит и это не надо, записываем как есть.
sql вполне сам справляется - раскладывает по ячейкам данные из json
хоть txt, хоть csv https://dev.mysql.com/doc/refman/8.0/en/load-data.html

[rPman]

Artikul2, за секунду миллион? это что же там запилили в mysql для этого?
но тут уже больше верится.

[d'Ivan]

Паркинг

Ошибка

Answer 2

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

Миллион элементов в json - это сильно (жирно).
Предлагаю следующий вариант:
- В качестве брокера использовать любой брокер сообщений/менеджер очередей с ACK/NACK механизмом (Redis Streams, RabbitMQ, Kafka)
- Все json разбиваем на 2 категории - большие и маленькие в зависимости от размера (кот. поддерживает брокер)

Алгоритм будет следующий:
Producer:
- Приходит запрос с json
- Если json маленький, то отправляем в брокер напрямую
- Если json большой, то сохраняем его в отдельную БД и получаем ID этой записи, в брокер отправляем ID этой записи

Consumer:
- Получает сообщение из брокера
- Если json содержится в сообщении (когда маленький), то сохраняем в БД
- Если json был большим и передан ID из БД, то читаем этот JSON из временный БД и сохраняем в целевую БД
- Коммитим сообщение

Пример такого запроса:

// Маленький объект
{
   "data": {
       "key": "value"
    },
    "id": null
}

// Большой объект
{
    "data": null,
    "id": 13123123
}

P.S. название паттерна хранения большого объекта во внешнем хранилище и передача только его id не помню

Comments

[Artikul2]

Миллион элементов в json

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

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

Artikul2, я описал кейс, который можно использовать независимо от брокера, т.к. есть 2 ограничения:
1. Ограничение брокера на максимальный размер сообщения
2. Подтверждение обработки

Первое - решили на уровне архитектуры - большие сообщения хранятся в отдельной БД
Второе - все перечисленные брокеры имеют ACK/NACK механизмы (так или иначе)

В данном случае, не думаю что выбор брокера так уж важен