Google搜尋原理
阿新 • • 發佈：2019-02-11
這篇文章中，我們介紹了google，它是一個大型的搜尋引擎（of
a large-scale search
engine）的原型，搜尋引擎在超文字中應用廣泛。Google的設計能夠高效地抓網頁並建立索引，它的查詢結果比其它現有系統都高明。這個原型的全文和超連接的資料庫至少包含24'000'000個網頁。我們可以從http://google.stanford.edu/下載。
設計搜尋引擎是一項富有挑戰性的工作。搜尋引擎為上億個網頁建立索引，其中包含大量迥然不同的詞彙。而且每天要回答成千上萬個查詢。在網路中，儘管大型搜尋引擎非常重要，但是學術界卻很少研究它。此外由於技術的快速發展和網頁的大量增加，現在建立一個搜尋引擎和三年前完全不同。
本文詳細介紹了我們的大型搜尋引擎，據我們所知，在公開發表的論文中，這是第一篇描述地如此詳細。除了把傳統資料搜尋技術應用到如此大量級網頁中所遇到的問題，還有許多新的技術挑戰，包括應用超文字中的附加資訊改進搜尋結果。
本文將解決這個問題，描述如何運用超文字中的附加資訊，建立一個大型實用系統。任何人都可以在網上隨意釋出資訊，如何有效地處理這些無組織的超文字集合，也是本文要關注的問題。
關鍵詞 World Wide Web，搜尋引擎，資訊檢索，PageRank,
Google 1 緒論 Web
給資訊檢索帶來了新的挑戰。Web上的資訊量快速增長，同時不斷有毫無經驗的新使用者來體驗Web這門藝術。人們喜歡用超級連結來網上衝浪，通常都以象
Yahoo這樣重要的網頁或搜尋引擎開始。大家認為List(目錄)有效地包含了大家感興趣的主題，但是它具有主觀性，建立和維護的代價高，升級慢，不能包括所有深奧的主題。基於關鍵詞的自動搜尋引擎通常返回太多的低質量的匹配。使問題更遭的是，一些廣告為了贏得人們的關注想方設法誤導自動搜尋引擎。
我們建立了一個大型搜尋引擎解決了現有系統中的很多問題。應用超文字結構，大大提高了查詢質量。我們的系統命名為google，取名自googol的通俗拼法，即10的100次方，這和我們的目標建立一個大型搜尋引擎不謀而合。
1.1 網路搜尋引擎-升級換代（scaling up）：1994-2000
搜尋引擎技術不得不快速升級（scale
dramatically）跟上成倍增長的web數量。1994年，第一個Web搜尋引擎，World
Wide Web
Worm(WWWW)可以檢索到110，000個網頁和Web的檔案。到1994年11月，頂級的搜尋引擎聲稱可以檢索到2'000'000
（WebCrawler）至100'000'000個網路檔案（來自 Search Engine
Watch）。可以預見到2000年，可檢索到的網頁將超過1'000'000'000。同時，搜尋引擎的訪問量也會以驚人的速度增長。在1997年的三四月份，World
Wide Web Worm 平均每天收到1500個查詢。
在1997年11月，Altavista
聲稱它每天要處理大約20'000'000個查詢。隨著網路使用者的增長，到2000年，自動搜尋引擎每天將處理上億個查詢。我們系統的設計目標要解決許多問題，包括質量和可升級性，引入升級搜尋引擎技術（scaling
search engine
technology），把它升級到如此大量的資料上。
1.2 Google：跟上Web的步伐（Scaling with the
Web）建立一個能夠和當今web規模相適應的搜尋引擎會面臨許多挑戰。抓網頁技術必須足夠快，才能跟上網頁變化的速度（keep
them up to
date）。儲存索引和文件的空間必須足夠大。索引系統必須能夠有效地處理上千億的資料。處理查詢必須快，達到每秒能處理成百上千個查詢（hundreds
to thousands per
second.）。隨著Web的不斷增長，這些任務變得越來越艱鉅。然而硬體的執行效率和成本也在快速增長，可以部分抵消這些困難。
還有幾個值得注意的因素，如磁碟的尋道時間（disk
seek time），作業系統的效率（operating system
robustness）。在設計Google的過程中，我們既考慮了Web的增長速度，又考慮了技術的更新。Google的設計能夠很好的升級處理海量資料集。它能夠有效地利用儲存空間來儲存索引。優化的資料結構能夠快速有效地存取（參考4.2節）。進一步，我們希望，相對於所抓取的文字檔案和HTML網頁的數量而言，儲存和建立索引的代價儘可能的小（參考附錄B）。對於象Google這樣的集中式系統，採取這些措施得到了令人滿意的系統可升級性（scaling
properties）。
1. 3 設計目標
1.3.1
提高搜尋質量我們的主要目標是提高Web搜尋引擎的質量。1994年，有人認為建立全搜尋索引（a
complete search
index）可以使查詢任何資料都變得容易。根據Best of the
Web 1994 -- Navigators
，"最好的導航服務可以使在Web上搜索任何資訊都很容易（當時所有的資料都可以被登入）"。然而1997年的Web就迥然不同。近來搜尋引擎的使用者已經證實索引的完整性不是評價搜尋質量的唯一標準。使用者感興趣的搜尋結果往往湮沒在"垃圾結果Junk
result"中。實際上，到1997年11月為止，四大商業搜尋引擎中只有一個能夠找到它自己（搜尋自己名字時返回的前十個結果中有它自己）。導致這一問題的主要原因是文件的索引數目增加了好幾個數量級，但是使用者能夠看的文件數卻沒有增加。使用者仍然只希望看前面幾十個搜尋結果。因此，當集合增大時，我們就需要工具使結果精確（在返回的前幾十個結果中，有關文件的數量）。由於是從成千上萬個有點相關的文件中選出幾十個，實際上，相關的概念就是指最好的文件。高精確非常重要，甚至以響應（系統能夠返回的有關文件的總數）為代價。令人高興的是利用超文字連結提供的資訊有助於改進搜尋和其它應用。尤其是連結結構和連結文字，為相關性的判斷和高質量的過濾提供了大量的資訊。Google既利用了連結結構又用到了anchor文字（見2.1和2.2
節）。
1.3.2
搜尋引擎的學術研究隨著時間的流逝，除了發展迅速，Web越來越商業化。1993年，只有1.5%的Web服務是來自.com域名。到1997
年，超過了60%。同時，搜尋引擎從學術領域走進商業。到現在大多數搜尋引擎被公司所有，很少技公開術細節。這就導致搜尋引擎技術很大程度上仍然是暗箱操作，並傾向做廣告（見附錄A）。Google的主要目標是推動學術領域在此方面的發展，和對它的瞭解。另一個設計目標是給大家一個實用的系統。應用對我們來說非常重要，因為現代網路系統中存在大量的有用資料（us
because we think some of the most interesting research will involve
leveraging the vast amount of usage data that is available from modern
web
systems）。例如，每天有幾千萬個研究。然而，得到這些資料卻非常困難，主要因為它們沒有商業價值。我們最後的設計目標是建立一個體繫結構能夠支援新的關於海量Web資料的研究。為了支援新研究，Google以壓縮的形式儲存了實際所抓到的文件。設計google的目標之一就是要建立一個環境使其他研究者能夠很快進入這個領域，處理海量Web資料，得到滿意的結果，而通過其它方法卻很難得到結果。系統在短時間內被建立起來，已經有幾篇論文用到了
Google建的資料庫，更多的在起步中。我們的另一個目標是建立一個宇宙空間實驗室似的環境，在這裡研究者甚至學生都可以對我們的海量Web資料設計或做一些實驗。
2. 系統特點
Google搜尋引擎有兩個重要特點，有助於得到高精度的搜尋結果。
第一點，應用Web的連結結構計算每個網頁的Rank值，稱為PageRank，將在98頁詳細描述它。
第二點，Google利用超連結改進搜尋結果。
2.1 PageRank:給網頁排序
Web的引用（連結）圖是重要的資源，卻被當今的搜尋引擎很大程度上忽視了。我們建立了一個包含518'000'000個超連結的圖，它是一個具有重要意義的樣本。這些圖能夠快速地計算網頁的PageRank值，它是一個客觀的標準，較好的符合人們心目中對一個網頁重要程度的評價，建立的基礎是通過引用判斷重要性。因此在web中，PageRank能夠優化關鍵詞查詢的結果。對於大多數的主題，在網頁標題查詢中用PageRank優化簡單文字匹配，我們得到了令人驚歎的結果（從google.stanford.edu可以得到演示）。對於Google主系統中的全文搜尋，PageRank也幫了不少忙。
2.1.1 計算PageRank
文獻檢索中的引用理論用到Web中，引用網頁的連結數，一定程度上反映了該網頁的重要性和質量。PageRank發展了這種思想，網頁間的連結是不平等的。
PageRank定義如下:
我們假設T1...Tn指向網頁A（例如，被引用）。引數d是制動因子，使結果在0，1之間。通常d等於0.85。在下一節將詳細介紹d。C（A）定義為網頁
A指向其它網頁的連結數，網頁A的PageRank值由下式給出：
PR(A) = (1-d) + d (PR(T1)/C(T1) + ... + PR(Tn)/C(Tn))
注意PageRank的形式，分佈到各個網頁中，因此所有網頁的PageRank和是1。
PageRank或PR（A）可以用簡單的迭代演算法計算，相應規格化Web連結矩陣的主特徵向量。中等規模的網站計算26'000'000網頁的
PageRank值要花費幾小時。還有一些技術細節超出了本文論述的範圍。
2.1.2 直覺判斷
PageRank被看作使用者行為的模型。我們假設網上衝浪是隨機的，不斷點選連結，從不返回，最終煩了，另外隨機選一個網頁重新開始衝浪。隨機訪問一個網頁的可能性就是它的PageRank值。制動因子d是隨機訪問一個網頁煩了的可能性，隨機另選一個網頁。對單個網頁或一組網頁，一個重要的變數加入到制動因子d中。這允許個人可以故意地誤導系統，以得到較高的PageRank值。我們還有其它的PageRank演算法，見98頁。
另外的直覺判斷是一個網頁有很多網頁指向它，或者一些PageRank值高的網頁指向它，則這個網頁很重要。直覺地，在Web中，一個網頁被很多網頁引用，那麼這個網頁值得一看。一個網頁被象Yahoo這樣重要的主頁引用即使一次，也值得一看。如果一個網頁的質量不高，或者是死連結，象Yahoo這樣的主頁不會鏈向它。PageRank處理了這兩方面因素，並通過網路連結遞迴地傳遞。
2.2 連結描述文字（Anchor
Text）我們的搜尋引擎對連結文字進行了特殊的處理。大多數搜尋引擎把連結文字和它所鏈向的網頁（the
page that the link is
on）聯絡起來。另外，把它和連結所指向的網頁聯絡起來。這有幾點好處。
第一，通常連結描述文字比網頁本身更精確地描述該網頁。
第二，連結描述文字可能鏈向的文件不能被文字搜尋引擎檢索到，例如影象，程式和資料庫。有可能使返回的網頁不能被抓到。注意哪些抓不到的網頁將會帶來一些問題。在返回給使用者前檢測不了它們的有效性。這種情況搜尋引擎可能返回一個根本不存在的網頁，但是有超級連結指向它。然而這種結果可以被挑出來的，所以此類的問題很少發生。連結描述文字是對被鏈向網頁的宣傳，這個思想被用在World
Wide Web Worm
中，主要因為它有助於搜尋非文字資訊，能夠用少量的已下載文件擴大搜索範圍。我們大量應用連結描述文字，因為它有助於提高搜尋結果的質量。有效地利用連結描述文字技術上存在一些困難，因為必須處理大量的資料。現在我們能抓到24'000'000個網頁，已經檢索到259'000'000多個連結描述文字。
2.3
其它特點除了PageRank和應用連結描述文字外，Google還有一些其它特點。
第一,所有hit都有位置資訊，所以它可以在搜尋中廣泛應用鄰近性（proximity）。
第二，Google跟蹤一些視覺化外表細節，例如字號。黑體大號字比其它文字更重要。
第三，知識庫儲存了原始的全文html網頁。
3 有關工作 Web檢索研究的歷史簡短。World Wide Web
Worm（）是最早的搜尋引擎之一。後來出現了一些用於學術研究的搜尋引擎，現在它們中的大多數被上市公司擁有。與Web的增長和搜尋引擎的重要性相比，有關當今搜尋引擎技術的優秀論文相當少。根據Michael
Mauldin（Lycos Inc的首席科學家）)
，"各種各樣的服務（包括Lycos）非常關注這些資料庫的細節。"雖然在搜尋引擎的某些特點上做了大量工作。具有代表性的工作有，對現有商業搜尋引擎的結果進行傳遞，或建立小型的個性化的搜尋引擎。最後有關資訊檢索系統的研究很多，尤其在有組織機構集合（well
controlled
collections）方面。在下面兩節，我們將討論在資訊檢索系統中的哪些領域需要改進以便更好的工作在Web上。
3.1
資訊檢索資訊檢索系統誕生在幾年前，並發展迅速。然而大多數資訊檢索系統研究的物件是小規模的單一的有組織結構的集合，例如科學論文集，或相關主題的新聞故事。實際上，資訊檢索的主要基準，the
Text Retrieval
Conference（），用小規模的、有組織結構的集合作為它們的基準。
大型文集基準只有20GB，相比之下，我們抓到的24000000個網頁佔147GB。在TREC上工作良好的系統，在Web上卻不一定產生好的結果。例如，標準向量空間模型企圖返回和查詢請求最相近的文件，把查詢請求和文件都看作由出現在它們中的詞彙組成的向量。在Web環境下，這種策略常常返回非常短的文件，這些文件往往是查詢詞再加幾個字。例如，查詢"Bill
Clinton"，返回的網頁只包含"Bill Clinton
Sucks"，這是我們從一個主要搜尋引擎中看到的。網路上有些爭議，使用者應該更準確地表達他們想查詢什麼，在他們的查詢請求中用更多的詞。我們強烈反對這種觀點。如果使用者提出象"Bill
Clinton"這樣的查詢請求，應該得到理想的查詢結果，因為這個主題有許多高質量的資訊。象所給的例子，我們認為資訊檢索標準需要發展，以便有效地處理Web資料。
3.2 有組織結構的集合（Well Controlled
Collections）與Web的不同點
Web是完全無組織的異構的大量文件的集合。Web中的文件無論內在資訊還是隱含資訊都存在大量的異構性。例如，文件內部就用了不同的語言（既有人類語言又有程序），詞彙（email地址，連結，郵政編碼，電話號碼，產品號），型別（文字，HTML，PDF，影象，聲音），有些甚至是機器建立的檔案（log檔案，或數據庫的輸出）。可以從文件中推斷出來，但並不包含在文件中的資訊稱為隱含資訊。隱含資訊包括來源的信譽，更新頻率，質量，訪問量和引用。不但隱含資訊的可能來源各種各樣，而且被檢測的資訊也大不相同，相差可達好幾個數量級。例如，一個重要主頁的使用量，象Yahoo
每天瀏覽數達到上百萬次，於此相比無名的歷史文章可能十年才被訪問一次。很明顯，搜尋引擎對這兩類資訊的處理是不同的。
Web與有組織結構集合之間的另外一個明顯區別是，事實上，向Web上傳資訊沒有任何限制。靈活利用這點可以釋出任何對搜尋引擎影響重大的資訊，使路由阻塞，加上為牟利故意操縱搜尋引擎，這些已經成為一個嚴重的問題。這些問題還沒有被傳統的封閉的資訊檢索系統所提出來。它關心的是元資料的努力，這在Web
搜尋引擎中卻不適用，因為網頁中的任何文字都不會向用戶聲稱企圖操縱搜尋引擎。甚至有些公司為牟利專門操縱搜尋引擎。
4 系統分析（System
Anatomy）首先，我們提供高水平的有關體系結構的討論。然後，詳細描述重要的資料結構。最後，主要應用：抓網頁，索引，搜尋將被嚴格地檢查。
Figure 1. High Level Google Architecture
4.1Google體系結構概述這一節，我們將看看整個系統是如何工作的（give
a high
level），見圖1。本節不討論應用和資料結構，在後幾節中討論。為了效率大部分Google是用c或c++實現的，既可以在Solaris也可以在
Linux上執行。
Google系統中，抓網頁（下載網頁）是由幾個分散式crawlers完成的。一個URL伺服器負責向crawlers提供URL列表。抓來的網頁交給儲存服務器storeserver。然後，由儲存伺服器壓縮網頁並把它們存到知識庫repository中。每個網頁都有一個ID，稱作docID，當新
URL從網頁中分析出時，就被分配一個docID。由索引器和排序器負責建立索引index
function。索引器從知識庫中讀取文件，對其解壓縮和分析。每個文件被轉換成一組詞的出現情況，稱作命中hits。Hits紀錄了詞，詞在文件中的位置，最接近的字號，大小寫。索引器把這些hits分配到一組桶barrel中，產生經過部分排序後的索引。索引器的另一個重要功能是分析網頁中所有的連結，將有關的重要資訊存在連結描述anchors檔案中。該檔案包含了足夠的資訊，可以用來判斷每個連結鏈出鏈入節點的資訊，和連結文字。
URL分解器resolver閱讀連結描述anchors檔案，並把相對URL轉換成絕對URL，再轉換成docID。為連結描述文字編制索引，並與它所指向的docID關聯起來。同時建立由docID對組成的連結資料庫。用於計算所有文件的PageRank值。用docID分類後的barrels，送給排序器sorter，再根據wordID進行分類，建立反向索引inverted
index。這個操作要恰到好處，以便幾乎不需要暫存空間。排序器還給出docID和偏移量列表，建立反向索引。一個叫DumpLexicon的程式把這個列表和由索引器產生的字典結合在一起，建立一個新的字典，供搜尋器使用。這個搜尋器就是利用一個Web伺服器，使用由DumpLexicon所生成的字典，利用上述反向索引以及頁面等級PageRank來回答使用者的提問。
4.2主要資料結構經過優化的Google資料結構，能夠用較小的代價抓取大量文件，建立索引和查詢。雖然近幾年CPU和輸入輸出速率迅速提高。磁碟尋道仍然需要10ms。任何時候Google系統的設計都儘可能地避免磁碟尋道。這對資料結構的設計影響很大。
4.2.1
大檔案大檔案BigFiles是指虛擬檔案生成的多檔案系統，用長度是64位的整型資料定址。多檔案系統之間的空間分配是自動完成的。
BigFiles包也處理已分配和未分配檔案描述符。由於操縱系統不能滿足我們的需要，BigFiles也支援基本的壓縮選項。
4.2.2 知識庫 Figure 2. Repository Data Structure
知識庫包含每個網頁的全部HTML。每個網頁用zlib（見RFC1950）壓縮。壓縮技術的選擇既要考慮速度又要考慮壓縮率。我們選擇zlib的速度而不是壓縮率很高的bzip。知識庫用bzip的壓縮率接近4：1。而用zlib的壓縮率是3：1。文件一個挨著一個的儲存在知識庫中，字首是docID，長度，URL，見圖2。訪問知識庫不需要其它的資料結構。這有助於資料一致性和升級。用其它資料結構重構系統，我們只需要修改知識庫和crawler錯誤列表檔案。
4.2.3
檔案索引檔案索引儲存了有關文件的一些資訊。索引以docID的順序排列，定寬ISAM（Index
sequential access
mode）。每條記錄包括當前檔案狀態，一個指向知識庫的指標，檔案校驗和，各種統計表。如果一個文件已經被抓到，指標指向docinfo檔案，該檔案的寬度可變，包含了URL和標題。否則指標指向包含這個URL的URL列表。這種設計考慮到簡潔的資料結構，以及在查詢中只需要一個磁碟尋道時間就能夠訪問一條記錄。還有一個檔案用於把URL轉換成docID。它是URL校驗和與相應docID的列表，按校驗和排序。要想知道某個URL的docID，需要計算URL的校驗和，然後在校驗和檔案中執行二進位制查詢，找到它的docID。通過對這個檔案進行合併，可以把一批URL轉換成對應的docID。URL分析器用這項技術把URL轉換成docID。這種成批更新的模式是至關重要的，否則每個連結都需要一次查詢，假如用一塊磁碟，322'000'000個連結的資料集合將花費一個多月的時間。
4.2.4
詞典詞典有幾種不同的形式。和以前系統的重要不同是，詞典對記憶體的要求可以在合理的價格內。現在實現的系統，一臺256M記憶體的機器就可以把詞典裝入到記憶體中。現在的詞典包含14000000詞彙（雖然一些很少用的詞彙沒有加入到詞典中）。它執行分兩部分-詞彙表（用null分隔的連續串）和指標的雜湊表。不同的函式，詞彙表有一些輔助資訊，這超出了本文論述的範圍。
4.2.5 hit list hit
list是一篇文件中所出現的詞的列表，包括位置，字號，大小寫。Hit
list佔很大空間，用在正向和反向索引中。因此，它的表示形式越有效越好。我們考慮了幾種方案來編碼位置，字號，大小寫-簡單編碼（3個整型數），緊湊編碼（支援優化分配位元位），哈夫曼編碼。Hit的詳細資訊見圖3。我們的緊湊編碼每個hit用2位元組。有兩種型別hit，特殊hit和普通hit。特殊
hit包含URL，標題，連結描述文字，meta
tag。普通hit包含其它每件事。它包括大小寫特徵位，字號，12位元用於描述詞在文件中的位置（所有超過4095的位置標記為4096）。字號採用相對於文檔的其它部分的相對大小表示，佔3位元(實際只用7個值，因為111標誌是特殊hit)。特殊hit由大小寫特徵位，字號位為7表示它是特殊
hit，用4位元表示特殊hit的型別，8位元表示位置。對於anchor
hit八位元位置位分出4位元用來表示在anchor中的位置，4位元用於表明anchor出現的雜湊表hash
of the
docID。短語查詢是有限的，對某些詞沒有足夠多的anchor。我們希望更新anchor
hit的儲存方式，以便解決地址位和docIDhash域位數不足的問題。
因為搜尋時，你不會因為文件的字號比別的文件大而特殊對待它，所以採用相對字號。
hit表的長度儲存在hit前。為節省空間hit表長度，在正向索引中和wordID結合在一起，在反向索引中和docID結合儲存。這就限制它相應地只佔8到5位元（用些技巧，可以從wordID中借8bit）如果大於這些位元所能表示的長度，用溢位碼填充，其後兩位元組是真正的長度。
Figure 3. Forward and Reverse Indexes and the Lexicon
4.2.6
正向索引實際上，正向索引已經部分排序。它被存在一定數量的barrel中（我們用64個barrels）。每個barrel裝著一定範圍的
wordID。如果一篇文件中的詞落到某個barrel，它的docID將被記錄到這個barrel中，緊跟著那些詞（文件中所有的詞彙，還是落入該
barrel中的詞彙）對應的hitlist。這種模式需要稍多些的儲存空間，因為一個docID被用多次，但是它節省了桶數和時間，最後排序器進行索引時降低編碼的複雜度。更進一步的措施是，我們不是儲存docID本身，而是儲存相對於該桶最小的docID的差。用這種方法，未排序的barrel的
docID只需24位，省下8位記錄hitlist長。
4.2.7
反向索引除了反向索引由sorter加工處理之外，它和正向索引包含相同的桶。對每個有效的docID，字典包含一個指向該詞所在桶的指標。它指向由docID和它的相應hitlist組成的doclish，這個doclist代表了所有包含該詞的文件。
doclist中docID的順序是一個重要的問題。最簡單的解決辦法是用doclish排序。這種方法合併多個詞時很快。另一個可選方案是用文件中該詞出現的次數排序。這種方法回答單詞查詢，所用時間微不足道。當多詞查詢時幾乎是從頭開始。並且當用其它Rank演算法改進索引時，非常困難。我們綜合了這兩種方法，建立兩組反向索引barrel，一組barrels的hitlist只包含標題和anchor
hit，另一組barrel包含全部的hitlist。我們首先查第一組索引桶，看有沒有匹配的項，然後查較大的那組桶。
4.3
抓網頁執行網路爬行機器人是一項具有挑戰性的任務。執行的效能和可靠性甚至更重要，還有一些社會焦點。網路爬行是一項非常薄弱的應用，它需要成百上千的web服務器和各種域名伺服器的參與，這些伺服器不是我們系統所能控制的。為了覆蓋幾十億的網頁，Google擁有快速的分散式網路爬行系統。一個
URL伺服器給若干個網路爬行機器人（我們採用3個）提供URL列表。URL伺服器和網路爬行機器人都是用Python實現的。每個網路爬行機器人可以同時開啟300個連結。抓取網頁必須足夠快。最快時，用4個網路爬行機器人每秒可以爬行100個網頁。速率達每秒600K。執行的重點是找DNS。每個網路爬行機器人有它自己的DNS
cache，所以它不必每個網頁都查DNS。每一百個連線都有幾種不同的狀態：查DNS，連線主機，傳送請求，接收回答。這些因素使網路爬行機器人成為系統比較複雜的部分。它用非同步IO處理事件，若干請求佇列從一個網站到另一個網站不停的抓取網頁。執行一個連結到500多萬臺伺服器的網頁爬行機器人，產生
1千多萬登陸口，導致了大量的Email和電話。因為網民眾多，總有些人不知道網路爬行機器人是何物，這是他們看到的第一個網路爬行機器人。幾乎每天我們都會收到這樣的Email"哦，你從我們的網站看了太多的網頁，你想幹什麼？"還有一些人不知道網路搜尋機器人避免協議（the
robots exclusion
protocol），以為他們的網頁上寫著"版權所有，勿被索引"的字樣就會被保護不被索引，不必說，這樣的話很難被web
crawler理解。因為資料量如此之大，還會遇到一些意想不到的事情。例如，我們的系統曾經企圖抓一個線上遊戲，結果抓到了遊戲中的大量垃圾資訊。解決這個問題很簡單。但是我們下載了幾千萬網頁後才發現了這個問題。因為網頁和伺服器的種類繁多，實際上不在大部分Internet上執行它就測試一個網頁爬行機器人是不可能。總是有幾百個隱含的問題發生在整個web的一個網頁上，導致網路爬行機器人崩潰，或者更糟，導致不可預測的不正確的行為。能夠訪問大部分Internet的系統必須精力充沛並精心測試過。由於象crawler這樣大型複雜的系統總是產生這樣那樣的問題，因此花費一些資源讀這些
Email，當問題發生時解決它，是有必要的。
4.4
Web索引分析-任何執行在整個Web上的分析器必須能夠處理可能包含錯誤的大型集合。範圍從HTML標記到標記之間幾K位元組的0，非ASCII字元，幾百層HTML標記的巢狀，各種各樣令人難以想象的錯誤。為了獲得最大的速度，我們沒有采用YACC產生上下文無關文法CFG分析器，而是採用靈活的方式產生詞彙分析器，它自己配有堆疊。分析器的改進大大提高了執行速度，它的精力如此充沛完成了大量工作。把文件裝入barrel建立索引-分析完一篇文件，之後把該文件裝入barrel中，用記憶體中的hash表-字典，每個詞彙被轉換成一個wordID。當hash表字典中加入新的項時，笨拙地存入檔案。一旦詞彙被轉換成wordID，它們在當前文件的出現就轉換成hitlist，被寫進正向barrel。索引階段並行的主要困難是字典需要共享。
我們採用的方法是，基本字典中有140萬個固定詞彙，不在基本字典中的詞彙寫入日誌，而不是共享字典。這種方法多個索引器可以並行工作，最後一個索引器只需處理一個較小的額外詞彙日誌。排序-為了建立反向索引，排序器讀取每個正向barrel，以wordID排序，建立只有標題anchor
hi
t的反向索引barrel和全文反向索引barrel。這個過程一次只處理一個barrel，所以只需要少量暫存空間。排序階段也是並行的，我們簡單地同時執行儘可能多的排序器，不同的排序器處理不同的桶。由於barrel不適合裝入主存，排序器進一步依據wordID和docID把它分成若干籃子，以便適合裝入主存。然後排序器把每個籃子裝入主存進行排序，並把它的內容寫回到短反向barrel和全文反向barrel。
4.5
搜尋搜尋的目標是提供有效的高質量的搜尋結果。多數大型商業搜尋引擎好像在效率方面花費了很大力氣。因此我們的研究以搜尋質量為重點，相信我們的解決方案也可以用到那些商業系統中。
Google查詢評價過程見圖4。
1. 分析查詢。
2. 把詞彙轉換成wordID。
3. 在短barrel中查詢每個詞彙doclist的開頭。
4. 掃描doclist直到找到一篇匹配所有關鍵詞的文件
5. 計算該文件的rank
6.
如果我們在短barrel，並且在所有doclist的末尾，開始從全文barrel的doclist的開頭查詢每個詞，goto
第四步
7. 如果不在任何doclist的結尾，返回第四步。
8. 根據rank排序匹配文件，返回前k個。圖4
Google查詢評價在有限的響應時間內，一旦找到一定數量的匹配文件，搜尋引擎自動執行步驟8。這意味著，返回的結果是子優化的。我們現在研究其它方法來解決這個問題。過去根據PageRank排序hit，看來能夠改進這種狀況。
4.5.1 Ranking系統
Google比典型搜尋引擎儲存了更多的web資訊。每個hitlish包括位置，字號，大小寫。另外，我們還考慮了連結描述文字。Rank綜合所有這些資訊是困難的。ranking函式設計依據是沒有某個因素對rank影響重大。首先，考慮最簡單的情況-單個詞查詢。為了單個詞查詢中一個文件的
rank，Goole在文件的hitlist中查詢該詞。Google認為每個hit是幾種不同型別（標題，連結描述文字anchor，URL，普通大字號文字，普通小字號文字，......）之一，每種有它自己的型別權重。型別權重建立了一個型別索引向量。Google計算hitlist中每種hit的數量。然後每個hit數轉換成count-weight。Count-weight開始隨hit數線性增加，很快逐漸停止，以至於hit數與此不相關。我們計算
count-weight向量和type-weight向量的標量積作為文件的IR值。最後IR值結合PageRank作為文件的最後rank
對於多詞查詢，更復雜些。現在，多詞hitlist必須同時掃描，以便關鍵詞出現在同一文件中的權重比分別出現時高。相鄰詞的hit一起匹配。對每個匹配
hit
的集合計算相鄰度。相鄰度基於hit在文件中的距離，分成10個不同的bin值，範圍從短語匹配到根本不相關。不僅計算每類hit數，而且要計算每種型別的相鄰度，每個型別相似度對，有一個型別相鄰度權type-prox-weight。Count轉換成count-weight，計算count-
weight type-proc-weight的標量積作為IR值。應用某種debug
mode所有這些數和矩陣與查詢結果一起顯示出來。這些顯示有助於改進rank系統。
4.5.2 反饋
rank函式有很多引數象type-weight和type-prox-weight。指明這些引數的正確值有點黑色藝術black
art。為此，我們的搜尋引擎有一個使用者反饋機制。值得信任的使用者可以隨意地評價返回的結果。儲存反饋。然後，當修改rank函式時，對比以前搜尋的
rank，我們可以看到修改帶來的的影響。雖然不是十全十美，但是它給出了一些思路，當rank函式改變時對搜尋結果的影響。
5執行和結果搜尋結果的質量是搜尋引擎最重要的度量標準。完全使用者評價體系超出了本文的論述範圍，對於大多數搜尋，我們的經驗說明Google的搜尋結果比那些主要的商業搜尋引擎好。作為一個應用PageRank，連結描述文字，相鄰度的例子，圖4給出了Google搜尋bill
Clinton的結果。它說明了Google的一些特點。伺服器對結果進行聚類。這對過濾結果集合相當有幫助。這個查詢，相當一部分結果來自
whitehouse.gov域，這正是我們所需要的。現在大多數商業搜尋引擎不會返回任何來自whitehouse.gov的結果，這是相當不對的。注意第一個搜尋結果沒有標題。因為它不是被抓到的。Google是根據連結描述文字決定它是一個好的查詢結果。同樣地，第五個結果是一個Email地址，當然是不可能抓到的。也是連結描述文字的結果。所有這些結果質量都很高，最後檢查沒有死連結。因為它們中的大部分PageRank值較高。PageRank
百分比用紅色線條表示。沒有結果只含Bill沒有Clinton或只含Clinton沒有Bill。因為詞出現的相近性非常重要。當然搜尋引擎質量的真實測試包含廣泛的使用者學習或結果分析，此處篇幅有限，請讀者自己去體驗Google，http://google.stanford.edu/。
5.1
儲存需求除了搜尋質量，Google的設計可以隨著Web規模的增大而有效地增大成本。一方面有效地利用儲存空間。表1列出了一些統計數字的明細表和Google儲存的需求。由於壓縮技術的應用知識庫只需53GB的儲存空間。是所有要儲存資料的三分之一。按當今磁碟價格，知識庫相對於有用的資料來說比較便宜。搜尋引擎需要的所有資料的儲存空間大約55GB。大多數查詢請求只需要短反向索引。檔案索引應用先進的編碼和壓縮技術，一個高質量的搜尋引擎可以執行在7GB的新PC。
5.2
系統執行搜尋引擎抓網頁和建立索引的效率非常重要。Google的主要操作是抓網頁，索引，排序。很難測試抓全部網頁需要多少時間，因為磁碟滿了，域名伺服器崩潰，或者其它問題導致系統停止。總的來說，大約需要9天時間下載26000000網頁（包括錯誤）。然而，一旦系統執行順利，速度非常快，下載最後11000000網頁只需要63小時，平均每天4000000網頁，每秒48.5個網頁。索引器和網路爬行機器人同步執行。索引器比網路爬行機器人快。因為我們花費了大量時間優化索引器，使它不是瓶頸。這些優化包括批量更新文件索引，本地磁碟資料結構的安排。索引器每秒處理54個網頁。排序器完全並行，用4臺機器，排序的整個過程大概需要24小時。
5.3
搜尋執行改進搜尋執行不是我們研究的重點。當前版本的Google可以在1到10秒間回答查詢請求。時間大部分花費在NFS磁碟IO上（由於磁碟普遍比機器慢）。進一步說，Google沒有做任何優化，例如查詢緩衝區，常用詞彙子索引，和其它常用的優化技術。我們傾向於通過分散式，硬體，軟體，和演算法的改進來提高Google的速度。我們的目標是每秒能處理幾百個請求。表2有幾個現在版本Google響應查詢時間的例子。它們說明IO緩衝區對再次搜尋速度的影響。
6 結論
Google設計成可伸縮的搜尋引擎。主要目標是在快速發展的World
Wide
Web上提供高質量的搜尋結果。Google應用了一些技術改進搜尋質量包括PageRank，連結描述文字，相鄰資訊。進一步說，Google是一個收集網頁，建立索引，執行搜尋請求的完整的體系結構。
6.1
未來的工作大型Web搜尋引擎是個複雜的系統，還有很多事情要做。我們直接的目標是提高搜尋效率，覆蓋大約100000000個網頁。一些簡單的改進提高了效率包括請求緩衝區，巧妙地分配磁碟空間，子索引。另一個需要研究的領域是更新。我們必須有一個巧妙的演算法來決定哪些舊網頁需要重新抓取，哪些新網頁需要被抓取。這個目標已經由實現了。受需求驅動，用代理cache建立搜尋資料庫是一個有前途的研究領域。我們計劃加一些簡單的已經被商業搜尋引擎支援的特徵，例如布林算術符號，否定，填充。然而另外一些應用剛剛開始探索，例如相關反饋，聚類（Google現在支援簡單的基於主機名的聚類）。我們還計劃支援使用者上下文（象使用者地址），結果摘要。我們正在擴大連結結構和連結文字的應用。簡單的實驗證明，通過增加使用者主頁的權重或書籤，PageRank可以個性化。對於連結文字，我們正在試驗用連結周圍的文字加入到連結文字。Web搜尋引擎提供了豐富的研究課題。如此之多以至於我們不能在此一一列舉，因此在不久的將來，我們希望所做的工作不止本節提到的。
6.2
高質量搜尋當今Web搜尋引擎使用者所面臨的最大問題是搜尋結果的質量。結果常常是好笑的，並且超出使用者的眼界，他們常常灰心喪氣浪費了寶貴的時間。例如，一個最流行的商業搜尋引擎搜尋"Bill
Clillton"的結果是the Bill Clinton Joke of the Day: April 14,
1997。Google的設計目標是隨著Web的快速發展提供高質量的搜尋結果，容易找到資訊。為此，Google大量應用超文字資訊包括連結結構和連結文字。Google還用到了相鄰性和字號資訊。評價搜尋引擎是困難的，我們主觀地發現Google的搜尋質量比當今商業搜尋引擎高。通過PageRank分析連結結構使
Google能夠評價網頁的質量。用連結文字描述連結所指向的網頁有助於搜尋引擎返回相關的結果（某種程度上提高了質量）。最後，利用相鄰性資訊大大提高了很多搜尋的相關性。
6.3
可升級的體系結構除了搜尋質量，Google設計成可升級的。空間和時間必須高效，處理整個Web時固定的幾個因素非常重要。實現Google系統，CPU、訪存、記憶體容量、磁碟尋道時間、磁碟吞吐量、磁碟容量、網路IO都是瓶頸。在一些操作中，已經改進的Google克服了一些瓶頸。
Google的主要資料結構能夠有效利用儲存空間。進一步，網頁爬行，索引，排序已經足夠建立大部分web索引，共24000000個網頁，用時不到一星期。我們希望能在一個月內建立100000000網頁的索引。
6.4 研究工具
Google不僅是高質量的搜尋引擎，它還是研究工具。Google蒐集的資料已經用在許多其它論文中，提交給學術會議和許多其它方式。最近的研究，例如，提出了Web查詢的侷限性，不需要網路就可以回答。這說明Google不僅是重要的研究工具，而且必不可少，應用廣泛。我們希望Google是全世界研究者的資源，帶動搜尋引擎技術的更新換代。
7致謝 Scott Hassan and Alan
Steremberg評價了Google的改進。他們的才智無可替代，作者由衷地感謝他們。感謝Hector
Garcia-Molina, Rajeev Motwani, Jeff Ullman, and Terry
Winograd和全部WebBase開發組的支援和富有深刻見解的討論。最後感謝IBM，Intel，Sun和投資者的慷慨支援，為我們提供裝置。這裡所描述的研究是Stanford綜合數字圖書館計劃的一部分，由國家科學自然基金支援，合作協議號IRI-9411306。DARPA
，NASA，Interva研究，Stanford數字圖書館計劃的工業合作伙伴也為這項合作協議提供了資金。參考文獻
?
Google的設計目標是可升級到10億網頁。我們的磁碟和機器大概能處理這麼多網頁。系統各個部分耗費的總時間是並行的和線性的。包括網頁爬行機器人，索引器和排序器。擴充套件後我們認為大多數資料結構執行良好。然而10億網頁接近所有常用作業系統的極限（我們目前執行在Solaris和Linux上）。包括主存地址，開放檔案描述符的數量，網路socket和頻寬，以及其它因素。我們認為當網頁數量大大超過10億網頁時，會大大增加系統複雜性。
9.2集中式索引體系的可升級性隨著計算機效能的提高，海量文字索引的成本比較公平。當然頻寬需求高的其它應用如視訊，越來越普遍。但是，與多媒體例如視訊相比，文字產品的成本低，因此文字仍然普遍。
圖2 Google系統的工作流程圖
(注：原圖來自Sergey Brin and Lawrence Page, The Anatomy of a
Large-Scale Hypertextual. Web Search Engine,
1998.http://www-db.stanford.edu/%7Ebackrub/Google.html)
①
Google使用高速的分散式爬行器(Crawler)系統中的漫遊遍歷器(Googlebot)定時地遍歷網頁，將遍歷到的網頁送到儲存伺服器(Store
Server)中。
②
儲存伺服器使用zlib格式壓縮軟體將這些網頁進行無失真壓縮處理後存入資料庫Repository中。Repository獲得了每個網頁的完全
Html程式碼後，對其壓縮後的網頁及URL進行分析，記錄下網頁長度、URL、URL長度和網頁內容，並賦予每個網頁一個文件號(docID)，以便當系統出現故障的時候，可以及時完整地進行網頁的資料恢復。
③
索引器(Indexer)從Repository中讀取資料，以後做以下四步工作：
④
(a)將讀取的資料解壓縮後進行分析，它將網頁中每個有意義的詞進行統計後，轉化為關鍵詞(wordID)的若干索引項(Hits)，生成索引項列表，該列表包括關鍵詞、關鍵詞的位置、關鍵詞的大小和大小寫狀態等。索引項列表被存入到資料桶(Barrels)中，並生成以文件號(docID)部分排序的順排檔索引。
索引項根據其重要程度分為兩種：當索引項中的關鍵詞出現在URL、標題、錨文字(Anchor
Text)和標籤中時，表示該索引項比較重要，稱為特殊索引項(Fancy
Hits)；其餘情況則稱為普通索引項(Plain
Hits)。在系統中每個Hit用兩個位元組(byte)儲存結構表示：特殊索引項用1位(bit)表示大小寫，用二進位制程式碼111(佔3位)表示是特殊索引項，其餘12位有4位表示特殊索引項的型別(即hit是出現在URL、標題、連結結點還是標籤中)，剩下8位表示hit在網頁中的具體位置；普通索引項是用1位表示大小寫，3位表示字型大小，其餘12位表示在網頁中的具體位置。
順排檔索引和Hit的儲存結構如圖3所示。
圖3 順排檔索引和Hit的儲存結構
值得注意的是，當特殊索引項來自Anchor
Text時，特殊索引項用來表示位置的資訊（8位）將分為兩部分：4位表示Anchor
Text出現的具體位置，另4位則用來與表示Anchor
Text所連結網頁的docID相連線，這個docID是由URL
Resolver經過轉化存入順排檔索引的。
(b)索引器除了對網頁中有意義的詞進行分析外，還分析網頁的所有超文字連結，將其Anchor
Text、URL指向等關鍵資訊存入到Anchor文件庫中。
(c)索引器生成一個索引詞表(Lexicon)，它包括兩個部分：關鍵詞的列表和指標列表，用於倒排檔文件相連線(如圖3所示)。
(d)索引器還將分析過的網頁編排成一個與Repository相連線的文件索引(Document
Index)，並記錄下網頁的URL和標題，以便可以準確查找出在Repository中儲存的原網頁內容。而且把沒有分析的網頁傳給URL
Server，以便在下一次工作流程中進行索引分析。
⑤ URL分析器（URL
Resolver）讀取Anchor文件中的資訊，然後做⑥中的工作。
⑥ (a)將其錨文字(Anchor
Text)所指向的URL轉換成網頁的docID；(b)將該docID與原網頁的docID形成"連結對"，存入Link資料庫中；(c)將
Anchor Text指向的網頁的docID與順排檔特殊索引項Anchor
Hits相連線。
⑦
資料庫Link記錄了網頁的連結關係，用來計算網頁的PageRank值。
⑧ 文件索引(Document
Index)把沒有進行索引分析的網頁傳遞給URL Server，URL
Server則向Crawler提供待遍歷的URL，這樣，這些未被索引的網頁在下一次工作流程中將被索引分析。
⑨
排序器（Sorter）對資料桶(Barrels)的順排檔索引重新進行排序，生成以關鍵詞(wordID)為索引的倒排檔索引。倒排檔索引結構如圖4所示：
圖4 倒排檔索引結構
⑩
將生成的倒排檔索引與先前由索引器產生的索引詞表(Lexicon)相連線產生一個新的索引詞表供搜尋器(Searcher)使用。搜尋器的功能是由網頁伺服器實現的，根據新產生的索引詞表結合上述的文件索引(Document
Index)和Link資料庫計算的網頁PageRank值來匹配檢索。
在執行檢索時，Google通常遵循以下步驟（以下所指的是單個檢索詞的情況）：
(1)將檢索詞轉化成相應的wordID；
(2)利用Lexicon，檢索出包含該wordID的網頁的docID；
(3)根據與Lexicon相連的倒排檔索引，分析各網頁中的相關索引項的情況，計算各網頁和檢索詞的匹配程度，必要時呼叫順排檔索引；
(4)根據各網頁的匹配程度，結合根據Link產生的相應網頁的PageRank情況，對檢索結果進行排序；
(5)呼叫Document
Index中的docID及其相應的URL，將排序結果生成檢索結果的最終列表，提供給檢索使用者。
使用者檢索包含多個檢索詞的情況與以上單個檢索詞的情況類似：先做單個檢索詞的檢索，然後根據檢索式中檢索符號的要求進行必要的布林操作或其他操作。
a large-scale search
engine）的原型，搜尋引擎在超文字中應用廣泛。Google的設計能夠高效地抓網頁並建立索引，它的查詢結果比其它現有系統都高明。這個原型的全文和超連接的資料庫至少包含24'000'000個網頁。我們可以從http://google.stanford.edu/下載。
設計搜尋引擎是一項富有挑戰性的工作。搜尋引擎為上億個網頁建立索引，其中包含大量迥然不同的詞彙。而且每天要回答成千上萬個查詢。在網路中，儘管大型搜尋引擎非常重要，但是學術界卻很少研究它。此外由於技術的快速發展和網頁的大量增加，現在建立一個搜尋引擎和三年前完全不同。
本文詳細介紹了我們的大型搜尋引擎，據我們所知，在公開發表的論文中，這是第一篇描述地如此詳細。除了把傳統資料搜尋技術應用到如此大量級網頁中所遇到的問題，還有許多新的技術挑戰，包括應用超文字中的附加資訊改進搜尋結果。
本文將解決這個問題，描述如何運用超文字中的附加資訊，建立一個大型實用系統。任何人都可以在網上隨意釋出資訊，如何有效地處理這些無組織的超文字集合，也是本文要關注的問題。
關鍵詞 World Wide Web，搜尋引擎，資訊檢索，PageRank,
Google 1 緒論 Web
給資訊檢索帶來了新的挑戰。Web上的資訊量快速增長，同時不斷有毫無經驗的新使用者來體驗Web這門藝術。人們喜歡用超級連結來網上衝浪，通常都以象
Yahoo這樣重要的網頁或搜尋引擎開始。大家認為List(目錄)有效地包含了大家感興趣的主題，但是它具有主觀性，建立和維護的代價高，升級慢，不能包括所有深奧的主題。基於關鍵詞的自動搜尋引擎通常返回太多的低質量的匹配。使問題更遭的是，一些廣告為了贏得人們的關注想方設法誤導自動搜尋引擎。
我們建立了一個大型搜尋引擎解決了現有系統中的很多問題。應用超文字結構，大大提高了查詢質量。我們的系統命名為google，取名自googol的通俗拼法，即10的100次方，這和我們的目標建立一個大型搜尋引擎不謀而合。
1.1 網路搜尋引擎-升級換代（scaling up）：1994-2000
搜尋引擎技術不得不快速升級（scale
dramatically）跟上成倍增長的web數量。1994年，第一個Web搜尋引擎，World
Wide Web
Worm(WWWW)可以檢索到110，000個網頁和Web的檔案。到1994年11月，頂級的搜尋引擎聲稱可以檢索到2'000'000
（WebCrawler）至100'000'000個網路檔案（來自 Search Engine
Watch）。可以預見到2000年，可檢索到的網頁將超過1'000'000'000。同時，搜尋引擎的訪問量也會以驚人的速度增長。在1997年的三四月份，World
Wide Web Worm 平均每天收到1500個查詢。
在1997年11月，Altavista
聲稱它每天要處理大約20'000'000個查詢。隨著網路使用者的增長，到2000年，自動搜尋引擎每天將處理上億個查詢。我們系統的設計目標要解決許多問題，包括質量和可升級性，引入升級搜尋引擎技術（scaling
search engine
technology），把它升級到如此大量的資料上。
1.2 Google：跟上Web的步伐（Scaling with the
Web）建立一個能夠和當今web規模相適應的搜尋引擎會面臨許多挑戰。抓網頁技術必須足夠快，才能跟上網頁變化的速度（keep
them up to
date）。儲存索引和文件的空間必須足夠大。索引系統必須能夠有效地處理上千億的資料。處理查詢必須快，達到每秒能處理成百上千個查詢（hundreds
to thousands per
second.）。隨著Web的不斷增長，這些任務變得越來越艱鉅。然而硬體的執行效率和成本也在快速增長，可以部分抵消這些困難。
還有幾個值得注意的因素，如磁碟的尋道時間（disk
seek time），作業系統的效率（operating system
robustness）。在設計Google的過程中，我們既考慮了Web的增長速度，又考慮了技術的更新。Google的設計能夠很好的升級處理海量資料集。它能夠有效地利用儲存空間來儲存索引。優化的資料結構能夠快速有效地存取（參考4.2節）。進一步，我們希望，相對於所抓取的文字檔案和HTML網頁的數量而言，儲存和建立索引的代價儘可能的小（參考附錄B）。對於象Google這樣的集中式系統，採取這些措施得到了令人滿意的系統可升級性（scaling
properties）。
1. 3 設計目標
1.3.1
提高搜尋質量我們的主要目標是提高Web搜尋引擎的質量。1994年，有人認為建立全搜尋索引（a
complete search
index）可以使查詢任何資料都變得容易。根據Best of the
Web 1994 -- Navigators
，"最好的導航服務可以使在Web上搜索任何資訊都很容易（當時所有的資料都可以被登入）"。然而1997年的Web就迥然不同。近來搜尋引擎的使用者已經證實索引的完整性不是評價搜尋質量的唯一標準。使用者感興趣的搜尋結果往往湮沒在"垃圾結果Junk
result"中。實際上，到1997年11月為止，四大商業搜尋引擎中只有一個能夠找到它自己（搜尋自己名字時返回的前十個結果中有它自己）。導致這一問題的主要原因是文件的索引數目增加了好幾個數量級，但是使用者能夠看的文件數卻沒有增加。使用者仍然只希望看前面幾十個搜尋結果。因此，當集合增大時，我們就需要工具使結果精確（在返回的前幾十個結果中，有關文件的數量）。由於是從成千上萬個有點相關的文件中選出幾十個，實際上，相關的概念就是指最好的文件。高精確非常重要，甚至以響應（系統能夠返回的有關文件的總數）為代價。令人高興的是利用超文字連結提供的資訊有助於改進搜尋和其它應用。尤其是連結結構和連結文字，為相關性的判斷和高質量的過濾提供了大量的資訊。Google既利用了連結結構又用到了anchor文字（見2.1和2.2
節）。
1.3.2
搜尋引擎的學術研究隨著時間的流逝，除了發展迅速，Web越來越商業化。1993年，只有1.5%的Web服務是來自.com域名。到1997
年，超過了60%。同時，搜尋引擎從學術領域走進商業。到現在大多數搜尋引擎被公司所有，很少技公開術細節。這就導致搜尋引擎技術很大程度上仍然是暗箱操作，並傾向做廣告（見附錄A）。Google的主要目標是推動學術領域在此方面的發展，和對它的瞭解。另一個設計目標是給大家一個實用的系統。應用對我們來說非常重要，因為現代網路系統中存在大量的有用資料（us
because we think some of the most interesting research will involve
leveraging the vast amount of usage data that is available from modern
web
systems）。例如，每天有幾千萬個研究。然而，得到這些資料卻非常困難，主要因為它們沒有商業價值。我們最後的設計目標是建立一個體繫結構能夠支援新的關於海量Web資料的研究。為了支援新研究，Google以壓縮的形式儲存了實際所抓到的文件。設計google的目標之一就是要建立一個環境使其他研究者能夠很快進入這個領域，處理海量Web資料，得到滿意的結果，而通過其它方法卻很難得到結果。系統在短時間內被建立起來，已經有幾篇論文用到了
Google建的資料庫，更多的在起步中。我們的另一個目標是建立一個宇宙空間實驗室似的環境，在這裡研究者甚至學生都可以對我們的海量Web資料設計或做一些實驗。
2. 系統特點
Google搜尋引擎有兩個重要特點，有助於得到高精度的搜尋結果。
第一點，應用Web的連結結構計算每個網頁的Rank值，稱為PageRank，將在98頁詳細描述它。
第二點，Google利用超連結改進搜尋結果。
2.1 PageRank:給網頁排序
Web的引用（連結）圖是重要的資源，卻被當今的搜尋引擎很大程度上忽視了。我們建立了一個包含518'000'000個超連結的圖，它是一個具有重要意義的樣本。這些圖能夠快速地計算網頁的PageRank值，它是一個客觀的標準，較好的符合人們心目中對一個網頁重要程度的評價，建立的基礎是通過引用判斷重要性。因此在web中，PageRank能夠優化關鍵詞查詢的結果。對於大多數的主題，在網頁標題查詢中用PageRank優化簡單文字匹配，我們得到了令人驚歎的結果（從google.stanford.edu可以得到演示）。對於Google主系統中的全文搜尋，PageRank也幫了不少忙。
2.1.1 計算PageRank
文獻檢索中的引用理論用到Web中，引用網頁的連結數，一定程度上反映了該網頁的重要性和質量。PageRank發展了這種思想，網頁間的連結是不平等的。
PageRank定義如下:
我們假設T1...Tn指向網頁A（例如，被引用）。引數d是制動因子，使結果在0，1之間。通常d等於0.85。在下一節將詳細介紹d。C（A）定義為網頁
A指向其它網頁的連結數，網頁A的PageRank值由下式給出：
PR(A) = (1-d) + d (PR(T1)/C(T1) + ... + PR(Tn)/C(Tn))
注意PageRank的形式，分佈到各個網頁中，因此所有網頁的PageRank和是1。
PageRank或PR（A）可以用簡單的迭代演算法計算，相應規格化Web連結矩陣的主特徵向量。中等規模的網站計算26'000'000網頁的
PageRank值要花費幾小時。還有一些技術細節超出了本文論述的範圍。
2.1.2 直覺判斷
PageRank被看作使用者行為的模型。我們假設網上衝浪是隨機的，不斷點選連結，從不返回，最終煩了，另外隨機選一個網頁重新開始衝浪。隨機訪問一個網頁的可能性就是它的PageRank值。制動因子d是隨機訪問一個網頁煩了的可能性，隨機另選一個網頁。對單個網頁或一組網頁，一個重要的變數加入到制動因子d中。這允許個人可以故意地誤導系統，以得到較高的PageRank值。我們還有其它的PageRank演算法，見98頁。
另外的直覺判斷是一個網頁有很多網頁指向它，或者一些PageRank值高的網頁指向它，則這個網頁很重要。直覺地，在Web中，一個網頁被很多網頁引用，那麼這個網頁值得一看。一個網頁被象Yahoo這樣重要的主頁引用即使一次，也值得一看。如果一個網頁的質量不高，或者是死連結，象Yahoo這樣的主頁不會鏈向它。PageRank處理了這兩方面因素，並通過網路連結遞迴地傳遞。
2.2 連結描述文字（Anchor
Text）我們的搜尋引擎對連結文字進行了特殊的處理。大多數搜尋引擎把連結文字和它所鏈向的網頁（the
page that the link is
on）聯絡起來。另外，把它和連結所指向的網頁聯絡起來。這有幾點好處。
第一，通常連結描述文字比網頁本身更精確地描述該網頁。
第二，連結描述文字可能鏈向的文件不能被文字搜尋引擎檢索到，例如影象，程式和資料庫。有可能使返回的網頁不能被抓到。注意哪些抓不到的網頁將會帶來一些問題。在返回給使用者前檢測不了它們的有效性。這種情況搜尋引擎可能返回一個根本不存在的網頁，但是有超級連結指向它。然而這種結果可以被挑出來的，所以此類的問題很少發生。連結描述文字是對被鏈向網頁的宣傳，這個思想被用在World
Wide Web Worm
中，主要因為它有助於搜尋非文字資訊，能夠用少量的已下載文件擴大搜索範圍。我們大量應用連結描述文字，因為它有助於提高搜尋結果的質量。有效地利用連結描述文字技術上存在一些困難，因為必須處理大量的資料。現在我們能抓到24'000'000個網頁，已經檢索到259'000'000多個連結描述文字。
2.3
其它特點除了PageRank和應用連結描述文字外，Google還有一些其它特點。
第一,所有hit都有位置資訊，所以它可以在搜尋中廣泛應用鄰近性（proximity）。
第二，Google跟蹤一些視覺化外表細節，例如字號。黑體大號字比其它文字更重要。
第三，知識庫儲存了原始的全文html網頁。
3 有關工作 Web檢索研究的歷史簡短。World Wide Web
Worm（）是最早的搜尋引擎之一。後來出現了一些用於學術研究的搜尋引擎，現在它們中的大多數被上市公司擁有。與Web的增長和搜尋引擎的重要性相比，有關當今搜尋引擎技術的優秀論文相當少。根據Michael
Mauldin（Lycos Inc的首席科學家）)
，"各種各樣的服務（包括Lycos）非常關注這些資料庫的細節。"雖然在搜尋引擎的某些特點上做了大量工作。具有代表性的工作有，對現有商業搜尋引擎的結果進行傳遞，或建立小型的個性化的搜尋引擎。最後有關資訊檢索系統的研究很多，尤其在有組織機構集合（well
controlled
collections）方面。在下面兩節，我們將討論在資訊檢索系統中的哪些領域需要改進以便更好的工作在Web上。
3.1
資訊檢索資訊檢索系統誕生在幾年前，並發展迅速。然而大多數資訊檢索系統研究的物件是小規模的單一的有組織結構的集合，例如科學論文集，或相關主題的新聞故事。實際上，資訊檢索的主要基準，the
Text Retrieval
Conference（），用小規模的、有組織結構的集合作為它們的基準。
大型文集基準只有20GB，相比之下，我們抓到的24000000個網頁佔147GB。在TREC上工作良好的系統，在Web上卻不一定產生好的結果。例如，標準向量空間模型企圖返回和查詢請求最相近的文件，把查詢請求和文件都看作由出現在它們中的詞彙組成的向量。在Web環境下，這種策略常常返回非常短的文件，這些文件往往是查詢詞再加幾個字。例如，查詢"Bill
Clinton"，返回的網頁只包含"Bill Clinton
Sucks"，這是我們從一個主要搜尋引擎中看到的。網路上有些爭議，使用者應該更準確地表達他們想查詢什麼，在他們的查詢請求中用更多的詞。我們強烈反對這種觀點。如果使用者提出象"Bill
Clinton"這樣的查詢請求，應該得到理想的查詢結果，因為這個主題有許多高質量的資訊。象所給的例子，我們認為資訊檢索標準需要發展，以便有效地處理Web資料。
3.2 有組織結構的集合（Well Controlled
Collections）與Web的不同點
Web是完全無組織的異構的大量文件的集合。Web中的文件無論內在資訊還是隱含資訊都存在大量的異構性。例如，文件內部就用了不同的語言（既有人類語言又有程序），詞彙（email地址，連結，郵政編碼，電話號碼，產品號），型別（文字，HTML，PDF，影象，聲音），有些甚至是機器建立的檔案（log檔案，或數據庫的輸出）。可以從文件中推斷出來，但並不包含在文件中的資訊稱為隱含資訊。隱含資訊包括來源的信譽，更新頻率，質量，訪問量和引用。不但隱含資訊的可能來源各種各樣，而且被檢測的資訊也大不相同，相差可達好幾個數量級。例如，一個重要主頁的使用量，象Yahoo
每天瀏覽數達到上百萬次，於此相比無名的歷史文章可能十年才被訪問一次。很明顯，搜尋引擎對這兩類資訊的處理是不同的。
Web與有組織結構集合之間的另外一個明顯區別是，事實上，向Web上傳資訊沒有任何限制。靈活利用這點可以釋出任何對搜尋引擎影響重大的資訊，使路由阻塞，加上為牟利故意操縱搜尋引擎，這些已經成為一個嚴重的問題。這些問題還沒有被傳統的封閉的資訊檢索系統所提出來。它關心的是元資料的努力，這在Web
搜尋引擎中卻不適用，因為網頁中的任何文字都不會向用戶聲稱企圖操縱搜尋引擎。甚至有些公司為牟利專門操縱搜尋引擎。
4 系統分析（System
Anatomy）首先，我們提供高水平的有關體系結構的討論。然後，詳細描述重要的資料結構。最後，主要應用：抓網頁，索引，搜尋將被嚴格地檢查。
Figure 1. High Level Google Architecture
4.1Google體系結構概述這一節，我們將看看整個系統是如何工作的（give
a high
level），見圖1。本節不討論應用和資料結構，在後幾節中討論。為了效率大部分Google是用c或c++實現的，既可以在Solaris也可以在
Linux上執行。
Google系統中，抓網頁（下載網頁）是由幾個分散式crawlers完成的。一個URL伺服器負責向crawlers提供URL列表。抓來的網頁交給儲存服務器storeserver。然後，由儲存伺服器壓縮網頁並把它們存到知識庫repository中。每個網頁都有一個ID，稱作docID，當新
URL從網頁中分析出時，就被分配一個docID。由索引器和排序器負責建立索引index
function。索引器從知識庫中讀取文件，對其解壓縮和分析。每個文件被轉換成一組詞的出現情況，稱作命中hits。Hits紀錄了詞，詞在文件中的位置，最接近的字號，大小寫。索引器把這些hits分配到一組桶barrel中，產生經過部分排序後的索引。索引器的另一個重要功能是分析網頁中所有的連結，將有關的重要資訊存在連結描述anchors檔案中。該檔案包含了足夠的資訊，可以用來判斷每個連結鏈出鏈入節點的資訊，和連結文字。
URL分解器resolver閱讀連結描述anchors檔案，並把相對URL轉換成絕對URL，再轉換成docID。為連結描述文字編制索引，並與它所指向的docID關聯起來。同時建立由docID對組成的連結資料庫。用於計算所有文件的PageRank值。用docID分類後的barrels，送給排序器sorter，再根據wordID進行分類，建立反向索引inverted
index。這個操作要恰到好處，以便幾乎不需要暫存空間。排序器還給出docID和偏移量列表，建立反向索引。一個叫DumpLexicon的程式把這個列表和由索引器產生的字典結合在一起，建立一個新的字典，供搜尋器使用。這個搜尋器就是利用一個Web伺服器，使用由DumpLexicon所生成的字典，利用上述反向索引以及頁面等級PageRank來回答使用者的提問。
4.2主要資料結構經過優化的Google資料結構，能夠用較小的代價抓取大量文件，建立索引和查詢。雖然近幾年CPU和輸入輸出速率迅速提高。磁碟尋道仍然需要10ms。任何時候Google系統的設計都儘可能地避免磁碟尋道。這對資料結構的設計影響很大。
4.2.1
大檔案大檔案BigFiles是指虛擬檔案生成的多檔案系統，用長度是64位的整型資料定址。多檔案系統之間的空間分配是自動完成的。
BigFiles包也處理已分配和未分配檔案描述符。由於操縱系統不能滿足我們的需要，BigFiles也支援基本的壓縮選項。
4.2.2 知識庫 Figure 2. Repository Data Structure
知識庫包含每個網頁的全部HTML。每個網頁用zlib（見RFC1950）壓縮。壓縮技術的選擇既要考慮速度又要考慮壓縮率。我們選擇zlib的速度而不是壓縮率很高的bzip。知識庫用bzip的壓縮率接近4：1。而用zlib的壓縮率是3：1。文件一個挨著一個的儲存在知識庫中，字首是docID，長度，URL，見圖2。訪問知識庫不需要其它的資料結構。這有助於資料一致性和升級。用其它資料結構重構系統，我們只需要修改知識庫和crawler錯誤列表檔案。
4.2.3
檔案索引檔案索引儲存了有關文件的一些資訊。索引以docID的順序排列，定寬ISAM（Index
sequential access
mode）。每條記錄包括當前檔案狀態，一個指向知識庫的指標，檔案校驗和，各種統計表。如果一個文件已經被抓到，指標指向docinfo檔案，該檔案的寬度可變，包含了URL和標題。否則指標指向包含這個URL的URL列表。這種設計考慮到簡潔的資料結構，以及在查詢中只需要一個磁碟尋道時間就能夠訪問一條記錄。還有一個檔案用於把URL轉換成docID。它是URL校驗和與相應docID的列表，按校驗和排序。要想知道某個URL的docID，需要計算URL的校驗和，然後在校驗和檔案中執行二進位制查詢，找到它的docID。通過對這個檔案進行合併，可以把一批URL轉換成對應的docID。URL分析器用這項技術把URL轉換成docID。這種成批更新的模式是至關重要的，否則每個連結都需要一次查詢，假如用一塊磁碟，322'000'000個連結的資料集合將花費一個多月的時間。
4.2.4
詞典詞典有幾種不同的形式。和以前系統的重要不同是，詞典對記憶體的要求可以在合理的價格內。現在實現的系統，一臺256M記憶體的機器就可以把詞典裝入到記憶體中。現在的詞典包含14000000詞彙（雖然一些很少用的詞彙沒有加入到詞典中）。它執行分兩部分-詞彙表（用null分隔的連續串）和指標的雜湊表。不同的函式，詞彙表有一些輔助資訊，這超出了本文論述的範圍。
4.2.5 hit list hit
list是一篇文件中所出現的詞的列表，包括位置，字號，大小寫。Hit
list佔很大空間，用在正向和反向索引中。因此，它的表示形式越有效越好。我們考慮了幾種方案來編碼位置，字號，大小寫-簡單編碼（3個整型數），緊湊編碼（支援優化分配位元位），哈夫曼編碼。Hit的詳細資訊見圖3。我們的緊湊編碼每個hit用2位元組。有兩種型別hit，特殊hit和普通hit。特殊
hit包含URL，標題，連結描述文字，meta
tag。普通hit包含其它每件事。它包括大小寫特徵位，字號，12位元用於描述詞在文件中的位置（所有超過4095的位置標記為4096）。字號採用相對於文檔的其它部分的相對大小表示，佔3位元(實際只用7個值，因為111標誌是特殊hit)。特殊hit由大小寫特徵位，字號位為7表示它是特殊
hit，用4位元表示特殊hit的型別，8位元表示位置。對於anchor
hit八位元位置位分出4位元用來表示在anchor中的位置，4位元用於表明anchor出現的雜湊表hash
of the
docID。短語查詢是有限的，對某些詞沒有足夠多的anchor。我們希望更新anchor
hit的儲存方式，以便解決地址位和docIDhash域位數不足的問題。
因為搜尋時，你不會因為文件的字號比別的文件大而特殊對待它，所以採用相對字號。
hit表的長度儲存在hit前。為節省空間hit表長度，在正向索引中和wordID結合在一起，在反向索引中和docID結合儲存。這就限制它相應地只佔8到5位元（用些技巧，可以從wordID中借8bit）如果大於這些位元所能表示的長度，用溢位碼填充，其後兩位元組是真正的長度。
Figure 3. Forward and Reverse Indexes and the Lexicon
4.2.6
正向索引實際上，正向索引已經部分排序。它被存在一定數量的barrel中（我們用64個barrels）。每個barrel裝著一定範圍的
wordID。如果一篇文件中的詞落到某個barrel，它的docID將被記錄到這個barrel中，緊跟著那些詞（文件中所有的詞彙，還是落入該
barrel中的詞彙）對應的hitlist。這種模式需要稍多些的儲存空間，因為一個docID被用多次，但是它節省了桶數和時間，最後排序器進行索引時降低編碼的複雜度。更進一步的措施是，我們不是儲存docID本身，而是儲存相對於該桶最小的docID的差。用這種方法，未排序的barrel的
docID只需24位，省下8位記錄hitlist長。
4.2.7
反向索引除了反向索引由sorter加工處理之外，它和正向索引包含相同的桶。對每個有效的docID，字典包含一個指向該詞所在桶的指標。它指向由docID和它的相應hitlist組成的doclish，這個doclist代表了所有包含該詞的文件。
doclist中docID的順序是一個重要的問題。最簡單的解決辦法是用doclish排序。這種方法合併多個詞時很快。另一個可選方案是用文件中該詞出現的次數排序。這種方法回答單詞查詢，所用時間微不足道。當多詞查詢時幾乎是從頭開始。並且當用其它Rank演算法改進索引時，非常困難。我們綜合了這兩種方法，建立兩組反向索引barrel，一組barrels的hitlist只包含標題和anchor
hit，另一組barrel包含全部的hitlist。我們首先查第一組索引桶，看有沒有匹配的項，然後查較大的那組桶。
4.3
抓網頁執行網路爬行機器人是一項具有挑戰性的任務。執行的效能和可靠性甚至更重要，還有一些社會焦點。網路爬行是一項非常薄弱的應用，它需要成百上千的web服務器和各種域名伺服器的參與，這些伺服器不是我們系統所能控制的。為了覆蓋幾十億的網頁，Google擁有快速的分散式網路爬行系統。一個
URL伺服器給若干個網路爬行機器人（我們採用3個）提供URL列表。URL伺服器和網路爬行機器人都是用Python實現的。每個網路爬行機器人可以同時開啟300個連結。抓取網頁必須足夠快。最快時，用4個網路爬行機器人每秒可以爬行100個網頁。速率達每秒600K。執行的重點是找DNS。每個網路爬行機器人有它自己的DNS
cache，所以它不必每個網頁都查DNS。每一百個連線都有幾種不同的狀態：查DNS，連線主機，傳送請求，接收回答。這些因素使網路爬行機器人成為系統比較複雜的部分。它用非同步IO處理事件，若干請求佇列從一個網站到另一個網站不停的抓取網頁。執行一個連結到500多萬臺伺服器的網頁爬行機器人，產生
1千多萬登陸口，導致了大量的Email和電話。因為網民眾多，總有些人不知道網路爬行機器人是何物，這是他們看到的第一個網路爬行機器人。幾乎每天我們都會收到這樣的Email"哦，你從我們的網站看了太多的網頁，你想幹什麼？"還有一些人不知道網路搜尋機器人避免協議（the
robots exclusion
protocol），以為他們的網頁上寫著"版權所有，勿被索引"的字樣就會被保護不被索引，不必說，這樣的話很難被web
crawler理解。因為資料量如此之大，還會遇到一些意想不到的事情。例如，我們的系統曾經企圖抓一個線上遊戲，結果抓到了遊戲中的大量垃圾資訊。解決這個問題很簡單。但是我們下載了幾千萬網頁後才發現了這個問題。因為網頁和伺服器的種類繁多，實際上不在大部分Internet上執行它就測試一個網頁爬行機器人是不可能。總是有幾百個隱含的問題發生在整個web的一個網頁上，導致網路爬行機器人崩潰，或者更糟，導致不可預測的不正確的行為。能夠訪問大部分Internet的系統必須精力充沛並精心測試過。由於象crawler這樣大型複雜的系統總是產生這樣那樣的問題，因此花費一些資源讀這些
Email，當問題發生時解決它，是有必要的。
4.4
Web索引分析-任何執行在整個Web上的分析器必須能夠處理可能包含錯誤的大型集合。範圍從HTML標記到標記之間幾K位元組的0，非ASCII字元，幾百層HTML標記的巢狀，各種各樣令人難以想象的錯誤。為了獲得最大的速度，我們沒有采用YACC產生上下文無關文法CFG分析器，而是採用靈活的方式產生詞彙分析器，它自己配有堆疊。分析器的改進大大提高了執行速度，它的精力如此充沛完成了大量工作。把文件裝入barrel建立索引-分析完一篇文件，之後把該文件裝入barrel中，用記憶體中的hash表-字典，每個詞彙被轉換成一個wordID。當hash表字典中加入新的項時，笨拙地存入檔案。一旦詞彙被轉換成wordID，它們在當前文件的出現就轉換成hitlist，被寫進正向barrel。索引階段並行的主要困難是字典需要共享。
我們採用的方法是，基本字典中有140萬個固定詞彙，不在基本字典中的詞彙寫入日誌，而不是共享字典。這種方法多個索引器可以並行工作，最後一個索引器只需處理一個較小的額外詞彙日誌。排序-為了建立反向索引，排序器讀取每個正向barrel，以wordID排序，建立只有標題anchor
hi
t的反向索引barrel和全文反向索引barrel。這個過程一次只處理一個barrel，所以只需要少量暫存空間。排序階段也是並行的，我們簡單地同時執行儘可能多的排序器，不同的排序器處理不同的桶。由於barrel不適合裝入主存，排序器進一步依據wordID和docID把它分成若干籃子，以便適合裝入主存。然後排序器把每個籃子裝入主存進行排序，並把它的內容寫回到短反向barrel和全文反向barrel。
4.5
搜尋搜尋的目標是提供有效的高質量的搜尋結果。多數大型商業搜尋引擎好像在效率方面花費了很大力氣。因此我們的研究以搜尋質量為重點，相信我們的解決方案也可以用到那些商業系統中。
Google查詢評價過程見圖4。
1. 分析查詢。
2. 把詞彙轉換成wordID。
3. 在短barrel中查詢每個詞彙doclist的開頭。
4. 掃描doclist直到找到一篇匹配所有關鍵詞的文件
5. 計算該文件的rank
6.
如果我們在短barrel，並且在所有doclist的末尾，開始從全文barrel的doclist的開頭查詢每個詞，goto
第四步
7. 如果不在任何doclist的結尾，返回第四步。
8. 根據rank排序匹配文件，返回前k個。圖4
Google查詢評價在有限的響應時間內，一旦找到一定數量的匹配文件，搜尋引擎自動執行步驟8。這意味著，返回的結果是子優化的。我們現在研究其它方法來解決這個問題。過去根據PageRank排序hit，看來能夠改進這種狀況。
4.5.1 Ranking系統
Google比典型搜尋引擎儲存了更多的web資訊。每個hitlish包括位置，字號，大小寫。另外，我們還考慮了連結描述文字。Rank綜合所有這些資訊是困難的。ranking函式設計依據是沒有某個因素對rank影響重大。首先，考慮最簡單的情況-單個詞查詢。為了單個詞查詢中一個文件的
rank，Goole在文件的hitlist中查詢該詞。Google認為每個hit是幾種不同型別（標題，連結描述文字anchor，URL，普通大字號文字，普通小字號文字，......）之一，每種有它自己的型別權重。型別權重建立了一個型別索引向量。Google計算hitlist中每種hit的數量。然後每個hit數轉換成count-weight。Count-weight開始隨hit數線性增加，很快逐漸停止，以至於hit數與此不相關。我們計算
count-weight向量和type-weight向量的標量積作為文件的IR值。最後IR值結合PageRank作為文件的最後rank
對於多詞查詢，更復雜些。現在，多詞hitlist必須同時掃描，以便關鍵詞出現在同一文件中的權重比分別出現時高。相鄰詞的hit一起匹配。對每個匹配
hit
的集合計算相鄰度。相鄰度基於hit在文件中的距離，分成10個不同的bin值，範圍從短語匹配到根本不相關。不僅計算每類hit數，而且要計算每種型別的相鄰度，每個型別相似度對，有一個型別相鄰度權type-prox-weight。Count轉換成count-weight，計算count-
weight type-proc-weight的標量積作為IR值。應用某種debug
mode所有這些數和矩陣與查詢結果一起顯示出來。這些顯示有助於改進rank系統。
4.5.2 反饋
rank函式有很多引數象type-weight和type-prox-weight。指明這些引數的正確值有點黑色藝術black
art。為此，我們的搜尋引擎有一個使用者反饋機制。值得信任的使用者可以隨意地評價返回的結果。儲存反饋。然後，當修改rank函式時，對比以前搜尋的
rank，我們可以看到修改帶來的的影響。雖然不是十全十美，但是它給出了一些思路，當rank函式改變時對搜尋結果的影響。
5執行和結果搜尋結果的質量是搜尋引擎最重要的度量標準。完全使用者評價體系超出了本文的論述範圍，對於大多數搜尋，我們的經驗說明Google的搜尋結果比那些主要的商業搜尋引擎好。作為一個應用PageRank，連結描述文字，相鄰度的例子，圖4給出了Google搜尋bill
Clinton的結果。它說明了Google的一些特點。伺服器對結果進行聚類。這對過濾結果集合相當有幫助。這個查詢，相當一部分結果來自
whitehouse.gov域，這正是我們所需要的。現在大多數商業搜尋引擎不會返回任何來自whitehouse.gov的結果，這是相當不對的。注意第一個搜尋結果沒有標題。因為它不是被抓到的。Google是根據連結描述文字決定它是一個好的查詢結果。同樣地，第五個結果是一個Email地址，當然是不可能抓到的。也是連結描述文字的結果。所有這些結果質量都很高，最後檢查沒有死連結。因為它們中的大部分PageRank值較高。PageRank
百分比用紅色線條表示。沒有結果只含Bill沒有Clinton或只含Clinton沒有Bill。因為詞出現的相近性非常重要。當然搜尋引擎質量的真實測試包含廣泛的使用者學習或結果分析，此處篇幅有限，請讀者自己去體驗Google，http://google.stanford.edu/。
5.1
儲存需求除了搜尋質量，Google的設計可以隨著Web規模的增大而有效地增大成本。一方面有效地利用儲存空間。表1列出了一些統計數字的明細表和Google儲存的需求。由於壓縮技術的應用知識庫只需53GB的儲存空間。是所有要儲存資料的三分之一。按當今磁碟價格，知識庫相對於有用的資料來說比較便宜。搜尋引擎需要的所有資料的儲存空間大約55GB。大多數查詢請求只需要短反向索引。檔案索引應用先進的編碼和壓縮技術，一個高質量的搜尋引擎可以執行在7GB的新PC。
5.2
系統執行搜尋引擎抓網頁和建立索引的效率非常重要。Google的主要操作是抓網頁，索引，排序。很難測試抓全部網頁需要多少時間，因為磁碟滿了，域名伺服器崩潰，或者其它問題導致系統停止。總的來說，大約需要9天時間下載26000000網頁（包括錯誤）。然而，一旦系統執行順利，速度非常快，下載最後11000000網頁只需要63小時，平均每天4000000網頁，每秒48.5個網頁。索引器和網路爬行機器人同步執行。索引器比網路爬行機器人快。因為我們花費了大量時間優化索引器，使它不是瓶頸。這些優化包括批量更新文件索引，本地磁碟資料結構的安排。索引器每秒處理54個網頁。排序器完全並行，用4臺機器，排序的整個過程大概需要24小時。
5.3
搜尋執行改進搜尋執行不是我們研究的重點。當前版本的Google可以在1到10秒間回答查詢請求。時間大部分花費在NFS磁碟IO上（由於磁碟普遍比機器慢）。進一步說，Google沒有做任何優化，例如查詢緩衝區，常用詞彙子索引，和其它常用的優化技術。我們傾向於通過分散式，硬體，軟體，和演算法的改進來提高Google的速度。我們的目標是每秒能處理幾百個請求。表2有幾個現在版本Google響應查詢時間的例子。它們說明IO緩衝區對再次搜尋速度的影響。
6 結論
Google設計成可伸縮的搜尋引擎。主要目標是在快速發展的World
Wide
Web上提供高質量的搜尋結果。Google應用了一些技術改進搜尋質量包括PageRank，連結描述文字，相鄰資訊。進一步說，Google是一個收集網頁，建立索引，執行搜尋請求的完整的體系結構。
6.1
未來的工作大型Web搜尋引擎是個複雜的系統，還有很多事情要做。我們直接的目標是提高搜尋效率，覆蓋大約100000000個網頁。一些簡單的改進提高了效率包括請求緩衝區，巧妙地分配磁碟空間，子索引。另一個需要研究的領域是更新。我們必須有一個巧妙的演算法來決定哪些舊網頁需要重新抓取，哪些新網頁需要被抓取。這個目標已經由實現了。受需求驅動，用代理cache建立搜尋資料庫是一個有前途的研究領域。我們計劃加一些簡單的已經被商業搜尋引擎支援的特徵，例如布林算術符號，否定，填充。然而另外一些應用剛剛開始探索，例如相關反饋，聚類（Google現在支援簡單的基於主機名的聚類）。我們還計劃支援使用者上下文（象使用者地址），結果摘要。我們正在擴大連結結構和連結文字的應用。簡單的實驗證明，通過增加使用者主頁的權重或書籤，PageRank可以個性化。對於連結文字，我們正在試驗用連結周圍的文字加入到連結文字。Web搜尋引擎提供了豐富的研究課題。如此之多以至於我們不能在此一一列舉，因此在不久的將來，我們希望所做的工作不止本節提到的。
6.2
高質量搜尋當今Web搜尋引擎使用者所面臨的最大問題是搜尋結果的質量。結果常常是好笑的，並且超出使用者的眼界，他們常常灰心喪氣浪費了寶貴的時間。例如，一個最流行的商業搜尋引擎搜尋"Bill
Clillton"的結果是the Bill Clinton Joke of the Day: April 14,
1997。Google的設計目標是隨著Web的快速發展提供高質量的搜尋結果，容易找到資訊。為此，Google大量應用超文字資訊包括連結結構和連結文字。Google還用到了相鄰性和字號資訊。評價搜尋引擎是困難的，我們主觀地發現Google的搜尋質量比當今商業搜尋引擎高。通過PageRank分析連結結構使
Google能夠評價網頁的質量。用連結文字描述連結所指向的網頁有助於搜尋引擎返回相關的結果（某種程度上提高了質量）。最後，利用相鄰性資訊大大提高了很多搜尋的相關性。
6.3
可升級的體系結構除了搜尋質量，Google設計成可升級的。空間和時間必須高效，處理整個Web時固定的幾個因素非常重要。實現Google系統，CPU、訪存、記憶體容量、磁碟尋道時間、磁碟吞吐量、磁碟容量、網路IO都是瓶頸。在一些操作中，已經改進的Google克服了一些瓶頸。
Google的主要資料結構能夠有效利用儲存空間。進一步，網頁爬行，索引，排序已經足夠建立大部分web索引，共24000000個網頁，用時不到一星期。我們希望能在一個月內建立100000000網頁的索引。
6.4 研究工具
Google不僅是高質量的搜尋引擎，它還是研究工具。Google蒐集的資料已經用在許多其它論文中，提交給學術會議和許多其它方式。最近的研究，例如，提出了Web查詢的侷限性，不需要網路就可以回答。這說明Google不僅是重要的研究工具，而且必不可少，應用廣泛。我們希望Google是全世界研究者的資源，帶動搜尋引擎技術的更新換代。
7致謝 Scott Hassan and Alan
Steremberg評價了Google的改進。他們的才智無可替代，作者由衷地感謝他們。感謝Hector
Garcia-Molina, Rajeev Motwani, Jeff Ullman, and Terry
Winograd和全部WebBase開發組的支援和富有深刻見解的討論。最後感謝IBM，Intel，Sun和投資者的慷慨支援，為我們提供裝置。這裡所描述的研究是Stanford綜合數字圖書館計劃的一部分，由國家科學自然基金支援，合作協議號IRI-9411306。DARPA
，NASA，Interva研究，Stanford數字圖書館計劃的工業合作伙伴也為這項合作協議提供了資金。參考文獻
?
Google的設計目標是可升級到10億網頁。我們的磁碟和機器大概能處理這麼多網頁。系統各個部分耗費的總時間是並行的和線性的。包括網頁爬行機器人，索引器和排序器。擴充套件後我們認為大多數資料結構執行良好。然而10億網頁接近所有常用作業系統的極限（我們目前執行在Solaris和Linux上）。包括主存地址，開放檔案描述符的數量，網路socket和頻寬，以及其它因素。我們認為當網頁數量大大超過10億網頁時，會大大增加系統複雜性。
9.2集中式索引體系的可升級性隨著計算機效能的提高，海量文字索引的成本比較公平。當然頻寬需求高的其它應用如視訊，越來越普遍。但是，與多媒體例如視訊相比，文字產品的成本低，因此文字仍然普遍。
圖2 Google系統的工作流程圖
(注：原圖來自Sergey Brin and Lawrence Page, The Anatomy of a
Large-Scale Hypertextual. Web Search Engine,
1998.http://www-db.stanford.edu/%7Ebackrub/Google.html)
①
Google使用高速的分散式爬行器(Crawler)系統中的漫遊遍歷器(Googlebot)定時地遍歷網頁，將遍歷到的網頁送到儲存伺服器(Store
Server)中。
②
儲存伺服器使用zlib格式壓縮軟體將這些網頁進行無失真壓縮處理後存入資料庫Repository中。Repository獲得了每個網頁的完全
Html程式碼後，對其壓縮後的網頁及URL進行分析，記錄下網頁長度、URL、URL長度和網頁內容，並賦予每個網頁一個文件號(docID)，以便當系統出現故障的時候，可以及時完整地進行網頁的資料恢復。
③
索引器(Indexer)從Repository中讀取資料，以後做以下四步工作：
④
(a)將讀取的資料解壓縮後進行分析，它將網頁中每個有意義的詞進行統計後，轉化為關鍵詞(wordID)的若干索引項(Hits)，生成索引項列表，該列表包括關鍵詞、關鍵詞的位置、關鍵詞的大小和大小寫狀態等。索引項列表被存入到資料桶(Barrels)中，並生成以文件號(docID)部分排序的順排檔索引。
索引項根據其重要程度分為兩種：當索引項中的關鍵詞出現在URL、標題、錨文字(Anchor
Text)和標籤中時，表示該索引項比較重要，稱為特殊索引項(Fancy
Hits)；其餘情況則稱為普通索引項(Plain
Hits)。在系統中每個Hit用兩個位元組(byte)儲存結構表示：特殊索引項用1位(bit)表示大小寫，用二進位制程式碼111(佔3位)表示是特殊索引項，其餘12位有4位表示特殊索引項的型別(即hit是出現在URL、標題、連結結點還是標籤中)，剩下8位表示hit在網頁中的具體位置；普通索引項是用1位表示大小寫，3位表示字型大小，其餘12位表示在網頁中的具體位置。
順排檔索引和Hit的儲存結構如圖3所示。
圖3 順排檔索引和Hit的儲存結構
值得注意的是，當特殊索引項來自Anchor
Text時，特殊索引項用來表示位置的資訊（8位）將分為兩部分：4位表示Anchor
Text出現的具體位置，另4位則用來與表示Anchor
Text所連結網頁的docID相連線，這個docID是由URL
Resolver經過轉化存入順排檔索引的。
(b)索引器除了對網頁中有意義的詞進行分析外，還分析網頁的所有超文字連結，將其Anchor
Text、URL指向等關鍵資訊存入到Anchor文件庫中。
(c)索引器生成一個索引詞表(Lexicon)，它包括兩個部分：關鍵詞的列表和指標列表，用於倒排檔文件相連線(如圖3所示)。
(d)索引器還將分析過的網頁編排成一個與Repository相連線的文件索引(Document
Index)，並記錄下網頁的URL和標題，以便可以準確查找出在Repository中儲存的原網頁內容。而且把沒有分析的網頁傳給URL
Server，以便在下一次工作流程中進行索引分析。
⑤ URL分析器（URL
Resolver）讀取Anchor文件中的資訊，然後做⑥中的工作。
⑥ (a)將其錨文字(Anchor
Text)所指向的URL轉換成網頁的docID；(b)將該docID與原網頁的docID形成"連結對"，存入Link資料庫中；(c)將
Anchor Text指向的網頁的docID與順排檔特殊索引項Anchor
Hits相連線。
⑦
資料庫Link記錄了網頁的連結關係，用來計算網頁的PageRank值。
⑧ 文件索引(Document
Index)把沒有進行索引分析的網頁傳遞給URL Server，URL
Server則向Crawler提供待遍歷的URL，這樣，這些未被索引的網頁在下一次工作流程中將被索引分析。
⑨
排序器（Sorter）對資料桶(Barrels)的順排檔索引重新進行排序，生成以關鍵詞(wordID)為索引的倒排檔索引。倒排檔索引結構如圖4所示：
圖4 倒排檔索引結構
⑩
將生成的倒排檔索引與先前由索引器產生的索引詞表(Lexicon)相連線產生一個新的索引詞表供搜尋器(Searcher)使用。搜尋器的功能是由網頁伺服器實現的，根據新產生的索引詞表結合上述的文件索引(Document
Index)和Link資料庫計算的網頁PageRank值來匹配檢索。
在執行檢索時，Google通常遵循以下步驟（以下所指的是單個檢索詞的情況）：
(1)將檢索詞轉化成相應的wordID；
(2)利用Lexicon，檢索出包含該wordID的網頁的docID；
(3)根據與Lexicon相連的倒排檔索引，分析各網頁中的相關索引項的情況，計算各網頁和檢索詞的匹配程度，必要時呼叫順排檔索引；
(4)根據各網頁的匹配程度，結合根據Link產生的相應網頁的PageRank情況，對檢索結果進行排序；
(5)呼叫Document
Index中的docID及其相應的URL，將排序結果生成檢索結果的最終列表，提供給檢索使用者。
使用者檢索包含多個檢索詞的情況與以上單個檢索詞的情況類似：先做單個檢索詞的檢索，然後根據檢索式中檢索符號的要求進行必要的布林操作或其他操作。