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.4Web索引分析—任何運行在整個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/ 。
