lucene性能优化

优化搜索性能 
虽然建立索引的操作非常耗时，但是那毕竟只在最初创建时才需要，平时只是少量的维护操作，更何况这些可以放到一个后台进程处理，并不影响用户搜索。我们创建索引的目的就是给用户搜索，所以搜索的性能才是我们最关心的。下面就来探讨一下如何提高搜索性能。 

1 将索引放入内存 
这是一个最直观的想法，因为内存比磁盘快很多。Lucene提供了RAMDirectory可以在内存中容纳索引： 

Directory fsDir = FSDirectory.getDirectory(“/data/index/”, false); 
Directory ramDir = new RAMDirectory(fsDir); 
Searcher searcher = new IndexSearcher(ramDir); 

但是实践证明RAMDirectory和FSDirectory速度差不多，当数据量很小时两者都非常快，当数据量较大时（索引文件400M）RAMDirectory甚至比FSDirectory还要慢一点，这确实让人出乎意料。 
而且lucene的搜索非常耗内存，即使将400M的索引文件载入内存，在运行一段时间后都会out of memory，所以个人认为载入内存的作用并不大。 

2 优化时间范围限制 
既然载入内存并不能提高效率，一定有其它瓶颈，经过测试发现最大的瓶颈居然是时间范围限制，那么我们可以怎样使时间范围限制的代价最小呢？ 
当需要搜索指定时间范围内的结果时，可以： 
1、用RangeQuery，设置范围，但是RangeQuery的实现实际上是将时间范围内的时间点展开，组成一个个BooleanClause加入到 BooleanQuery中查询，因此时间范围不可能设置太大，经测试，范围超过一个月就会抛BooleanQuery.TooManyClauses，可以通过设置 BooleanQuery.setMaxClauseCount(int maxClauseCount)扩大，但是扩大也是有限的，并且随着maxClauseCount扩大，占用内存也扩大 
2、用RangeFilter代替RangeQuery，经测试速度不会比RangeQuery慢，但是仍然有性能瓶颈，查询的90%以上时间耗费在 RangeFilter，研究其源码发现RangeFilter实际上是首先遍历所有索引，生成一个BitSet，标记每个document，在时间范围内的标记为true，不在的标记为false，然后将结果传递给Searcher查找，这是十分耗时的。 
3、进一步提高性能，这个又有两个思路： 
a、缓存Filter结果。既然RangeFilter的执行是在搜索之前，那么它的输入都是一定的，就是IndexReader，而 IndexReader是由Directory决定的，所以可以认为RangeFilter的结果是由范围的上下限决定的，也就是由具体的 RangeFilter对象决定，所以我们只要以RangeFilter对象为键，将filter结果BitSet缓存起来即可。lucene API已经提供了一个CachingWrapperFilter类封装了Filter及其结果，所以具体实施起来我们可以cache CachingWrapperFilter对象，需要注意的是，不要被CachingWrapperFilter的名字及其说明误导，CachingWrapperFilter看起来是有缓存功能，但的缓存是针对同一个filter的，也就是在你用同一个filter过滤不同 IndexReader时，它可以帮你缓存不同IndexReader的结果，而我们的需求恰恰相反，我们是用不同filter过滤同一个 IndexReader，所以只能把它作为一个封装类。 
b、降低时间精度。研究Filter的工作原理可以看出，它每次工作都是遍历整个索引的，所以时间粒度越大，对比越快，搜索时间越短，在不影响功能的情况下，时间精度越低越好，有时甚至牺牲一点精度也值得，当然最好的情况是根本不作时间限制。 
下面针对上面的两个思路演示一下优化结果（都采用800线程随机关键词随即时间范围）： 
第一组，时间精度为秒： 
方式 直接用RangeFilter 使用cache 不用filter 
平均每个线程耗时 10s 1s 300ms 

第二组，时间精度为天 
方式 直接用RangeFilter 使用cache 不用filter 
平均每个线程耗时 900ms 360ms 300ms 

由以上数据可以得出结论： 
1、 尽量降低时间精度，将精度由秒换成天带来的性能提高甚至比使用cache还好，最好不使用filter。 
2、 在不能降低时间精度的情况下，使用cache能带了10倍左右的性能提高。 

3 使用更好的分析器 
这个跟创建索引优化道理差不多，索引文件小了搜索自然会加快。当然这个提高也是有限的。较好的分析器相对于最差的分析器对性能的提升在20%以下。