共计 1594 个字符，预计需要花费 4 分钟才能阅读完成。
前言
随着时间推移，基于工夫数据的相关度逐步升高。有可能咱们会想要查看上周、上个月甚至上一年度产生了什么，然而大多数状况，咱们只关怀以后产生的。历史旧数据的拜访热度变的很低，甚至曾经没有了搜寻的需要，但仍然占用存储空间，占用系统资源。针对这些数据，有必要进行资源的开释。
删除旧索引
基于时序的数据个别是依照工夫范畴来创立索引的，按工夫范畴索引带来的益处是能够不便地删除旧数据。删除整个索引比删除单个文档要更加高效：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=1
POST /logs-2022-06-27/_settings
{"number_of_replicas": 1}敞开旧索引
当索引变得更“老”，到了简直不会再被拜访的工夫点。能够在这个阶段删除它们，也能够抉择敞开。被敞开的索引，还会存在于集群中，但它们不会耗费磁盘空间以外的资源（比方：内存）。另外，从新关上一个索引要比从备份中复原快得多。
在敞开之前，须要刷新索引来确保没有事务残留在事务日志中。一个空白的事务日志会使得索引在从新关上时复原得更快：
POST /logs-2022-01-*/_flush
POST /logs-2022-01-*/_close
POST /logs-2022-01-*/_open 归档旧索引
历史十分旧的索引，能够通过归档至硬盘封存。归档后就能够将索引从集群中删除，开释集群空间资源了。
参考
https://www.elastic.co/guide/…
