应该指数进行优化后的增量指标的分类：设?

Question

我们完全重新索引，每次7天(即创建该指数从头开始)在我们的指数分类：设和递增的索引，每2个小时左右。我们的指数有700,000个文件和一个全面的索引，大约需要17小时(这是不是一个问题)。

当我们这样做增量指标，我们仅指数内容已经改变了过去两小时，所以它需要多少时间-周围的一个半小时。然而，我们注意到，很多这个时候(或许10分钟)是花在运行的IndexWriter.优化()方法。

的 LuceneFAQ 提到了：

该IndexWriter类支持的一个优化()方法，契约索引的数据库，并加速查询。你可能想要使用这种方法在执行一个完整索引的文件设定的或以后的增量更新的指数。如果你增量更新添加了文件频繁，你想要执行的优化，只有一旦在一段时间，以避免额外开销的优化。

...但这似乎并没有得到任何定义什么是"常见"的意思。优化CPU密集和非常IO密集型的，因此，我们宁愿不这样做，如果我们可以摆脱它。有多少是命中的运行查询于联合国优化指数(我想特别是在查询后的性能完全重新指标相比，在20递增的索引，其中说，50,000文件已经改变)?我们应该优化后，每增的索引，或者是性命不值得吗？

Answer 1

垫子，因为你似乎有一个好主意怎么只要你的当前进程的需要，我建议删除 optimize() 和措施的影响。

做很多的文件变化，在这2小时windows？如果只有一小部分(50,000/700,000是约7%)是逐步重新编制索引，然后我不认为你得到多少价值的 optimize().

一些想法：

• 不要做一个增量 optimize() 在所有。我的经验说你是不是看到一个巨大改善查询。
• 做 optimize() 每日而不是2-每小时。
• 做 optimize() 在低容量的时间(这是什么 如果是的话，为什么不试 说).

和确保采取的测量。这种变化可以在黑暗中拍摄没有他们。

Answer 2

一个 optimize 操作的读写整个指数，这就是为什么这么IO密集型!

背后的想法优化操作是重新组合所有各分段在本分类：设索引入一个单一的片段，这样可以大大减少查询时间为你没有打开和搜索些文件的查询。如果你使用的正常分类：设指数文件的结构(而不是组合的结构)，你会得到一个新段，每个提交操作；同样，作为重新索引我假设?

我认为 Matt 有很好的建议和我的第二他说的一切-是的驱动数据。我实际上更进一步，并只optmize a)当需要和b)当你低查询量。

如查询的表现是密切相关的段数，在你的指数，一个简单的 ls -1 index/segments_* | count 可能是一个有用的指标时，在优化的真正需要的。

或者，追踪查询的性能和容量并开始一个优化的，当你达到不可接受的低性能与可接受的低量将是一个更好的解决方案。

Answer 3

在此邮件中，Otis Gospodnetic建议反对使用optimize，如果您的索引看到不断更新。它是从2007年开始的，但是调用 optimize（）本质上是一个IO重的操作。您可以考虑使用更加逐步的方法; MergeScheduler