Как лучше сделать парсер данных с разных источников?

Работаю над парсером сейчас, нужен совет как лучше сделать.
Сейчас делаю так.

Парсер делится на 3 части:
spider;
checker;
html page parser;


Структура БД:
таблица SITES с сайтами донорами;
таблица URLS с id сайта, ссылка, статус;
таблица DATA с данными (id сайта, ссылка, тайтл, контент);


Как планирую реализовать работу:
Спайдером иду на сайты доноров собираю ссылки, записываю в базу URLS ставлю статус не проиндексировано;
Чекером проверяю таблицу URLS по статусу, передаю ссылки по которым нужно парсить html page parser'y;
Html page parser'ом иду по ссылкам получаю контент, проверяю на валидность, проверяю на дубликаты в таблице DATA, записываю контент в таблицу DATA если всё ок, меняю статус в таблице URLS.

Спайдер и чекер думаю поставить на крон. Html page parser под каждый донор разный. Если чекер по статусу находит не проиндексированную ссылку, он смотрит какому сайту она принадлежит и запускает соответствующий Html page parser.

Как такой вариант ? С парсерами не работал, так что хз как лучше.
  • Вопрос задан
  • 1332 просмотра
Пригласить эксперта
Ответы на вопрос 3
@alexalexes
В вашей схеме еще не хватает подсистемы scheduler - планировщик заданий.
Его нужно чаще всего запускать по крону (а может он у вас будет вертеться в бесконечном цикле, а может спать в потоковом режиме выполнения).
Планировщик, на основе результатов проходов паука, парсера, ограничений на проходимых сайтах, нагрузки собственной системы, будет регулировать частоту запуска перезапуска заданий.
Желательно, чтобы задания паука и парсера были достаточно атомарны.
Паук в одну страницу постучал, записал статус получения ответа, каков контент в ответе (html или текстовое сообщение, или JSON и тд.), удалось ли ему распознать структуру, метаданные и тд.
Если, например, вернулась 404 стр, то возможно, с помощью планировщика установить правило, что можно натравить паука на url чуть позже, через час, день, неделю и тд.
По аналогии, можно фиксировать статусы работы других подсистем checker-а, парсера.
Если один из модулей застревает на 5 разе на каком-то задании, то сыпать критическую ошибку в лог и тд.

В общем, каков бы состав модулей не был, но планировщик нужен.
Ответ написан
vadi7
@vadi7
Linux adherent
Подумайте о масштабировании и возможности запуска множества экземпляров подсистем параллельно с регулированием нагрузки. Например, серверы очередей могут в этом помочь.
Ответ написан
@Paltinik Автор вопроса
Наткнулся на пост где человек делал подобное, ссылка: тык
ну я бы ещё к этому функционалу подключил мультикурл + поддержку прокси (есть отличная штука под это дело AngryCurl) на его базе я и делал свой парсер, только вместо crawler использовал DiDom.
И ещё в своём парсере настройку для разных сайтов я закидывал в отдельный php файл, при запуске парсера я задаю параметры. Например ставлю на крон задание запускать скрипт каждую минуту такой командой:
/parser.php https://toster.ru/

первым делом проверяем в скрипте работает ли сейчас скрипт с этими параметрами, если работает то ничего не делаем. Контроль работы скрипта осуществляю лочкой файла, таким способом:

$site=$argv[1];
if(!$argv[1]) {
$site = $_GET['site'];
}
flock($lock = fopen(__DIR__.'/parser/lock_files/'.md5($site),"w"),LOCK_EX|LOCK_NB) or die('ERROR: SCRIPT RUNNING...');


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

В скрипте стоит неограниченное время выполнения, даже если скрипт упадёт, крон его практически сразу же и поднимет. Так же удобно что под каждый сайт можно в кроне задать разную частоту запуска парсера.

Не знаю на сколько эффективно я сделал контроль работы скрипта отдельного экземпляра (через лочку файла) т.к. доступа к процессам например у меня нету на шаред хостинге, нашёл решение такое, попробовал = работает = меня устраивает.. может и всплывут какие то подводные камни хз, на данный момент полёт нормальный.

Как вообще такая логика, может что то надо пересмотреть ?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы