索引的生命周期

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 删除