Платформа для парсера 24/7 и архитектура?

Question

[Andrey_Dolg]

Какую платформу выбрать для парсера.
Есть паук который работает через мультипроцессинг и в 20-40 процессах ждёт ответа от сервера. Ввиду особенности необходимой информации вопрос больше не в самом парсинге. Так как средняя необходимая скорость сейчас 9 запросов в секунду(может стать больше) то интересует чужой опыт выбора облачного решения под подобную задачу. И да время простоя в 10-15 секунд накапливает дополнительный объём запросов что необходимо обработать. Хранения информации в рантайме достаточно, интересует именно устойчивость.

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

Upd...
На сколько я понимаю serverless cloud не подходит для этой задачи ввиду оплаты по процессорному времени, а он постоянно занят. Моя теория что подходить VPS на подобие почтового сервера который априори рассчитан на большое количество маленьких запросов.

Answer 1

[Sergey Shvyrev]

Мне в свое время мозги вправил StormCrawler. Достаточно подробно описана инфраструктура. Понравились решения для фетчинга и индексации.
Переделал на микросервисы. Считаю хорошим решением для старта.

Answer 2

[xmoonlight]

Добавлю то, о чём ещё не упоминали.
Вот как бы сама архитектура "на пальцах":

0-[Командуем: url task manager: queue]
1-1234567890 [льём: head-less browser/etc.]
2-1234567890 [decomposer]
3-123456...
....
N-1234567890 [сохраняем: db data insert]
Goto 0

Строки - уровни обработки, числа - параллельные единичные потоки.

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

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

Comments

[Andrey_Dolg]

В моё случае это по сути однопоточная идея так как параллелизм стартует только на задаче IO ожидания ответа от сервера. С одной стороны это не совсем верно но с другой я не знаю куда мне надо идти.
У меня задача похожа на спринты, когда я не знаю не объём не ссылки до следующей итерации.

схема

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

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

Буду переделывать на асинхронный вариант.

[xmoonlight]

Andrey_Dolg, вот и "горлышко" - пока один процесс ждёт ответа - он блокирует весь процесс обработки. А если есть уровни, то ожидание ответа сервера не влияет на свободные потоки для обработки уже полученных от сервера "сырых" данных.

Притом, ещё и ждёте, пока не наберётся пачка из 20-ти урлов!

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

[alnagaev]

Где можно подробнее почитать про кэширование "скелета" нахождения данных? Звучит интригующе

[xmoonlight]

alnagaev, нигде, это приходит с опытом.