ES时序数据过期处理 elasticsearch

前言随着时间推移，基于时间数据的相关度逐渐降低。有可能我们会想要查看上周、上个月甚至上一年度发生了什么，但是大多数情况，我们只关心当前发生的。历史旧数据的访问热度变的很低，甚至已经没有了搜索的需求，但依然占用存储空间，占用系统资源。针对这些数据，有必要进行资源的释放。
删除旧索引基于时序的数据一般是按照时间范围来创建索引的，按时间范围索引带来的好处是可以方便地删除旧数据。删除整个索引比删除单个文档要更加高效：Elasticsearch 只需要删除整个文件夹。删除索引是终极手段。
迁移旧索引随着数据被记录，很有可能存在一个热点索引——今日的索引。所有新文档都会写入这个索引，几乎所有查询也都以它为目标。这个索引对 IO 和 CPU 就有比较高的要求，应当使用最好的硬件，建议使用 SSD。历史的旧的数据几乎是只读，不会写入，并且搜索的频率也比较小，应当使用相对较差的硬件，建议比较大的硬盘
Elasticsearch 是如何得知哪台是最好的服务器呢？通过给每台服务器指定任意的标签来告诉它。
在 Elasticsearch 的 yml 文件中配置 node.attr 属性，标记当前节点是一个热节点：

node.attr.my_node_type=hot

其中 my_node_type 是一个任意的标签名称。同理，标记一个冷节点：

node.attr.my_node_type=warm

通过给节点打标签，Elasticsearch 就知道了哪些节点是热（Hot）节点，哪些是冷（Warm）节点，接下来通过对索引进行设置，Elasticsearch 就会自动的按照对应关系，把索引分配到对应的节点上。
创建索引时，指定索引创建在 Hot 节点上：

PUT logs-2022-06-27 { "settings":{ "number_of_shards":2, "number_of_replicas":0, "index.routing.allocation.require.my_node_type":"hot" } }

随着时间推移，索引可能变得不再热门，将其分配到 Warm 节点上：

PUT logs-2022-06-27/_settings { "index.routing.allocation.require.my_node_type":"warm" }

段文件合并优化历史的索引不大可能会改变，比如日志事件是静态的。将每个分片中的小段合并至一个大段，会占用更少的资源更快地响应查询。合并通过 optimize API 来做到。
历史的索引有可能拥有副本分片。如果下发一个优化（Optimize）请求，它会优化主分片和副本分片，这有些浪费。可以临时移除副本分片，进行优化，然后再恢复副本分片：

POST /logs-2022-06-27/_settings { "number_of_replicas": 0 }POST /logs-2022-06-27/_optimize?max_num_segments=1POST /logs-2022-06-27/_settings { "number_of_replicas": 1 }

关闭旧索引当索引变得更“老”，到了几乎不会再被访问的时间点。可以在这个阶段删除它们，也可以选择关闭。被关闭的索引，还会存在于集群中，但它们不会消耗磁盘空间以外的资源（比如：内存）。另外，重新打开一个索引要比从备份中恢复快得多。
在关闭之前，需要刷新索引来确保没有事务残留在事务日志中。一个空白的事务日志会使得索引在重新打开时恢复得更快：