Stormcrawler, индекс состояния и повторное сканирование - PullRequest
Новая
       21

Stormcrawler, индекс состояния и повторное сканирование

0 голосов
/ 20 марта 2019

Итак, у нас успешно работает stormcrawler, и основной индекс в настоящее время содержит чуть более 2 миллионов URL-адресов с наших различных веб-сайтов, внесенных в него. Это работает хорошо, однако SC, кажется, не переиндексирует URL-адреса, которые он индексировал ранее, и я пытаюсь выяснить, почему.

Я попытался найти подробную информацию о том, как SC выбирает следующий URL из индекса состояния. Кажется, он не выбирает самое старое nextFetchDate, потому что у нас есть документы в таблице состояния с nextFetchDate от 3 февраля 2019 года.

Просматривая логи, я вижу записи вроде: 

2019-03-20 09:21:17.221 c.d.s.e.p.AggregationSpout Thread-29-spout-executor[17 17] [INFO] [spout #5]  Populating buffer with nextFetchDate <= 2019-03-20T09:21:17-04:00

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

Выполняя запрос к документам в индексе состояния с параметром nextFetchDate старше, чем сегодня, я вижу, что 1,4 миллиона из 2 миллионов URL-адресов имеют значение nextFetchDate в прошлом.

Было бы неплохо, если бы сканер мог получить URL с старейшим nextFetchDate и начать сканирование там.

Как мне поставить в очередь те URL, которые были пропущены при следующей дате их получения?

1 Ответ

0 голосов
/ 21 марта 2019

По умолчанию носики ES получают самые старые записи. То, что показывают журналы, не противоречит этому: оно запрашивает записи с датой nextFetchDate ниже 20 марта для шарда # 5.

В качестве значения nextFetchDate следует понимать «не ползти до даты D», через трещины ничего не падает.

Выполняя запрос к документам в индексе состояния с параметром nextFetchDate старше, чем сегодня, я вижу, что 1,4 миллиона из 2 миллионов URL-адресов имеют в прошлом значение nextFetchDate.

Да, это нормально.

Было бы неплохо, если бы сканер мог получить URL с самой старой датой nextFetchDate и начать сканирование там.

это то, что он делает

Как мне поставить в очередь те URL, которые были пропущены при следующей дате их получения?

они не пропущены. Они должны быть выбраны носиками

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

Проверьте журналы на предмет тех конкретных URL-адресов, которые должны быть извлечены первыми: отправляются ли они носиками вообще? Для этого вам может потребоваться включить журналы в DEBUG.

...