每个索引的 ElasticSearch 段答案

【问题标题】：ElasticSearch Segments Per Index每个索引的 ElasticSearch 段
【发布时间】：2015-08-03 05:06:12
【问题描述】：

我们有每月索引（当前为 11 个月），每个索引有 22 个分片。我看到每个索引似乎有很多段（大约 1200 到 1380 段）。较旧的索引应该只有很少的更新，如果它们发生任何更新的话。从我读过的所有内容来看，听起来 ES 应该自动合并段，但现在我有点担心这不会发生。我知道我们可以手动运行优化，但需要分配另一个资源来完成这项工作（以免影响当前系统）。我对 ES 相当陌生（如果这不是很明显），我真的想了解我们是否有问题。也可能是我们需要将 index.merge.policy.segments_per_tier 调整为小于 10。真的不确定。

粗略的索引统计：

11 个索引每个索引 22 个分片每个索引 6500 万个文档每个索引 350 GB

非常感谢任何信息、建议等。

谢谢，

【问题讨论】：

您现在可以执行的最佳步骤，尤其是您拥有基于时间的索引时，是手动优化未写入的索引。您肯定会看到性能的改进。段越多，使用的堆内存就越多。 ES 确实会自动合并段，但是 Lucene 应该有一些条件来合并段（段的大小、其中删除的文档数、几乎相同大小的段数等）。过去的版本中存在与合并相关的问题，但不确定您是否遇到了问题。
感谢安德烈的信息！我们目前处于 1.3 版（即将升级到 1.5 版）。手动运行优化有多大影响？如果我们停止所有索引，是否需要大约几分钟、几小时等来优化与我们的大小相似的索引？再次感谢。
您是否在旧索引中编制索引？
到某个点，然后没有。所以不应该修改超过 6 个月的索引。
我认为您不应该仅仅为了优化索引而完全停止索引。当您认为集群上的负载不是那么高时，您可以尝试每天优化一个索引...

标签： elasticsearch

【解决方案1】：

您现在可以执行的最佳步骤是手动优化未写入的索引，尤其是您拥有基于时间的索引。您肯定会看到性能的改进。段越多，使用的堆内存就越多。

ES 确实会自动合并段，但 Lucene 需要满足某些条件来合并段（段的大小、其中已删除文档的数量、几乎相同大小的段数等）。过去的版本中存在与合并相关的问题，但不确定您是否遇到了问题。

当您认为集群上的负载没有那么高时，您可以尝试每天优化一个索引。您可能知道Curator 可用于此操作和其他操作。

【讨论】：

谢谢安德烈，感谢您提供的信息。