Lucene 4.0 正式版新特性

         2012年10月12日,Lucene 4.0正式发布了(点击这里下载最新版),这个版本因为诸多的新特性和大胆的架构调整一直备受期待。无论是索引结构,索引算法以及整体架构的包容性都发生了翻天覆地的变化。正如大家一直所说的Lucene是一个搜索工具包 ,而4.0的发布则让Lucene向搜索框架的方向迈出了一大步。 下面我们来逐一解读Lucene 4.0的新特性吧。

 

Lucene 4.0 的关键词:

       架构解耦,索引结构可定制化,索引结构透明化,向搜索框架方向发展。

 

Lucene 4.0 正式版亮点功能:

     一、通过解码器Codec 机制 Lucene 索引格式与Lucene架构解耦,变成了Plugin方式实现,包括:Terms , Postings lists ,Stored 字段,Term Vectors 等都可以以自定义的格式予以支持。

        正如Mysql支持多种存储引擎一样,现在Lucene也可以了。

 

     二、排序相关的算法与向量空间模型解耦(即Lucene中经典的经典的(TF/IDF)模型)。同时提供:最佳匹配 Okapi BM 25,随机分歧 (Divergence from Randomness ),语言模型和基于信息量的模型。 不同的算法模型可以组合串联起来使用,这等于完全解放了Lucene的生产力!。

     

     三、新的DocValues类型可以为每个文档提供存储额外的类型数据。类似:PayLoad, 可以在用这个特性自定义排序打分参数。

     四、IndexWriter 写入索引到硬盘支持完全并发,之前IndexWriter在应用层能多线程调用,但在写入硬盘的时候还是逐个线程顺序写入的。这对于经常要重建索引的场景,减少了等待索引的时间。

     具体图形化的演示,请参考我之前的一片文章: http://blog.csdn.net/accesine960/article/details/6780068

 

     五、每个Document的标准化因子 norms 不再局限于一个字节。自定义排序的实现可以使用任何DocValues类型的排序因子。

 

     六、索引结构更加透明化,增加了索引统计机制,利用这些统计信息,Lucene索引内容不再是一个黑匣子了。

            包括: 提供针对term或者Field的token数量,针对某个filed的Posting数量,包含某个field的positing的文档数量。当然有了这些索引统计的数据后,就可以自定义的改进评分机制了。

     也就是说以下方法将会成为你的新朋友:

     TermsEnum.docFreq(),TermsEnum.totalTermFreq(),Fields.getUniqueTermCount(),Fields.getUniqueFieldCount()

 

      七、索引term不再局限于UTF-16的字符格式,Lucene 4.0中 term 可以是任何二进制数值(java中的byte数组)。默认情况下文本类term是UTF-8字节方式存储。

 

     八、在搜索时使用Filter效率有大幅提升

 

      九、针对索引merge线程添加了IO限速机制,减少搜索线程与合并索引线程引起的IO争用现象。

 

      十、由于架构的解耦,增加了一系列可插拔和可替换的模块,包括: 

       A: 添加编码器codec:针对类 Hadoop DFS 的文件系统提供。

       B: 内存编码器codec:把所有的term和posting放到一个内存中的FST(有限状态机),针对内存型应用提升了搜索速度。

       C: 脉冲编码器codec:主要利用了 Zipf 定律,根据term的频率,把频率达到制定阈值的term以inline的方式存储。

                   了解c++ inline 函数的同学,应该知道inline对于提升函数调用速度的威力吧。

   

       D: 明文编码器codec: Lucene的索引结构为了提升效率,从来都是一个黑匣子。现在这个黑匣子可以以明文的方式存储了。

                   很显然这个编码器主要是调试、演示用的。估计很多需要写论文的同学们很乐意使用这个功能。

 

       E: Bloom编码器codec: 国内很多人把Bloom翻译为布隆,我还是喜欢直接用英文的Bloom。

                    关于什么是Bloom 参考我之前的一片文章:http://blog.csdn.net/accesine960/article/details/1491483

       F:直接编码器 codec : 由这个名字可以看到,这个编码器是为提升效率用的,主要针对高内存需求类的场景定制的。

      G: 块解码器 codec:  使用了一个新的索引结构和压缩模式schema。

 

      十一、Term 偏移量可以选择与Postings list存储在一起。

 

      十二、新增AutomatonQuery ,用来返回所有Term匹配有限状态机文章列表

      十三、FuzzyQuery 查询速度提升了100-200倍。

      十四、新增拼写检查器DirectSpellChecker,新的拼写检查器不需要单独的索引,能够直接使用主索引。

      十五、 运行中的内存数据结构优化,包括:term 目录,FiledCache 等。

      以:500万wekipedia数据为例 3.x 索引时需要600M内存,4.x 索引时需要 200M内存。

 

     十六、所有的搜索逻辑现在针对每个segment上工作。IndexReaer 也被完全重构,变成了:Atomic 和 Composite Reader。

        这个变化比较大,我们知道Lucene在生成索引的时候会先生成小的Segment然后逐渐合并成大的Segment。Lucene的所有结构和组件都是以多个Segment为导向进行设计架构的。为搜索多个Segment需要MultiReader,而多Reader的会导致在搜索TermEnum 或者 Postings 的时候搜索效率的下降。因此新的Reader去掉了MultiReader,以Atomic和Composite Reader 代替。

 

     十七、Lucene 4.0 提供了模块化的API。 以模块化的方式提供了 非结构化信息管理分析器 和 空间信息搜索模块。

 

 

相关参考:

http://www.lucidimagination.com/blog/2011/09/12/flexible-ranking-in-lucene-4

http://blog.mikemccandless.com/2011/05/265-indexing-speedup-with-lucenes.html

http://blog.mikemccandless.com/2012/03/new-index-statistics-in-lucene-40.html

http://blog.mikemccandless.com/2012/03/new-index-statistics-in-lucene-40.html

http://blog.mikemccandless.com/2011/06/primary-key-lookups-are-28x-faster-with.html

http://blog.mikemccandless.com/2010/06/lucenes-pulsingcodec-on-primary-key.html

http://blog.mikemccandless.com/2010/10/lucenes-simpletext-codec.html

http://www.slideshare.net/otisg/finite-state-queries-in-lucene

http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html

http://blog.mikemccandless.com/2010/07/lucenes-ram-usage-for-searching.html

http://blog.thetaphi.de/2012/02/is-your-indexreader-atomic-major.html

posted @ 2012-12-29 17:10  爱开卷360  阅读(2258)  评论(0编辑  收藏  举报