Какая инфраструктура должна быть для 24/7 парсера обновляющего БД?

Question

[guruloz]

Привет мастера.
Есть парсер, которые постоянно висит и делает много запросов на curl, плотно работая с БД. Проверка на существования сущности в БД, добавление данных, обновление и т.д.
Проблема в том, что из-за большого количества запросов запросы к АПИ сильно тормозят, пока парсер работает. Как построить архитектуру, чтобы всем было комфортно: и скорость АПИ и регулярность обновлений данных?
Решит ли проблему мастер-слейв связка? И где можно почитать про подобную инфраструктуру, для больших сайтов-парсеров, краулеров, в большим количеством данных.

Comments

[Лентюй]

"большое количество" это сколько?

[Илья]

конкретизируйте понятие "много"

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

таки что именно тормозит, в первую очередь? Запросы на вставку в огромные индексы?
Может, MySQL не оптимальное хранилище для этих данных, а больше подойдёт key-value или файловая система?

[Ромзес Панагиотис]

Сергей Соколов,

Может, MySQL не оптимальное хранилище для этих данных, а больше подойдёт key-value или файловая система?

Это вряд ли. СУБД еще нужно уметь правильно пользоваться. Сомневаюсь, что это случай для автора.
Файловая система тоже ограничена. Тем же количеством открытых файловых дескрипторов. Да и блокировки при обновлении тоже надо самому разруливать во избежание состояния гонки.

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

Ромзес Панагиотис, может какой-то специфичный парсинг не текстовых данных, а к примеру, больших наборов int id. Хранить каждый id строкой в БД крайне неэффективно и альтренатива – сортированные наборы писать бинарными файлами прямо на диск.

Answer 1

[Vitaly Karasik]

Универсальный ответ - "зависит".
Нужно сделать PoC, посмотреть на запросы, оптимизировать их. Потом оценить траффик в продакшен и сделать load test. По следам это оптимизировать и масштабировать.
С точки зрения инфраструктуры - если много reads, то slave[s] очень помогут.
С точки зрения архитектуры - засылка задач в очередь и вытаскивание из нее помогают сгладить пики.

Comments

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

"PoC" — proof of concept?

[Vitaly Karasik]

да

Answer 2

[Гена]

Посмотри в сторону https://amphp.org/, там и http клиент есть вместо CURL. Я на нём сделал демона который работает 24/7, если появляются новые запросы он обрабатывает их асинхронно. Так же реализовал возможность ограничить максимальное кол-во одновременно исходящих соединений как для всего сервера так и для отдельных источников.
У меня 1 демон с каналом связи 100мбит/c за час 4-8 млн. страниц парсит, хз много это или мало....

Answer 3

[Ромзес Панагиотис]

Можно построить архитектуру приложений так, что API будет работать преимущественно в режиме чтения с СУБД.
А другой процесс-воркер будет получать задачи через очередь сообщений и интенсивно писать в СУБД.
В API вместо блокирующего ответ клиенту парсинга нужно сразу слать задание в очередь сообщений. Тогда соединения не будут удерживаться подолгу, а почти сразу будут закрыты по отправке в очередь.
Все, что шлется в API для добавления в очередь, можно возвращать ответ 202 (Accepted).
Как только воркер выполнит задачу, он обновит результат парсинга в БД. А тем временем, при обращении по API информация будет считана с БД без каких-либо блокирующих операций.

То есть небольшой апгрейд состоит в схеме:
APIs (write) -> MQ -> Worker(s) -> DB
APIs (read) <-> DB
Так легко добавить любой компонент в случае большой нагрузки.

Ну и, необходимо замерять нагрузку, чтобы знать где узкое горлышко.