lucene索引优化

1、这篇文章主要介绍了如何提高 Lucene 的索引速度。介绍的大部分思路都是很容易尝试的，当然另外一部分可能会加大你程序的复杂度。所以请确认索引速度确实很慢，而且很慢的原因确实是因为 Lucene自身而造成的。 推荐姐妹篇： 皿提高和优化 Lucene搜索速度?确认你在使用最新的 Lucene 版本。?尽量使用本地文件系统远程文件系统一般来说都会降低索引速度。 如果索引必须分布在远程服务器，请尝试先在本地生成索引，然后分发到远程服务器上。?使用更快的硬件设备，特别是更快的 IO 设备?在索引期间复用单一的IndexWhter实例?使用按照内存消耗Flush代替根据文档数量Flush在 Lucen

2、e2.2 之前的版本，可以在每次添加文档后调用 ramSizelnBytes 方法,当索引消耗过多的内存时，然后在调用 flush()方法。这样做在索引大量小文档或者文档大小不定的情况下尤为有效。你必须先把 maxBufferedDocs 参数设置足够大，以防止 writer 基于文档数量 flush。但是注意，别把这个值设置的太大，否则你将遭遇Lucene-845 号 BUG 不过这个 BUCE 经在 2.3 版本中得到解决。在 Lucene2.3 之后的版本。 IndexWriter 可以自动的根据内存消耗调用 flush()。你可以通过 writer.setRAMBufferSizeMB

3、()来设置缓存大小。 当你打算按照内存大小 flush 后，确保没有在别的地方设置 MaxBufferedDocs 值。 否则 flush 条件将变的不确定(谁先符合条件就按照谁)。?在你能承受的范围内使用更多的内存在 flush 前使用更多的内存意味着 Lucene 将在索引时生成更大的 segment,也意味着合并次数也随之减少。在 Lucene-843 中测试，大概 48M 时存可能是一个比较合适的值。但是，你的程序可能会是另外一个值。这跟不同的机器也有一定的关系，请自己多加测试，选择一个权衡值。?关闭复合文件格式调用 setUseCompoundFile(false)可以关闭复合文件选

4、项。 生成复合文件将消耗更多的时间(经过 Lucene-888 测试，大概会增加 7%-33%勺时间)。但是请注意,这样做将大大的增加搜索和索引使用的文件句柄的数量。如果合并因子也很大的话，你可能会出现用光文件句柄的情况。重用 Document 和 Field 实例在 lucene2.3 中，新增了一个叫 setValue 的方法，可以允许你改变字段的值。这样的好处是你可以在整个索引进程中复用一个 Filed 实例。这将极大的减少 GC 负担。最好创建一个单一的 Document 实例，然后添加你想要的字段到文档中。同时复用添加到文档的 Field 实例，通用调用相应的 SetValue 方法

5、改变相应的字段的值。然后重新将 Document 添加到索引中。注意：你不能在一个文档中多个字段共用一个 Field 实例，在文档添加到索引之前，Field 的值都不应该改变。也就是说如果你有 3 个字段，你必须创建 3 个 Field 实例，然后再之后的 Document 添加过程中复用它们。?在你的分析器 Analyzer 中使用一个单一的 Token 实例在分析器中共享一个单一的 token 实例也将缓解 GC 的压力。?在 Token 中使用 char 口接口来代替 String 接口来表示数据在 Lucene2.3 中，Token 可以使用 char 数组来表示他的数据。这样可以避免

6、构建字符串以及 GC 回收字符串的消耗。通过配合使用单一 Token 实例和使用char 口接口你可以避免创建新的对象。?设置 autoCommit 为 false在 Lucene2.3 中对拥有存储字段和 Term 向量的文档进行了大量的优化，以节省大索引合并的时间。你可以将单一复用的 IndexWriter 实例的 autoCommit 设置为 false 来见证这些优化带来的好处。注意这样做将导致 searcher 在IndexWriter 关闭之前不会看到任何索引的更新。如果你认为这个对你很重要，你可以继续将 autoCommit 设置为 true,或者周期性的打开和关闭你的 writ

7、er。?如果你要索引很多小文本字段，如果没有特别需求，建议你将这些小文本字段合并为一个大的 contents 字段，然后只索引 contents。（当然你也可以继续存储那些字段）?加大 mergeFactor 合并因子，但不是越大越好大的合并因子将延迟 segment 的合并时间，这样做可以提高索引速度，因为合并是索引很耗时的一个部分。但是，这样做将降低你的搜索速度。同时，你有可能会用光你的文件句柄如果你把合并因子设置的太大。值太大了设置可能降低索引速度，因为这意味着将同时合并更多的 segment,将大大的增加硬盘的负担。?关闭所有你实际上没有使用的功能如果你存储了字段，但是在查询时根本没有

8、用到它们，那么别存储它们。同样 Term向量也是如此。如果你索引很多的字段，关闭这些字段的不必要的特性将对索引速度提升产生很大的帮助?使用一个更快的分析器有时间分析文档将消耗很长的时间。 举例来说， StandardAnalyzer 就比较耗时,尤其在Lucene2.3 版本之前。你可以尝试使用一个更简单更快但是符合你需求的分析器。?加速文档的构建时间在通常的情况下，文档的数据来源可能是外部（比如数据库，文件系统，蜘蛛从网站上的抓取等），这些通常都比较耗时，尽量优化获取它们的性能。?在你真的需要之前不要随意的优化 optimize 索引（只有在需要更快的搜索速度的时候）?在多线程中共享一个 I

9、ndexWriter最新的硬件都是适合高并发的（多核 CPU 多通道内存构架等），所以使用多线程添加文档将会带来不小的性能提升。就算是一台很老的机器，并发添加文档都将更好的利用 IO 和 CPU 多测试并发的线程数目，获得一个临界最优值。?将文档分组在不同的机器上索引然后再合并如果你有大量的文本文档需要索引，你可以把你的文档分为若干组，在若干台机器上分别索引不同的组， 然后利用 writer.addIndexesNoOptimize 来将它们合并到最终的一个索引文件中。?运行性能测试程序如果以上的建议都没有发生效果。建议你运行下性能检测程序。找出你的程序中哪个部分比较耗时。这通常会给你想不到的

10、惊喜。当你取回文档时，使用 FieldSelector 仔细的选择哪些字段需要获取，如何获取。不要获取多于你需要的 hits获取更多的搜索结果将会降低搜索速度。有两个原因：其一，search 方法在返回 Hits 对象时，如果超过 100 个 hits,lucene 将在内部自动重新执行搜索。解决方案：使用返回 HitCollector 的 Search 方法。其二,搜索结果可能分布在硬盘的不同地方，获取他们可能需要很多的 IO 操作。这个是很难避免的，除非索引比较小，可以直接缓存到内存当中。如果你不需要完整的文档对象，你只需要其中的一个很小的字段，你可以使用 FieldCache 类来缓存它，从而达到快速访问的效果。当使用 fuzzy 查询时设置一个较小的比较长度（pre 巾 xLength）Fuzzy 查询执行 CPL集型字符串比较，尽量避免将用户查询的 Term 与所有的 Term 进行比较。你可以设置只比较以前 N 个字符开头的 Term。prefixLength 在 QueryParser 以及 FuzzyQuery 中可