elasticsearch elasticsearch ttl与每日投放表

我知道在elasticsearch中保持滚动数据窗口有两种主要模式：

按照logstash的建议创建每日索引，并在旧索引掉出窗口时删除它们，从而删除它们包含的所有记录

使用elasticsearch的TTL功能和单个索引，让elasticsearch在旧记录掉出窗口时自动逐个删除它们

出于本能，我选择2，如下所示：

• 我不必写cron作业
• 一个大索引更容易与我的同事沟通，也更容易让他们查询（我想是吧？）
• 任何导致旧日志事件出现的噩梦流动态都不会导致创建新索引，旧事件只会在elasticsearch用于进行ttl清理的60年代期间挂起

但我的直觉告诉我，一次删除一个索引的计算强度可能要小得多，尽管我不知道ttl的强度要小多少，也不知道ttl的成本有多高

在上下文中，我的入站流很少会达到每秒4K消息（mps）以上的峰值，并且更有可能挂起大约1-2K mps

有人有比较这两种方法的经验吗？正如你可能知道的，我对这个世界是新来的！如果您能提供任何帮助，包括帮助您思考此类问题的正确方法，我将不胜感激

---

干杯

简而言之，选择选项1，删除不再需要的索引

详细的回答是，这在某种程度上取决于添加到索引中的文档数量以及分片和复制设置。如果您的索引吞吐量相当低，TTL可以执行，但是当您开始向Elasticsearch写入更多文档时（或者如果您的复制系数很高），您将遇到两个问题

删除带有TTL的文档需要Elasticsearch在所有碎片和所有这些文档中运行一个定期服务（），该服务将过期。搜索一个大的索引可能是一个非常繁重的操作（特别是当你被严重切分时），但更糟糕的是删除

在Elasticsearch（Lucene，真的）中不会立即执行删除，而是将文档“标记为删除”。要删除已删除的文档并回收磁盘空间，需要进行段合并。如果索引中有大量的删除，则会给段合并操作带来更大的压力，严重影响其他线程池

我们最初采用TTL路线，有一个ES集群完全不可用，由于贪婪的合并线程，我们开始拒绝搜索和索引请求

---

您可以尝试“什么文档吞吐量太大？”但从您的用例来看，我建议您节省一些时间，只使用性能更高的索引删除路径。

我将使用选项1，即每天删除索引

日下降指数 优点：

• 这是删除数据最有效的方法
• 如果需要重新构造索引（例如，应用新映射、增加碎片数量），则可以轻松地将任何更改应用于新索引
• 通过使用对客户端隐藏当前索引（即名称）的详细信息
• 基于时间的搜索可以定向为仅搜索特定的小索引
• 简化创建每日索引的过程

有关这些好处的详细信息，请参见

缺点：

• 需要进行更多的设置工作（例如设置cron作业），但是有一个插件（）可以帮助您完成这项工作
• 如果对数据执行更新，则文档数据的所有版本都需要位于同一索引中，即多个索引对您不起作用

使用TTL或查询删除数据 优点：

• 易于理解且易于实现

缺点：

• 删除文档时，该文档仅标记为已删除。在包含它的段离开之前，它不会被物理删除。这是非常低效的，因为删除的数据将消耗磁盘空间、CPU和内存