Стоит задача - написание довольно таки толстого парсера веб-страниц.
Задача парсера будет состоять в парсинге сайтов-конкурентов, анализированием цен, приведением цен к средней, записи средней цены для товаров на своем ресурсе.
Парсер будет находиться на отдельном поддомене, иметь форму входа в личный кабинет.
В личном кабинете будет выводиться различная статистика, протокол работы и прочая информация.
На выбор 2 ЯП, php и golang.
Собственно сам вопрос, на чем экономически выгоднее писать подобный парсер (в дополнении с небольшим веб-интерфейсом).
Проблема в написнии граббера
(потому что парсером хтмл с огромной долей вероятности будет что-то на основе lxml)
в том, что тем кого вы парсите совсем не интересно обслуживать ваши запросы.
И они будут сильно стараться ваши запросы не обслуживать
А писать его нужно на простом и лаконичном ЯП
Потому, обычно, пишут на питоне
sim3x, касательно лаконичности - лично для меня, как php, go и python - одинаково лаконичны.
Никогда ранее не писал парсеры для живых проектов, потому важно знать, с какими трудности могу столкнуться если склонюсь к go, например отсутствие библиотек и т.д.
Роман Савчук,
Много либ не потребуется
- ротация прокси / прозрачная работа с ними
- кеширование результаов грабинга
- орм для нормальной работы с данными
- многопоточность / управление потоками
Ни на одном участке от ЯП не требуется супер производительность - задержки на сети сожрут любую скорость
ex Software Engineer at Reddit TS/React/GraphQL/Go
Если выберешь Go то посмотри в сторону пакета goquery - jquery селекторы на go. Но мне кажется удобнее всего на js (node 8), в мастер-слэйв режиме, т.е. 1 инстанс рулит/балансирует, другие инстансы-воркеры занимаются непосредственно парсингом.
Я бы выбрал Go. У него множество плюсов для быстрой обработки, многопоточность и т.д.
Небольшое выступление, можно посмотреть https://www.youtube.com/watch?v=MitOZ3Bx6QE (не реклама)
В основном первые 5-7 минут
Просто из практики в реальной работе, о скорости.
Как уже выше заметили - основную часть времени программа будет простаивать, т.е. ожидать ответ (загрузка страниц). В общем flow это время будет несоизмеримо больше чем обработка ответа. Поэтому оптимальнее здесь использовать асинхронную сетевую модель, когда вы отправляете массу запросов, а потом по событиям уже будут "дёргаться" обработчики ответа. Это гораздо экономнее нежели многопоточный подход, даже если это будут green threads Go. Ведь в последнем случае будет создано множество потоков с запросами, которые будут простаивать 90% времени своей работы в ожидании ответа.
Почему такое внимание уделяется времени простаивания (ожидания ответа) ? Дело в том, что только в идеальных условиях вы получаете ответ на запрос максимально быстро. В реальных же условиях далеко не всё так безоблачно. К тому же не забывайте про использование прокси, иначе вас непременно будут банить. А использование прокси увеличивает время ожидания ответа весьма значительно.
Средний
Средний
