我们每隔7小时对Lucene索引和增量索引每7天运行一次完整的重新索引(即从头开始创建索引).我们的索引有大约700,000个文档,完整索引大约需要17个小时(这不是问题).
当我们进行增量索引时,我们只会对过去两小时内已更改的内容进行索引,因此所需时间会少得多 - 大约半小时.但是,我们注意到很多时候(可能是10分钟)花在运行IndexWriter.optimize()方法上.
该LuceneFAQ提到:
IndexWriter类支持optimize()方法,该方法压缩索引数据库并加快查询速度.在执行文档集的完整索引或索引的增量更新之后,您可能希望使用此方法.如果增量更新经常添加文档,则只需要偶尔执行一次优化,以避免额外的优化开销.
......但这似乎没有给出"经常"含义的任何定义.优化是CPU密集型和非常密集的IO,所以如果我们能够摆脱它,我们宁愿不这样做.在未优化的索引上运行查询的效果是多少(特别是在完全重新索引之后的查询性能方面与20个增量索引之后相比,例如50,000个文档已经更改)？我们应该在每个增量索引之后进行优化还是性能损失不值得？
你能否就lucene性能应遵循的步骤提出建议.特别是大数据(大约1TB的pdf文件要编入索引)