干货 | Elasticsearch 索引生命周期管理 ILM 实战指南

在基于日志、指标、实时时间序列的大型系统中，集群的索引也具备类似上图中相通的属性，一个索引自创建之后，不可能无限期的存在下去， 从索引产生到索引“消亡”，也会经历：“生、老、病、死”的阶段。

我们把索引的“生、老、病、死”的全过程类比称为索引的生命周期。

 

由于自然规律，人会“不可逆转”的由小长到大，由大长到老，且理论上年龄一般不会超过 150 岁（吉尼斯世界纪录：122岁零164天）。

 

索引不是人，理论上：一旦创建了索引，它可以一直存活下去（假定硬件条件允许，寿命是无限的）。

 

索引创建后，它自身是相对静态的，没有“自然规律”牵引它变化，若放任其成长，它只会变成一个数据量极大的臃肿的“大胖子”。

 

这里可能就会引申出来问题：若是时序数据的索引，随着时间的推移，业务索引的数据量会越来越大。但，基于如下的因素：

非常有必要对索引进行管理起来，不再放任其“野蛮长成体弱多病、潜在风险极大的大胖子”，而是限制其分阶段、有目标的、有规律的生长。

 

这种分阶段、有目标的操作和实现，我们称为索引生命周期管理。

 

索引生命周期管理 (ILM) 是在 Elasticsearch 6.6（公测版）首次引入，在 6.7 版本正式推出的一项功能。

 

ILM 是 Elasticsearch 的一部分，主要用来帮助用户管理索引。

 

没有 ILM 之前索引生命周期管理基于：rollover + curator 实现。

 

ILM 是早些年呼声非常高的功能之一，我印象中 2017 年南京的 meetup 中，就有公司说实现了类似的功能。

 

Kibana 7.12.0 索引生命周期管理配置界面如下图所示：

冷热架构也叫热暖架构，是“Hot-Warm” Architecture的中文翻译。

 

冷热架构本质是给节点设置不同的属性，让每个节点具备了不同的属性。

 

为演示 ILM，需要首先配置冷热架构，三个节点在 elasticsearch.yml 分别设置的属性如下：

拿舆情数据举例，通俗解读如下：

 

 • 热节点（Hot）：存放用户最关心的热数据。

比如：最近3天的数据——近期大火的“曹县牛皮666，我的宝贝”。

 

 • 温节点（Warm）：存放前一段时间沉淀的热数据，现在不再热了。

比如：3-7天的热点事件——“特斯拉车顶事件”。

 

 • 冷节点（Cold）：存放用户不太关心或者关心优先级低的冷数据，很久之前的热点事件。

比如：7天前或者很久前的热点事件——去年火热的“后浪视频“、”马老师不讲武德”等。

 

如果磁盘数量不足，冷数据是待删除优先级最高的。

 

如果硬件资源不足，热节点优先配置为 SSD 固态盘。

 

检索优先级最高的是热节点的数据，基于热节点检索数据自然比基于全量数据响应时间要快。

 

更多冷热架构推荐：干货 | Elasticsearch 冷热集群架构实战。

 

实际Elasticsearch 5.X 之后的版本已经推出：Rollover API。Rollover API解决的是以日期作为索引名称的索引大小不均衡的问题。

 

Rollover API对于日志类的数据非常有用，一般我们按天来对索引进行分割（数据量更大还能进一步拆分），没有Rollover之前，需要在程序里设置一个自动生成索引的模板。

 

推荐阅读：干货 | Elasticsearch索引生命周期管理探索

 

rollover 滚动索引实践一把：

如上的验证结论是：

_id 为 6 的数据索引名称变成了：my-index-2021.05.30-000002，实现了 后缀 id 自增。

这里要强调下，索引滚动变化的三个核心条件：

 

 • "max_age": "7d", 最长期限 7d，超过7天，索引会实现滚动。

 • "max_docs": 5, 最大文档数 5，超过 5个文档，索引会实现滚动（测试需要，设置的很小）。

 • "max_primary_shard_size": "50gb"，主分片最大存储容量 50GB，超过50GB，索引就会滚动。

注意，三个条件是或的关系，满足其中一个，索引就会滚动。

 

压缩索引的本质：在索引只读等三个条件的前提下，减少索引的主分片数。

有图有真相：

为高效检索，核心业务索引都会保持在内存中，意味着内存使用率会变得很高。

 

对于一些非业务必须、非密集访问的某些索引，可以考虑释放内存，仅磁盘存储，必要的时候再还原检索。

 

这时候，就会用到 Frozen 冷冻索引。除了在内存中维护其元数据，冻结索引在集群上几乎没有开销，并且冷冻索引是只读的。

 

具体使用如下：

 

综合上述拆解分析可知：

 

有了：冷热集群架构，集群的不同节点有了明确的角色之分，冷热数据得以物理隔离，SSD 固态盘使用效率会更高。

 

有了：rollover 滚动索引，索引可以基于文档个数、时间、占用磁盘容量滚动升级，实现了索引的动态变化。

 

有了：Shrink 压缩索引、Frozen 冷冻索引，索引可以物理层面压缩、冷冻，分别释放了磁盘空间和内存空间，提高了集群的可用性。

 

除此之外，还有：Force merge 段合并、Delete 索引数据删除等操作，索引的“生、老、病、死”的全生命周期的更迭，已然有了助推器。

 

如上指令单个操作，非常麻烦和繁琐，有没有更为快捷的方法呢？

 

有的！

 

第一：命令行可以 DSL 大综合实现。

 

第二：可以借助 Kibana 图形化界面实现。

 

下面两小节会结合实例解读。

 

5、Elasticsearch ILM 实战
5.1 核心概念：不同阶段（Phrase）的功能点（Acitons）
 

注意：仅在 Hot 阶段可以设置：Rollover 滚动。

 • 基于：max_age=3天、最大文档数为5、最大size为：50gb rollover 滚动索引。

 • 设置优先级为：100（值越大，优先级越高）。

5.2.2 Warm 阶段

 • 实现段合并，max_num_segments 设置为1.

 • 副本设置为 0。

 • 数据迁移到：warm 节点。

 • 优先级设置为：50。

5.2.3 Cold 阶段

 • 冷冻索引

 • 数据迁移到冷节点

5.2.4 Delete 阶段

 • 删除索引

关于触发滚动的条件：

 

 • Hot 阶段的触发条件：手动创建第一个满足模板要求的索引。

 • 其余阶段触发条件：min_age，索引自创建后的时间。

时间类似：业务里面的 热节点保留 3 天，温节点保留 7 天，冷节点保留 30 天的概念。

 

核心步骤总结如下：

 

 • 第一步：创建生周期 policy。
 • 第二步：创建索引模板，模板中关联 policy 和别名。
 • 第三步：创建符合模板的起始索引，并插入数据。
 • 第四步: 索引基于配置的 ilm 滚动。

实现效果如下GIF动画（请耐心看完）