基於以上結果，本文在不一樣的文檔集合上進行了實驗， 搜索引擎建索引的時間開銷較小的是ht://Dig, Indri, IXE, Lucene, MG4J, Swish-E, Swish++, Terrier, XMLSearch, 和 Zettair。而建索引後的存儲大小的分析，能夠分爲三種類型，Lucene, MG4J, Swish-E, Swish++, XMLSearch 和 Zettair 的索引的大小是數據集大 小的25%-35%。 而Terrier則 是50%。 ht://Dig, Omega, 和 OmniFind 更是比數據集的100%還要大。 最後， 考察的另 一個方面是建索引階段的內存使用狀況。 ht://Dig, Lucene, 和 XMLSearch會有固定大小的內存開銷。 而且前二者的內存開銷與數據集的大小無關（30 MB ~120MB）。 另一方面， IXE, MG4J, Swish-E, Swish++, 和 Terrier的內存開銷要大的多， 而且呈線性增加。 小數據集合的話，內存開銷爲320MB到600MB， 而大數據集時， 大約要1G內存開銷。數據庫
本文還發現，搜索引擎在存儲和管理索引的時候，使用數據庫的搜索引擎（DataparkSearch, mnoGoSearch, 和 OpenFTS）在建索引階段的性能要明顯的差勁， 所以它們的索引時間開銷大約是最優的搜索引擎3到6倍。apache
在第二個實驗中， 能 夠看到， 給定了數據集和查詢類型（1個仍是2個單詞的查詢詞）後， 搜索引擎的查詢時間開銷都差很少。對於1個單詞的查詢詞， 查 詢時間開銷大約是小於10ms到90ms， 而2個單詞的查詢詞的查詢時間開銷大約是小於10ms到110ms。查詢最快的搜索引擎包括Indri, IXE, Lucene, 和 XMLSearch。 惟一的不一樣在於， 當 查詢詞是數據集合中的低頻詞的時候， 大部分搜索引擎只檢索到0個或者1個文檔， 這樣檢索百分比不就具備表明性。編程
基於WT10g數據集的實驗顯示只有Indri, IXE, MG4J, Terrier, 和 Zettair在索引整個數據集的時候，和 以前TREC-4數 據集時候相比， 性能降低的不會太過度。而Swish-E, 和 Swish++在給定的系統參數（操做系 統， 內存等）狀況下， 根本不能完成整個數據集的索引。ht://Dig 和 Lucene 的索引時間開銷會暴漲， 以致於在最後的比較中， 它倆都被忽略了。 Zettair是建索引最快的搜 索引擎，而且它的平均準確率/召回率比值和Indri, MG4J, 以及 Terrier 差很少。和其餘搜索引擎相比， IXE的平均準確率/召回率比值最低。 若是將這個結果和其餘TREC會議項目方向（例如Tera數據集）相比， 就 能看到IXE, MG4J, 和Terrier也能進入到搜索引擎榜單的前列。而和官方的TREC評估之因此有差別，是由於開發人員對搜索引擎作了精細的調整，在最後的發佈版中，針對每一個項目方向的 特殊需求，作的不少細緻的調整並無完整地記錄下來， 由於這些調整和會議方向是的確特別相符合。api
第6章 結論
本文給出了比較不一樣的開源搜索引擎的方法， 而且在不一樣大小的數據集合上進行了實驗後給出告終論。 首先， 選出17個搜索引擎（從29個已知的搜索引擎中）用來進行比較。進 行了測試後發現只有10個搜索引擎可以在合理的時間開銷範圍內（小於1個小時）索引2.7GB的文檔數據集， 之 後就用這10個搜 索引擎來進行查詢測試。在建索引階段， 內存的開銷表現各異， 而且不一樣搜索引擎的索引的存儲空間佔用也大小不一。 在查詢測試中， 可以索引最大數據集的搜索引擎的表現並無明顯差別。服務器
最後的實驗是比較大數據集（10GB）的建索引的性能比較， 而且分析不一樣層次的準確率。 只有5個搜索引擎可以索引這個數據集（基於給定的服務器參數）。經過觀測平均準確率/召回率比值， 得出Zettair是優勝者， 同時Indri的效果也基本相同。將本文的結果 和TREC評估的 官方結果進行比較， 的確可以發現有差距。 可是事實上， TREC每一個會議方向的開發者都會作細緻的調整，而且這種調整不會被記錄下來的。編程語言
分析了被忽略的搜索引擎的初始測試結果(Datapark, mnoGoSearch, Namazu, OpenFTS, 和Glimpse)， 相比而言，這 些被忽略的搜索引擎的時間開銷的表現的確要差勁。性能
從上文信息中， 能 看到全部可用的搜索引擎的在索引和查詢階段的特徵和性能表現。在表6.1 中本文給出了搜索引擎在索引2.7GB數據時的索引時間開銷和索引存儲大小，以及平均查詢時間。這裏的查詢時間排序是基於2.7GB的數據集，考慮了全部的查詢詞（1個或者2個單詞的，原始分佈和歸一化分佈的）。本文 也給出了索引WT10g數據集，準確率排名前五的搜索引擎。測試
基於小數據集（TREC-4）和大數據集（WT10g）， 分析了搜索 引擎的總體性能，能夠看出Zettair是最完整的引擎之一， 不管是它比其餘搜索引擎在處理大信息量的時少的多（要比第二名的索引時間的一半還少）的時間開銷，仍是它在數據集WT10g上取得的最高的準確率和召回率。大數據
另外，爲了決定採用哪一個搜索引擎， 還必須針對站點的特殊需求進行補充。 一些方面仍是須要考慮的， 像編程語言（例如， 對源碼的二次開發）， 服務器的性能（例如， 可用內存）。 舉例來講， 若是待索引的數據集至關大， 並且指望數據集會常常更變， 那麼考慮到索引時間開銷和查詢時間開銷， 而關注一下Zettair， MG4J和Swish++彷佛要明智些， 因 爲它們更快一些。Swish-E或許也行。 另外一個 角度， 若是磁盤大小有限， 但願省存儲空間，那麼Lecence是很好的選擇， 它 的存儲空間開銷要小， 而其查詢也很快， 缺點是建索引時間開銷較大。 最後， 如 果數據集合變化不多， 由於全部的搜索引擎的查詢時間相差不大， 那麼你能夠考慮一下你的站點想採用的編程 語言， 那麼二次開發的週期會大大縮短。 想用Java的話， MG4J， Terrier或者Lucene可用， C/C++的話，能夠看一下Swish-E， Swish++， ht://Dig， XMLSearch, Zettair。搜索引擎
參考書目
[1] R. Baeza-Yates and B. Ribeiro-Neto. Modern Information Retrieval.
Addison-Wesley, Wokingham, UK, 1999.
[2] IBM OmniFind Yahoo! Homepage. http://omnifind.ibm.yahoo.net/.
[3] Indri Homepage. http://www.lemurproject.org/indri/.
[4] Lemur Toolkit Homepage. http://www.lemurproject.org/.
[5] Load Monitor Project Homepage. http://sourceforge.net/projects/monitor.
[6] Lucene Homepage. http://jakarta.apache.org/lucene/.
[7] Managing Gigabytes Homepage. http://www.cs.mu.oz.au/mg/.
[8] Nutch Homepage. http://lucene.apache.org/nutch/.
[9] QOS Project Homepage. http://qos.sourceforge.net/.
[10] SWISH++ Homepage. http://homepage.mac.com/pauljlucas/software/swish/.
[11] SWISH-E Homepage. http://www.swish-e.org/.
[12] Terrier Homepage. http://ir.dcs.gla.ac.uk/terrier/.
[13] Text REtrieval Conference (TREC) Homepage. http://trec.nist.gov/.
[14] Xapian Code Library Homepage. http://www.xapian.org/.
[15] Zettair Homepage. http://www.seg.rmit.edu.au/zettair/.
[16] ht://Dig Homepage. http://www.htdig.org/.
[17] Christopher D. Manning, Prabhakar Raghavan, and Hinrich Schtze. Introduction to Information Retrieval. Cambridge University Press, Cambridge, UK, 2008.
[18] Ian H. Witten, Alistair Moffat, and Timothy C. Bell. Managing Gigabytes: Compressing and Indexing Documents and Images. Morgan Kaufmann Publishers, San Francisco, CA, 1999.
史春奇，
搜索工程師，
中科院計算所畢業，
chunqi.shi@hotmail.com