开源搜索引擎索引性能的比较研究，本文主要内容关键词为：开源论文,索引论文,性能论文,搜索引擎论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
1 引言
随着互联网信息量的激增，为用户提供网上相关信息的检索成为迫切需求。当你准备在网站上提供这种检索服务的时候，你可以选择，要么利用商业搜索引擎，要么选择开源搜索引擎。由于商业搜索引擎存在着付费和功能限制的弊端，所以站长们通常会首选开源搜索引擎。开源搜索引擎不仅能提供商业搜索引擎的同类功能，并且拥有开源理念带来的好处：不花钱，可以更自由地维护软件，也可以通过二次开发来满足个人的需求。现今，搜索引擎的开源产品很多，而要决定采用哪个开源产品，就必须认真考虑每个开源产品的特性。这些特性通常包括：编程语言、索引文件的存储格式、查询能力、排序策略，在线索引能力和增量索引能力等。而在这些要考察的特性中，索引性能又是最重要的，因为索引结果直接影响着查询和排序。
2 12款主流开源搜索引擎项目简介
目前已知的开源搜索引擎有很多。根据我们收集到的信息，排除掉那些过时项目——ASPSeek,BBDBot,ebhath，Eureka,ISearch,MPS Information Server,PLWeb和一些基于同一项目的应用项目——Nutch,Compass,Solr（这三个项目都是基于Lucene的应用）。另外，经过初步的索引实验我们又去除了那些表现实在不尽如人意的项目，本文最终确定用于比较研究的项目是：ht://Dig,IXE,Indri,Lucene,MG4J,Omega,OmniFind，Swish—E,Swish++,Terrier,XMLSearch和Zettair。以下是对这12个开源搜索引擎项目的简单介绍，主要包括开发者、开发地及项目赖以著称的特性。
ht://Dig[1]，提供一组工具可以索引和搜索一个站点，提供一个命令行工具和CGI界面来执行搜索。尽管已经有了更新的版本，但是根据项目的网站显示，3.1.6版是最快的版本。
IXEToolkit，是模块化C++类集合，有一组工具完成索引和查询。Tiscali（来自意大利）提供有商业版本，同时提供了一个非商业版本仅用于科学研究。
Indri[2]，是基于Lemur的搜索引擎。Lemur是用来研究语言模型和信息检索的工具。这个项目是马萨诸塞大学和CMU合作项目的产物。
Lucene[3]，是Apache软件基金会的一个文本搜索引擎库。由于它是一个库，所以很多项目基于这个库，例如Nutch项目。目前，它捆绑自带的最简单的应用是索引文档集合。
MG4J[4]，是针对大文本集合的一个全文索引工具，由米兰大学开发。它提供了通用的字符串和位级别的I/O的优化的类库作为副产物。
Omega，基于Xapian的应用。Xapian是开源的统计信息检索库，由C++开发，但是被移植到了（Perl,Python,Java,C#）等多种语言。
IBM Omnifind Yahoo! Edition[5]，非常适合内网搜索的搜索软件，它结合了基于Lucene索引的内网搜索，并利用Yahoo实现了外网搜索。
Swish—E[6]（简单网页索引系统一增强版），是开源的索引和检索引擎，可以把它看做是Swish的增强版。
Swish++[7]，是基于Swish—E的索引和检索工具。尽管经过C++全部重写，但是并没有实现Swish—E的全部功能。
Terrier[8]（太字节检索），由苏格兰的格拉斯哥大学开发的模块化的平台，能够快速地构架互联网、内网和桌面的搜索引擎。它附带了索引、查询和评估标准TREC集合的功能。
XMLSearch，C++开发的索引和检索的一组类，利用文本操作（相等、前缀、后缀、分段）来扩展了查询能力。Barcino（来自智利）提供了一个商业版，同时也有供学术研究的非商业版。
Zettair[9]（先前称为Lucy），由皇家墨尔本理工大学的搜索引擎小组开发的文本检索引擎，主要特征是能够处理超大量的文本。
3 索引实验的准备工作
3.1 测试文档数据的选取
为了比较不同的搜索引擎的索引性能，有必要选择几个大小不同的文档集合，从小于1G的文本，到2.5G或者3G的文本。另外一个是文本的类型考虑，常用于搜索引擎分析的文本类型是HTML。要收集3G的HTML数据，一种方法是抓取一个在线网站作为数据集合，但由于本文关注于索引的性能，所以还是用本地数据比较稳定。
TREC—4的文本集合，包含有许多文件，分别对应到华尔街时报、美联社、洛杉矶时报等等。每个文件都是SGML的格式，需要先解析数据，生成HTML的文档，每个大约是500KB的样子[10]；然后把这个数据集分成3个不同大小的组，一个750MB（1 549个文档），一个1.6GB（3 193个文档），另外一个2.7GB（5 572个文档）；最后，再进一步使用WT10g的数据进行测试比较。这个集合包含了1 692 096个文档，划分成5 117个文件，总大小是10.2GB[11]。这个文档集合又被分成不同大小的组（2.4GB、4.8GB、7.2GB、10.2GB），被分别用来测试对应的索引时间。
3.2 实验方法
我们在选定文档集合上运行了3个实验，前两个实验是基于解析好的文档集合（TREC—4），而最后一个实验是基于WT10g的数据集的。第一个实验，记录每个搜索引擎的索引数据的时间开销和资源开销。第二个测试比较增量索引的时间开销。所有的索引流程是在同一个电脑上依次执行的。第三个测试比较针对有能力索引全部文档的搜索引擎，在WT10g的不同大小的数据集上的索引时间开销。
3.3 实验环境
实验所用计算机的主要性能参数：奔腾四3.2GHz处理器，2G内存，SATA硬盘，运行DebianLinux（内核2.6.15）。为了分析每个搜索引擎在索引过程中的资源开销，必须要有监控工具。目前有几种资源监控工具可供选择，例如“LoadMonitor”和“QOS”。但对于本文的工作，只要一个简单的监控就能完成。因此我们只用了一个后台进程来记录每个进程在一段时间内的CPU和内存的开销。
4 索引实验
4.1 TREC—4数据集合的索引测试
这个索引测试记录每个搜索引擎在索引过程中的时间开销和资源开销（CPU、内存占用、索引磁盘占用）。在每个测试阶段之后，都会分析时间开销，只有时间开销合理的搜索引擎才被用来进行下一轮更大数据集的测试。本文根据之前的观测，主观地定义合理的时间开销是不超过最快搜索引擎时间开销的20倍。
4.1.1 索引时间
本文忽略了Datapark,Glimpse,mnoGoSearch,Namazu和OpenFTS搜索引擎，因为它们基于750MB的数据的索引时间开销要花费77到320分钟。另外，所有采用数据库作为索引存储的搜索引擎的索引时间开销都会比其他搜索引擎要大得多。不同文档大小的索引时间开销如图1所示。
对于750MB数据集合，搜索引擎建索引的时间开销是1～32分钟；而对于1.6GB的数据集合，时间开销是2分钟～1个小时；对2.7GB的数据集合建索引的时间开销是5分钟～1小时。但是Omega相当例外，大数据的索引时间开销要达到17小时50分钟。
4.1.2 内存和CPU开销
CPU开销在索引阶段几乎是一个常数，接近100%。同时，根据观察把内存的状态划分为6种不同的情况，分别为：稳定不变(C)、线性变化(L)、阶梯变化(S)、和组合情况：线性再阶梯变化(L—S)、线性再保持不变(L—C)、阶梯变化再保持不变(S—C)。ht://Dig,Lucene和XMLSearch在建索引过程中有稳定的内存占用；MG4J，Omega，Swish—E和Zettair表现为线性增长；Swish++是阶梯变化；Indri则是线性增长，然后释放部分已经占用的空间，接着又开始线性增长；Terrier是开始表现为阶梯变化，然后释放部分空间，最后成稳定地使用内存，直到索引结束；Omega是一个线性的增长，当到了1.6GB的时候，稳定不变。详细情况见表1。
4.1.3 索引存储空间占用
在表2中列出了能够在合理的时间开销内索引全部文档集合的搜索引擎的索引的大小。据观察分为3个组：索引只占数据集合大小25%～35%的一组，还有一组是50%～55%，最后一组是甚至超过100%的数据集合大小。
本文还测试了增量索引的时间开销，增量大小设置成初始大小的1%、5%和10%。基于1.6GB的数据集，每个增量的文档都是原来集合里面所没有出现过的。比较ht://Dig,Indri,IXE,Swish—E和Swish++，图2给出了它们的增量索引时间开销的具体比较。
图2 对不同大小增量信息做增量索引时的时间开销
4.2 WT10g数据集合的索引测试
另外一个实验是在WebTREC（WT10g）数据集合上完成的，统计不同的分组的建索引的时间开销。关注了两组搜索引擎：具有索引原文件格式的能力的搜索引擎（每个文件包含一组记录，包含原始的HTML页面）；另外一组不能理解文件格式，需要解析数据集合，并且抽出每个HTML页面。Indri，MG4J，Terrier和Zettair是能够直接索引WT10g文件，不需要任何修改；ht://Dig,IXE,Lucene,Swish—E和Swish++需要解析数据。
我们在WT10g数据集合（10.2G）上测试了通过上一阶段测试的搜索引擎，只有Indri,IXE,MG4J,Terrier和Zettair能够索引整个数据集合，并且时间开销也只是线性地增长，其他的搜索引擎的时间开销会暴涨或者由于内存不足而出现崩溃。ht://Dig和Lucene需要花费7倍的预期建索引的时间，并且超过了最快的搜索引擎（Zettair）时间开销的20倍，而Swish—E和Swish++由于内存不足崩溃了。基于上述结果，本文考察了各个分组(2.4G、4.8G、7.2G和10.2G)的建索引时间。图3给出了能够索引整个数据集的搜索引擎建索引的时间开销。可以看出，这些搜索引擎的时间开销是成线性正比增长的。
图3 索引WT10g数据集时各搜索引擎的时间开销
5 评估与总结
基于以上实验数据和对结果的分析，针对主流开源搜索引擎的索引性能，我们做了如下总结。第一，建索引的时间开销较小的是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则是比数据集本身还要大。第三，建索引阶段的内存使用情况如下，ht://Dig,Lucene和XMLSearch会有固定大小的内存开销，并且前两者的内存开销与数据集的大小无关（30MB～120MB）；另外，IXE,MG4J,Swish—E,Swish++和Terrier的内存开销要大得多，并且呈线性增长；针对小数据集合，内存开销为320MB到600MB，而大数据集时，大约要1G以上的内存开销。第四，搜索引擎在存储和管理索引的时候，使用数据库的搜索引擎（如：DataparkSearch,mnoGoSearch和OpenFTS）在建索引阶段的性能较弱，其索引时间开销大约是最优搜索引擎的3倍到6倍。第五，当数据集合非常大时（log以上），只有Indri,IXE,MTerrier和Zettair的索引性能不会大幅下降。而Swish—E和Swish++在给定的系统参数下，根本不能完成对大数据集合的索引。