В своем исходном Google Paper Сергей Брин и Лоуренс Пейдж объяснили, что они не сохранили HTML-контент просканированных веб-страниц загружался непосредственно в репозиторий, поскольку они хотели сэкономить место на жестком диске. Вот этот абзац:
4.2.2 Репозиторий
Репозиторий содержит полный HTML-код каждой веб-страницы. Каждая страница сжимается с помощью zlib (см. RFC1950). Выбор метода сжатия — это компромисс между скоростью и степенью сжатия. Мы предпочли скорость zlib значительному улучшению сжатия, предлагаемому bzip. Коэффициент сжатия bzip был примерно 4:1 в репозитории по сравнению со сжатием zlib 3:1. В репозитории документы хранятся один за другим и имеют префиксы с идентификатором документа, длиной и URL-адресом, как показано на рис. 2. Репозиторий не требует использования других структур данных для доступа к нему. Это помогает обеспечить согласованность данных и значительно упрощает разработку; мы можем перестроить все остальные структуры данных только из репозитория и файла, в котором перечислены ошибки сканера.
Очевидно, они использовали алгоритм сжатия (в их случае zlib), чтобы сначала сжать данные, а затем сохранить их в хранилище. Сжатые данные на самом деле представляют собой двоичные данные, которые можно сохранить непосредственно в файловой системе. Метаданные (заголовок страницы, размер страницы, ссылки и т. д.) могут быть сохранены в БД со ссылкой на двоичный файл в файловой системе. Звучит как хорошая идея, но если мы говорим о поисковой системе, которая сканирует миллиарды страниц, то такой способ сохранения данных может иметь некоторые недостатки.
Что было бы лучшим подходом сегодня? Если вы хотите создать крупномасштабную поисковую систему, которая будет обрабатывать контент миллионов веб-сайтов, где и как вы будете сохранять HTML-контент просканированных страниц?
