4.2.6 Переднего указателя

Передний указатель на самом деле уже частично отсортированы. Он хранится в число баррелей (мы использовали 64). Каждая бочка проводит целый ряд wordID автора. Если документ содержит слова, которые попадают в частности баррель, DocId записывается в ствол, за которым следует список wordID с hitlists, которые соответствуют этим словам. Эта схема требует немного больше места для хранения, потому что дублируется DocIds но разница очень мала для разумного количества сегментов и экономит много времени и сложности кодирования в заключительной фазе индексации сделано сортировщика. Кроме того, вместо хранения фактического wordID, мы сохраняем каждый wordID как относительная разница от минимальной wordID, которая падает в бочку wordID является дюйма Таким образом, мы можем использовать только 24 бита для wordID находится в несортированный баррелей, оставшиеся 8 бит для длины списка хитом.

4.2.7 Инвертированный индекс

Инвертированный индекс состоит из тех же баррелей переднего указателя, за исключением того, что они были обработаны сортировщика. Для каждого действительны wordID, лексикон содержит указатель в ствол, что wordID попадает. Он указывает на DocList из DocId вместе с соответствующими списками хитом. Это DocList представляет все вхождения этого слова во всех документах.

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

4.3 Сканирования Интернета

Запуск Роботы является сложной задачей. Есть хитрый производительностью и надежностью, и что еще более важно, существуют социальные вопросы. Сканирование является самой хрупкой применения, так как она включает в себя взаимодействие с сотнями тысяч веб-серверов и различные серверы имен, которые все не зависящим от системы.

В целях расширения до сотен миллионов веб-страниц, Google имеет быстрый распределенного сканирования системы. Один служит URLserver списки URL-адресов к ряду сканеров (мы обычно бегали 3). Оба URLserver и сканеры реализованы в Python. Каждый гусеничный держит примерно 300 открытых соединений одновременно. Это необходимо для получения веб-страниц на достаточно высокой скоростью. В пиковые скорости, система может сканировать более 100 веб-страниц в секунду, используя четыре сканерам. Это составляет примерно 600 тыс. в секунду данных. Основной упор производительности DNS-запросов. Каждый гусеничный поддерживает свой собственный кэш DNS так что не нужно делать поиск DNS ползать перед каждым документом. Каждый из сотен соединений может быть в ряде различных состояниях: поиск DNS, при подключении к хост, отправку запроса и получение ответа. Эти факторы делают гусеничный комплексного компонента системы. Он использует асинхронное IO управлять событиями, а количество очередей, чтобы переместить страницы получает от штата к штату.

Оказывается, что для запуска гусеничном который подключается к более полумиллиона серверов и генерирует десятки миллионов записей журнала генерирует достаточное количество электронной почты и телефонных звонков. Из-за огромного числа людей, выйдя на линию, всегда есть те, кто не знает, что искатель, потому что это первый, который они видели. Почти каждый день мы получили письмо что-то вроде: "Ничего себе, вы смотрели на много страниц из моего веб-сайта. Как вам это нравится?" Есть также некоторые люди, которые не знают о протоколе исключения роботов , и думают, что их страницы должны быть защищены от индексации заявления вроде: "Эта страница защищена авторским правом и не должны индексироваться", который, само собой разумеется, трудно для сканеров понять. Кроме того, из-за огромного объема данных, неожиданные вещи будут происходить. Например, наша система пытались просканировать онлайн-игры. Это привело к много мусора сообщения в середине их игру! Оказывается, это была легкая задача исправить. Но эта проблема не придумали, пока мы не скачали десятки миллионов страниц. В связи с огромным изменения веб-страниц и серверов, это практически невозможно проверить гусеничных, не запуская ее на большую часть интернета. Неизменно, существуют сотни неясных проблем, которые могут произойти только на одной странице из всей сети и привести к краху гусеничных, или еще хуже, привести к непредсказуемым или неправильное поведение. Системы, в которых доступ к большим частям Интернета должны быть разработаны, чтобы быть очень прочной и тщательно проверены. Так как большие сложные системы, такие как сканеры будут неизменно вызывают проблемы, там должно быть значительные ресурсы, предназначенные для чтения электронной почты и решение этих проблем по мере их появления.