Какой оптимальный способ сбора данных со сторонних сайтов?

Question

[Aleksey FRZ]

Помогите прояснить картину, в интернете довольно не конкретная информация.
Стоит задача: сбор данных с определенных сайтов (это значения double) и сравнение их с эталонной цифрой, получая разницу, значения меняются много раз в минуту. Цифры эти на сайте находятся на разных страницах. Скорость получения данных и их анализа имеет наивысший приоритет. Если скачивать каждую страницу и парсить регулярками получится очень медленно. Пока со всех сайтов скачаешь страницы и проанализируешь, данные уже могут быть не актуальны.

ИТОГО: есть 10 сайтов где на разных страницах есть значения double, которые меняются скажем 6 раз в минуту. Как их вытаскивать максимально быстро?

UPD: задачу буду решать на Java + JSoup

Comments

[hzzzzl]

а точно ли "получится медленно"?
10 сайтов + 6 раз в минуту это немного и нечасто, или там на каждой странице по миллиону чисел?

[Aleksey FRZ]

hzzzzl, около тысячи чисел и они на разных страницах. То есть надо сначало получить ссылки на эти страницы, потом каждую скачать и обработать. Я тестировал это через jsoup. Слышал, что можно это все реализовать просто перехватив запрос, но не до конца понимаю как это должно работать.

[Aleksey FRZ]

Bavashi, да

[сергей кузьмин]

Aleksey FRZ мне кажется делов всего - запустить ваш джар на 10 (20, 100 и т. д.) машинах - получите ответ приблизительно в 10 ,20,100 раз быстреe; плюс "небольшие дополнителные расходы" по написанию кода чтоб синхронизировать между собой эти копии

[Sergey Shvyrev]

Простите, как всегда... сначала ответил, потом прочёл комменты.)

По собственному опыту делал бы так:

1. Один контрлируемый сайт - один под. Конфиги консулом можно раскидать.

2. Разделите парсинг от загрузки. Конкретно в Jsoup метод parse (Jsoup.parse(String value)). В разных пулах даже советовал бы.

3. Выберите http клиент неблокирующий потоки. Который будет загружать контент с сайтов. Это позволит загружать параллельно с количеством потоков n+1, где n - число ядер (можно больше, но не рекомендую).

4. Нужна скорость пишите на Java 8, компилируйте в нативное приложение. Java 11 на 20% медленнее. Ограничения AOT можно обойти на уровне кубера, ребутнув под например.

[Aleksey FRZ]

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

[сергей кузьмин]

Aleksey FRZ, спасибо за фидбек - если речь о стоимости вам по моему прямо на fl.ru искать узнавать расценки и заказывать работу и платить

[Aleksey FRZ]

CellycoMobiles, поясните по пункту 1. Пункт 2 - загрузку осуществляю методом connect.get(), а дальше разбираю страницу через select. Сегодня тестировал, медленно. Я понимаю, что без параллелизма не обойтись.

[Sergey Shvyrev]

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

Если использовать Jsoup для загрузки - будет долго.

Часто туже страницу можно получить через GET запрос. И после этого парсить методом Jsoup.parse(htmlText).

Необходимо оптимизировать загрузку. Для этого загружаем html неблокируя поток. Это позволит использовать большее количество одновременных загрузок. Рекомендуемое количество потоков = n+1 , где n - число доступных ядер процессора. Но если очень нужно, то можно использовать n << 1. Есть нюансы, но можно. У меня так прокси чекер работает 24/7, все норм.

В крайнем случае. Можно просто loom и netty использовать. Но это сложно. Выберите фреймворк, какой вам проще.

В моих парсерах используется Vertx. О его достоинствах писал ниже. Но есть и недостатки.

У Vertx есть пул для блокирующих потоков, worker-ов. Предлагаю парсинг перенести в этот пул. Парсинг к сожалению нельзя сделать неблокирующим.

Предлагаю делать так:
1. Грузим html через какой-то неблокирующий поток. Сохраняем в кэше.
2. Подписываемся на триггер кеша, при отработкеихендлера парсим html Text из кэша воркером из блокирующего потока.
3. Сохраняем результаты парсинга.

[Aleksey FRZ]

сергей кузьмин, не не, речь о времени выполнения

[Aleksey FRZ]

CellycoMobiles, большое спасибо за развернутый ответ. Буду вникать в этот вариант. Как вы решили проблему парсинга JS сайтов? Где html код генерируется скриптами. Я столкнулся с этой проблемой, jsoup бесполезен в этом случае.

[Sergey Shvyrev]

Aleksey FRZ, парсинг js сайтов...
Сложный вопрос. Выбираю по скорости между : селениумом и htmlunite.

[Aleksey FRZ]

CellycoMobiles, дадите свои контакты пожалуйста? Напрошусь в будущем на кодревью того, что у меня получилось.

[Sergey Shvyrev]

Aleksey FRZ, да, конечно.

Пишите в Телегу.
https://t.me/dmitrysedov

Спасибо за доверие.

Answer 1

[Sergey Shvyrev]

Прекрасный выбор технологий.
Осталось только в много потоке запустить краулеры.
Ну или, если реализовывать миуросервисы, параллельно несколько инстансов запускать, которые будут обрабатывать каждый сайт, который нужно контролировать.

Рекомендовал бы второй вариант. Это удобнее, например произошла какая-то ошибка в одном из коаулкров - остальные продолжили работу, пока кубер поднимает упавший.

В моей компании парсеры реализованы на Vertx.
Причины выбора этого фреймворка:

1. Собственный DNS resolver. хост, либо 8.8.8.8, либо кастомизируемый список.
   
2. Неблокирующие запросы. Можно запускать много запросов одновременно. Спасает на бесплатных медленных проксях.
   
3. сложные блокирующие операции, как например парсинг ответа или ожидание капчи, реализуются в отдельных потоках. Worker threads, с отдельным пулом. Очень комфортно разделять от общей лоики.
   

Много пишу. Слушайте у меня есть уже реализованы проект, открытый на гитхабе. В конкурсе участвовал, но проиграл. Там как раз все о чем пишу реализовано. Только не все Javadocs расписаны.

Может я статейку на Хабр напишу, чем все в один ответ запихивать... Как вы считаете?

Comments

[Sergey Shvyrev]

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

[Sergey Shvyrev]

Bavashi, да ошибся. Там другой грубиян был. Прошу прощения