Google的开始－－剖析大规模超文本网络搜索引擎
生活随笔
收集整理的這篇文章主要介紹了
Google的开始－－剖析大规模超文本网络搜索引擎
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
轉載自：[url]http://www.yeeyan.com/articles/view/thunder/364[/url]
原作者: Sergey Brin and Lawrence Page譯者: 雷聲大雨點大 (Blog)
譯者：本文是谷歌創始人Sergey和Larry在斯坦福大學計算機系讀博士時的一篇論文。發表于1997年。Google的一切應該都起源與此。深入了解Google，深入了解互聯網的未來，當讀此文。我把全文分成6個部分，推薦到這里。有興趣的朋友可以一起來翻譯。
我沒有發現本文的完整中譯，只找到了這個片段，由xfygx朋友翻譯了本文的第一部分，其他似乎沒有全部完成。
所以，這部分譯文是xfygx原作，而非我的翻譯！我只是就自己的理解做了些改動。如果有幸xfygx朋友能看到我在他/她博客的留言，來我們譯言，我非常希望能把本文轉到他/她名下。
另外，如果您發現已有其他出色的完整中譯版了，請告訴我們。免得譯者們重復勞動。
摘要
在本文中，我們將介紹Google，一個充分利用超文本文件（譯者：即HTML文件）結構進行搜索的大規模搜索引擎的原型。Google可以有效地對互聯網（Web）資源進行爬行搜索（crawl）〔注 1〕和索引，比目前已經存在的系統有更令人滿意的搜索結果。該原型的數據庫包括2400萬頁面的全文和之間的鏈接，可通過[url]http://google.stanford.edu/[/url]訪問。
設計搜索引擎是一項富有挑戰的任務。搜索引擎為數以億計的網頁建立索引，而這些網頁包含了同樣數量級的不同詞語。每天響應數千萬計的查詢請求。盡管大規模網絡搜索引擎是很重要的，但在這個領域很少有理論研究。更由于技術的飛速發展和互聯網的普及，今天這樣的搜索引擎和三年前的搜索引擎會是非常不同的。本文對我們的大規模搜索引擎進行了深入的討論，這也是目前為止我們所知道的公開發表的第一篇如此詳細的討論。
除了如何把傳統的搜索技術擴展到前所未有的海量數據，我們還面臨這樣一個新的技術挑戰：如何使用超文本文件所蘊含的擴展信息以產生更好的搜索結果。本文討論了如何建立一個實用的大規模系統，以利用超文本文件中的額外信息。另外，我們也關注了如何有效處理超文本文件不可控的問題，因為人們可以隨意發表超文 本文件（譯者：如個人網頁）。
關鍵詞
World Wide Web, Search Engines, Information retrieval, PageRank, Google
1.簡介
互聯網對信息檢索（Information Retrieval）領域產生了新的挑戰。網上的信息數量是在不斷的快速增長，同時有越來越多對網絡搜索毫無經驗的新用戶上網。在網上沖浪時，人們一般會利用網絡的“鏈接圖”（譯者：想像每個網頁是一個點，網頁之間的鏈接是從一個點指向另一個點的邊，這就構成了一張有向圖。）。而這經常從一個人工維護的網址列表（如Yahoo!）或是一個搜索引擎開始。人工維護的列表有效覆蓋了流行的主題，但這些是主觀的，花費高昂，更新緩慢，并且不能覆蓋全部的主題，特別是冷僻的主題。依賴關鍵詞匹配的自動搜索引擎通常返回太多的低質量的匹配結果。更糟的是，一些廣告商通過某些方式誤導搜索引擎以試圖吸引人們的注意力。我們建立了一個大規模搜索引擎來解決已存在系統的許多問題。它充分利用超文本文件所表達額外信息來提供更高質量的搜索結果。我們選擇這個名字，Google，是因為它是googol（表示10的100次方)這個詞的常用拼寫法。而這個詞的意義與我們建立這個大規模搜索引擎的目標是非常一致的。
1.1 互聯網搜索引擎 -- 擴展：1994 - 2000
搜索引擎技術必須極大規模地擴展才能趕上互聯網的發展步伐。在1994年,最早的 web搜索引擎之一，World Wide Web Worm(WWWW) [McBryan 94]已經索引了11萬web頁面和文檔。到了1997年的11月，頂級的搜索引擎聲稱的索引的頁面數量從2百萬(WebCrawler) 到10億(根據 Search Engine Watch)。可以想像到2000年，索引全部的Web將需要包含超過十億的文檔。同時，搜索引擎需要處理的查詢請求也會有不可想像的增長。在1994年 3月到4月間，World Wide Web Worm平均每天收到1500個查詢。而到了1997年的11月，Altavista聲稱 它平均每天要處理大約2千萬的查詢。隨著web的用戶和使用搜索引擎的自動系統數量的增加，到2000年，頂級的搜索引擎每天將會需要處理數以億計的查詢。我們的系統的目標是解決這些由搜索引擎大規模擴展所帶來的問題，包括質量和可擴展性。
1.2 Google:與Web同步發展
即便建立一個適應今天互聯網信息量的搜索引擎已經面臨著許多的挑戰。我們需要使用快速爬行搜索技術收集web文檔并保持它們的及時更新；我們需要可以有效存儲文檔索引和文檔自身（這不是必須的）的海量存儲空間；我們需要可以有效處理數百GB數據的索引系統；我們還需要可以在一秒內處理成百上千的查詢的計算能力。
這些任務都隨著Web的增長而愈發變的困難。然而，硬件性能的提高和費用的降低可以部分的抵消這些困難。但某些方面是個例外，如硬盤數據讀取的速度和操作系統的魯棒性（譯者：可以通俗地理解為穩定性）都沒有顯著提高。在設計Google的過程中，我們已經考慮到了Web 和技術這兩方面的發展。Google被設計為可以適應極大數據量。它有效使用存儲空間來保存索引。它的數據結構被優化以便可以快速和有效的存取數據（見 4.2節)。另外，我們認為，相對于文本以及HTML文檔數量的增長，索引和存儲花費它們的費用最終會下降(見附錄B)。因此，Google這樣的集中式（譯者：而非分布到許多遠程計算機，如P2P系統）搜索系統隨著互聯網的發展而擴容就成為可能。
1.3 設計目標
1.3.1 提高搜索質量
我們的主要目標是提高web搜索引擎的質量。在1994年，一些人認為用一個完整的搜索索引就可以很容易地找到任何信息。在1994年互聯網最佳－－導航員上，有這樣的話"最好的導航服務應該是使用戶可以很容易的在Web上找到任何信息"。然而，到1997，這個任務仍是非常困難的。在最近使用搜索引擎的用戶都可以很容易的證實索引的完整性并不是決定搜索結果質量的唯一因素。"垃圾結果" 經常會使用戶找不到真正感興趣的結果。實際上，到1997年的十一月，四個頂級搜索引擎中，僅僅只有一個可以在搜索時發現它自身(對查詢自己名字的請求，返回結果中將自己排在結果中的前十名)。產生這個問題的主要原因之一是在這些搜索引擎的索引庫中文檔的數量成數量級地增長，而用戶看這么多文檔的能力卻不可能這樣增長。用戶往往只看結果中的前數十個。因此，隨著文檔規模的增加，我們需要工具來提高查準率（在前十個結果中返回相關內容）。實際上，我們說的"相關"是指最好的那一份，因為可能會有幾萬份“稍微“相關的文檔。查準率在我們的眼中是如此的重要，以至于我們甚至愿意為此損失一些查全率。最近的研究顯示，超文本文件中的信息可以有助于提高搜索和其他應用[Marchiori 97] [Spertus 97] [Weiss 96] [Kleinberg 98]。特別是網頁鏈接的結構，以及鏈接本身的文字，為相關性判定和進行質量的篩選提供了許多信息。Google使用了網頁鏈接結構和錨（譯者：HTML中的語法，表示一個指向網頁的鏈接）鏈接中的文字。（詳見2.1和2.2節）
1.3.2 搜索引擎的理論研究
隨著WEB的巨大發展，互聯網也越來越商業化。在1993年，只有1.5%的web服務器是.com的域名。而到了1997年，這個數字已經變成了60%。同時，搜索引擎的從學術研究變成了商業性質。到目前為止，大多數的搜索引擎的開發都是由公司來進行的，很少有詳細的技術資料被公開。這導致了這項技術帶有了許多神秘的色彩，并且是以廣告為主（見附錄A）。對于Google，我們有一個非常重要的目標就是推動搜索引擎在學術界的發展和理解。
另外的重要的設計目標是建立一個可以讓一定數量的用戶實際使用的系統。用戶使用對我們來說非常重要，因為我們認為真正利用了現代互聯網系統的海量數據的研究才是最有價值的。比如現在每天有數千萬用戶查詢，但由于這些數據被認為具有商業價值，很難拿來作學術研究。
我們最終的設計目標是建立一個可以支持在大規模互聯網數據上進行研究活動的系統構架。為了支持研究活動，Google存儲了全部的在爬行搜索中發現的實際數據，并壓縮起來。主要的目標之一是建立一個環境，在這個環境中，研究者可以很快的利用這個難得的系統，處理web數據，產生令人感興趣的結果。在短時間內系統就被建立起來，已經有一些論文使用了通過Google生成的數據庫。還有許多其它的項目在進行之中。另外的目標是我們希望建立一個類似空間站的環境，使得研究者，甚至是學生可以在我們的大規模web數據上進行實驗。
〔注 1〕爬行搜索，Crawl，是指搜索引擎會跟隨網頁間的鏈接從一個網頁“爬行”到下一個網頁。而對每一個網頁的分析和記錄，或者這個過程的結果，則稱為“索引”。
2.系統功能
Google搜索引擎通過兩個重要功能來產生高精確度的結果。第一，它利用互聯網的鏈接結構為每個網頁計算出一個高質量的排名。這個排名被稱為PageRank[注一]，具體在Larry Page98年的論文[Page 98]中有詳述。第二，Google利用鏈接本身來提高搜索結果的質量。
2.1 PageRank: 給互聯網帶來秩序
現有的搜索引擎在很大程度上忽略了一個重要資源－－把互聯網看做是一個引用關系（鏈接關系）圖（見第一部分的注解）。我們已經產生了包含5億1千8百萬這樣的超文本鏈接（就是網頁指向網頁的鏈接）的地圖－－這是對整個互聯網的一個相當顯著的采樣。這樣的地圖讓我們能快速計算網頁的“PageRank”－－一個對于網頁被引用程度的客觀衡量，而被引用程度與人們對于網頁重要性的主觀認識也很好地吻合。由于這樣的吻合，PageRank成為對用關鍵字搜索網頁返回的結果進行排序的極好方式。對于最熱門的分類，局限于網頁標題進行簡單的文字查找，PageRank排序后的搜索結果效果極好。而在整個Google系統中進行全文查找，PageRank的作用也是非常顯著的。
2.1.1 PageRank 計算簡述
學術文獻的引用機制被應用到互聯網上－－主要就是計算一個網頁被引用，或被反向鏈接的次數。這給出了對一個網頁重要性或質量的估計。PageRank進一步發展了這個想法：來自不同頁面的鏈接被給以不同的權重，并依據一個網頁上鏈接的個數正態化。PageRank的定義如下：
我們假定網頁 A 有若干其他網頁（T1...Tn）指向它（即引用關系）。參數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)可以通過一個簡單的循環算法來計算。這對應于正態化后的互聯網鏈接矩陣的主要艾根向量的計算。另外，2千6百萬網頁的PageRank可以在一臺中型服務器上，通過幾小時的計算完成。這里有很多細節超出了本論文的討論范圍。
2.1.2 直觀解釋
PageRank 可以被想像成一個對用戶行為建立的模型。我們假想一個“隨機上網者”；隨機地給他一個網頁；他漫無目的地點擊網頁的鏈接，而從來不點“返回鍵”；最終他覺得煩了，又從另一個隨機的網頁從新開始。在上述模型中，“隨機上網者”訪問一個頁面的概率就是這個頁面的PageRank。而阻尼系數d，則是我們的“隨機上網者”在訪問了一個頁面后，覺得煩了，開始訪問一個新的頁面的概率。上述模型的一個重要變形是把阻尼系數d加到一個網頁上，還是加到一組網頁上。這個變形使得故意欺騙系統獲得高排名的企圖幾乎變成不可能的。我們對PageRank有若干延伸，詳見這里[Page 98]。
另一個直觀的解釋是如果有很多其他網頁指向一個頁面，或者其他有很高PageRank的網頁指向這個頁面，該頁面應該有較高的PageRank。直覺告訴我們，如果一個網頁被互聯網上的很多其他網頁引用，它應該是值得關注的。而那些只有一個引用的頁面，如果它來自象Yahoo!首頁，那大約這個網頁也值得看看。如果一個網頁質量不高或根本就是一個死鏈接，Yahoo首頁多半不會鏈接它。PageRank 考慮了上述兩種以及之間的各種情況，它用遞歸方式把網頁的權重通過互聯網的鏈接結構傳播出去。
2.2 錨鏈接（Anchor，是HTML的語法，即網頁鏈接）的文本
鏈接的文字在我們的搜索引擎中受到特殊處理。大多數搜索引擎把鏈接中的文本部分（比如keso這個鏈接中的keso）歸屬于這個鏈接所在的網頁。而我們除此之外，還把它歸屬于這個鏈接指向的頁面。這有幾個好處。第一，錨鏈接對被指向網頁的描述，通常比網頁本身的描述更準確。第二，錨鏈接可能指向那些不能被建立文本索引的文檔，如圖片、程序、數據庫。這使得現在不能爬行搜索的頁面可以被搜索到了。注意，以前從未被爬行搜索過的頁面可能會產生問題，因為它們的有效性從未被驗證過。比如搜索引擎甚至會返回一個有鏈接指向，但其實根本不存在的頁面。然而，由于我們可以對結果排序，這個問題很少會出現。
把錨鏈接中的文本傳播到被指向的頁面這個想法，在World Wide Web Worm [McBryan 94] 已經被實施了。主要用于對非文本文件的搜索，和把搜索結果擴展到更多下載文檔。而我們使用錨鏈接，主要是因為它可以提供高質量的結果。有效使用錨鏈接在技術上是很難實現的，因為大量數據需要處理。在我們現在爬行搜索過的2千4百萬網頁中，我們為2億5千9百萬錨鏈接建立了索引。
2.3 其他功能
除了使用PageRank和利用錨鏈接中的文本外，Google還有其他一些功能。第一，它有所有網頁的位置信息，因此在搜索過程中充分應用了接近程度。第二，Google 記錄網頁的一些視覺表現，如單詞的字體大小。大字體的權重比小字體要高。第三，完整的原始HTML頁面被保存下來（即Google的網頁快照功能）。
[注一] PageRank 可以譯為網頁排名，建議后面就用原文了。另外，Page 恰恰是Google創始人之一Larry Page的姓。
3相關工作
基于web的搜索研究有一段簡短的的歷史。萬維網蠕蟲( wwww )[ mcbryan 94 ]是第一個網上搜索引擎。但隨后,產生了幾個學院派的搜索引擎,其中有不少現在已經是公開的上市公司了。相比Web的增長和搜索引擎的重要性,現在幾乎沒有關于當前搜索引擎有價值的研究材料 [Pinkerton 94].。據邁克爾.茂丁( lycos公司首席科學家)[Mauldin] "各種服務(包括lycos )緊密的守衛著這些數據庫" 。
不過,在搜索引擎的具體的特點上已進行了相當的工作。對現有商業搜索引擎產生的搜索結果的后處理已經取得了卓有成效的成果,或是產生小規模的“個性化的“搜索引擎。最終,有過不少針對信息檢索系統的研究,尤其是對受控制的結果集的研究。在隨后兩節中,我們將討論一些必須擴大研究的領域,以便更好地在Web上工作。
3.1信息檢索
信息檢索系統的研究,已經有很多年了,并且成果顯著[Witten 94] 。 然而,大多數信息檢索系統 的 研究 針對的是 受控制的同質集合 ，例如,主題相關的科學論文或新聞故事。的確,信息檢索的主要的基準,文本檢索會議[TREC 96] ,用了一個相當小的，并且受控制的集合 作為其基準。“非常大的語料庫“; 基準只有20gb 大小， 相較于我們搜索過的 2千4百萬網頁，有147gb 的數據量 。在TREC 上工作很好的搜索引擎，拿到Web上來往往效果不佳。舉例來說,標準向量空間模型試圖返回和搜索條件最為近似的文件,假定搜索和文件都是各自文字定義的向量。對Web 而言,這種策略只會返回非常簡短的文件，包含查詢本身和幾句話。舉例來說,我們已經看到了一個主要的搜索引擎返回的一個頁面僅僅含有“比爾.克林頓真糟“;和從“比爾.克林頓“搜索來的圖片。 有人爭論到 ,在Web上用戶應該更具體,更準確地指出他們要什么,并且在搜索查詢中增添更多詞。我們堅決反對這種立場。如果用戶發出對“比爾克林頓“的搜索查詢 ,他們應得到合理的結果,因為就這個話題存在著大量的高品質的資料。鑒于這一類的例子,我們認為標準的信息檢索工作需要擴大范圍，從而有效處理 Web。
3.2 Web和受控集合的不同
互聯網 Web是一個廣闊的充滿完全不受控制的異構文件的集合。Web 上的文件,不但內部格式極其不同,而且外部元信息也未必可用。例如,文件內部的不同,有各自的語言(包括自然語言和編程語言),各自的詞匯(電子郵件地址,鏈接,郵編,電話號碼,產品號碼)，文件格式的不同(文本格式, html格式, pdf格式,圖像格式,聲音格式),并且甚至可能是機器產生的(日志文件或者數據庫的輸出文件) 。在另一方面,我們定義文件的外部元信息，從這些信息就可以推斷出一個文件的大概,但是元信息并不包含在文件中。文件外部元信息的例子,包括這樣一些信息： 來源的聲譽,更新頻率,質量,受歡迎程度 和 用法 , 和引用。不僅是外部元信息的可能來源千差萬別,而且衡量的方式也存在很多不同數量級的差異。舉例來說,比較從一個大型網站的主頁得到的使用信息,如，雅虎，目前每天獲得幾百萬的頁面瀏覽量， 而一個晦澀的歷史文章,可能每10年才能被瀏覽一次。顯而易見,搜索引擎必須嚴重區別對待這兩個條目。
另一個Web 和受控集合的較大差異是,幾乎沒有限制控制人們在網上可以放什么。把這種靈活性的內容發布和產生巨大影響的搜索引擎結合起來 ，去吸引訪問瀏覽量。 并且很多公司通過故意操縱搜索引擎來贏利，日益成為一個嚴重問題。這個問題在傳統的封閉的信息檢索系統中一直沒有發現 。另外,有趣的是我們注意到web搜索引擎使得想通過元數據操縱搜索引擎的努力基本上失敗了,因為網頁上的任何文字如果不是用來呈現給用戶的， 就是被濫用來操縱搜索引擎。甚至有許多公司專門操縱搜索引擎以達到贏利的目的。
（斷斷續續地把它翻完了。第4部分是Google搜索引擎最核心的一塊，有一些設計細節還不是很懂，希望能和大家一起探討。翻譯不當之處還請各位指出，謝謝。）
4 系統剖析（System Anatomy）
首先，我們對架構做一個高層的討論。接著，對重要的數據結構有一個深入的描述。最后，我們將深入分析主要的應用程序：爬蟲，索引和搜索。
4.1 Google架構概述
[img]http://infolab.stanford.edu/~backrub/over.gif[/img]
圖1. Google高層架構
在這一部分，我們將對圖1中整個系統是怎么運行的有一個高層的概述。這一部分沒有提到應用程序和數據結構，這些會在接下來的幾部分里討論。考慮到效率，Google的大部分是用C或C++實現，可以在Solaris或者Linux下運行。
在Google中，網頁抓取（下載web頁面）的工作由分布式的爬蟲（crawlers）完成。有一個URL服務器（圖1中的URL Server）把需要抓取的URL列表發送給爬蟲。網頁抓取好之后被發送到存儲服務器（圖1中的Store Server）。接著存儲服務器將抓取來的網頁壓縮并存放在倉庫(repository)里。每一個網頁都有一個與之相關的ID，叫docID。在一個網頁里每發現一個新的URL，就會賦予它一個ID。索引功能由索引器（圖1中的indexer）和排序器（圖1中的sorter）完成。索引器有很多功能。它從倉庫中讀取，解壓并分析文檔。每個文檔都被轉化成一個詞的集合，詞出現一次叫做一個命中（hits）。每條命中記錄了一個詞，這個詞在文檔中的位置，字體大小的近似值以及大小寫信息。索引器將這些命中分布到一系列“桶”（barrels）里面，建立一個半排序(partially sorted)的正排索引(forward index)。索引器還有一個重要的功能。它解析出每張網頁里面的所有鏈接，并把這些鏈接的相關重要信息存放在一個錨(anchors)文件里。這個文件包含了足夠的信息，以顯示每個鏈接從哪里連接過來，鏈到哪里和鏈接的描述。
URL分解器（URLresolver）讀取錨文件，將相對URL轉化為絕對URL，再轉化成docID。它為錨文本建立一個正排索引，并與錨指向的docID關聯起來。它還產生一個有docID對組成的鏈接數據庫。這個鏈接數據庫喲功能來計算所有文件的PageRank值。
排序器(sorter)對按照docID排序的(這里做了簡化，詳情見4.2.5小節)“桶”(barrels)重新按照wordID排序，用于產生倒排索引(inverted index)。這個操作在恰當的時候進行，所以需要很少的暫存空間。排序器還在倒排索引中建立一個wordID和偏移量的列表。一個叫DumpLexicon的程序把這個列表與由索引器產生的詞典結合起來，生成一個新的詞典，供搜索器（searcher）使用。搜索器由一個Web服務器運行，根據DumpLexicon產生的詞典，倒排索引和PageRank值來回答查詢。
4.2 主要的數據結構
Google的數據結構經過了優化，這樣大量的文檔能夠在較低的成本下被抓取，索引和搜索。盡管CPU和I/O速率這些年以驚人的速度增長，但是每一個磁盤查找操作仍需要大概10微秒才能完成。Google在設計時盡量避免磁盤查找，這一設計也大大影響了數據結構的設計。
4.2.1 BigFiles
BigFiles是分布在不同文件系統下面的虛擬文件，通過64位整數尋址。虛擬文件被自動分配到不同文件系統。BigFiles的包還負責分配和釋放文件描述符（譯者注：牽涉到操作系統底層），因為操作系統提供的功能并不能滿足我們的要求。BigFiles還支持基本的壓縮選項。
4.2.2 數據倉庫（Repository）
[img]http://infolab.stanford.edu/~backrub/repos.gif[/img]
圖2. 數據倉庫的結構
數據倉庫包括了每個web頁面的整個HTML代碼。每個頁面用zlib（參見RFC1950）壓縮。壓縮技術的選擇是速度和壓縮比的一個權衡。我們選擇zlib是因為它的壓縮速度要比bzip快很多。在數據倉庫上，bzip的壓縮比是4：1，而zlib的是3：1。在數據倉庫中，文檔一個一個連接存放，每個文檔有一個前綴，包括docID，長度和URL（如圖2）。要訪問這些文檔，數據倉庫不再需要其他的數據結構。這使得保持數據一致性和開發都更簡單；我們可以僅僅通過數據倉庫和一個記錄爬蟲錯誤信息的文件來重建其他所有的數據結構。
4.2.3 文檔索引（Document Index）
文檔索引保存了每個文檔的信息。它是一個根據docID排序的定長(fixed width)ISAM（索引順序訪問模式Index sequential access mode）索引。這些信息被存放在每個條目(entry)里面，包括當前文檔狀態，指向數據倉庫的指針，文檔校驗和(checksum)和各種統計數據。如果文檔已經被抓取了，它還會包括一個指針，這個指針指向一個叫docinfo的變長(variable width)文件，里面記錄了文檔的URL和標題。否則，這個指針將指向一個URL列表，里面只有URL。這樣設計的目的是為了有一個相對緊湊的數據結構，在一次搜索操作中只需要一次磁盤查找就能取出一條記錄。
另外，還有一個文件用來將URL轉化成docID。這個文件是一個列表，包括URL校驗和(checksum)和對應的docID，根據校驗和排序。為了找到某一個URL的docID，首先計算URL的校驗和，然后在校驗和文件里做一次二分查找，找到它的docID。URL轉化成docID是通過文件合并批量操作的。這個技術是在URL分解器（URL resolver）把URL轉化成docID時使用的。這種批量更新的模式很關鍵，因為如果我們為每個鏈接做一次磁盤查找，一個磁盤需要1個月的時間才能為我們的3.22億條鏈接的數據集完成更新。
4.2.4 詞典（Lexicon）
詞典多種不同格式。與早前的系統相比，一個重要的變化是現在的詞典可以以合理的成本全部放在內存里面。目前的實現中，我們把詞典放在一個256M的主存里面。現在的詞典有1.4千萬單詞（盡管一些非常用詞沒有被包含進來）。它由兩部分實現——一個單詞列表（連接在一起，但是通過空白nulls分開）和一個指針的哈希表(hash table)。單詞列表還有一些附加信息，但是這些不在本篇文章的討論范圍。
4.2.5 命中列表（Hit Lists）
一個命中列表對應著一個單詞在一個文檔中出現的位置、字體和大小寫信息的列表。命中列表占用了正排索引和倒排索引的大部分空間，所以怎樣盡可能有效的表示是很重要的。我們考慮了對位置，字體和大小寫信息的多種編碼方式——簡單編碼（3個整數），壓縮編碼（手工優化分配比特）和霍夫曼編碼（Huffman coding）。命中（hit）的詳情見圖3。
[img]http://infolab.stanford.edu/~backrub/barrels.gif[/img]
圖3. 正、倒排索引和詞典
我們的壓縮編碼每個命中用到兩個字節(byte)。有兩種命中：特殊命中（fancy hit）和普通命中（plain hit）。特殊命中包括在URL，標題，錨文本和meta標簽上的命中。其他的都是普通命中。一個普通的命中包括一個表示大小寫的比特(bit)，字體大小，和12個bit表示的單詞在文件中的位置（所有比4095大的位置都被標示為4096）。字體在文檔中的相對大小用3個比特表示（實際上只用到7個值，因為111標示一個特殊命中）。一個特殊命中包含一個大小寫比特，字體大小設置為7用來表示它是一個特殊命中，4個比特用來表示特殊命中的類型，8個比特表示位置。對于錨命中，表示位置的8個比特被分成兩部分，4個比特表示在錨文本中的位置，4個比特為錨文本所在docID的哈希（hash）值。由于一個詞并沒有那么多的錨文本，所以短語搜索受到一些限制。我們期望能更新錨命中的存儲方式能讓位置和docID哈希值能有更大的范圍。我們使用在一個文檔中的相對字體大小是因為在搜索時，你并不希望對于內容相同的不同文檔，僅僅因為一個文檔字體比較大而有更高的評級（rank）。
命中列表的長度存在命中的前面。為了節省空間，命中列表的長度在正排索引中與wordID結合，在倒排索引中與docID結合。這樣就將長度分別限制在8個比特和5個比特（有一些技巧可以從wordID中借用8個比特）。如果長度超過了這個范圍，會在這些比特中使用轉義碼，在接下來的兩個字節(byte)里才存放真正的長度。
4.2.6 正排索引（Forward Index）
正排索引實際上已經部分排序（partially sorted）。它被存放在一系列的桶（barrels）里面（我們用了64個）。每個桶保存了一定范圍內的wordID。如果一個文檔包含了屬于某個桶的單詞，它的docID將被記錄在桶里面，后面接著一個wordID的列表和相應的命中列表。這種結構需要一點多余空間，因為存儲了重復的docID，由于桶的數量很小，所以存儲空間的差別很小，但是它能在排序器（sorter）建立最終索引的時候大大節省時間并降低了程序復雜度。更進一步，我們并沒有存儲完整的wordID，而是存儲每個wordID相對于其對應的桶里面最小wordID的差距。這樣我們只用到了24個比特，從而為命中列表長度（hit list length）留出了8個比特。
4.2.7 倒排索引（Inverted Index）
倒排索引與正排索引有著相同的桶，但是它們是先經過排序器處理過的。對每一個合法的wordID，詞典包含了一個指向對應的桶的指針。它指向一個docID的列表和相應的命中列表。這個文檔列表顯示了有這個單詞出現的所有文檔。
一個重要的事情是如何對這個文檔列表排序。一個簡單的方法是按照docID排序。在多個單詞的查詢中，這種方法可以快速地完成兩個文檔列表的歸并。另一種方案是按照這個詞在文檔中出現的評分(ranking)排序。這種方式使得單個詞的查詢相當簡單，并且多詞查詢的返回結果也很可能接近開頭（譯者注：這句不是很理解）。但是，歸并要困難得多。而且，開發也會困難得多，因為每次評分函數變動就需要重新建立整個索引。我們綜合了兩種方案，設計了兩個倒排桶集合——一個集合只包括標題和錨命中（譯者注：后面簡稱短桶），另一個集合包含所有的命中（譯者注：后面簡稱全桶）。這樣我們首先檢查第一個桶集合，如果沒有足夠的匹配再檢查那個大一點的。
4.3 網頁抓取（Crawling the Web）
運行網絡爬蟲是一項很有挑戰性的任務。這里不光涉及到巧妙的性能和可靠性問題，更重要的，還有社會問題。抓取是一個很脆弱的應用，因為它需要與成百上千各種各樣的web服務器和域名服務器交互，這些都不在系統的控制范圍之內。
為了抓取幾億網頁，Google有一個快速的分布式爬蟲系統。一個單獨的URL服務器（URLserver）為多個爬蟲(crawler,一般是3個)提供URL列表。URL服務器和爬蟲都用Python實現。每個爬蟲同時打開大概300個連接(connecton)。這樣才能保證足夠快地抓取速度。在高峰時期，系統通過4個爬蟲每秒鐘爬取100個網頁。這大概有600K每秒的數據傳輸。一個主要的性能壓力在DNS查詢(lookup)。每個爬蟲都維護一個自己的DNS緩存，這樣在它抓取網頁之前就不再需要每次都做DNS查詢。幾百個連接可能處于不同的狀態：查詢DNS，連接主機，發送請求，接受響應。這些因素使得爬蟲成為系統里一個復雜的模塊。它用異步IO來管理事件，用一些隊列來管理頁面抓取的狀態。
事實證明，爬蟲連接了50多萬個服務器，產生了幾千萬條日志信息，會帶來大量的電子郵件和電話。因為很多人在網上，他們并不知道爬蟲是什么，因為這是他們第一次見到。幾乎每天，我們都會收到這樣的電子郵件：“哇，你看了好多我站上的頁面，你覺得怎么樣？”也有很多人并不知道爬蟲禁用協議（robots exclusion protocol），他們認為可以通過在頁面上聲明“本頁面受版權保護，拒絕索引”就可以保護頁面，不用說，網絡爬蟲很難理解這樣的話。而且，由于涉及到大量的數據，一些意想不到的事情總會發生。比如，我們的系統試圖去抓取一個在線游戲。這導致了游戲中出現大量的垃圾消息！這個問題被證實是很容易解決的。但是往往我們在下載了幾千萬個頁面之后這個問題才被發現。因為網絡頁面和服務器總是在變化中，在爬蟲正式運行在大部分的互聯網站點之前是不可能進行測試的。不變的是，總有一些奇怪的錯誤只會在一個頁面里面出現，并且導致爬蟲崩潰，或者更壞，導致不可預測的或者錯誤的行為。需要訪問大量互聯網站點的系統需要設計得很健壯并且小心地測試。因為大量像爬蟲這樣的系統持續導致問題，所以需要大量的人力專門閱讀電子郵件，處理新出現遇到的問題。
4.4 網站索引（Indexing the Web）
解析——任何被設計來解析整個互聯網的解析器都必須處理大量可能的錯誤。從HTML標簽里面的錯別字到一個標簽里面上千字節的0，非ASCII字符，嵌套了幾百層的HTML標簽，還有大量超乎人想象的錯誤和“創意”。為了達到最快的速度，我們沒有使用YACC產生CFG（context free gramma，上下文無關文法）解析器，而是用flex配合它自己的棧生成了一個詞法分析器。開發這樣一個解析器需要大量的工作才能保證它的速度和健壯。
為文檔建立桶索引——每一個文檔解析過后，編碼存入桶里面。每一個單詞被內存里的哈希表——詞典轉化成一個wordID。詞典哈希表新加的內容都被記錄在一個文件里。單詞在被轉化成我wordID的時候，他們在當前文檔中的出現會被翻譯成命中列表，并寫入正排桶(forward barrels)中。建立索引階段的并行操作主要的困難在于詞典需要共享。我們并沒有共享整個詞典，而是在內存里保存一份基本詞典，固定的1千4百萬個單詞，多余的詞寫入一個日志文件。這樣，多個索引器就可以同時運行，最后由一個索引器來處理這個記錄著多余單詞的小日志文件。
排序——為了產生倒排索引，排序器取出各個正排的桶，然后根據wordID排序來產生一個標題和錨命中的倒排桶，和一個全文的倒排桶。每次處理一個桶，所以需要的暫存空間很少。而且，我們簡單地通過用盡可能多的機器運行多個排序器做到排序的并行化，不同的排序器可以同時處理不同的桶。因為桶并不能全部放在主存里面，排序器會根據wordID和docID將它們進一步分割成可以放在內存里面的桶(basket)。接著，排序器將每個桶載入內存，排好序，把內容寫入短的倒排桶和完整的倒排桶。
4.5 搜索（Searching）
搜索的目標是高效地返回高質量的結果。很多大型的商業搜索引擎在效率方面看起來都有很大的進步。所以我們更專注于搜索結果的質量，但是我們相信我們的解決方案只要花一點精力就可以很好的應用到商業的數據上。Google的查詢評估流程如圖4。
為了限制響應時間，一旦某個數量(現在是40,000)的匹配文檔被找到，搜索器自動跳到圖4中的第8步。這意味著有可能返回次優的結果。我們現在在研究新的方法來解決這個問題。在過去，我們根據PageRank值排序，有較好的效果。
解析查詢（Query）。
把單詞轉化成wordID。
從每個單詞的短桶文檔列表開始查找。
掃描文檔列表直到有一個文檔匹配了所有的搜索詞語。
計算這個文檔對應于查詢的評分。
如果我們到達短桶的文檔列表結尾，從每個單詞的全桶(full barrel)文檔列表開始查找，跳到第4步。
如果我們沒有到達任何文檔列表的結尾，跳到第4步。
根據評分對匹配的文檔排序，然后返回評分最高的k個。
圖4 Google查詢評估
4.5.1 評分系統（The Ranking System）
Google比典型的搜索引擎維護了根多的web文檔的信息。每一個命中列表（hitlist）包含了位置，字體和大小寫信息。而且，我們綜合考慮了錨文本命中和頁面的PageRank值。把所有的信息綜合成一個評分是很困難的。我們設計了評分函數保證沒有一個因素有太大的影響。首先，考慮簡單的情況——一個單詞的查詢。為了對一個單詞的查詢計算文檔的分值，Google首先為這個單詞查看這個文檔的命中列表。Google將命中分為不同類型（標題，錨，URL，普通文本大字體，普通文本小字體，……），每一種類型都有自己的類型權重值（type-weight）。類型權重值構成一個由類型尋址（indexed）的向量。Google數出命中列表中每種類型命中的數量。每個數量轉化成一個數量權重（count-weight）。數量權重開始隨著數量線性增長，但是很快停止增長，以保證單詞命中數多于某個數量之后對權重不再有影響。我們通過數量權重向量和類型權重向量的點乘為一個文檔算出一個IR分數。最后這個IR分數與PageRank綜合產生這個文檔最終的評分。
對于一個多詞搜索，情況要更復雜。現在，多個命中列表必須一次掃描完，這樣一個文檔中較近的命中才能比相距較遠的命中有更高的評分。多個命中列表里的命中結合起來才能匹配出相鄰的命中。對每一個命中的匹配集(matched set)，會計算出一個接近度。接近度是基于兩個命中在文檔（或錨文本）中相隔多遠計算的，但是被分為10個等級從短語匹配到“一點都不近”。不光要為每一種類型的命中計數，還要為每一種類型和接近度都計數。每一個類型和接近度的組有一個類型-接近度權重（type-prox-weight）。數量被轉化成數量權重。我們通過對數量權重和類型-接近度權重做點乘計算出IR分值。所有這些數字和矩陣都會在特殊的調試模式下與搜索結果一起顯示出來。這些顯示結果在開發評分系統的時候很有幫助。
4.5.2 反饋（Feedback）
評分函數有很多參數比如類型權重和類型-接近度權重。找出這些參數的權重值簡直就跟妖術一樣。為了調整這些參數，我們在搜索引擎里有一個用戶反饋機制。一個被信任的用戶可以選擇性地評價所有的返回結果。這個反饋被記錄下來。然后在我們改變評分系統的時候，我們能看到修改對之前評價過的搜索結果的影響。盡管這樣并不完美，但是這也給我們一些改變評分函數來影響搜索結果的想法。
5 結果與表現
衡量一個搜索引擎最重要的標準是其搜索結果的質量。雖然如何做一個完整的用戶評估超越了本文的范圍，但是我們在Google身上得到的經驗，表明它提供結果，比主要商用搜索引擎對絕大多數搜索提供的結果更好。圖表4 表示的 Google對于搜索“比爾.克林頓”的結果，作為一個例子可以說明，對PageRank, anchor text （關鍵詞）,和proximity（相似度）的使用。這樣的搜索結果顯示了Google的特色。搜索結果被服務器串聯在一起。這樣的方法當在需要對結果集篩選時非常有用。很大數量的結果會來自域名whitehouse.gov，有理由相信這個來源含有本次該搜索中被期望找到的結果。當前，絕大多數主要的商用搜索引擎不會返回任何來自whitehouse.gov的結果，更不用說正確的結果。注意，第一個搜索到的連接沒有標題，是因為它不是抓取得結果，而是Google 基于anchor text 決定這個結果是查詢所期望得到的好結果。同樣的，第15號結果是一個電子郵件地址，當然這也是基于anchor text的結果，而非可抓取得結果。
所有結果都是合理的高質量頁面，而且最后檢查，沒有壞連接。這主要歸功于他們有很高的PageRank。PageRank的百分比使用紅色條形圖表示。最后，這里的結果中，沒有只有Bill沒有Clinton 或只有 Clinton 沒有Bill 的，這是因為我們在關鍵詞出現時使用了非常重要的proximity。當然對一個實際的對搜索引擎的質量測試應該包括廣泛的對用戶研究或者對搜索結果的分析，但是我們沒有時間做以上析。但是我們邀請讀者在 [url]http://google.stanford.edu/flp[/url] 自己測試Google。
5.1 存儲需求
除搜索質量外，Gooogle被設計為能夠消化互聯網規模不斷增長帶來的效能問題。一方面，使用高效存儲。表一是對Google的統計與存儲需求的詳細分類，由于壓縮后的存儲體積為53GB，為源數據的三分之一多一點。就當前的硬盤價格來說可以為有用資源提供廉價的相關存儲設備。更重要的是，搜索引擎使用的所有數據的總合需要相應的存儲大約為55GB。此外，大多數查詢能被要求充分使用短反向索引 [short inverted index]，在更好的編碼與壓縮文檔索引后，一個高質量的網絡搜索引擎可能只需要一臺有7GB存儲空間的新電腦。
5.2 系統性能
這對搜索引擎的抓取與索引來說很重要。這樣信息被轉化為數據的速度以及系統主要部分改變后被測試的速度都相對更快。就Google來說，主要操作包括：抓取，索引和排序。一旦硬盤被填滿、或命名服務器崩潰，或者其它問題導致系統停止，都很難度量抓取所需要化費的時間。全部花費在下載2千6百萬個頁面[包括錯誤頁面]的時間大概是9天。但是如果系統運行更為流暢，這個過程還可以更快，最后的1千1百個頁面只使用了63個小時，平均4百萬每天，每秒48.5頁。索引的運行速度快于抓取速度的重要原因是我們花費了足夠的時間來優化索引程序，使它不要成為瓶頸。優化包括對本地硬盤上的文檔的索引進行大規模的升級和替換關鍵的數據結構。索引的速度達到大概54頁每秒。排序可以完全平行作業，使用四臺機器，整個處理時間花費近24個小時。
5.3 搜索性能
提高搜索性能并不是本次我們研究的重點。當前版本的Google返回多數查詢結果的時間是1到10秒。這個時間主要受到硬盤IO以及NFS[網絡文件系統，當硬盤安置到許多機器上時使用] 的限制。進一步說，Google沒有做任何優化，例如查詢緩沖區，常用詞匯子索引，和其它常用的優化技術。我們傾向于通過分布式，硬件，軟件，和算法的改進來提高Google的速度。我們的目標是每秒能處理幾百個請求。表2有幾個現在版本Google響應查詢時間的例子。它們說明IO緩沖區對再次搜索速度的影響。
另外一篇參考譯文：[url]http://blog.csdn.net/fxy_2002/archive/2004/12/23/226604.aspx[/url]
原作者: Sergey Brin and Lawrence Page譯者: 雷聲大雨點大 (Blog)
譯者：本文是谷歌創始人Sergey和Larry在斯坦福大學計算機系讀博士時的一篇論文。發表于1997年。Google的一切應該都起源與此。深入了解Google，深入了解互聯網的未來，當讀此文。我把全文分成6個部分，推薦到這里。有興趣的朋友可以一起來翻譯。
我沒有發現本文的完整中譯，只找到了這個片段，由xfygx朋友翻譯了本文的第一部分，其他似乎沒有全部完成。
所以，這部分譯文是xfygx原作，而非我的翻譯！我只是就自己的理解做了些改動。如果有幸xfygx朋友能看到我在他/她博客的留言，來我們譯言，我非常希望能把本文轉到他/她名下。
另外，如果您發現已有其他出色的完整中譯版了，請告訴我們。免得譯者們重復勞動。
摘要
在本文中，我們將介紹Google，一個充分利用超文本文件（譯者：即HTML文件）結構進行搜索的大規模搜索引擎的原型。Google可以有效地對互聯網（Web）資源進行爬行搜索（crawl）〔注 1〕和索引，比目前已經存在的系統有更令人滿意的搜索結果。該原型的數據庫包括2400萬頁面的全文和之間的鏈接，可通過[url]http://google.stanford.edu/[/url]訪問。
設計搜索引擎是一項富有挑戰的任務。搜索引擎為數以億計的網頁建立索引，而這些網頁包含了同樣數量級的不同詞語。每天響應數千萬計的查詢請求。盡管大規模網絡搜索引擎是很重要的，但在這個領域很少有理論研究。更由于技術的飛速發展和互聯網的普及，今天這樣的搜索引擎和三年前的搜索引擎會是非常不同的。本文對我們的大規模搜索引擎進行了深入的討論，這也是目前為止我們所知道的公開發表的第一篇如此詳細的討論。
除了如何把傳統的搜索技術擴展到前所未有的海量數據，我們還面臨這樣一個新的技術挑戰：如何使用超文本文件所蘊含的擴展信息以產生更好的搜索結果。本文討論了如何建立一個實用的大規模系統，以利用超文本文件中的額外信息。另外，我們也關注了如何有效處理超文本文件不可控的問題，因為人們可以隨意發表超文 本文件（譯者：如個人網頁）。
關鍵詞
World Wide Web, Search Engines, Information retrieval, PageRank, Google
1.簡介
互聯網對信息檢索（Information Retrieval）領域產生了新的挑戰。網上的信息數量是在不斷的快速增長，同時有越來越多對網絡搜索毫無經驗的新用戶上網。在網上沖浪時，人們一般會利用網絡的“鏈接圖”（譯者：想像每個網頁是一個點，網頁之間的鏈接是從一個點指向另一個點的邊，這就構成了一張有向圖。）。而這經常從一個人工維護的網址列表（如Yahoo!）或是一個搜索引擎開始。人工維護的列表有效覆蓋了流行的主題，但這些是主觀的，花費高昂，更新緩慢，并且不能覆蓋全部的主題，特別是冷僻的主題。依賴關鍵詞匹配的自動搜索引擎通常返回太多的低質量的匹配結果。更糟的是，一些廣告商通過某些方式誤導搜索引擎以試圖吸引人們的注意力。我們建立了一個大規模搜索引擎來解決已存在系統的許多問題。它充分利用超文本文件所表達額外信息來提供更高質量的搜索結果。我們選擇這個名字，Google，是因為它是googol（表示10的100次方)這個詞的常用拼寫法。而這個詞的意義與我們建立這個大規模搜索引擎的目標是非常一致的。
1.1 互聯網搜索引擎 -- 擴展：1994 - 2000
搜索引擎技術必須極大規模地擴展才能趕上互聯網的發展步伐。在1994年,最早的 web搜索引擎之一，World Wide Web Worm(WWWW) [McBryan 94]已經索引了11萬web頁面和文檔。到了1997年的11月，頂級的搜索引擎聲稱的索引的頁面數量從2百萬(WebCrawler) 到10億(根據 Search Engine Watch)。可以想像到2000年，索引全部的Web將需要包含超過十億的文檔。同時，搜索引擎需要處理的查詢請求也會有不可想像的增長。在1994年 3月到4月間，World Wide Web Worm平均每天收到1500個查詢。而到了1997年的11月，Altavista聲稱 它平均每天要處理大約2千萬的查詢。隨著web的用戶和使用搜索引擎的自動系統數量的增加，到2000年，頂級的搜索引擎每天將會需要處理數以億計的查詢。我們的系統的目標是解決這些由搜索引擎大規模擴展所帶來的問題，包括質量和可擴展性。
1.2 Google:與Web同步發展
即便建立一個適應今天互聯網信息量的搜索引擎已經面臨著許多的挑戰。我們需要使用快速爬行搜索技術收集web文檔并保持它們的及時更新；我們需要可以有效存儲文檔索引和文檔自身（這不是必須的）的海量存儲空間；我們需要可以有效處理數百GB數據的索引系統；我們還需要可以在一秒內處理成百上千的查詢的計算能力。
這些任務都隨著Web的增長而愈發變的困難。然而，硬件性能的提高和費用的降低可以部分的抵消這些困難。但某些方面是個例外，如硬盤數據讀取的速度和操作系統的魯棒性（譯者：可以通俗地理解為穩定性）都沒有顯著提高。在設計Google的過程中，我們已經考慮到了Web 和技術這兩方面的發展。Google被設計為可以適應極大數據量。它有效使用存儲空間來保存索引。它的數據結構被優化以便可以快速和有效的存取數據（見 4.2節)。另外，我們認為，相對于文本以及HTML文檔數量的增長，索引和存儲花費它們的費用最終會下降(見附錄B)。因此，Google這樣的集中式（譯者：而非分布到許多遠程計算機，如P2P系統）搜索系統隨著互聯網的發展而擴容就成為可能。
1.3 設計目標
1.3.1 提高搜索質量
我們的主要目標是提高web搜索引擎的質量。在1994年，一些人認為用一個完整的搜索索引就可以很容易地找到任何信息。在1994年互聯網最佳－－導航員上，有這樣的話"最好的導航服務應該是使用戶可以很容易的在Web上找到任何信息"。然而，到1997，這個任務仍是非常困難的。在最近使用搜索引擎的用戶都可以很容易的證實索引的完整性并不是決定搜索結果質量的唯一因素。"垃圾結果" 經常會使用戶找不到真正感興趣的結果。實際上，到1997年的十一月，四個頂級搜索引擎中，僅僅只有一個可以在搜索時發現它自身(對查詢自己名字的請求，返回結果中將自己排在結果中的前十名)。產生這個問題的主要原因之一是在這些搜索引擎的索引庫中文檔的數量成數量級地增長，而用戶看這么多文檔的能力卻不可能這樣增長。用戶往往只看結果中的前數十個。因此，隨著文檔規模的增加，我們需要工具來提高查準率（在前十個結果中返回相關內容）。實際上，我們說的"相關"是指最好的那一份，因為可能會有幾萬份“稍微“相關的文檔。查準率在我們的眼中是如此的重要，以至于我們甚至愿意為此損失一些查全率。最近的研究顯示，超文本文件中的信息可以有助于提高搜索和其他應用[Marchiori 97] [Spertus 97] [Weiss 96] [Kleinberg 98]。特別是網頁鏈接的結構，以及鏈接本身的文字，為相關性判定和進行質量的篩選提供了許多信息。Google使用了網頁鏈接結構和錨（譯者：HTML中的語法，表示一個指向網頁的鏈接）鏈接中的文字。（詳見2.1和2.2節）
1.3.2 搜索引擎的理論研究
隨著WEB的巨大發展，互聯網也越來越商業化。在1993年，只有1.5%的web服務器是.com的域名。而到了1997年，這個數字已經變成了60%。同時，搜索引擎的從學術研究變成了商業性質。到目前為止，大多數的搜索引擎的開發都是由公司來進行的，很少有詳細的技術資料被公開。這導致了這項技術帶有了許多神秘的色彩，并且是以廣告為主（見附錄A）。對于Google，我們有一個非常重要的目標就是推動搜索引擎在學術界的發展和理解。
另外的重要的設計目標是建立一個可以讓一定數量的用戶實際使用的系統。用戶使用對我們來說非常重要，因為我們認為真正利用了現代互聯網系統的海量數據的研究才是最有價值的。比如現在每天有數千萬用戶查詢，但由于這些數據被認為具有商業價值，很難拿來作學術研究。
我們最終的設計目標是建立一個可以支持在大規模互聯網數據上進行研究活動的系統構架。為了支持研究活動，Google存儲了全部的在爬行搜索中發現的實際數據，并壓縮起來。主要的目標之一是建立一個環境，在這個環境中，研究者可以很快的利用這個難得的系統，處理web數據，產生令人感興趣的結果。在短時間內系統就被建立起來，已經有一些論文使用了通過Google生成的數據庫。還有許多其它的項目在進行之中。另外的目標是我們希望建立一個類似空間站的環境，使得研究者，甚至是學生可以在我們的大規模web數據上進行實驗。
〔注 1〕爬行搜索，Crawl，是指搜索引擎會跟隨網頁間的鏈接從一個網頁“爬行”到下一個網頁。而對每一個網頁的分析和記錄，或者這個過程的結果，則稱為“索引”。
2.系統功能
Google搜索引擎通過兩個重要功能來產生高精確度的結果。第一，它利用互聯網的鏈接結構為每個網頁計算出一個高質量的排名。這個排名被稱為PageRank[注一]，具體在Larry Page98年的論文[Page 98]中有詳述。第二，Google利用鏈接本身來提高搜索結果的質量。
2.1 PageRank: 給互聯網帶來秩序
現有的搜索引擎在很大程度上忽略了一個重要資源－－把互聯網看做是一個引用關系（鏈接關系）圖（見第一部分的注解）。我們已經產生了包含5億1千8百萬這樣的超文本鏈接（就是網頁指向網頁的鏈接）的地圖－－這是對整個互聯網的一個相當顯著的采樣。這樣的地圖讓我們能快速計算網頁的“PageRank”－－一個對于網頁被引用程度的客觀衡量，而被引用程度與人們對于網頁重要性的主觀認識也很好地吻合。由于這樣的吻合，PageRank成為對用關鍵字搜索網頁返回的結果進行排序的極好方式。對于最熱門的分類，局限于網頁標題進行簡單的文字查找，PageRank排序后的搜索結果效果極好。而在整個Google系統中進行全文查找，PageRank的作用也是非常顯著的。
2.1.1 PageRank 計算簡述
學術文獻的引用機制被應用到互聯網上－－主要就是計算一個網頁被引用，或被反向鏈接的次數。這給出了對一個網頁重要性或質量的估計。PageRank進一步發展了這個想法：來自不同頁面的鏈接被給以不同的權重，并依據一個網頁上鏈接的個數正態化。PageRank的定義如下：
我們假定網頁 A 有若干其他網頁（T1...Tn）指向它（即引用關系）。參數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)可以通過一個簡單的循環算法來計算。這對應于正態化后的互聯網鏈接矩陣的主要艾根向量的計算。另外，2千6百萬網頁的PageRank可以在一臺中型服務器上，通過幾小時的計算完成。這里有很多細節超出了本論文的討論范圍。
2.1.2 直觀解釋
PageRank 可以被想像成一個對用戶行為建立的模型。我們假想一個“隨機上網者”；隨機地給他一個網頁；他漫無目的地點擊網頁的鏈接，而從來不點“返回鍵”；最終他覺得煩了，又從另一個隨機的網頁從新開始。在上述模型中，“隨機上網者”訪問一個頁面的概率就是這個頁面的PageRank。而阻尼系數d，則是我們的“隨機上網者”在訪問了一個頁面后，覺得煩了，開始訪問一個新的頁面的概率。上述模型的一個重要變形是把阻尼系數d加到一個網頁上，還是加到一組網頁上。這個變形使得故意欺騙系統獲得高排名的企圖幾乎變成不可能的。我們對PageRank有若干延伸，詳見這里[Page 98]。
另一個直觀的解釋是如果有很多其他網頁指向一個頁面，或者其他有很高PageRank的網頁指向這個頁面，該頁面應該有較高的PageRank。直覺告訴我們，如果一個網頁被互聯網上的很多其他網頁引用，它應該是值得關注的。而那些只有一個引用的頁面，如果它來自象Yahoo!首頁，那大約這個網頁也值得看看。如果一個網頁質量不高或根本就是一個死鏈接，Yahoo首頁多半不會鏈接它。PageRank 考慮了上述兩種以及之間的各種情況，它用遞歸方式把網頁的權重通過互聯網的鏈接結構傳播出去。
2.2 錨鏈接（Anchor，是HTML的語法，即網頁鏈接）的文本
鏈接的文字在我們的搜索引擎中受到特殊處理。大多數搜索引擎把鏈接中的文本部分（比如keso這個鏈接中的keso）歸屬于這個鏈接所在的網頁。而我們除此之外，還把它歸屬于這個鏈接指向的頁面。這有幾個好處。第一，錨鏈接對被指向網頁的描述，通常比網頁本身的描述更準確。第二，錨鏈接可能指向那些不能被建立文本索引的文檔，如圖片、程序、數據庫。這使得現在不能爬行搜索的頁面可以被搜索到了。注意，以前從未被爬行搜索過的頁面可能會產生問題，因為它們的有效性從未被驗證過。比如搜索引擎甚至會返回一個有鏈接指向，但其實根本不存在的頁面。然而，由于我們可以對結果排序，這個問題很少會出現。
把錨鏈接中的文本傳播到被指向的頁面這個想法，在World Wide Web Worm [McBryan 94] 已經被實施了。主要用于對非文本文件的搜索，和把搜索結果擴展到更多下載文檔。而我們使用錨鏈接，主要是因為它可以提供高質量的結果。有效使用錨鏈接在技術上是很難實現的，因為大量數據需要處理。在我們現在爬行搜索過的2千4百萬網頁中，我們為2億5千9百萬錨鏈接建立了索引。
2.3 其他功能
除了使用PageRank和利用錨鏈接中的文本外，Google還有其他一些功能。第一，它有所有網頁的位置信息，因此在搜索過程中充分應用了接近程度。第二，Google 記錄網頁的一些視覺表現，如單詞的字體大小。大字體的權重比小字體要高。第三，完整的原始HTML頁面被保存下來（即Google的網頁快照功能）。
[注一] PageRank 可以譯為網頁排名，建議后面就用原文了。另外，Page 恰恰是Google創始人之一Larry Page的姓。
3相關工作
基于web的搜索研究有一段簡短的的歷史。萬維網蠕蟲( wwww )[ mcbryan 94 ]是第一個網上搜索引擎。但隨后,產生了幾個學院派的搜索引擎,其中有不少現在已經是公開的上市公司了。相比Web的增長和搜索引擎的重要性,現在幾乎沒有關于當前搜索引擎有價值的研究材料 [Pinkerton 94].。據邁克爾.茂丁( lycos公司首席科學家)[Mauldin] "各種服務(包括lycos )緊密的守衛著這些數據庫" 。
不過,在搜索引擎的具體的特點上已進行了相當的工作。對現有商業搜索引擎產生的搜索結果的后處理已經取得了卓有成效的成果,或是產生小規模的“個性化的“搜索引擎。最終,有過不少針對信息檢索系統的研究,尤其是對受控制的結果集的研究。在隨后兩節中,我們將討論一些必須擴大研究的領域,以便更好地在Web上工作。
3.1信息檢索
信息檢索系統的研究,已經有很多年了,并且成果顯著[Witten 94] 。 然而,大多數信息檢索系統 的 研究 針對的是 受控制的同質集合 ，例如,主題相關的科學論文或新聞故事。的確,信息檢索的主要的基準,文本檢索會議[TREC 96] ,用了一個相當小的，并且受控制的集合 作為其基準。“非常大的語料庫“; 基準只有20gb 大小， 相較于我們搜索過的 2千4百萬網頁，有147gb 的數據量 。在TREC 上工作很好的搜索引擎，拿到Web上來往往效果不佳。舉例來說,標準向量空間模型試圖返回和搜索條件最為近似的文件,假定搜索和文件都是各自文字定義的向量。對Web 而言,這種策略只會返回非常簡短的文件，包含查詢本身和幾句話。舉例來說,我們已經看到了一個主要的搜索引擎返回的一個頁面僅僅含有“比爾.克林頓真糟“;和從“比爾.克林頓“搜索來的圖片。 有人爭論到 ,在Web上用戶應該更具體,更準確地指出他們要什么,并且在搜索查詢中增添更多詞。我們堅決反對這種立場。如果用戶發出對“比爾克林頓“的搜索查詢 ,他們應得到合理的結果,因為就這個話題存在著大量的高品質的資料。鑒于這一類的例子,我們認為標準的信息檢索工作需要擴大范圍，從而有效處理 Web。
3.2 Web和受控集合的不同
互聯網 Web是一個廣闊的充滿完全不受控制的異構文件的集合。Web 上的文件,不但內部格式極其不同,而且外部元信息也未必可用。例如,文件內部的不同,有各自的語言(包括自然語言和編程語言),各自的詞匯(電子郵件地址,鏈接,郵編,電話號碼,產品號碼)，文件格式的不同(文本格式, html格式, pdf格式,圖像格式,聲音格式),并且甚至可能是機器產生的(日志文件或者數據庫的輸出文件) 。在另一方面,我們定義文件的外部元信息，從這些信息就可以推斷出一個文件的大概,但是元信息并不包含在文件中。文件外部元信息的例子,包括這樣一些信息： 來源的聲譽,更新頻率,質量,受歡迎程度 和 用法 , 和引用。不僅是外部元信息的可能來源千差萬別,而且衡量的方式也存在很多不同數量級的差異。舉例來說,比較從一個大型網站的主頁得到的使用信息,如，雅虎，目前每天獲得幾百萬的頁面瀏覽量， 而一個晦澀的歷史文章,可能每10年才能被瀏覽一次。顯而易見,搜索引擎必須嚴重區別對待這兩個條目。
另一個Web 和受控集合的較大差異是,幾乎沒有限制控制人們在網上可以放什么。把這種靈活性的內容發布和產生巨大影響的搜索引擎結合起來 ，去吸引訪問瀏覽量。 并且很多公司通過故意操縱搜索引擎來贏利，日益成為一個嚴重問題。這個問題在傳統的封閉的信息檢索系統中一直沒有發現 。另外,有趣的是我們注意到web搜索引擎使得想通過元數據操縱搜索引擎的努力基本上失敗了,因為網頁上的任何文字如果不是用來呈現給用戶的， 就是被濫用來操縱搜索引擎。甚至有許多公司專門操縱搜索引擎以達到贏利的目的。
（斷斷續續地把它翻完了。第4部分是Google搜索引擎最核心的一塊，有一些設計細節還不是很懂，希望能和大家一起探討。翻譯不當之處還請各位指出，謝謝。）
4 系統剖析（System Anatomy）
首先，我們對架構做一個高層的討論。接著，對重要的數據結構有一個深入的描述。最后，我們將深入分析主要的應用程序：爬蟲，索引和搜索。
4.1 Google架構概述
[img]http://infolab.stanford.edu/~backrub/over.gif[/img]
圖1. Google高層架構
在這一部分，我們將對圖1中整個系統是怎么運行的有一個高層的概述。這一部分沒有提到應用程序和數據結構，這些會在接下來的幾部分里討論。考慮到效率，Google的大部分是用C或C++實現，可以在Solaris或者Linux下運行。
在Google中，網頁抓取（下載web頁面）的工作由分布式的爬蟲（crawlers）完成。有一個URL服務器（圖1中的URL Server）把需要抓取的URL列表發送給爬蟲。網頁抓取好之后被發送到存儲服務器（圖1中的Store Server）。接著存儲服務器將抓取來的網頁壓縮并存放在倉庫(repository)里。每一個網頁都有一個與之相關的ID，叫docID。在一個網頁里每發現一個新的URL，就會賦予它一個ID。索引功能由索引器（圖1中的indexer）和排序器（圖1中的sorter）完成。索引器有很多功能。它從倉庫中讀取，解壓并分析文檔。每個文檔都被轉化成一個詞的集合，詞出現一次叫做一個命中（hits）。每條命中記錄了一個詞，這個詞在文檔中的位置，字體大小的近似值以及大小寫信息。索引器將這些命中分布到一系列“桶”（barrels）里面，建立一個半排序(partially sorted)的正排索引(forward index)。索引器還有一個重要的功能。它解析出每張網頁里面的所有鏈接，并把這些鏈接的相關重要信息存放在一個錨(anchors)文件里。這個文件包含了足夠的信息，以顯示每個鏈接從哪里連接過來，鏈到哪里和鏈接的描述。
URL分解器（URLresolver）讀取錨文件，將相對URL轉化為絕對URL，再轉化成docID。它為錨文本建立一個正排索引，并與錨指向的docID關聯起來。它還產生一個有docID對組成的鏈接數據庫。這個鏈接數據庫喲功能來計算所有文件的PageRank值。
排序器(sorter)對按照docID排序的(這里做了簡化，詳情見4.2.5小節)“桶”(barrels)重新按照wordID排序，用于產生倒排索引(inverted index)。這個操作在恰當的時候進行，所以需要很少的暫存空間。排序器還在倒排索引中建立一個wordID和偏移量的列表。一個叫DumpLexicon的程序把這個列表與由索引器產生的詞典結合起來，生成一個新的詞典，供搜索器（searcher）使用。搜索器由一個Web服務器運行，根據DumpLexicon產生的詞典，倒排索引和PageRank值來回答查詢。
4.2 主要的數據結構
Google的數據結構經過了優化，這樣大量的文檔能夠在較低的成本下被抓取，索引和搜索。盡管CPU和I/O速率這些年以驚人的速度增長，但是每一個磁盤查找操作仍需要大概10微秒才能完成。Google在設計時盡量避免磁盤查找，這一設計也大大影響了數據結構的設計。
4.2.1 BigFiles
BigFiles是分布在不同文件系統下面的虛擬文件，通過64位整數尋址。虛擬文件被自動分配到不同文件系統。BigFiles的包還負責分配和釋放文件描述符（譯者注：牽涉到操作系統底層），因為操作系統提供的功能并不能滿足我們的要求。BigFiles還支持基本的壓縮選項。
4.2.2 數據倉庫（Repository）
[img]http://infolab.stanford.edu/~backrub/repos.gif[/img]
圖2. 數據倉庫的結構
數據倉庫包括了每個web頁面的整個HTML代碼。每個頁面用zlib（參見RFC1950）壓縮。壓縮技術的選擇是速度和壓縮比的一個權衡。我們選擇zlib是因為它的壓縮速度要比bzip快很多。在數據倉庫上，bzip的壓縮比是4：1，而zlib的是3：1。在數據倉庫中，文檔一個一個連接存放，每個文檔有一個前綴，包括docID，長度和URL（如圖2）。要訪問這些文檔，數據倉庫不再需要其他的數據結構。這使得保持數據一致性和開發都更簡單；我們可以僅僅通過數據倉庫和一個記錄爬蟲錯誤信息的文件來重建其他所有的數據結構。
4.2.3 文檔索引（Document Index）
文檔索引保存了每個文檔的信息。它是一個根據docID排序的定長(fixed width)ISAM（索引順序訪問模式Index sequential access mode）索引。這些信息被存放在每個條目(entry)里面，包括當前文檔狀態，指向數據倉庫的指針，文檔校驗和(checksum)和各種統計數據。如果文檔已經被抓取了，它還會包括一個指針，這個指針指向一個叫docinfo的變長(variable width)文件，里面記錄了文檔的URL和標題。否則，這個指針將指向一個URL列表，里面只有URL。這樣設計的目的是為了有一個相對緊湊的數據結構，在一次搜索操作中只需要一次磁盤查找就能取出一條記錄。
另外，還有一個文件用來將URL轉化成docID。這個文件是一個列表，包括URL校驗和(checksum)和對應的docID，根據校驗和排序。為了找到某一個URL的docID，首先計算URL的校驗和，然后在校驗和文件里做一次二分查找，找到它的docID。URL轉化成docID是通過文件合并批量操作的。這個技術是在URL分解器（URL resolver）把URL轉化成docID時使用的。這種批量更新的模式很關鍵，因為如果我們為每個鏈接做一次磁盤查找，一個磁盤需要1個月的時間才能為我們的3.22億條鏈接的數據集完成更新。
4.2.4 詞典（Lexicon）
詞典多種不同格式。與早前的系統相比，一個重要的變化是現在的詞典可以以合理的成本全部放在內存里面。目前的實現中，我們把詞典放在一個256M的主存里面。現在的詞典有1.4千萬單詞（盡管一些非常用詞沒有被包含進來）。它由兩部分實現——一個單詞列表（連接在一起，但是通過空白nulls分開）和一個指針的哈希表(hash table)。單詞列表還有一些附加信息，但是這些不在本篇文章的討論范圍。
4.2.5 命中列表（Hit Lists）
一個命中列表對應著一個單詞在一個文檔中出現的位置、字體和大小寫信息的列表。命中列表占用了正排索引和倒排索引的大部分空間，所以怎樣盡可能有效的表示是很重要的。我們考慮了對位置，字體和大小寫信息的多種編碼方式——簡單編碼（3個整數），壓縮編碼（手工優化分配比特）和霍夫曼編碼（Huffman coding）。命中（hit）的詳情見圖3。
[img]http://infolab.stanford.edu/~backrub/barrels.gif[/img]
圖3. 正、倒排索引和詞典
我們的壓縮編碼每個命中用到兩個字節(byte)。有兩種命中：特殊命中（fancy hit）和普通命中（plain hit）。特殊命中包括在URL，標題，錨文本和meta標簽上的命中。其他的都是普通命中。一個普通的命中包括一個表示大小寫的比特(bit)，字體大小，和12個bit表示的單詞在文件中的位置（所有比4095大的位置都被標示為4096）。字體在文檔中的相對大小用3個比特表示（實際上只用到7個值，因為111標示一個特殊命中）。一個特殊命中包含一個大小寫比特，字體大小設置為7用來表示它是一個特殊命中，4個比特用來表示特殊命中的類型，8個比特表示位置。對于錨命中，表示位置的8個比特被分成兩部分，4個比特表示在錨文本中的位置，4個比特為錨文本所在docID的哈希（hash）值。由于一個詞并沒有那么多的錨文本，所以短語搜索受到一些限制。我們期望能更新錨命中的存儲方式能讓位置和docID哈希值能有更大的范圍。我們使用在一個文檔中的相對字體大小是因為在搜索時，你并不希望對于內容相同的不同文檔，僅僅因為一個文檔字體比較大而有更高的評級（rank）。
命中列表的長度存在命中的前面。為了節省空間，命中列表的長度在正排索引中與wordID結合，在倒排索引中與docID結合。這樣就將長度分別限制在8個比特和5個比特（有一些技巧可以從wordID中借用8個比特）。如果長度超過了這個范圍，會在這些比特中使用轉義碼，在接下來的兩個字節(byte)里才存放真正的長度。
4.2.6 正排索引（Forward Index）
正排索引實際上已經部分排序（partially sorted）。它被存放在一系列的桶（barrels）里面（我們用了64個）。每個桶保存了一定范圍內的wordID。如果一個文檔包含了屬于某個桶的單詞，它的docID將被記錄在桶里面，后面接著一個wordID的列表和相應的命中列表。這種結構需要一點多余空間，因為存儲了重復的docID，由于桶的數量很小，所以存儲空間的差別很小，但是它能在排序器（sorter）建立最終索引的時候大大節省時間并降低了程序復雜度。更進一步，我們并沒有存儲完整的wordID，而是存儲每個wordID相對于其對應的桶里面最小wordID的差距。這樣我們只用到了24個比特，從而為命中列表長度（hit list length）留出了8個比特。
4.2.7 倒排索引（Inverted Index）
倒排索引與正排索引有著相同的桶，但是它們是先經過排序器處理過的。對每一個合法的wordID，詞典包含了一個指向對應的桶的指針。它指向一個docID的列表和相應的命中列表。這個文檔列表顯示了有這個單詞出現的所有文檔。
一個重要的事情是如何對這個文檔列表排序。一個簡單的方法是按照docID排序。在多個單詞的查詢中，這種方法可以快速地完成兩個文檔列表的歸并。另一種方案是按照這個詞在文檔中出現的評分(ranking)排序。這種方式使得單個詞的查詢相當簡單，并且多詞查詢的返回結果也很可能接近開頭（譯者注：這句不是很理解）。但是，歸并要困難得多。而且，開發也會困難得多，因為每次評分函數變動就需要重新建立整個索引。我們綜合了兩種方案，設計了兩個倒排桶集合——一個集合只包括標題和錨命中（譯者注：后面簡稱短桶），另一個集合包含所有的命中（譯者注：后面簡稱全桶）。這樣我們首先檢查第一個桶集合，如果沒有足夠的匹配再檢查那個大一點的。
4.3 網頁抓取（Crawling the Web）
運行網絡爬蟲是一項很有挑戰性的任務。這里不光涉及到巧妙的性能和可靠性問題，更重要的，還有社會問題。抓取是一個很脆弱的應用，因為它需要與成百上千各種各樣的web服務器和域名服務器交互，這些都不在系統的控制范圍之內。
為了抓取幾億網頁，Google有一個快速的分布式爬蟲系統。一個單獨的URL服務器（URLserver）為多個爬蟲(crawler,一般是3個)提供URL列表。URL服務器和爬蟲都用Python實現。每個爬蟲同時打開大概300個連接(connecton)。這樣才能保證足夠快地抓取速度。在高峰時期，系統通過4個爬蟲每秒鐘爬取100個網頁。這大概有600K每秒的數據傳輸。一個主要的性能壓力在DNS查詢(lookup)。每個爬蟲都維護一個自己的DNS緩存，這樣在它抓取網頁之前就不再需要每次都做DNS查詢。幾百個連接可能處于不同的狀態：查詢DNS，連接主機，發送請求，接受響應。這些因素使得爬蟲成為系統里一個復雜的模塊。它用異步IO來管理事件，用一些隊列來管理頁面抓取的狀態。
事實證明，爬蟲連接了50多萬個服務器，產生了幾千萬條日志信息，會帶來大量的電子郵件和電話。因為很多人在網上，他們并不知道爬蟲是什么，因為這是他們第一次見到。幾乎每天，我們都會收到這樣的電子郵件：“哇，你看了好多我站上的頁面，你覺得怎么樣？”也有很多人并不知道爬蟲禁用協議（robots exclusion protocol），他們認為可以通過在頁面上聲明“本頁面受版權保護，拒絕索引”就可以保護頁面，不用說，網絡爬蟲很難理解這樣的話。而且，由于涉及到大量的數據，一些意想不到的事情總會發生。比如，我們的系統試圖去抓取一個在線游戲。這導致了游戲中出現大量的垃圾消息！這個問題被證實是很容易解決的。但是往往我們在下載了幾千萬個頁面之后這個問題才被發現。因為網絡頁面和服務器總是在變化中，在爬蟲正式運行在大部分的互聯網站點之前是不可能進行測試的。不變的是，總有一些奇怪的錯誤只會在一個頁面里面出現，并且導致爬蟲崩潰，或者更壞，導致不可預測的或者錯誤的行為。需要訪問大量互聯網站點的系統需要設計得很健壯并且小心地測試。因為大量像爬蟲這樣的系統持續導致問題，所以需要大量的人力專門閱讀電子郵件，處理新出現遇到的問題。
4.4 網站索引（Indexing the Web）
解析——任何被設計來解析整個互聯網的解析器都必須處理大量可能的錯誤。從HTML標簽里面的錯別字到一個標簽里面上千字節的0，非ASCII字符，嵌套了幾百層的HTML標簽，還有大量超乎人想象的錯誤和“創意”。為了達到最快的速度，我們沒有使用YACC產生CFG（context free gramma，上下文無關文法）解析器，而是用flex配合它自己的棧生成了一個詞法分析器。開發這樣一個解析器需要大量的工作才能保證它的速度和健壯。
為文檔建立桶索引——每一個文檔解析過后，編碼存入桶里面。每一個單詞被內存里的哈希表——詞典轉化成一個wordID。詞典哈希表新加的內容都被記錄在一個文件里。單詞在被轉化成我wordID的時候，他們在當前文檔中的出現會被翻譯成命中列表，并寫入正排桶(forward barrels)中。建立索引階段的并行操作主要的困難在于詞典需要共享。我們并沒有共享整個詞典，而是在內存里保存一份基本詞典，固定的1千4百萬個單詞，多余的詞寫入一個日志文件。這樣，多個索引器就可以同時運行，最后由一個索引器來處理這個記錄著多余單詞的小日志文件。
排序——為了產生倒排索引，排序器取出各個正排的桶，然后根據wordID排序來產生一個標題和錨命中的倒排桶，和一個全文的倒排桶。每次處理一個桶，所以需要的暫存空間很少。而且，我們簡單地通過用盡可能多的機器運行多個排序器做到排序的并行化，不同的排序器可以同時處理不同的桶。因為桶并不能全部放在主存里面，排序器會根據wordID和docID將它們進一步分割成可以放在內存里面的桶(basket)。接著，排序器將每個桶載入內存，排好序，把內容寫入短的倒排桶和完整的倒排桶。
4.5 搜索（Searching）
搜索的目標是高效地返回高質量的結果。很多大型的商業搜索引擎在效率方面看起來都有很大的進步。所以我們更專注于搜索結果的質量，但是我們相信我們的解決方案只要花一點精力就可以很好的應用到商業的數據上。Google的查詢評估流程如圖4。
為了限制響應時間，一旦某個數量(現在是40,000)的匹配文檔被找到，搜索器自動跳到圖4中的第8步。這意味著有可能返回次優的結果。我們現在在研究新的方法來解決這個問題。在過去，我們根據PageRank值排序，有較好的效果。
解析查詢（Query）。
把單詞轉化成wordID。
從每個單詞的短桶文檔列表開始查找。
掃描文檔列表直到有一個文檔匹配了所有的搜索詞語。
計算這個文檔對應于查詢的評分。
如果我們到達短桶的文檔列表結尾，從每個單詞的全桶(full barrel)文檔列表開始查找，跳到第4步。
如果我們沒有到達任何文檔列表的結尾，跳到第4步。
根據評分對匹配的文檔排序，然后返回評分最高的k個。
圖4 Google查詢評估
4.5.1 評分系統（The Ranking System）
Google比典型的搜索引擎維護了根多的web文檔的信息。每一個命中列表（hitlist）包含了位置，字體和大小寫信息。而且，我們綜合考慮了錨文本命中和頁面的PageRank值。把所有的信息綜合成一個評分是很困難的。我們設計了評分函數保證沒有一個因素有太大的影響。首先，考慮簡單的情況——一個單詞的查詢。為了對一個單詞的查詢計算文檔的分值，Google首先為這個單詞查看這個文檔的命中列表。Google將命中分為不同類型（標題，錨，URL，普通文本大字體，普通文本小字體，……），每一種類型都有自己的類型權重值（type-weight）。類型權重值構成一個由類型尋址（indexed）的向量。Google數出命中列表中每種類型命中的數量。每個數量轉化成一個數量權重（count-weight）。數量權重開始隨著數量線性增長，但是很快停止增長，以保證單詞命中數多于某個數量之后對權重不再有影響。我們通過數量權重向量和類型權重向量的點乘為一個文檔算出一個IR分數。最后這個IR分數與PageRank綜合產生這個文檔最終的評分。
對于一個多詞搜索，情況要更復雜。現在，多個命中列表必須一次掃描完，這樣一個文檔中較近的命中才能比相距較遠的命中有更高的評分。多個命中列表里的命中結合起來才能匹配出相鄰的命中。對每一個命中的匹配集(matched set)，會計算出一個接近度。接近度是基于兩個命中在文檔（或錨文本）中相隔多遠計算的，但是被分為10個等級從短語匹配到“一點都不近”。不光要為每一種類型的命中計數，還要為每一種類型和接近度都計數。每一個類型和接近度的組有一個類型-接近度權重（type-prox-weight）。數量被轉化成數量權重。我們通過對數量權重和類型-接近度權重做點乘計算出IR分值。所有這些數字和矩陣都會在特殊的調試模式下與搜索結果一起顯示出來。這些顯示結果在開發評分系統的時候很有幫助。
4.5.2 反饋（Feedback）
評分函數有很多參數比如類型權重和類型-接近度權重。找出這些參數的權重值簡直就跟妖術一樣。為了調整這些參數，我們在搜索引擎里有一個用戶反饋機制。一個被信任的用戶可以選擇性地評價所有的返回結果。這個反饋被記錄下來。然后在我們改變評分系統的時候，我們能看到修改對之前評價過的搜索結果的影響。盡管這樣并不完美，但是這也給我們一些改變評分函數來影響搜索結果的想法。
5 結果與表現
衡量一個搜索引擎最重要的標準是其搜索結果的質量。雖然如何做一個完整的用戶評估超越了本文的范圍，但是我們在Google身上得到的經驗，表明它提供結果，比主要商用搜索引擎對絕大多數搜索提供的結果更好。圖表4 表示的 Google對于搜索“比爾.克林頓”的結果，作為一個例子可以說明，對PageRank, anchor text （關鍵詞）,和proximity（相似度）的使用。這樣的搜索結果顯示了Google的特色。搜索結果被服務器串聯在一起。這樣的方法當在需要對結果集篩選時非常有用。很大數量的結果會來自域名whitehouse.gov，有理由相信這個來源含有本次該搜索中被期望找到的結果。當前，絕大多數主要的商用搜索引擎不會返回任何來自whitehouse.gov的結果，更不用說正確的結果。注意，第一個搜索到的連接沒有標題，是因為它不是抓取得結果，而是Google 基于anchor text 決定這個結果是查詢所期望得到的好結果。同樣的，第15號結果是一個電子郵件地址，當然這也是基于anchor text的結果，而非可抓取得結果。
所有結果都是合理的高質量頁面，而且最后檢查，沒有壞連接。這主要歸功于他們有很高的PageRank。PageRank的百分比使用紅色條形圖表示。最后，這里的結果中，沒有只有Bill沒有Clinton 或只有 Clinton 沒有Bill 的，這是因為我們在關鍵詞出現時使用了非常重要的proximity。當然對一個實際的對搜索引擎的質量測試應該包括廣泛的對用戶研究或者對搜索結果的分析，但是我們沒有時間做以上析。但是我們邀請讀者在 [url]http://google.stanford.edu/flp[/url] 自己測試Google。
5.1 存儲需求
除搜索質量外，Gooogle被設計為能夠消化互聯網規模不斷增長帶來的效能問題。一方面，使用高效存儲。表一是對Google的統計與存儲需求的詳細分類，由于壓縮后的存儲體積為53GB，為源數據的三分之一多一點。就當前的硬盤價格來說可以為有用資源提供廉價的相關存儲設備。更重要的是，搜索引擎使用的所有數據的總合需要相應的存儲大約為55GB。此外，大多數查詢能被要求充分使用短反向索引 [short inverted index]，在更好的編碼與壓縮文檔索引后，一個高質量的網絡搜索引擎可能只需要一臺有7GB存儲空間的新電腦。
5.2 系統性能
這對搜索引擎的抓取與索引來說很重要。這樣信息被轉化為數據的速度以及系統主要部分改變后被測試的速度都相對更快。就Google來說，主要操作包括：抓取，索引和排序。一旦硬盤被填滿、或命名服務器崩潰，或者其它問題導致系統停止，都很難度量抓取所需要化費的時間。全部花費在下載2千6百萬個頁面[包括錯誤頁面]的時間大概是9天。但是如果系統運行更為流暢，這個過程還可以更快，最后的1千1百個頁面只使用了63個小時，平均4百萬每天，每秒48.5頁。索引的運行速度快于抓取速度的重要原因是我們花費了足夠的時間來優化索引程序，使它不要成為瓶頸。優化包括對本地硬盤上的文檔的索引進行大規模的升級和替換關鍵的數據結構。索引的速度達到大概54頁每秒。排序可以完全平行作業，使用四臺機器，整個處理時間花費近24個小時。
5.3 搜索性能
提高搜索性能并不是本次我們研究的重點。當前版本的Google返回多數查詢結果的時間是1到10秒。這個時間主要受到硬盤IO以及NFS[網絡文件系統，當硬盤安置到許多機器上時使用] 的限制。進一步說，Google沒有做任何優化，例如查詢緩沖區，常用詞匯子索引，和其它常用的優化技術。我們傾向于通過分布式，硬件，軟件，和算法的改進來提高Google的速度。我們的目標是每秒能處理幾百個請求。表2有幾個現在版本Google響應查詢時間的例子。它們說明IO緩沖區對再次搜索速度的影響。
另外一篇參考譯文：[url]http://blog.csdn.net/fxy_2002/archive/2004/12/23/226604.aspx[/url]
總結
以上是生活随笔為你收集整理的Google的开始－－剖析大规模超文本网络搜索引擎的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 算法编程JS控制台输入总结（V8和nod
- 下一篇： esp8266用arduino连上阿里云