elasticsearch ttl 与每日丢弃表

Question

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

1. 按照 logstash 的建议创建每日索引，并在旧索引掉出窗口时删除它们包含的所有记录
2. 使用 elasticsearch 的 TTL 功能和单一索引，当旧记录掉出窗口时，elasticsearch 会自动单独删除旧记录

本能地我选择2，如：

• 我不必编写 cron 作业
• 单个大索引更容易与我的同事交流并让他们查询（我认为？）
• 任何会导致旧日志事件出现的噩梦流动态都不会导致新索引的创建，并且旧事件只会在 elasticsearch 用来进行 ttl 清理的 60 年代期间存在。

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

就上下文而言，我的入站流很少会达到每秒 4K 消息 (mps) 以上的峰值，并且更有可能保持在 1-2K mps 左右。

有没有人比较这两种方法的经验？你可能会说我是这个世界的新手！将不胜感激任何帮助，甚至包括关于思考这类事情的正确方法的帮助。

干杯！

Answer 1

简短的回答是，使用选项 1 并简单地删除不再需要的索引。

长答案是它在某种程度上取决于您添加到索引中的文档量以及您的分片和复制设置。如果您的索引吞吐量相当低，TTLs 可以是高性能的，但是当您开始向 Elasticsearch 写入更多文档时（或者如果您的复制因子很高），您会遇到两个问题。

1. 删除带有 TTL 的文档需要 Elasticsearch 运行定期服务 (IndicesTTLService) 到 find documents，这些服务在所有分片和 issue deletes 的所有这些文档中都已过期。搜索大型索引可能是一项相当繁重的操作（尤其是在您进行大量分片的情况下），但更糟糕的是删除。
2. 在 Elasticsearch（实际上是 Lucene）中不会立即执行删除，而是将文档“标记为删除”。需要进行段合并以清除已删除的文档并回收磁盘空间。如果您在索引中有大量删除，它将给您的段合并操作带来更多更多压力，以至于严重影响其他线程池。

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

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

Answer 2

我会选择选项 1 - 即每日删除指数。

每日下降指数

优点：

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

Time-Based Data Guide 中也详细介绍了这些好处，另请参阅Retiring Data

缺点：

• 需要更多的工作来设置（例如设置 cron 作业），但是有一个插件 (curator) 可以帮助解决这个问题。
• 如果您对数据执行更新，则文档数据的所有版本都需要位于同一个索引中，即多个索引不适合您。

使用 TTL 或查询删除数据

优点：

• 简单易懂且易于实施

缺点：

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