3

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

碎片化？

我想知道以下几点：衡量现有索引碎片的最佳实践是什么？卢克能帮我吗？

听听您对这个分析主题的看法会很有趣。

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

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

1 回答 1

3

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

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

对于每个请求，我们都会创建一个新的搜索器对象

打开阅读器的成本很高。您应该使用SearcherManager，它只会在必要时帮助您重新打开（增量打开）您的索引。

于 2012-08-29T12:41:49.543 回答