elasticsearch - 为什么 Elasticsearch 中的段合并需要停止写入索引

Question

我正在寻找运行优化(ES 1.X)，它现在在 ES 最新版本中被称为 forcemerge API。在阅读了 this 和 this 等文章后。似乎我们应该只在只读索引上运行它，引用官方 ES 文档:

Force merge should only be called against read-only indices. Running force merge against a read-write index can cause very large segments to be produced (>5Gb per segment)

但我不明白

在运行 forcemerge 或优化 API 之前将索引置于只读模式的原因。

如上面的 ES 文档所述，它可能导致非常大的段，这不应该是这种情况，因为我的理解是，新的更新首先写入内存中，刷新发生时写入段，那么为什么在 forcemerge 期间写入可以生产非常大的分割市场吗？

如果我们不想将索引置于只读模式并且仍然运行强制合并来清除删除，那么还有什么解决方法。

如果我需要提供任何其他信息，请告诉我。

Answer 1

forcemerge 可以显着提高查询的性能，因为它允许您将现有数量的段合并到更有效的查询数量较少的段中，因为段是按顺序搜索的。合并时，所有标记为删除的文档也会被清理。
作为基于合并策略的 Elasticsearch 内务管理的一部分，合并会在后台定期自动发生。
棘手的事情:合并策略只考虑最大 5 GB 的段。使用带有允许您指定结果段数量的参数的 forcemerge API，您可能会面临结果段大于 5GB 的风险，这意味着将来的合并请求将不再考虑它们。只要您不删除或更新文档，就没有任何问题。但是，如果您继续删除或更新文档，Lucene 会将现有段中的旧版本文档标记为已删除，并将新版本的文档写入新段中。如果您删除的文档位于大于 5GB 的段中，则不会对其进行更多的内务处理，即标记为删除的文档将永远不会被清理。
通过在执行强制合并之前将索引设置为只读，您可以确保最终不会得到包含大量遗留文档的大段，这会消耗内存和磁盘上的宝贵资源并减慢查询速度。refresh 正在做一些不同的事情:正确的是，您要索引的文档首先在内存中处理，然后再写入磁盘。但是允许您实际查找文档(“段”)的数据结构不会立即为每个文档创建，因为这会非常低效。仅当内部缓冲区已满或发生 refresh 时才会创建段。通过触发刷新，您可以立即查找文档。该段最初仍然只存在于内存中，因为 - 再次 - 在每个段创建后立即将其同步到磁盘将是非常低效的。内存中的段会定期同步到磁盘。即使您在同步到磁盘之前拔掉插头，您也不会丢失任何信息，因为 Elasticsearch 维护了一个 translog，允许 Elasticsearch “重放”所有尚未进入磁盘段的索引请求。