Lucene 2.4.0的性能

一直在使用Lucene，对它的性能也一直比较乐观，相信只要做适当的配置优化，性能总可以达到要求的。只是这两天连续在网上看到几个有影响力的人对它的印象不太好。

 

这是相关的链接：

亿级数据的高并发通用搜索引擎架构设计[原创]

JavaEye3.0开发手记之三 － 狮身人面

 

 

心里咯噔的一下子虚了，感觉又给Lucene忽悠了。Lucene自称性能也不错的，而且用户群体多。也有好几个语言版本，基于它开发的工具也多。怎么也这么儿戏呀。这世界真的没有可以信任了，那么多的食品安全事件，就像House的主角说的“Everybody lies”。

 

但是我这个人也比较执着，不是自己看到的数据却也不会死心的，于是决定自己亲身实验一番。

 

以下是测试环境：

CPU AMD Turion 64 *2, 1.80G

Memory 3G

Windows XP

Eclipse

Lucene-core 2.4.0

 

测试对象：

170M大小的日志文件，总共2071364行，每行做成一个Lucene的Document

1.08G大小的日志文件，总共9076020行， 每行做成一个Lucene的Document

 

测试用例：

170M大小的日志文件，commit every 10000 documents，Field.Store.YES，默认设置
索引时间	索引大小	搜索时间
138秒	240M	首次187ms，后续平均25ms
170M大小的日志文件， Field.Store.NO， MaxBufferedDocs 10000，MaxFieldLength 10240，MergeFactor 1000, RAMBufferSizeMB 32
索引时间	索引大小	搜索时间
68秒	68.8M	首次203ms，后续平均45ms
1.08G大小的日志文件， Field.Store.NO， MaxBufferedDocs 10000，MaxFieldLength 10240，MergeFactor 1000, RAMBufferSizeMB 32
索引时间	索引大小	搜索时间
598秒	317M	首次469ms，后续平均93ms，后续MAX 453ms，后续MIN 16ms

 

 

1.08G大小的日志文件，主从索引，Merge every 100,000 Documents， Field.Store.NO， MaxBufferedDocs 10000，MaxFieldLength 10240，MergeFactor 1000, RAMBufferSizeMB 32
索引时间	索引大小	搜索时间
378秒	317M	首次406ms，后续平均87ms，后续MAX 406ms，后续MIN 0ms
1.08G大小的日志文件，主从索引，Merge every 500,000 Documents， Field.Store.NO， MaxBufferedDocs 10000，MaxFieldLength 10240，MergeFactor 1000, RAMBufferSizeMB 32
索引时间	索引大小	搜索时间
387秒	317M	首次407ms，后续平均90ms，后续MAX 422ms，后续MIN 0ms

 

看到这样的测试数据，心理总算踏实多了。应该说如果不对Lucene的索引配置做一些调整，索引时间确实挺长的。用上面170M文件，200多万行记录来说，配置前后相差了一半的时间。1G多文件，900多万行记录索引也只用了598秒，速度也不慢吧。后面用的主从索引模式更是将索引速度提高到380秒左右。搜索速度也还可以。

 

Lucene 2.3版本之后对性能方面做了比较大的提升，因此这里的测试数据才比较好看吧。也难怪大佬们对它恨铁不成钢的。

 

评论

1 楼 ginge 2009-08-09  

是的，很多东西如果不是亲身见过或者做过，真的很难相信。