为什么 Elasticsearch 中的段合并需要停止写入索引
Why segment merge in Elasticsearch requires stopping the writes to index
我正在寻找 运行 优化（ES 1.X），它现在在 ES 最新版本中被称为 forcemerge API。在阅读了 this and 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)
但是我不明白
- 在 运行 强制合并或优化 API 之前将索引置于只读模式的原因 API。
- 正如上面 ES 文档中所解释的，它可能会导致非常大的段，但据我所知，情况并非如此，新的更新首先写入内存，刷新时写入段，所以为什么在 forcemerge 期间写入可以产生非常大的段？
如果我们不想将索引置于只读模式并且仍然运行强制合并以删除删除，还有什么解决方法。
如果我需要提供任何其他信息，请告诉我。
forcemerge 可以显着提高查询的性能，因为它允许您将现有数量的段合并为数量更少的段，这样查询效率更高，因为段是按顺序搜索的。合并时，还会清除所有标记为删除的文档。
作为 Elasticsearch 基于合并策略的内部管理的一部分，合并会在后台定期自动发生。
棘手的事情：合并策略只考虑最大 5 GB 的段。将 forcemerge API 与允许您指定结果段数的参数一起使用，您冒着结果段大于 5GB 的风险，这意味着它们将不再被未来的合并请求考虑。只要您不删除或更新文档，就没有错。但是，如果您不断删除或更新文档，Lucene 会将现有段中的旧版本文档标记为已删除，并将新版本的文档写入新段。如果您删除的文档位于大于 5GB 的段中，则不会对其进行更多的整理，即标记为删除的文档将永远不会被清理。
通过在执行强制合并之前将索引设置为只读，您可以确保不会以包含大量遗留文档的巨大段结束，这会消耗宝贵的内存和磁盘资源并降低速度你的问题。
A refresh 正在做一些不同的事情：你想要索引的文档首先在内存中处理，然后再写入磁盘，这是正确的。但是允许您实际查找文档（“段”）的数据结构不会立即为每个文档创建，因为这会非常低效。仅当内部缓冲区已满或出现 refresh 时才会创建段。通过触发刷新，您可以使文档立即可供查找。该段最初仍然只存在于内存中，因为 - 再一次 - 在创建每个段后立即将其同步到磁盘将是非常低效的。内存中的段会定期同步到磁盘。即使您在同步到磁盘之前拔下插头，您也不会丢失任何信息，因为 Elasticsearch 维护一个 translog，它允许 Elasticsearch “重放”所有尚未进入磁盘段的索引请求。
我正在寻找 运行 优化（ES 1.X），它现在在 ES 最新版本中被称为 forcemerge API。在阅读了 this and 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)
但是我不明白
- 在 运行 强制合并或优化 API 之前将索引置于只读模式的原因 API。
- 正如上面 ES 文档中所解释的，它可能会导致非常大的段，但据我所知，情况并非如此，新的更新首先写入内存，刷新时写入段，所以为什么在 forcemerge 期间写入可以产生非常大的段？
如果我们不想将索引置于只读模式并且仍然运行强制合并以删除删除，还有什么解决方法。
如果我需要提供任何其他信息，请告诉我。
forcemerge 可以显着提高查询的性能，因为它允许您将现有数量的段合并为数量更少的段，这样查询效率更高，因为段是按顺序搜索的。合并时，还会清除所有标记为删除的文档。
作为 Elasticsearch 基于合并策略的内部管理的一部分，合并会在后台定期自动发生。
棘手的事情：合并策略只考虑最大 5 GB 的段。将 forcemerge API 与允许您指定结果段数的参数一起使用，您冒着结果段大于 5GB 的风险，这意味着它们将不再被未来的合并请求考虑。只要您不删除或更新文档，就没有错。但是，如果您不断删除或更新文档，Lucene 会将现有段中的旧版本文档标记为已删除，并将新版本的文档写入新段。如果您删除的文档位于大于 5GB 的段中，则不会对其进行更多的整理，即标记为删除的文档将永远不会被清理。
通过在执行强制合并之前将索引设置为只读，您可以确保不会以包含大量遗留文档的巨大段结束，这会消耗宝贵的内存和磁盘资源并降低速度你的问题。
A refresh 正在做一些不同的事情：你想要索引的文档首先在内存中处理，然后再写入磁盘，这是正确的。但是允许您实际查找文档（“段”）的数据结构不会立即为每个文档创建，因为这会非常低效。仅当内部缓冲区已满或出现 refresh 时才会创建段。通过触发刷新，您可以使文档立即可供查找。该段最初仍然只存在于内存中，因为 - 再一次 - 在创建每个段后立即将其同步到磁盘将是非常低效的。内存中的段会定期同步到磁盘。即使您在同步到磁盘之前拔下插头，您也不会丢失任何信息，因为 Elasticsearch 维护一个 translog，它允许 Elasticsearch “重放”所有尚未进入磁盘段的索引请求。