elasticsearch ttl vs每日下降表

Question

据我所知，在elasticsearch中保留数据滚动窗口有两种主导模式：

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

本能地，我选择2，as：

• 我不必写cron工作
• 一个大的索引更容易与同事沟通并让他们查询（我认为？）
• 任何导致旧日志事件出现的噩梦流动态，都不会导致新索引的创建，旧事件只会在弹性搜索用于清理的60年代期间出现。

但我的直觉告诉我，一次丢弃一个索引的计算密集程度可能要低得多，尽管我不知道ttl的密集程度和成本是多少。

对于上下文，我的入站流很少会高于每秒4K消息（mps），并且更有可能挂在1-2K mps附近。

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

干杯！

Answer 1

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

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

1. 使用TTL删除文档要求Elasticsearch运行定期服务（IndicesTTLService）到find documents的所有分片已过期，issue deletes为所有这些文档过期。{{3}}。搜索一个大型索引可能是一项非常繁重的操作（特别是如果你进行了大量分片），但更糟糕的是删除。
2. 删除不会立即在Elasticsearch（Lucene，真的）中执行，而是“标记为删除”文档。需要段合并来清除已删除的文档并回收磁盘空间。如果索引中有大量删除操作，则会对您的段合并操作施加更多更多压力，从而严重影响其他线程池。

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

您可以尝试“文档吞吐量过多吗？”但从你的用例来看，我建议节省一些时间，然后选择更符合索引的索引删除路由。

Answer 2

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

每日掉落指数

的优点：

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

Time-Based Data Guide中还详细介绍了这些优势，另请参阅Retiring Data

缺点：

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

使用TTL或查询删除数据

专业人士：

• 易于理解且易于实施

缺点：

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