Apache LuceneTM5.0.0 版本即将发布

    源文地址:http://blog.mikemccandless.com/2014/11/apache-lucene-500-is-coming.html


最后,在密集发布一系列4.x版本的特性后,最近发布的是4.10.2版本,我们把工作重心转移到了Apache Lucene的另一个版本!

目前没有给出该版本确切的发布时间(什么时间完成就是什么时间!),但是自荐的发布经理已经着手在准备着相关的工作(谢谢你,Anshum!)

Lucene的主版本中将删除前面版本(4.10.x) 中所有废弃的APIs,不再支持3.x版本的索引,但是还是会向后兼容大多数4.x版本的索引格式,此外,4.10.x版本的分支将作为bug-fix(漏洞修复)的系列版本(不再添加新的特性,也不再对API进行修改)

5.0.0版本已经包含了一系列激动人心的改变,具体内容将随后阐述,这些改变目前正在紧罗密布开发中。

 

更强大的索引完整性保护功能


5.0.0版本的许多改变都集中于开发更强大的索引保护策略,以避免索引的损坏。


所有文件操作类都替换成了JavaNIO.2 API,为的是让我们能够更精确地处理读写错误(比如,Files.delete返回有意义的异常),以原子操作的方式对文件进行重命名,使索引提交更安全可控,减少了出现类似“Your entrie index is gonebugLucene-4870)的可怕风险。


Lucene的索引复制模块,以及基于Lucene构建的分布式服务器,比如ElasticSearchSolr,都有将索引文件从一个地方拷贝到其它的地方的功能需求。这样的功能需求是旨在备份索引(比如索引快照和索引恢复),或是在添加新的索引副本时,能够从其它的节点中迁移或者恢复索引分片。复制器尝试以增量的方式来复制索引,因此,如果同名文件在索引源和索引目的地都存在,并且校验和(check sum)的长度一致,那么该文件就不会被重新拷贝一遍。


不幸的是,这种处理方式有时会遗漏一些不易察觉的bugs(它们都很复杂)。还好我们有checksums(4.8.0版本中添加,参考Lucene-2446) Lucene已经能够检测复制器拷贝数据引发的位翻转错误(bit-flips)。这个问题还引出了ElasticSearch使用的压缩工具包中一个潜伏以久的bug


5.0.0中对这个问题做了更深入细致的研究,通过对每个段和每次提交事务(segment_N文件)赋予一个唯一的id,就可以在索引拷贝时检测出是否拷贝成了错误的文件名。每个索引文件都会在文件头记录段的id,然后在索引打开时对这些id进行交叉检验。


新的Lucene50Codec也引入了更加全面的索引损坏检测机制。


甚至CorruptIndexException 这个异常类都进行了提升。在检测到索引出现损坏时,该类会直指出现问题的索引文件和资源,当然该类的构造器也需要一个额外的参数。


当探测到某个浅层问题时(比如域信息文件(fieldinfos file)中域编号(field number)出错),抛出的异常对象CorruptIndexException 同时会检测文件的checksum是否匹配,以此缩小问题的来源范围,方便问题的定位。


最后,在索引合并过程中,IndexWriter会在合并之前检测待合并段是否损坏。这就意味着,如果Lucene应用升级到了5.0.0版本,那么在索引合并时就能够检测出4.x老版本索引中潜伏以久的索引损坏问题。


精简堆内存的占用


5.0.0版本同时也做了一些改变来减少索引过程和搜索过程堆内存的占用。


如果用户索引有1B(译者注:即10亿)的文档,那么在4.10.2版本中用基于FixedBitSet的过滤器来缓存文档就需要125MB的堆内存空间。但是在5.0.0中,Lucene支持随机写入和更高级的稀疏bitsetsRoaringDocIdSetSparseFixedBitSet),因此堆内存的占用与设置的bits数成比例,而非索引中文档的总数。这些bitsets同时也极大简化了MultiTermQuery的重写(rewriten)方式(不再需要CONSTANT_SCORE_AUTO_REWRITE_METHOD),此外也提供了比FixedBitSet更快速的线性查找实现方式。最后,它们还提供了更加精确的cost()方法的代码实现,使得查询阶段Lucene可以以更好的策略来对文档集合进行取交集运算。


    IndexWriter中,新引入Lucene50Codec类的使用,使索引合并时,堆内存占用大大降低,这是因为在处理过程中,待合并段所有域的doc values信息和norms信息不再一起导入到堆内存中;而只导入正在合并的单个域,该域合并完成后数据会立即删除。


    默认归一化信息(norms)的文本格式将优先使用稀疏编码,因此在搜索阶段,对于众多稀疏域,使用归一化信息时将大幅度减少堆内存的占用。


为堆内存占用提供explain API


    如果用户仍然感觉Lucene应用的堆内存占用多于预算值,5.0.0版本提供了新的API来打印出一个树形结构,以递归分解的方式显示出每个部分占用的堆内存容量。该APILuceneexplainAPI功能类似,只是将文档各个部分的打分值替换成了堆内存占用值。该API的输出如下:

_cz(5.0.0):C8330469: 28MB

  postings [...]: 5.2MB

    ...

    field 'latitude' [...]: 678.5KB

      term index [FST(nodes=6679,...)]: 678.3KB

这可比通过分析Java heap dump文件查看堆内存占用来得方便直观。

 

更多其它的改变


5.0.0版本做出了太多的改变,下面只列举一部分:


  • 旧的实验版的postings formtas(Sep/FixedVariableIntPostingsFormat)已经移除。PlusingPostingsFormat也已经移除,因为默认的postings format已经添加了unique terms功能。

  • FieldCache也已移走(移到了misc模块中专属的UninvertingReader类中)。这意味着如果用户想对某个域排序,用户应该使用doc values来索引域值,这可比FieldCache速度快得多,而且也消耗更少的堆内存。

  • 各种TokenizerAnalyzer初始化时也不再需要Reader类参数。

  • NormsFormat拥有专属的NormsConsumer/Producer

  • FieldInfo作了简化(Lucene”low schema”):不再有normType属性(全部以DocValuesType.NUMERIC代替),不再有isIndexed属性(今后只会检测IndexOptions对象)

  • 复合文件(cfs)的处理更加简单,处理逻辑移入了codec的控制范围。

  • SortedSetSortField,用于对multi-valued域进行排序的类,已经从sandbox升职到了Lucene的核心包。

  • PostingsFormat 在对倒排表进行写操作时改用”pull” API,就像doc values一样。这使得PostingsFormat更具威力,因为用户可以对倒排表结构动手动脚了。比如需要遍历整个倒排表中的每个term,来决定数据压缩的格式之类的操作。这可不是只访问一次倒排表就可以做到的。

  • IndexWriterConfig和分析组件的初始化不再需要传入Version对象。

 

    上述的改变只目前整理出来5.0.0版本众多改变的一个缩影。5.0.0版本还在开发过程中(欢迎提交补丁!)因此正式版本发布时,上述的内容依然会有所改变。

    

    译者注:欢迎关注新浪微薄:@帅广应s 了解Lucene的相关信息。