Apache LuceneTM5.0.0 版本即将发布
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 gone”bug（Lucene-4870）的可怕风险。
Lucene的索引复制模块，以及基于Lucene构建的分布式服务器,比如ElasticSearch和Solr，都有将索引文件从一个地方拷贝到其它的地方的功能需求。这样的功能需求是旨在备份索引(比如索引快照和索引恢复)，或是在添加新的索引副本时，能够从其它的节点中迁移或者恢复索引分片。复制器尝试以增量的方式来复制索引，因此，如果同名文件在索引源和索引目的地都存在，并且校验和(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支持随机写入和更高级的稀疏bitsets（RoaringDocIdSet和SparseFixedBitSet），因此堆内存的占用与设置的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来打印出一个树形结构，以递归分解的方式显示出每个部分占用的堆内存容量。该API与Lucene的explainAPI功能类似，只是将文档各个部分的打分值替换成了堆内存占用值。该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速度快得多，而且也消耗更少的堆内存。
各种Tokenizer和Analyzer初始化时也不再需要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的相关信息。