1 緒論

Web 給資訊檢索帶來了新的挑戰。 Web 上的資訊量快速增長，同時不斷有毫無經驗的新多使用者來體驗 Web 這門藝術。人們喜歡用超級連結來網上衝浪，通常都以象 Yahoo 這樣重要的網頁或搜尋引擎開始。大家認為 List(目錄) 有效地包含了大家感興趣的主題，但是它具有主觀性，建立和 WordPress 維護的代價高，升級慢，不能包括所有深奧的主題。基於關鍵詞的自動搜尋引擎通常返回太多的低質量的匹配。使問題更遭的是，一些廣告為了贏得人們的關注想方設法誤導自動搜尋引擎。我們建立了一個大型搜尋引擎解決了現有系統中的很多問題。應用超文字結構，大大提高了查詢質量。我們的系統命名為 google，取名自 googol 的通俗拼法，即 10 的 100 次方，這和我們的目標建立一個大型搜尋引擎不謀而合。

1.1 網路搜尋引擎—升級換代（scalingup）：

1994-2000 搜尋引擎技術不得不快速升級（scaledramatically）跟上成倍增長的 web 數量。 1994 年，第一個 Web 搜尋引擎，WorldWideWebWorm(WWWW) 可以檢索到 110，000 個網頁和 Web 的檔案。到 1994 年 11 月，頂級的搜尋引擎聲稱可以檢索到 2‘000′000（WebCrawler）至 100‘000′000 個網路檔案（來自 SearchEngineWatch）。可以預見到 2000 年，可檢索到的網頁將超過 1‘000′000‘000 。同時，搜尋引擎的訪問量也會以驚人的速度增長。在 1997 年的三四月份，WorldWideWebWorm 平均每天收到 1500 個查詢。在 1997 年 11 月，Altavista 聲稱它每天要處理大約 20′000′000 個查詢。隨著網路多使用者的增長. 到 2000 年，自動搜尋引擎每天將處理上億個查詢。我們系統的設計目標要解決許多問題，包括質量和可升級性，引入升級搜尋引擎技術（scalingsearchenginetechnology），把它升級到如此大量的資料上。

1.2Google：

跟上 Web 的步伐（ScalingwiththeWeb）建立一個能夠和當今 web 規模相適應的搜尋引擎會面臨許多挑戰。抓網頁技術必須足夠快，才能跟上網頁變化的速度（keepthemuptodate）。儲存索引和檔案的空間必須足夠大。索引系統必須能夠有效地處理上千億的資料。處理查詢必須快，達到每秒能處理成百上千個查詢（hundredstothousandspersecond.）。隨著 Web 的不斷增長，這些任務變得越來越艱鉅。然而硬體的執行效率和成本也在快速增長，可以部分抵消這些困難。還有幾個值得注意的因素，如磁碟的尋道時間（diskseektime），作業系統的效率（operatingsystemrobustness）。在設計 Google 的過程中，我們既考慮了 Web 的增長速度，又考慮了技術的更新。 Google 的設計能夠很好的升級處理海量資料集。它能夠有效地利用儲存空間來儲存索引。最佳化的資料結構能夠快速有效地存取（參考 4.2 節）。進一步，我們希望，相對於所抓取的文字檔案和 HTML 網頁的數量而言，儲存和建立索引的代價儘可能的小（參考附錄 B）。對於象 Google 這樣的集中式系統，採取這些措施得到了令人滿意的系統可升級性（scalingproperties）。

1.3 設計目標

1.3.1 提高搜尋質量我們的主要目標是提高 Web 搜尋引擎的質量。 1994 年，有人認為建立全搜尋索引（acompletesearchindex）可以使查詢任何資料都變得容易。根據 BestoftheWeb1994—Navigators，“最好的導航服務可以使在 Web 上搜尋任何資訊都很容易（當時所有的資料都可以被登入）” 。然而 1997 年的 Web 就迥然不同。近來搜尋引擎的多使用者已經證實索引的完整性不是評價搜尋質量的唯一標準。多使用者感興趣的搜尋結果往往湮沒在 “垃圾結果 Junkresult” 中。實際上，到 1997 年 11 月為止，四大商業搜尋引擎中只有一個能夠找到它自己（搜尋自己名字時返回的前十個結果中有它自己）。導致這一問題的主要原因是檔案的索引數目增加了好幾個數量級，但是多使用者能夠看的檔案數卻沒有增加。多使用者仍然只希望看前面幾十個搜尋結果。因此，當集合增大時，我們就需要工具使結果精確（在返回的前幾十個結果中，有關檔案的數量）。由於是從成千上萬個有點相關的檔案中選出幾十個，實際上，相關的概念就是指最好的檔案。高精確非常重要，甚至以響應（系統能夠返回的有關檔案的總數）為代價。令人高興的是利用超文字連結提供的資訊有助於改進搜尋和其它應用。尤其是連結結構和連結文字，為相關性的判斷和高質量的過濾提供了大量的資訊。 Google 既利用了連結結構又用到了 anchor 文字（見 2.1 和 2.2 節）。