lucene版本对比

一、为什么使用lucene

1、Lucene不是一个完整的全文索引应用，而是是一个用JAVA写的全文索引引擎工具包，它可以方便的嵌入到各种应用中实现针对应用的全文索引/检索功能。这样的定位，使得lucene有很高的抽象层次，便于扩展和整合到已有的系统。因为对于大多数的全文搜索应用来说，我们需要的是一个开发工具包而不是最终产品（虽然很多搜索引擎也可以扩展特性功能）。这也是程序员最愿意接受的封装层次。

2、Lucene的API接口设计的比较通用，输入输出结构都很像数据库的表==>记录==>字段，所以很多传统的应用的文件、数据库等都可以比较方便的映射到Lucene的存储结构/接口中。（上面语句有些来自在应用中加入全文检索功能——基于JAVA的全文索引引擎Lucene简介）。

二、lucene4.0新特性较重要部分

1、全部使用字节( utf-8 tytes )替代string来构建 term directory 。

带来的好处是：索引文件读取速度 30 倍的提升；占用原来大约10%的内存；搜索过程由于去掉了字符串的转化速度也会明显提升；

但是如果说这上面的好处只是一个副产品，你会怎么想？没错，Mysql有MyIsam，Innodb等诸多引擎供我们选择的，Lucene为什么不能向这个方向发展呢？

实现这个机制的模块叫：Codec （编码器），你可以实现自己的Codec 来进行自定义的扩展，很显然Codec的操作对象是Segment 。

2、支持多线程建索引，支持：concurrent flushing。

了解过Lucene 3.X的同学们都知道，诸如XXXPerThread 的类在建索引的时候已经支持多线程了，但是当每个线程的内存达到指定上限(maxBufferedDocs or ramMaxBufferSizeMB)的时候就需要写到硬盘上，而这个过程仍然不是多线程的，仍然需要一个个排队Flush到硬盘。Lucene 4.0 终于支持 concurrent flushing 了。DocumentsWriterPerThread ，Lucene 4.0 的Concurrent Flushing 正是这个类来实现的。

3、基于有限自动机的模糊匹配算法（FSA算法），FuzzyQuery

FuzzyQuery 这类查询估计大家用的比较少。在英文中单词拼写错误，比如： Lucene， Licene , lucen 等就可以用FuzzyQuery来进行查询提高查全率。

在lucene 4.0 之前的FuzzyQuery 的实现非常耗费cpu，实现算法也很暴力。具体过程是：读取每个term，然后计算每个term与查询词的“编辑距离”，如果在指定的范围内则返回。 Lucene 4.0 使用Levenshtein Automaton 的来衡量文字的"编辑距离" ，使用有限状态自动机来进行计算。以数百倍的效率提升了FuzzyQuery 的效率。

三、lucene4.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在应用层能多线程调用，但在写入硬盘的时候还是逐个线程顺序写入的。这对于经常要重建索引的场景，减少了等待索引的时间。

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

六、索引结构更加透明化，增加了索引统计机制，利用这些统计信息，Lucene索引内容不再是一个黑匣子了。包括：提供针对term 或者Field的token数量，针对某个filed的Posting数量，包含某个field的positing的文档数量。当然有了这些索引统计的数据后，就可以自定义的改进评分机制了。也就是说以下方法将会成为你的新朋友：

TermsEnum.docFreq(),TermsEnum.totalTermFreq(),Fields.getUni queTermCount()，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。

F：直接编码器 codec : 由这个名字可以看到，这个编码器是