performance - Lucene 以及如何测量索引碎片

Question

我们正在使用 Lucene 2.9.2(计划升级到 3.x)，众所周知，搜索查询会随着时间的推移而变慢。通常我们执行完整的重建索引。我已经阅读了问题 https://stackoverflow.com/a/668453/356815及其答案并立即回答:我们不使用 optimize() 因为运行它时性能不再可接受。

碎片化？

我想知道以下问题:衡量现有索引碎片化程度的最佳做法是什么？可以Luke帮助我吗？

很高兴听到您对这个分析主题的看法。

关于我们索引的更多信息:

• 我们已经为 400,000 份文档建立了索引
• 我们大量使用每个文档的属性
• 对于每个请求，我们创建一个新的搜索器对象(因为我们希望更改立即出现在搜索结果中)
• 查询性能介于 30 毫秒(重复相同的搜索)和 10 秒(复杂)之间
• 索引包含44个文件(15个.del文件，24个cfs文件)，大小为1GB

Answer 1

旧版本的 Lucene 无法有效处理大量段。这就是为什么有些人建议优化(将所有段合并在一起)以提高搜索性能的原因。

对于最新版本的 Lucene，情况并非如此。事实上，优化已被重命名为听起来不那么神奇(您现在需要调用 forceMerge(1))，并且总是合并段甚至被认为是有害的(看看来自 Lucene 开发人员 Simon Willnauer 的 nice article)。

For each request we create a new searcher object

打开一个阅读器是非常昂贵的。您应该使用 SearcherManager这将帮助您仅在必要时重新打开(增量打开)索引。