基于以上结果，本文在不同的文档集合上进行了实验， 搜索引擎建索引的时间开销较小的是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倍。
在第二个实验中， 能 够看到， 给定了数据集和查询类型（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评估之所以有差异，是因为开发人员对搜索引擎做了精细的调整，在最后的发布版中，针对每个项目方向的 特殊需求，做的很多细致的调整并没有完整地记录下来， 因为这些调整和会议方向是的确特别相符合。
第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
