Lucene 4的初步印象

最近花了很多时间在读Lucene的源代码,主要针对的版本是4.3。听说Lucene 4.* 相比Lucene 3.* 有很大的变化,所以学习过程中也对照3.6的代码比较了一下。
目前为止只是对写索引那块算是比较了解了,自己照着源代码写了一个单线程,无Merge,无rollback简单版的IndexWriter。还不错,能work。

说说印象

Lucene的代码很不好读,几个原因:
1. 逻辑本身很复杂,除了读取document中的数据建立索引以外,还要考虑多线程,考虑各种错误机制,比如OUT-OF-MEMORY之后如何回滚,还要支持two-phase commit,还要随时判断内存数据是否flush到disk上,还包括Merge机制… 所有的这些代码都交织到了一起;

2. 为了节约内存的使用,Lucene维护了自己的内存池,而且不少数据结构(比如Hash和List)都是自己实现的,这些代码很多都是散落在外。经常是一段代码看半天,最后发现其实就是执行list.add操作…

3. 有一些不必要的抽象层。纯属个人观点。Lucene将整个过程抽象成了一个processing chain,而且processing chain中的每个组件都是一个抽象类。这么做的本意是各个组件各做各的事情,互不影响。但实际的代码中,这种理想的耦合状态是达不到的,反倒是把处理流程切割得支离破碎,跟踪代码特别费事;

和3.*相比,Lucene 4有了重大的改进,除了API的使用有很大差异外,内部实现也差别很大:
1. Lucene 4的程序结构和分层更清楚,代码相比较而言更容易读。最重要的就是有了Codec这个抽象层(下一条详细谈)。另外,3.*中有一些散落的代码做了封装,看着更清楚;

2. Codec将索引文件的格式和其它逻辑分隔开了,一方面程序逻辑上更清楚,另一方面可以自己DIY索引文件的格式。比如4.3中就有一个SimpleTextCodec,可以将索引“明文”记录在txt文件上,挺好玩;

3. 所有的term value是以二进制的格式存储的。这是个重大的改进!它能极大的减少索引文件的尺寸。特别是对我这种很多时候是将Lucene当成倒排索引来用的人来说,这个特性真正让我决定要开始学习Lucene 4;

4. 据说Lucene 4用了新的索引格式,索引文件更加的小。因为这段代码都放在了Codec中,我没细看,所以是据说…

总而言之,Lucene 4相比Lucene 3确实有了非常大的改进。应该尽可能的考虑使用Lucene 4。
BTW,Lucene源码中还有一些很好玩的类,比如 RamUsageEstimator 这个类,可以用来估计一个Object占用memory的大小,很有用。

Advertisements
相册 | 此条目发表在Lucene分类目录,贴了, 标签。将固定链接加入收藏夹。

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s