Два Года С Сканерами (Веб-Майнинг)

Пауки бывают разные - большинство ползет по сети, кто-то парсит торренты, кто-то - fido/ed2k и прочие интересные вещи.

Суть одна – предоставить необходимую ему информацию в удобной для заказчика форме.

К сожалению, С.

Шульга ( привратник ) переоценили эту отрасль — добыча информации — дело популярное, но тем не менее технологии ИИ там мало используются, и до автоматических советников они далеки.

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

Стоимость проектов можно посмотреть в базах данных фрилансеров; они обычно смешны.

В основном разовые проекты.

Забанены по IP или по скорости запроса.

Групповые сканеры Похожий проект я реализовал для cenugids.lv. При этом многие (50+) краулеров используют одну и ту же кодовую базу, а точнее, это один краулер с интерфейсами для нескольких источников (для cenugids.lv это были магазины).

В основном используется для сбора информации из подобных источников (форумы, магазины).

Поведенческие сканеры Это предполагает маскировку бота под человека.

Заказчик обычно требует определенной стратегии поведения — собирать информацию только во время обеденного перерыва, 2 страницы в минуту, в течение рабочей недели 3-4 дня в неделю, например.

В технических характеристиках может быть даже предусмотрен перерыв на «отпуск» и смена «версии браузера» в соответствии с релизами.

Кэширующие сканеры Технически самое громоздкое решение, используемое для парсинга чего-то размером с eBay. Обычно он состоит из нескольких частей – одна вытаскивает из исходника места, которые стоит посетить (например, для магазина это категории и страницы).

Этот процесс происходит довольно редко, потому что.

эта информация достаточно постоянна.

Далее через случайные промежутки времени паук ходит по «интересным местам» и собирает ссылки на данные (например, товары).

Эти ссылки снова обрабатываются со случайными задержками и заносятся в базу данных.

Этот процесс не периодический, он непрерывный.

Параллельно с ним проверяются старые ссылки — т.е.

допустим, раз в 5 минут мы выбираем из базы 10 закешированных товаров и проверяем, живы ли они и не изменилась ли цена и атрибуты.

В этом технически наиболее громоздком решении заказчик получает данные не о снимке источника в какой-то момент, а более-менее актуальную информацию из базы данных самого краулера.

Естественно, с датой последнего обновления.

Количество запросов равно количеству страниц – что может быть заметнее? Обычно это достигается с помощью кэширующего искателя и расписаний сканирования.

Естественно, вы не можете конкурировать за трафик на целевой сайт. Бан по IP Самое простое, с чем можно столкнуться, это в начале войны с админом.

Первый выход – использовать прокси.

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

При разовых заказах это, конечно, отпадает. Хотя на реализацию такой инфраструктуры вместе с интерфейсами у меня ушла неделя.

Второй вариант — Тор.

Отличная P2P-сеть анонимизации с идеальным интерфейсом, где можно указать желаемую страну и точку выхода.

Скорость, в принципе, не так важна для решений кэширования.

Производительность неплохая - у меня есть один клиент, который до сих пор банит все точки выхода, правил iptables уже больше 9000 (на момент написания 9873), но результата все равно нет. Регистрация/авторизация Тривиальная проблема, которую можно решить по мере накопления опыта.

Авторизовался/установил куки/вошел/разобрал.

Капчи тоже ломаются.

Уходя в бесконечность Парсер может сойти с ума, если сайт каким-то образом генерирует бесконечное количество ссылок.

Например, добавление osCsid (OsCommerce SessionID)/PHPSESSID каждый раз может заставить сканер считать ссылку новой.

Я видел магазины, которые обычно генерировали псевдослучайные ссылки при обновлениях (таким образом, для поисковых систем один товар размещался на 50+ страницах с разными URL).

Наконец, баги в исходнике тоже могут генерировать неограниченное количество ссылок (например, магазин показывал следующую ссылку и +5 страниц от текущей даже где-то на 7000+ пустых страниц).

Кодировки Как ни странно, самый большой пробел — это кодировка.

cp1251? HTML-объекты? ПЯТЬ типов «пробелов» в таблице Юникода? Что, если клиент в конце запросит XML, а один неправильный символ полностью уничтожит simplexml? Мне, наверное, даже лень указывать на весь список ошибок кодировки.

Скажу сразу — при постобработке данных в моем краулере обработка кодирования занимает почти ровно половину.

512 мегабайт на сканер — это нормально при использовании mbstring, не говоря уже о дампе памяти просто при попытке создать тег +1 в XML. При обработке небольших сайтов это очевидно, но когда из исходника за раз выкачивается 50+ мегабайт. Поэтому, в основном, серьезные PHP-игроки уходят. Мой выбор — Питон.

Помимо XPath есть библиотеки для ed2k, kazzaa, торрентов, любых баз данных, идеальная обработка строк, скорость, стабильность и ООП.

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

, ты будешь винить себя.