> For the complete documentation index, see [llms.txt](https://book.gxd88.cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.gxd88.cn/kubernetesri-zhi-xi-tong-pian/64-elasticsearchan-zhuang-bu-shu/641-esgui-hua/suo-yin-de-sheng-ming-zhou-qi.md).

# 索引的生命周期

## Index Lifecycle 索引生命周期

在这些众多功能中，Index Lifecycle Management(索引生命周期管理，后文简称 ILM) 是最受社区欢迎的。今天我们从以下几方面来快速了解下该功能：

1. 为什么索引会有生命？什么是索引生命周期？
2. ILM 是如何划分索引生命周期的？
3. ILM 是如何管理索引生命周期的？
4. 实战

## Index Lifecycle 索引生命周期

先来看第一个问题：

> 为什么索引有生命？

索引(Index)是 Elasticsearch 中数据组织的一个逻辑概念，是具有相同或相似字段的文档组合。它由众多分片(Shard)组成，比如 `book`、`people`都可以用作索引名称，可以简单类比为关系型数据库的表(table)。

所谓生命，即生与死；索引的`生`与`死`便是`创建`与`删除`了。

在我们日常使用 Elasticsearch 的时候，索引的创建与删除似乎是很简单的事情，用的时候便创建，不用了删除即可，有什么好管理的呢？

这就要从 Elasticsearch 的应用场景来看了。

在`业务搜索`场景，用户会将业务数据存储在 Elasticsearch 中，比如商品数据、订单数据、用户数据等，实现快速的全文检索功能。像这类数据基本都是累加的，不会删除。一般删除的话，要么是业务升级，要么是业务歇菜了。此种场景下，基本只有生，没有死，也就不存在管理一说。

而在`日志业务`场景中，用户会将各种日志，如系统、防火墙、中间件、数据库、web 服务器、应用日志等全部实时地存入 Elasticsearch 中，进行即席日志查询与分析。这种类型的数据都会有时间维度，也就是时序性的数据。由于日志的数据量过大，用户一般不会存储全量的数据，一般会在 Elasticsearch 中存储热数据，比如最近7天、30天的数据等，而在7天或者30天之前的数据都会被`删除`。为了便于操作，用户一般会按照日期来建立索引，比如 nginx 的日志索引名可能为 `nginx_log-2018.11.12`、`nginx_log-2018.11.13`等，当要查询或删除某一天的日志时，只需要针对对应日期的索引做操作就可以了。那么在该场景下，每天都会上演大量索引的生与死。

一个索引由生到死的过程，即为一个生命周期。举例如下：

* 生：在 `2019年2月5日` 创建 `nginx_log-2019.02.05`的索引，开始处理日志数据的读写请求
* 生：在 `2019年2月6日` `nginx_log-2019.02.05` 索引便不再处理写请求，只处理读请求
* 死：在 `2019年3月5日` 删除 `nginx_log-2018.02.05`的索引

其他的索引，如 `nginx_log-2019.02.06` 等也会经过相同的一个生命周期。

## 2. ILM 是如何划分索引生命周期的？

我们现在已经了解何为生命周期了，而最简单的生命周期只需要`生`与`死`两个阶段即可。但在实际使用中生命周期是有多个阶段的，我们来看下 ILM 是如何划分生命周期的。

ILM 一共将索引生命周期分为四个阶段(Phase)：

1. Hot 阶段
2. Warm 阶段
3. Cold 阶段
4. Delete 阶段

### Hot 阶段

Hot 阶段可类比为人类`婴儿到青年`的阶段，在这个阶段，它会不断地进行知识的输入与输出(数据读写)，不断地长高长大(数据量增加)成有用的青年。

由于该阶段需要进行大量的数据读写，因此需要高配置的节点，一般建议将节点`内存与磁盘比`控制在 32 左右，比如 64GB 内存搭配 2TB 的 `SSD` 硬盘。

### Warm 阶段

Warm 阶段可类比为人类`青年到中年`的阶段，在这个阶段，它基本不会再进行知识的输入(数据写入)，主要进行知识输出(数据读取)，为社会贡献价值。

由于该阶段主要负责数据的读取，中等配置的节点即可满足需求，可以将节点`内存与磁盘比`提高到 64\~96 之间，比如 64GB 内存搭配 4\~6TB 的 `HDD` 磁盘。

### Cold 阶段

Cold 阶段可类别比为人类`中年到老年`的阶段，在这个阶段，它退休了，在社会有需要的时候才出来输出下知识(数据读取)，大部分情况都是静静地待着。

由于该阶段只负责少量的数据读取工作，低等配置的节点即可满足要求，可以将节点`内存与磁盘比`进一步提高到 96 以上，比如128，即 64GB 内存搭配 8 TB 的 `HDD` 磁盘。

### Delete 阶段

Delete 阶段可类比为人类`寿终正寝`的阶段，在发光发热之后，静静地逝去，Rest in Peace\~

ILM 对于索引的生命周期进行了非常详细的划分，但它并不强制要求必须有这个4个阶段，用户可以根据自己的需求组合成自己的生命周期。

## 3. ILM 是如何管理索引生命周期的？

所谓生命周期的管理就是控制 4 个生命阶段转换，何时由 Hot 转为 Warm，何时由 Warm 转为 Cold，何时 Delete 等。

阶段的转换必然是需要时机的，而对于时序数据来说，时间必然是最好的维度，而 ILM 也是以时间为转换的衡量单位。比如下面这张转换的示意图，即默认是 Hot 阶段，在**索引创建** 3 天后转为 Warm 阶段，7 天后转为 Cold 阶段，30 天后删除。这个设置的相关字段为 `min_age`，后文会详细讲解。

ILM 将不同的生命周期管理策略称为 `Policy`，而所谓的 `Policy` 是由不同阶段(`Phase`)的不同动作(`Action`)组成的。

`Action`是一系列操作索引的动作，比如 Rollover、Shrink、Force Merge等，不同阶段可用的 `Action` 不同，详情如下：

* Hot Phase
  * Rollover 滚动索引操作，可用在索引大小或者文档数达到某设定值时，创建新的索引用于数据读写，从而控制单个索引的大小。这里要注意的一点是，如果启用了 Rollover，那么所有阶段的时间不再以索引创建时间为准，而是以该索引 Rollover 的时间为准。
* Warm Phase
  * Allocate 设定副本数、修改分片分配规则(如将分片迁移到中等配置的节点上)等
  * Read-Onlly 设定当前索引为只读状态
  * Force Merge 合并 segment 操作
  * Shrink 缩小 shard 分片数
* Cold Phase
  * Allocate 同上
* Delete Phase
  * Delete 删除