Стратегия для сканирования/индексации часто обновляемых веб-страниц?

Ответ 1

Как я знаю, в литературе есть три разных фактора:

• Изменить частоту (как обновляется содержимое веб-страницы)
  • [1]: формализовать понятие "свежести" данных и использовать poisson process для моделирования изменения веб-страниц.
  • [2]: Оценка частоты
  • [3]: больше политики планирования
• Релевантность (сколько влияет на содержимое обновленной страницы на результаты поиска)
  • [4]: ​​Максимизируйте качество работы пользователей для тех, кто запрашивает поисковую систему.
  • [5]: Определите (почти) оптимальные частоты сканирования
• Информационная долговечность (время жизни фрагментов контента, которые появляются и исчезают с веб-страниц с течением времени, что показано, что они не сильно коррелируют с частотой изменения)
  • [6]: различать эфемерный и постоянный контент

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

Изменить. Я кратко расскажу о частотной оценке, упомянутой в [2], чтобы вы начали. Исходя из этого, вы должны быть в состоянии выяснить, что может быть полезно вам в других документах.:)

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

Шаг 1. Перейдите в Раздел 6.4 - Приложение к веб-искателю. Здесь Cho перечисляет 3 подхода для оценки частоты изменения веб-страницы.

• Единая политика: искатель пересматривает все страницы с частотой один раз в неделю.
• Наивная политика: в первые 5 посещений искатель посещает каждую страницу с частотой один раз в неделю. После 5 посещений сканер оценивает частоты изменения страниц с использованием наивной оценки (раздел 4.1)
• Наша политика: искатель использует предложенную оценку (раздел 4.2) для оценки частоты изменения.

Шаг 2. Наивная политика. Перейдите к разделу 4. Вы будете читать:

Интуитивно мы можем использовать X/T (X: количество обнаруженных изменений, T: период мониторинга) в качестве предполагаемой частоты изменений.

Подпоследовательность раздела 4.1 просто доказала, что эта оценка смещена ⁷ in-consistant ⁸ и эффективный ⁹.

Шаг 3. Улучшенная оценка. Перейдите в раздел 4.2. Новая оценка выглядит следующим образом:

где \bar X - n - X (количество обращений, которые элемент не изменил), а n - количество обращений. Поэтому просто возьмите эту формулу и оцените частоту изменения. Вам не нужно понимать доказательство в остальной части подраздела.

Шаг 4. В разделе 4.3 и разделе 5 есть несколько трюков и полезных методов, которые могут вам помочь. В разделе 4.3 обсуждалось, как бороться с нерегулярными интервалами. Раздел 5 решил вопрос: когда доступна дата последней модификации элемента, как мы можем использовать его для оценки частоты изменения? Предложенная оценка с использованием даты последней модификации показана ниже:

Объяснение приведенного выше алгоритма после фиг .10 в статье очень ясно.

Шаг 5. Теперь, если у вас есть интерес, вы можете посмотреть настройку эксперимента и результаты в разделе 6.

Так что это. Если вы теперь чувствуете себя более уверенно, продолжайте и попробуйте бумагу для свежести в [1].

Ссылки

[1] http://oak.cs.ucla.edu/~cho/papers/cho-tods03.pdf

[2] http://oak.cs.ucla.edu/~cho/papers/cho-freq.pdf

[3] http://hal.inria.fr/docs/00/07/33/72/PDF/RR-3317.pdf

[4] http://wwwconference.org/proceedings/www2005/docs/p401.pdf

[5] http://www.columbia.edu/~js1353/pubs/wolf-www02.pdf

[6] http://infolab.stanford.edu/~olston/publications/www08.pdf

Ответ 2

Алгоритмы Google в основном закрыты, они не скажут, как они это делают.

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

Это может быть реализовано путем хранения URL-адресов и связей между ними. Если вы сканируете и не выбрасываете какие-либо ссылки, график на сайт будет расти. Вычисляя для каждого node для каждого сайта (нормализованные) входы и выходы, вы можете определить, какая страница наиболее интересна для повторного сканирования чаще.

Ответ 3

Попытайтесь сохранить некоторые данные на главной странице на частоте обновления. Обнаружение обновления легко просто сохранить ETag/Last-Modified и отправить Заголовки If-None-Match/If-Update-Since с вашим следующим запросом. Сохранение рабочей частоты обновления (скажем, за последние 24 обхода) позволяет достаточно точно определить частоту обновления лицевых страниц.

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

Ответ 4

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

Проще говоря, XML-Sitemap - обычно называемый Sitemap, с capital S - список страниц вашего сайта. Создание и предоставление файла Sitemap помогает убедиться, что Google знает обо всех страниц на вашем сайте, включая URL-адреса, которые не могут быть Обычный процесс сканирования Google. Кроме того, вы также можете использовать Sitemaps для предоставления Google метаданных о конкретных типах контента на вашем сайте, включая видео, изображения, мобильный и новости.

Google использует это специально, чтобы помочь им обходить новостные сайты. Вы можете найти более подробную информацию здесь в файлах Sitemap и информации о новостях Google и файлах Sitemap здесь.

Обычно файл Sitemaps.xml можно найти на веб-сайте robots.txt. Например, TechCrunch Sitemap просто

http://techcrunch.com/sitemap.xml

который превращает эту проблему в регулярный анализ xml. Если вы не можете найти его в файле robots.txt, вы всегда можете связаться с веб-мастером и посмотреть, предоставят ли он его вам.

ОБНОВЛЕНИЕ 1 24 октября 2012 10:45,

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

Еще одна вещь, которую мы делаем, - это отслеживать несколько "индексных страниц" для изменений в данном домене. принимать например, в "Нью-Йорк Таймс". Мы создаем одну индексную страницу для домена верхнего уровня по адресу:

http://www.nytimes.com/

Если вы посмотрите на страницу, вы можете заметить дополнительные области, такие как World, US, Politics, Business и т.д. Мы создаем дополнительные индексные страницы для всех. У бизнеса есть дополнительные вложенные индексные страницы, такие как Global, DealBook, Markets, Economy и т.д. Нередко URL-адрес имеет 20 страниц с индексом. Если мы заметим какие-либо дополнительные URL-адреса, добавленные в индекс, мы добавим их в очередь для обхода.

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

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