Архитектура приложения для парсинга большого числа страниц
Добрый день.
Помогите, пожалуйста, со следующим вопросом:
Каждый день нужно сверять цены для ~10 миллионов товаров.
Раньше такое количество никогда не обрабатывал (особенно в заданные временные промежутки) , поэтому есть сомнения в реализации подобного.
Как прикинуть достаточную мощность сервера (или серверов ?), пропускную способность и подобное. Какую БД лучше использовать, возможно даже ЯП. Сколько потоков запускать и подобное.
Что бы вы использовали для подобной задачи? Размер страницы ~100кб , время отдачи ~ 2c + ~2c на прокси.
Тут сама задача выглядит странно. Целевой ресурс готов морально и технически, что вы (хорошо, если не ещё сотня таких же) будете его насиловать со скоростью 100rps? :)
Может, есть возможность сделать выгрузку цен в xml/csv/whatever и уже нормально работать с дампом?
Эксперемент критерий истины. Чушь. 100 килобайт парсить плевое дело. Я на работе 2 мегабайта на JS парсил на клиенте. При этом со сложной логикой перестроения DOM. + делал все асинхронно, чтобы браузер не вис.
В твоем случае обычным регулярным выражением можно все быстро спарсить одной строкой, получив на выходе массив. Или DOM селектором.
Спасибо за ответ.
Но меня больше смущают не 100кб а 10лям за сутки
это выходит по 115 запросов в секунду
а если учесть что одну страницу можно получить за ~4с (в идеальном случае), то фактически количество запросов нужно увеличить на 4, .. т.е. каждый момент времени будет висеть 460 необработанных запросов
