4,4 Индексирования веб-

• Разбор - Любой парсер, который предназначен для работы на всей Web должен обрабатывать огромный массив возможных ошибок. Они варьируются от опечатки в HTML теги для килобайт нулей в середине тега, не-ASCII символов, HTML теги вложенные сотни глубоко, и великое множество других ошибок, что воображение бросаю вызов любому, чтобы придумать с одинаково творческих. Для достижения максимальной скорости, вместо использования YACC генерировать CFG анализатор, мы используем гибкий для создания лексического анализатора, который мы снаряжение с собственным стеком. Развивая это парсер, который работает на разумной скорости и является очень надежным участвует достаточно много работы.

• Индексирования документов в бочки - После каждого документ разобран, его шифрования в ряде баррелей. Каждое слово преобразуется в wordID помощью в памяти хэш-таблицы - лексиконе. Новые дополнения к таблице хэш лексики записываются в файл. После слов преобразуют в wordID, их вхождения в настоящем документе, переводятся в хит списки и записываются в прямом баррелей. Основная трудность с распараллеливания индексации фазы является то, что лексика должна быть общей. А не делиться с лексикой, мы взяли способ записи лог всех лишних слов, которые не были в базовой лексики, которую мы зафиксирована на уровне 14 миллионов слов. Таким образом, несколько индексаторы могут выполняться параллельно, а затем небольшой лог-файл лишних слов может быть обработан одним окончательным индексатор.

• Сортировка - В целях получения инвертированного индекса, сортировщик принимает каждый из бочки вперед и сортирует его wordID производить перевернутой бочке для заголовка и якорь ударов и полный текст инвертируется баррель. Этот процесс происходит один ствол за один раз, таким образом, требует мало временного хранения. Кроме того, мы распараллелить фазу сортировки использовать столько машин, сколько у нас есть просто запустив несколько сортировщики, которая может обрабатывать различными ковшами в то же время. Поскольку баррелей не вписываются в основной памяти, сортировщик дальнейшего подразделяет их в корзинах которые вписываются в памяти на основе wordID и DocId. Тогда сортировщик, грузы каждой корзины в память, сортирует его и записывает его содержимое в короткие перевернутой бочки и полный перевернутой бочке.

4.5 Поиск

Целью поисков является обеспечение качества результатов поиска эффективно. Многие крупные коммерческие поисковые машины, казалось, сделали большой шаг вперед с точки зрения эффективности. Таким образом, мы обращали больше внимания на качество поиска в нашем исследовании, хотя мы считаем, что наши решения масштабируемых коммерческих объемах с немного больше усилий. Оценка Google запроса процесса показано на рисунке 4.

Разобрать запрос. Преобразование слова в wordIDs. Обратиться к началу DocList в короткий ствол для каждого слова. Сканирование через doclists пока не является документом, который соответствует всем условиям поиска. Вычислить ранг этого документа для запроса. Если мы в короткие бочки и в конце любого DocList, стремятся начала DocList в полном баррель за каждое слово и перейдите к шагу 4. Если мы не в конце любого DocList перейдите к шагу 4. Сортировать документы, которые соответствуют по рангам и вернуться к верхней. Рисунок 4. Вычисление запросов Google

 

Положить предел на время отклика, как только определенное количество (в настоящее время 40 000) соответствующих документов обнаружили, поисковик автоматически переходит к шагу 8 на рисунке 4. Это означает, что, возможно, что суб-оптимальных результатов будут возвращены. Мы в настоящее время изучают другие способы решения этой проблемы. В прошлом, мы разобрались хитов по PageRank, который, казалось, улучшить ситуацию.