lucene2.9的改进

Lucene 2.9的大部分重心放在了性能优化方面，这体现在从低端的内部基础结构改进到索引管理方式等多个方面。Lucene的索引数据库由一系列分离的“片断”组成，每个片段存放在独立的文件中。当你向索引中添加文档时，便会不断创建一些可以合并的新片断。Lucene会在FieldCache中缓存字段信息，不过在Lucene 2.4以及之前的版本中，加载字段缓存的开销相对较高，尤其在2.4版本中还会不断重新加载整个字段缓存。在发布2.9版本的准备过程中，Lucene团队意识到，在进行合并或删除的时候片断的改变频率通常比较高，不过较早的片断则更趋向于保持不变。因此，修改后的字段缓存只会加载更新过的片断。

Lucene跨片断加载FieldCache的效率也不够好。因此，2.9版本会为每个片段分别管理FieldCache，以此避开跨片断加载FieldCache的需求。这个改变的效果非常明显，Lucid Imagination的Mark Miller运行了一个简单的性能测试，表明在5,000,000个不同字符串下的情况下，Lucene 2.9相对于2.4版本会获得15倍左右的性能提高：
Lucene 2.4: 150.726s
Lucene 2.9: 9.695s

另一个显著的性能提高在于重开（re-opening）搜索的时候。Lucene 2.9引入了新的IndexWriter.getReader()方法，它可用于搜索目前完整的索引，包括当前IndexWriter会话中还没有提交的改变，这带来了接近于实时搜索的能力。此外，你还可以调用IndexWriter.setMergedSegmentWarmer()方法进行“预热”，这样那些片断便可以立即投入使用了。

另一个重大变化则是数字的处理方式，尤其是在范围查询（如“给我找出价格在0.5到9.99英镑之间的CD”）的场景下。在2.9版之前，Lucene的查询完全基于文本，因此对于数字的处理则变成了基于字符串的精确编码。这种做法经常会生成大量独立的关键字，Lucene需要通过遍历的方式来构建整个结果集。在此之前，许多开发人员使用了自定义的编码规则来应对这种情况，不过Lucene 2.9已经自带对数字的处理方式。Field和Query类会采取合适的精度进行索引和搜索，这样大大降低了需要搜索的关键字数量，使查询的响应能力得以显著提高。

2.9版本还引入了新的查询类型和适用性更广的多关键字查询（通配、前缀等等）方式，以及新的针对波斯语，阿拉伯语及中文的分析器。此外，这次更新还包括更好Unicode支持，一个新的查询分析框架，以及对地理位置的查询，它允许根据距离信息对文档进行过滤和排序（如“找出我家5英里范围内的所有干洗店”）。你可以在这里找到完整的改进列表。

一般来说，Lucene会在主要版本之间保持完整的兼容性，但是CHANGES.txt的“向后兼容策略”一节中列举了Lucene 2.9在许多地方对兼容性的破坏。对于2.9版本的升级操作很可能需要一次重新编译，合适完整的回归测试以及其它在这方面的努力。基于2.9版本的重新编译也会提示出所有即将被废弃的方法，这样开发人员便可以升级他们的应用程序，并为3.0版本作好准备。这是个明智的做法，因为Lucene 3.0会放弃对Java 1.4的支持，并且删除所有2.9版本中被标记为“deprecated”的功能。