elasticsearch ttl vs 每日丢弃表

Question

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

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

我本能地选择 2，因为:

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

但我的直觉告诉我，一次删除一个索引可能会减少很多计算密集度，尽管我不知道密集度降低了多少，也不知道 ttl 的成本有多少。

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

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

干杯!

Answer 1

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

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

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

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

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