Каким будет хороший конвейер для создания масштабируемого распределенного веб-сканера и скребка? - PullRequest
0 голосов
/ 21 февраля 2019

Я хотел бы создать полуобщий сканер и скребок для веб-страниц продуктов аптек.

Я знаю, что большинство веб-сайтов не равны, но большинство URL-адресов у меня есть.в списке следуйте одному конкретному типу логики:

  1. Например, с помощью Microdata, JSON-ld и т. д. Я уже могу очистить определенную группу веб-страниц.

  2. Используя XPath, хранящийся в файлах конфигурации, я могу сканировать и просматривать некоторые другие веб-сайты.

  3. И другие методы работают хорошо для остальных веб-сайтов, и если я уже смогу извлечь нужную мне информацию из 80% данных, я был бы более чем доволен результатом.

По сути , Я беспокоюсь о создании хорошего конвейера для решения проблем, связанных с мониторингом (для обработки веб-страниц, которые внезапно меняют свою структуру), масштабируемостьи производительность.

Я подумал о следующем конвейере (без учета хранилища):

Создайте 2 главных паука.Тот, который сканирует сайты с учетом их доменов.Он получает все URL-адреса внутри веб-страницы (конечно, подчиняясь robots.txt) и помещает их в систему очередей, в которой хранятся URL-адреса, готовые к обработке .Затем второй паук берет последний URL-адрес в очереди и извлекает его, используя метаданные, XPath или любой другой метод.Затем это снова помещается в другую систему очередей, которая в конечном итоге будет обрабатываться модулем, который помещает все данные в очереди в базу данных (которую я до сих пор не знаю, должен ли это быть SQL или NoSQL).

Преимущества этой системы в том, что при размещении очередей между основными процессами извлечения и хранения становится возможным выпол- нение распараллеливания и масштабирования.

Есть ли в моей логике какие-либо недостатки?Что мне не хватает?

Большое вам спасибо.

1 Ответ

0 голосов
/ 21 февраля 2019

Во-первых, этот подход будет работать;моя команда и я создали множество сканеров на основе этой структуры, и они эффективны.

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

  1. Существует одна программа для расписания , которая обрабатывает URL-адреса для загрузки.
  2. Существует программа для фактической загрузки
  3. Существует программа для извлечения информации из загруженных страниц и добавления новых ссылок для программы, которая обрабатываетпланирование.

Другая важная рекомендация заключается в том, что, если вы вообще используете cURL, вы захотите использовать мультиинтерфейс cURL и очередь FIFO для обработки отправки данных из планировщика взагрузчик.

Преимущество этого подхода состоит в том, что он отделяет обработку от загрузки.Это позволяет вам увеличить ваш сканер, добавляя новые серверы и работая параллельно.

На Potent Pages мы используем эту архитектуру для нашего паука сайтов, который обрабатывает одновременную загрузку сотен сайтов.Мы используем MySQL для сохранения данных (ссылки и т. Д.), Но по мере масштабирования вам придется много оптимизировать.Плюс phpmyadmin начинает выходить из строя, если у вас много баз данных, но наличие одной базы данных на сайт действительно ускоряет процесс синтаксического анализа, поэтому вам не нужно просматривать миллионы строк данных.

...