如何提高和优化Lucene搜索速度(转)

     原文地址

     确认你在使用Lucene的最新版本

• 尽量使用本地文件系统

远程文件系统一般来说都会降低搜索速度。如果索引必须分布在远程服务器，可以尝试将远程文件系统设置为只读。在某些情况下，这样可以提高性能。

• 使用更快的硬件设备，特别是更快的IO设备

Lucene搜索可以很好的工作在基于闪存的固态硬盘上。固态硬盘的寻道时间大概比传统的以磁盘为基础的硬盘快100倍。这意味着，配备固态硬盘的机器用于文件缓存的内存将变少，搜索需要较少的热身时间，能够更加迅速作出反应。

• 加大你的机器内存容量，给Java虚拟机分配更多的内存

索引越大，在搜索时需要使用更多的内存。如果你的机器没有足够大的内存或者你的Java虚拟机没有设置足够大的堆空间，频繁的页面文件交换和虚拟内存的使用将使你的硬盘处于超负荷状态运行，此时，一切的程序都将运行的很慢。

• 在程序中使用一个唯一的IndexSearch实例

在程序的查询中共享一个IndexSearch实例，它支持多线程安全。

• 当测试搜索速度时，忽略第一次查询时间

第一次搜索将花费部分时间在缓存上（特别在按某个字段排序的情况下），从而可能使你的测试结果不太准确（假设你在多个查询中复用一个IndexSearch实例）。另一方面来说，如果你一次又一次的重复同一个查询，所得的测试结果也是不准确的。因为操作系统将利用其高速缓存加速IO操作。在Linux上，你可以使用如下命令清除磁盘高速缓存：

echo 3 > /proc/sys/vm/drop_caches.

• 只有在必要的时候才重新构造IndexSearcher

为了获得更新的索引信息，你必须重新构造IndexSearch。当然，重新构造一个searcher会带来一定的系统开销（注意，这大多发生在大索引以及自定义排序上），所以你应该尽量减少重新构造。你可以考虑在重新构造之后强制进行一次搜索预热。

• 在搜索之前调用optimize优化你的索引

一个优化后的索引只含有一个Segment（其实说法不严谨，这也取决于一个Segment最多含有的文档参数），这将比同等情况下含多个Segment的索引搜索速度更快。特别是在大索引的情况下。如果你的程序不经常更新索引，那么花费一定的时间来优化下，然后使用优化后的索引来进行搜索。如果你的索引更新的频率很高，那么优化索引将会是一个很耗时间的事情，这个时候你可以减少mergeFactor参数。

个人建议，在频繁更新索引的情况下，使用两个索引，一个大的优化好的历史索引，一个小的实时添加的索引（如果数据不大的情况下，直接使用RAMDirectory，然后定时的合并到大索引中）

• 减小MergeFactor合并因子的值

更小的合并因子意味着索引中拥有更少的Segment，搜索速度也将更快。但是，这也将降低索引速度。你需要自己测试一个值来平衡二者的关系。（此条只适用于不能经常优化的索引库）

• 限制存储字段的使用以及获取尽可能少的数据

从索引中获取数据是一件很耗时间的事情，你最好只获取用户需要的数据。而不是整个文档中存储的数据。每个文档的取回，lucene都必须去索引文件中不同的地方甚至是不同的文件中查找。可以尝试将你需要的文档先按文档编号排序再获取。

• 当你取回文档时，使用FieldSelector仔细的选择哪些字段需要获取，如何获取。
• 不要获取多于你需要的hits

获取更多的搜索结果将会降低搜索速度。有两个原因：其一，search方法在返回Hits对象时，如果超过100个hits，lucene将在内部自动重新执行搜索。解决方案：使用返回HitCollector的Search方法。其二，搜索结果可能分布在硬盘的不同地方，获取他们可能需要很多的IO操作。这个是很难避免的，除非索引比较小，可以直接缓存到内存当中。如果你不需要完整的文档对象，你只需要其中的一个很小的字段，你可以使用FieldCache类来缓存它，从而达到快速访问的效果。

• 当使用 fuzzy 查询时设置一个较小的比较长度 （prefixLength）

Fuzzy查询执行CPU密集型字符串比较，尽量避免将用户查询的Term与所有的 Term进行比较。你可以设置只比较以前N个字符开头的Term。prefixLength在QueryParser以及FuzzyQuery中可以设置。默认值为0，将比较所有的Term。

• 考虑使用filters

有时候我们的查询将限制部分索引中的记录，这时候使用一个经过缓存了的bit set filter将比使用查询子句更有效，尤其在一个大索引中。过滤器经常用在查询分类结果上。它可以用查询子句限制来替换，区别在于使用Query将影响文档的得分，而Filter不会。