Как поисковые роботы отличаются от паука Wget?

[…], поэтому я использую составной ключ, чтобы убедиться, что комбинация name и group_id не может использоваться 2 раза.

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

CREATE TABLE tag (
    name varchar(50),
    group_id int,
    UNIQUE (name, group_id) );

Таким образом, вы получите СУБД, обеспечивающую для этих столбцов уникальную пару значений в каждой записи, не подразумевая, что являются ключом для поиска.

Итак, вы можете назначить любой первичный ключ, который вам нравится. Поскольку вы хотите, чтобы поле id было первичным ключом, сделайте это:

CREATE TABLE tag (
    name varchar(50),
    group_id int,
    id serial NOT NULL,
    UNIQUE (name, group_id),
    PRIMARY KEY (id) );
7
задан Léo Léopold Hertz 준영 10 May 2009 в 04:54
поделиться

4 ответа

Настоящий паук - это много работы

Написание паука для всей WWW - довольно сложная задача - вы должны позаботиться о многих «мелкие детали», такие как:

  • Каждый компьютер-паук должен получать данные от нескольких тысяч серверов параллельно, чтобы эффективно использовать пропускную способность соединения. (асинхронный ввод-вывод сокета).
  • Вам нужно несколько компьютеров, которые будут работать параллельно, чтобы охватить огромное количество информации в WWW (кластеризация; разделение работы)
  • Вы должны быть вежливы с паутиной места:
    • Уважайте файлы robots.txt.
    • Не извлекайте много информации слишком быстро: это перегружает серверы.
    • Не загружайте файлы, которые вам действительно не нужны (например, образы iso-дисков; tgz для загрузки программного обеспечения ...).
  • Вы должны иметь дело с файлами cookie / идентификаторами сеансов: многие сайты прикрепляют уникальные идентификаторы сеансов к URL-адресам для идентификации клиентских сеансов. Каждый раз, когда вы заходите на сайт, вы получаете новый идентификатор сеанса и новый виртуальный мир страниц (с тем же содержанием). Из-за таких проблем ранние поисковые системы игнорировали динамический контент. Современные поисковые системы узнали, в чем заключаются проблемы и как с ними бороться.
  • Вы должны обнаруживать и игнорировать проблемные данные: соединения, которые предоставляют, казалось бы, бесконечное количество данных, или соединения, которые слишком медленные для завершения.
  • Кроме того, следующие ссылки, вы можете проанализировать карты сайта , чтобы получить URL-адреса страниц.
  • Возможно, вы захотите оценить, какая информация важна для вас и часто изменяется, чтобы обновлять ее чаще, чем другие страницы. Примечание: паук для всей WWW получает много данных - вы платите за эту полосу пропускания. Вы можете использовать HTTP-запросы HEAD, чтобы угадать, изменилась страница или нет.
  • Помимо получения, вы хотите обработать информацию и сохранить ее. Google составляет индексы, в которых для каждого слова перечислены страницы, которые его содержат. Вам могут потребоваться отдельные компьютеры для хранения данных и инфраструктура для их подключения. Традиционные реляционные базы данных не удовлетворяют требованиям к объему данных и производительности хранения / индексации всей WWW.

Это большая работа. Но если ваша цель скромнее, чем читать весь WWW, вы можете пропустить некоторые части. Если вы просто хотите загрузить копию вики и т. Д., Переходите к спецификациям wget.

Примечание: если вы не верите, что это так много работы, вы можете прочитать, как Google повторно изобрел большую часть вычислительных колес (поверх базового ядра Linux) для создания хороших пауков. Даже если вы срежете много углов, это будет много работы.

Позвольте мне добавить еще несколько технических замечаний по трем пунктам

Параллельные соединения / асинхронная связь через сокеты

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

Лучшее решение - асинхронный ввод / вывод: обрабатывать около 1000 параллельных соединений в одном потоке, открывая сокеты в неблокирующем режиме и используя epoll или выбирая для обработки только тех соединений, которые получили данные. Начиная с ядра Linux 2.4, Linux имеет отличную поддержку масштабируемости (я также рекомендую вам изучить файлы с отображением памяти), которые постоянно улучшаются в более поздних версиях.

Примечание. Использование асинхронного ввода-вывода помогает гораздо больше, чем использование «быстрого языка»: Лучше написать процесс, управляемый epoll, для 1000 соединений, написанный на Perl, чем запускать 1000 процессов, написанных на C. Если вы все сделаете правильно, вы можете заполнить 100-мегабайтное соединение процессами, написанными на Perl.

Из исходного ответа: В Linux есть отличная поддержка масштабируемости (я также рекомендую вам изучить файлы с отображением в память), которые постоянно улучшаются в более поздних версиях.

Примечание. Использование асинхронного ввода-вывода помогает гораздо больше, чем использование «быстрого языка»: лучше написать Процесс, управляемый epoll, для 1000 соединений, написанных на Perl, чем для запуска 1000 процессов, написанных на C. Если вы все сделаете правильно, вы можете заполнить 100-мегабайтное соединение процессами, написанными на Perl.

Из исходного ответа: В Linux есть отличная поддержка масштабируемости (я также рекомендую вам изучить файлы с отображением в память), которые постоянно улучшаются в более поздних версиях.

Примечание. Использование асинхронного ввода-вывода помогает гораздо больше, чем использование «быстрого языка»: лучше написать Процесс, управляемый epoll, для 1000 соединений, написанных на Perl, чем для запуска 1000 процессов, написанных на C. Если вы все сделаете правильно, вы можете заполнить 100-мегабайтное соединение процессами, написанными на Perl.

Из исходного ответа: Если вы все сделаете правильно, вы можете насытить 100-мегабайтное соединение процессами, написанными на perl.

Из исходного ответа: Если вы все сделаете правильно, вы можете насытить 100-мегабайтное соединение процессами, написанными на perl.

Из исходного ответа: Обратной стороной этого подхода является то, что вам придется реализовать спецификацию HTTP самостоятельно в асинхронной форме (мне не известно о повторно используемой библиотеке, которая делает это). Это намного проще сделать с более простым протоколом HTTP / 1.0, чем с современным протоколом HTTP / 1.1. Вы, вероятно, в любом случае не выиграете от преимуществ HTTP / 1.1 для обычных браузеров, так что это может быть хорошим местом для экономии некоторых затрат на разработку.

Редактировать пять лет спустя: Сегодня существует множество бесплатных технологий с открытым исходным кодом, которые помогут вам в этой работе. Мне лично нравится асинхронная реализация http node.js - она ​​избавляет вас от всей работы, упомянутой в предыдущем абзаце. Конечно, сегодня также доступно множество модулей для других компонентов, которые вам нужны в вашем пауке. Однако учтите, что качество сторонних модулей может значительно отличаться. Вы должны проверить все, что используете. [Информация об устаревании:] Недавно я написал паука, используя node.js, и обнаружил, что надежность модулей npm для обработки HTML для ссылок и извлечения данных недостаточна. Для этой работы я «передал» эту обработку процессу, написанному на другом языке программирования. Но все быстро меняется, и к тому времени, когда вы прочтете этот комментарий, эта проблема, возможно, уже уйдет в прошлое ...

Разделение работы на несколько серверов

Один компьютер не успевает за пауками всей WWW. , Вам необходимо распределить свою работу по нескольким серверам и обмениваться информацией между ними. Я предлагаю назначить каждому серверу определенные «диапазоны доменных имен»: вести центральную базу данных доменных имен со ссылкой на компьютер-паук.

Извлекать URL-адреса из полученных веб-страниц в пакеты: сортировать их по их доменным именам; удалите дубликаты и отправьте их ответственному компьютеру-пауку. На этом компьютере сохраните индекс URL-адресов, которые уже получены, и получите оставшиеся URL-адреса.

Если вы сохраняете очередь URL-адресов, ожидающих загрузки на каждом компьютере-пауке, у вас не будет узких мест в производительности. Но для реализации этого достаточно много программирования.

Прочтите стандарты

Я упомянул несколько стандартов (HTTP / 1.x, Robots.txt, Cookies). Найдите время, чтобы прочитать их и реализовать. Если вы просто будете следовать примерам известных вам сайтов, вы совершите ошибки (забудете части стандарта, не относящиеся к вашим образцам) и создадите проблемы для тех сайтов, которые используют эти дополнительные функции.

Больно читать Стандартный документ HTTP / 1.1. Но все мелкие детали были добавлены к нему, потому что кому-то действительно нужна эта маленькая деталь и теперь он ее использует.

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

Больно читать Стандартный документ HTTP / 1.1. Но все мелкие детали были добавлены к нему, потому что кому-то действительно нужна эта маленькая деталь и теперь он ее использует.

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

Больно читать Стандартный документ HTTP / 1.1. Но все мелкие детали были добавлены к нему, потому что кому-то действительно нужна эта маленькая деталь и теперь он ее использует.

33
ответ дан 6 December 2019 в 05:04
поделиться

Я не уверен точно, на что ссылался оригинальный автор комментария, но я могу догадаться, что wget работает медленно как паук, поскольку он, кажется, использует только один поток выполнения (по крайней мере, тем, что вы показали).

«Реальные» пауки, такие как heritrix , используют много параллелизма и трюков для оптимизации их скорость сканирования, и в то же время они приятны веб-сайту, на котором они ползут. Обычно это означает ограничение количества посещений одного сайта со скоростью 1 в секунду (или около того) и одновременное сканирование нескольких сайтов.

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

4
ответ дан 6 December 2019 в 05:04
поделиться

К сожалению, многие из наиболее известных «настоящих» веб-пауков имеют закрытый исходный код и действительно закрытый двоичный код. Однако в wget отсутствует ряд основных методов:

  • Параллелизм; ты' мы никогда не сможем идти в ногу со всей сетью без одновременного получения нескольких страниц
  • Приоритезация; некоторые страницы важнее для пауков, чем другие
  • Ограничение скорости; вас быстро забанят, если вы продолжите вытаскивать страницы так быстро, как только можете
  • Сохранение не в локальную файловую систему; Сеть достаточно велика, чтобы не поместиться в едином дереве каталогов
  • Периодическая перепроверка страниц без перезапуска всего процесса; на практике, с настоящим пауком вы захотите часто перепроверять «важные» страницы на предмет обновлений, в то время как менее интересные страницы могут храниться месяцами.

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

2
ответ дан 6 December 2019 в 05:04
поделиться

Я не собираюсь вдаваться в подробности о том, как использовать паук в Интернете, я думаю, что комментарий wget касается сканирования одного веб-сайта, что по-прежнему является серьезной проблемой.

  • Как паук, вам нужно выяснить, когда остановиться, а не переходить к рекурсивному сканированию только потому, что URL-адрес изменился, например, date = 1/1/1900 на 1/2/1900 и так далее.
  • Еще сложнее разобраться Перезапись URL (я понятия не имею, что и как Google или любой другой справляется с этим). Довольно сложно проползти достаточно, но не слишком много. И как можно автоматически распознать перезапись URL с некоторыми случайными параметрами и случайными изменениями в содержании?
  • Вам необходимо проанализировать Flash / Javascript хотя бы до некоторого уровня
  • Вам нужно рассмотреть некоторые безумные проблемы HTTP, такие как базовый тег . Даже разобрать HTML непросто, учитывая, что большинство веб-сайтов не являются XHTML, а браузеры настолько гибки в синтаксисе.

Я не знаю, сколько из них реализовано или учтено в wget, но вы можете взглянуть на httrack, чтобы понять проблемы этого задача.

Я бы хотел дать вам несколько примеров кода, но это большие задачи, и достойный паук будет около 5000 loc без сторонних библиотек .

+ Некоторые из них уже были объяснены @ yaakov-belch, поэтому я не собираюсь вводить их снова

1
ответ дан 6 December 2019 в 05:04
поделиться
Другие вопросы по тегам:

Похожие вопросы: