About Nutch

http://eason982.blogspot.com/2007/10/about-nutch.html

Nutch 是一個開源Java 實現的搜索引擎。它提供了我們運行自己的搜索引擎所需的全部工具。可以為什麼我們需要建立自己的搜索引擎呢？畢竟我們已經有google可以使用。這里我列出3點原因：

(1)透明度：Nutch是開放源代碼的，因此任何人都可以查看他的排序算法是如何工作的。商業的搜索引擎排序算法都是保密的，我們無法知道為什麼搜索出來的排序結果是如何算出來的。更進一步，一些搜索引擎允許競價排名，比如百度，這樣的索引結果並不是和站台內容相關的。因此 Nutch 對學術搜索和政府類站台的搜索來說，是個好選擇。因為一個公平的排序結果是非常重要的。

對搜索引擎的理解：我們並沒有google的源代碼，因此學習搜索引擎Nutch是個不錯的選擇。了解一個大型分布式的搜索引擎如何工作是一件讓人很受益的事情。在寫Nutch的過程中，從學院派和工業派借鑒了很多知識：比如：Nutch的核心部分目前已經被重新用 Map Reduce 實現了。看過開復演講的人都知道 Map Reduce 的一點知識吧。Map Reduce 是一個分布式的處理模型，最先是從 Google 實驗室提出來的。你也可以從下面獲得更多的消息。

http://www.domolo.com/bbs/list.asp?boardid=29
http://domolo.oicp.net/bbs/list.asp?boardid=29

並且 Nutch 也吸引了很多研究者，他們非常樂於嘗試新的搜索算法，因為對Nutch 來說，這是非常容易實現擴展的。

(2)擴展性：你是不是不喜歡其他的搜索引擎展現結果的方式呢？那就用 Nutch 寫你自己的搜索引擎吧。

(3)Nutch 是非常靈活的：他可以被很好的客戶訂制並集成到你的應用程序中：使用Nutch 的外掛程式機制，Nutch 可以作為一個搜索不同資訊載體的搜索平台。當然，最簡單的就是集成Nutch到你的站台，為你的使用者提供搜索服務。

Nutch 的安裝分為3個層次：基於本地文件系統，基於局域網，或者基於 internet 。不同的安裝方式具有不同的特色。比如：索引一個本地文件系統相對於其他兩個來說肯定是要穩定多了，因為沒有 網絡錯誤也不同緩存文件的拷貝。基於Internet 的搜索又是另一個極端：抓取數以千計的網頁有很多技術問題需要解決：我們從哪些頁面開始抓取？我們如何分配抓取工作？何時需要重新抓取？我們如何解決失效的連結，沒有響應的站台和重復的內容？還有如何解決對大型資料的上百個並發訪問？搭建這樣一個搜索引擎是一筆不小的投資呀！在 " Building Nutch: Open Source Search," 的作者 Mike Cafarella 和 Doug Cutting 總結如下：

: ... 一個具有完全功能的搜索系統：1億頁面索引量，每秒2個並發索引，需要每月800美元。10億頁面索引量，每秒50個頁面請求，大概需要每月30000美元。

這篇文章將為你演示如何在中等級別的網站上搭建Nutch。第一部分集中在抓取上。Nutch的抓取架構，如何運行一個抓取程序，理解這個抓取過程產生了什麼。第二部分關注搜索。演示如何運行Nutch搜索程序。以及如何訂制Nutch 。

Nutch Vs. Lucene
Nutch 是基於 Lucene的。Lucene為 Nutch 提供了文本索引和搜索的API。一個常見的問題是；我應該使用Lucene還是Nutch？最簡單的回答是：如果你不需要抓取資料的話，應該使用Lucene。常見的應用場合是：你有資料源，需要為這些資料提供一個搜索頁面。在這種情況下，最好的方式是直接從資料庫中取出資料並用Lucene API建立索引。中文使用者，可以參考 WebLucene 或者 車東 的一些列文章。如果需要中文分詞幫助還可以聯系作者。

http://domolo.oicp.net/bbs/list.asp?boardid=24

Erik Hatcher 和 Otis Gospodnetić's 的 Lucene in Action 中詳細講述了這個過程。Nutch 適用於你無法直接獲取資料庫中的網站，或者比較分散的資料源的情況下使用。

架構

總體上Nutch可以分為2個部分：抓取部分和搜索部分。抓取程序抓取頁面並把抓取回來的資料做成反向索引，搜索程序則對反向索引搜索回答使用者的請求。抓取程序和搜索程序的接口是索引。兩者都使用索引中的字段。（）

實際上搜索程序和抓取程序可以分別位於不同的機器上。（）

這里我們先看看Nutch的抓取部分。

抓取程序： 抓取程序是被Nutch的抓取工具驅動的。這是一組工具，用來建立和維護幾個不同的資料結構： web database, a set of segments, and the index。下面我們逐個解釋上面提到的3個不同的資料結構。

The web database, 或者WebDB, 是一個特殊存儲資料結構，用來映像被抓取網站資料的結構和屬性的集合。WebDB 用來存儲從抓取開始（包括重新抓取）的所有網站結構資料和屬性。WebDB 只是被 抓取程序使用，搜索程序並不使用它。WebDB 存儲2種實體：頁面 和 連結。頁面 表示 網絡上的一個網頁，這個網頁的Url作為標示被索引，同時建立一個對網頁內容的MD5 哈希簽名。跟網頁相關的其它內容也被存儲，包括：頁面中的連結數量（外連結），頁面抓取資訊（在頁面被重復抓取的情況下），還有表示頁面級別的分數 score 。連結 表示從一個網頁的連結到其它網頁的連結。因此 WebDB 可以說是一個網絡圖，節點是頁面，連結是邊。

Segment 是 網頁 的集合，並且它被索引。 Segment 的 Fetchlist 是抓取程序使用的 url 列表 ， 它是從 WebDB中生成的。Fetcher 的輸出資料是從 fetchlist 中抓取的網頁。Fetcher 的輸出資料先被反向索引，然后索引后的結果被存儲在segment 中。 Segment 的生命周期是有限制的，當下一輪抓取開始后它就沒有用了。預設的 重新抓取間隔是30天。因此刪除超過這個時間期限的segment是可以的。而且也可以節省不少磁盤空間。Segment 的命名是 日期加時間 ，因此很直觀的可以看出他們的存活周期。


索引庫 是 反向索引所有系統中被抓取的頁面，他並不直接從頁面反向索引產生，它是合並很多小的 segment 的索引中產生的。Nutch 使用 Lucene 來建立索引，因此所有 Lucene 相關的工具 API 都用來建立索引庫。需要說明的是 Lucene 的 segment 的概念 和 Nutch 的 segment 概念是完全不同的，不要混淆哦。 可以參考 車東 的相關文章。 www.chedong.com 簡單來說 Lucene 的 segment 是 Lucene 索引庫的一部分，而 Nutch 的 Segment 是 WebDB 中 被 抓取和索引的一部分