是否应该在Lucene的增量索引之后优化索引？

Question

我们每隔7小时对Lucene索引和增量索引每7天运行一次完整的重新索引(即从头开始创建索引).我们的索引有大约700,000个文档,完整索引大约需要17个小时(这不是问题).

当我们进行增量索引时,我们只会对过去两小时内已更改的内容进行索引,因此所需时间会少得多 - 大约半小时.但是,我们注意到很多时候(可能是10分钟)花在运行IndexWriter.optimize()方法上.

该LuceneFAQ提到:

IndexWriter类支持optimize()方法,该方法压缩索引数据库并加快查询速度.在执行文档集的完整索引或索引的增量更新之后,您可能希望使用此方法.如果增量更新经常添加文档,则只需要偶尔执行一次优化,以避免额外的优化开销.

......但这似乎没有给出"经常"含义的任何定义.优化是CPU密集型和非常密集的IO,所以如果我们能够摆脱它,我们宁愿不这样做.在未优化的索引上运行查询的效果是多少(特别是在完全重新索引之后的查询性能方面与20个增量索引之后相比,例如50,000个文档已经更改)？我们应该在每个增量索引之后进行优化还是性能损失不值得？

Answer 1

Mat,因为您似乎很清楚当前流程需要多长时间,我建议您删除optimize()并测量影响.

那些2小时的窗户中有很多文件发生了变化吗？如果只有一小部分(50,000/700,000约为7%)被逐步重新编入索引,那么我认为你没有从中得到多少价值optimize().

一些想法:

• 根本不做增量optimize().我的经验表明,无论如何你都没有看到巨大的查询改进.
• 做optimize()日常,而不是2小时.
• 执行optimize()过程中的低容积倍(这是什么的javadoc说).

并确保您进行测量.这些变化可以在没有它们的情况下在黑暗中拍摄.