干货 | Elasticsearch 索引生命周期管理 ILM 实战指南
1、什么是索引生命周期?
关于人生,有人这么说:“人,生来一个人,死去一个人,所以,人生就是一个人生老病死的简称。”
在基于日志、指标、实时时间序列的大型系统中,集群的索引也具备类似上图中相通的属性,一个索引自创建之后,不可能无限期的存在下去, 从索引产生到索引“消亡”,也会经历:“生、老、病、死”的阶段。
我们把索引的“生、老、病、死”的全过程类比称为索引的生命周期。
2、什么是索引生命周期管理?
由于自然规律,人会“不可逆转”的由小长到大,由大长到老,且理论上年龄一般不会超过 150 岁(吉尼斯世界纪录:122岁零164天)。
索引不是人,理论上:一旦创建了索引,它可以一直存活下去(假定硬件条件允许,寿命是无限的)。
索引创建后,它自身是相对静态的,没有“自然规律”牵引它变化,若放任其成长,它只会变成一个数据量极大的臃肿的“大胖子”。
这里可能就会引申出来问题:若是时序数据的索引,随着时间的推移,业务索引的数据量会越来越大。但,基于如下的因素:
集群的单个分片最大文档数上限:2 的 32 次幂减去 1(20亿左右)。
索引最佳实践官方建议:分片大小控制在30GB-50GB,若索引数据量无限增大,肯定会超过这个值。
索引大到一定程度,当索引出现健康问题,会导致真个集群核心业务不可用。
大索引恢复的时间要远比小索引恢复慢的多得多。
索引大之后,检索会很慢,写入和更新也会受到不同程度的影响。
某些业务场景,用户更关心最近3天、最近7天的业务数据,大索引会将全部历史数据汇集在一起,不利于这种场景的查询。
非常有必要对索引进行管理起来,不再放任其“野蛮长成体弱多病、潜在风险极大的大胖子”,而是限制其分阶段、有目标的、有规律的生长。
这种分阶段、有目标的操作和实现,我们称为索引生命周期管理。
3、索引生命周期管理的历史演变
索引生命周期管理 (ILM) 是在 Elasticsearch 6.6(公测版)首次引入,在 6.7 版本正式推出的一项功能。
ILM 是 Elasticsearch 的一部分,主要用来帮助用户管理索引。
没有 ILM 之前索引生命周期管理基于:rollover + curator 实现。
ILM 是早些年呼声非常高的功能之一,我印象中 2017 年南京的 meetup 中,就有公司说实现了类似的功能。
Kibana 7.12.0 索引生命周期管理配置界面如下图所示:
4、索引生命周期管理的前提
本文演示试用版本:Elasticesarch:7.12.0,Kibana:7.12.0。
集群规模:3节点,属性(node_roles)设置分别如下:
节点 node-022:主节点+数据节点+热节点(Hot)。
节点 node-023:主节点+数据节点+温节点(Warm)。
节点 node-024:主节点+数据节点+冷节点(Cold)。
4.1 冷热集群架构
冷热架构也叫热暖架构,是“Hot-Warm” Architecture的中文翻译。
冷热架构本质是给节点设置不同的属性,让每个节点具备了不同的属性。
为演示 ILM,需要首先配置冷热架构,三个节点在 elasticsearch.yml 分别设置的属性如下:
- node.attr.box_type: hot
- node.attr.box_type: warm
- node.attr.box_type: cold
拿舆情数据举例,通俗解读如下:
热节点(Hot):存放用户最关心的热数据。
比如:最近3天的数据——近期大火的“曹县牛皮666,我的宝贝”。
温节点(Warm):存放前一段时间沉淀的热数据,现在不再热了。
比如:3-7天的热点事件——“特斯拉车顶事件”。
冷节点(Cold):存放用户不太关心或者关心优先级低的冷数据,很久之前的热点事件。
比如:7天前或者很久前的热点事件——去年火热的“后浪视频“、”马老师不讲武德”等。
如果磁盘数量不足,冷数据是待删除优先级最高的。
如果硬件资源不足,热节点优先配置为 SSD 固态盘。
检索优先级最高的是热节点的数据,基于热节点检索数据自然比基于全量数据响应时间要快。
更多冷热架构推荐:干货 | Elasticsearch 冷热集群架构实战。
4.2 rollover 滚动索引
实际Elasticsearch 5.X 之后的版本已经推出:Rollover API。Rollover API解决的是以日期作为索引名称的索引大小不均衡的问题。
Rollover API对于日志类的数据非常有用,一般我们按天来对索引进行分割(数据量更大还能进一步拆分),没有Rollover之前,需要在程序里设置一个自动生成索引的模板。
推荐阅读:干货 | Elasticsearch索引生命周期管理探索
rollover 滚动索引实践一把:
# 1、创建基于日期的索引
PUT %3Cmy-index-%7Bnow%2Fd%7D-000001%3E
{"aliases": {"my-alias": {"is_write_index": true}}
}# 2、批量导入数据
PUT my-alias/_bulk
{"index":{"_id":1}}
{"title":"testing 01"}
{"index":{"_id":2}}
{"title":"testing 02"}
{"index":{"_id":3}}
{"title":"testing 03"}
{"index":{"_id":4}}
{"title":"testing 04"}
{"index":{"_id":5}}
{"title":"testing 05"}# 3、rollover 滚动索引
POST my-alias/_rollover
{"conditions": {"max_age": "7d","max_docs": 5,"max_primary_shard_size": "50gb"}
}GET my-alias/_count# 4、在满足滚动条件的前提下滚动索引
PUT my-alias/_bulk
{"index":{"_id":6}}
{"title":"testing 06"}# 5、检索数据,验证滚动是否生效
GET my-alias/_search
如上的验证结论是:
{"_index" : "my-index-2021.05.30-000001","_type" : "_doc","_id" : "5","_score" : 1.0,"_source" : {"title" : "testing 05"}},{"_index" : "my-index-2021.05.30-000002","_type" : "_doc","_id" : "6","_score" : 1.0,"_source" : {"title" : "testing 06"}}
_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,索引就会滚动。
注意,三个条件是或的关系,满足其中一个,索引就会滚动。
4.3 shrink 压缩索引
压缩索引的本质:在索引只读等三个条件的前提下,减少索引的主分片数。
# 设置待压缩的索引,分片设置为5个。
PUT kibana_sample_data_logs_ext
{"settings": {"number_of_shards":5}
}# 准备索引数据
POST _reindex
{"source":{"index":"kibana_sample_data_logs"},"dest":{"index":"kibana_sample_data_logs_ext"}
}# shrink 压缩之前的三个必要条件
PUT kibana_sample_data_logs_ext/_settings
{"settings": {"index.number_of_replicas": 0,"index.routing.allocation.require._name": "node-024", "index.blocks.write": true }
}# 实施压缩
POST kibana_sample_data_logs_ext/_shrink/kibana_sample_data_logs_shrink
{"settings": {"index.number_of_replicas": 0,"index.number_of_shards": 1, "index.codec": "best_compression" },"aliases": {"kibana_sample_data_logs_alias": {}}
}
有图有真相:
强调一下三个压缩前的条件,缺一不可:
"index.number_of_replicas": 0
副本设置为 0。
"index.routing.allocation.require._name": "node-024"
分片数据要求都集中到一个独立的节点。
"index.blocks.write": true
索引数据只读。
4.4 Frozen 冷冻索引
为高效检索,核心业务索引都会保持在内存中,意味着内存使用率会变得很高。
对于一些非业务必须、非密集访问的某些索引,可以考虑释放内存,仅磁盘存储,必要的时候再还原检索。
这时候,就会用到 Frozen 冷冻索引。除了在内存中维护其元数据,冻结索引在集群上几乎没有开销,并且冷冻索引是只读的。
具体使用如下:
# 冷冻索引
POST kibana_sample_data_logs_shrink/_freeze# 冷冻后,不能写入
POST kibana_sample_data_logs_shrink/_doc/1
{"test":"12111"
}# 冷冻后,能检索,但不返回具体数据,只返回0。
POST kibana_sample_data_logs_shrink/_search# 解除冷冻
POST kibana_sample_data_logs_shrink/_unfreeze# 解除冷冻后,可以检索和写入了
POST kibana_sample_data_logs_shrink/_search
综合上述拆解分析可知:
有了:冷热集群架构,集群的不同节点有了明确的角色之分,冷热数据得以物理隔离,SSD 固态盘使用效率会更高。
有了:rollover 滚动索引,索引可以基于文档个数、时间、占用磁盘容量滚动升级,实现了索引的动态变化。
有了:Shrink 压缩索引、Frozen 冷冻索引,索引可以物理层面压缩、冷冻,分别释放了磁盘空间和内存空间,提高了集群的可用性。
除此之外,还有:Force merge 段合并、Delete 索引数据删除等操作,索引的“生、老、病、死”的全生命周期的更迭,已然有了助推器。
如上指令单个操作,非常麻烦和繁琐,有没有更为快捷的方法呢?
有的!
第一:命令行可以 DSL 大综合实现。
第二:可以借助 Kibana 图形化界面实现。
下面两小节会结合实例解读。
5、Elasticsearch ILM 实战
5.1 核心概念:不同阶段(Phrase)的功能点(Acitons)
注意:仅在 Hot 阶段可以设置:Rollover 滚动。
5.2 各生命周期 Actions 设定
后两节演示要用。
5.2.1 Hot 阶段
基于: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 天的概念。
5.3 DSL 实战索引生命周期管理
# step1: 前提:演示刷新需要
PUT _cluster/settings
{"persistent": {"indices.lifecycle.poll_interval": "1s"}
}# step2:测试需要,值调的很小
PUT _ilm/policy/my_custom_policy_filter
{"policy": {"phases": {"hot": {"actions": {"rollover": {"max_age": "3d","max_docs": 5,"max_size": "50gb"},"set_priority": {"priority": 100}}},"warm": {"min_age": "15s","actions": {"forcemerge": {"max_num_segments": 1},"allocate": {"require": {"box_type": "warm"},"number_of_replicas": 0},"set_priority": {"priority": 50}}},"cold": {"min_age": "30s","actions": {"allocate": {"require": {"box_type": "cold"}},"freeze": {}}},"delete": {"min_age": "45s","actions": {"delete": {}}}}}
}# step3:创建模板,关联配置的ilm_policy
PUT _index_template/timeseries_template
{"index_patterns": ["timeseries-*"], "template": {"settings": {"number_of_shards": 1,"number_of_replicas": 0,"index.lifecycle.name": "my_custom_policy_filter", "index.lifecycle.rollover_alias": "timeseries","index.routing.allocation.require.box_type": "hot"}}
}# step4:创建起始索引(便于滚动)
PUT timeseries-000001
{"aliases": {"timeseries": {"is_write_index": true}}
}# step5:插入数据
PUT timeseries/_bulk
{"index":{"_id":1}}
{"title":"testing 01"}
{"index":{"_id":2}}
{"title":"testing 02"}
{"index":{"_id":3}}
{"title":"testing 03"}
{"index":{"_id":4}}
{"title":"testing 04"}# step6:临界值(会滚动)
PUT timeseries/_bulk
{"index":{"_id":5}}
{"title":"testing 05"}# 下一个索引数据写入
PUT timeseries/_bulk
{"index":{"_id":6}}
{"title":"testing 06"}
核心步骤总结如下:
第一步:创建生周期 policy。
第二步:创建索引模板,模板中关联 policy 和别名。
第三步:创建符合模板的起始索引,并插入数据。
第四步: 索引基于配置的 ilm 滚动。
实现效果如下GIF动画(请耐心看完)
5.4、Kibana 图形化界面实现索引生命周期管理
步骤 1:配置 policy。
步骤 2:关联模板。
前提条件:
模板要自己 DSL 创建,以便关联。
PUT _index_template/timebase_template { "index_patterns": ["time_base-*"] }
创建起始索引,指定别名和写入。
PUT time_base-000001 { "aliases": { "timebase_alias": { "is_write_index": true } } }
6、小结
索引生命周期管理需要加强对三个概念的认知:
横向——Phrase 阶段:Hot、Warm、Cold、Delete 等对应索引的生、老、病、死。
纵向——Actions 阶段:各个阶段的动作。
横向纵向整合的Policy:实际是阶段和动作的综合体。
配置完毕Policy,关联好模板 template,整个核心工作就完成了80%。
剩下就是各个阶段 Actions 的调整和优化了。
实战表明:用 DSL 实现ILM 比图形化界面更可控、更便于问题排查。
ILM 你实际生产环境使用了吗?效果如何?欢迎留言讨论。
参考
https://www.elastic.co/guide/en/elasticsearch/reference/current/example-using-index-lifecycle-policy.html
https://ptran32.github.io/2020-08-08-hot-warm-cold-elasticsearch/
https://www.elastic.co/cn/blog/implementing-hot-warm-cold-in-elasticsearch-with-index-lifecycle-management
魏彬老师ET开源课堂
推荐:
如何系统的学习 Elasticsearch ?
全网首发!《 Elasticsearch 最少必要知识教程 V1.0 》低调发布
从实战中来,到实战中去——Elasticsearch 技能更快提升方法论
重磅 | 死磕 Elasticsearch 方法论认知清单(2020年国庆更新版)
干货 | Elasticsearch索引生命周期管理探索
干货 | Elasticsearch 索引设计实战指南
干货 | Elasticsearch索引管理利器——Curator深入详解
中国最大的 Elastic 非官方公众号
更短时间更快习得更多干货
点击查看“阅读原文”,和全球近 1100 位+ Elastic 爱好者(中国 50%+ Elastic 认证工程师来自死磕Elasticsearch 知识星球)每日精进 ELK 技能!
干货 | Elasticsearch 索引生命周期管理 ILM 实战指南相关推荐
- Elasticsearch 快照生命周期管理 (SLM) 实战指南
1.Elasticsearch 保证高可用性的方式 Elasticsearch 保证集群高可用的方式包含但不限于如下三种: 方式一:副本分片.主分片失效后,副本分片会被提升为主分片. 方式二:跨集群复 ...
- ElasticSearch索引生命周期管理(ILM)
注: 部分概念介绍来源于网络 6.6 版本的发布,Index Lifecycle Management(索引生命周期管理,后文简称 ILM ): ILM 可以将索引生命周期分为四个阶段(Phase)( ...
- Elasticsearch索引生命周期管理方案
点击上方蓝色"方志朋",选择"设为星标" 回复"666"获取独家整理的学习资料! 一.前言 在 Elasticsearch 的日常中,有很多 ...
- ES索引生命周期管理ILM
前言 在使用ES的过程中,你是否遇到过这样的问题: 1.单个索引数据量持续增长,导致查询速度降低,运维困难 2.希望能根据时间周期自动生成新的索引,比如天.周.月自动生成新的索引 3.希望能定期自动删 ...
- Elasticsearch 索引生命周期管理方案
Elasticsearch索引生命周期管理方案 文章目录 Elasticsearch索引生命周期管理方案 1.生命周期 1.1 阶段介绍 2.模拟过程(基础) 2.1 创建索引生命周期策略 2.2 创 ...
- 索引生命周期管理ILM看完不懂你锤我
阅读完本文你可以学到什么是索引生命周期管理,各个阶段可以做的操作以及如何使用索引模版使用索引生命周期策略,下面就跟我一起来吧 基础理论篇 索引生命周期管理(ILM)是一种可以让我们随着时间推移自动化的 ...
- 【Elasticsearch】Elasticsearch 索引生命周期管理
文章目录 1.概述 1.1 为什么要对elasticsearch进行生命周期管理? 1.2 什么是索引周期管理 1.3 各个阶段允许的action 1.3 如何对elasticsearch进行生命周期 ...
- Elasticsearch ILM 索引生命周期管理常见坑及避坑指南
之前的博文和视频都讲过 ILM 索引生命周期管理.但从近期的反馈和我自己的实战经验看,依然会有很多坑. 现将我自己和大家遇到的常见坑汇集如下,希望能让后来小伙伴少走弯路. 少啰嗦,直接上干货. 坑1: ...
- 【Elasticsearch】使用索引生命周期管理实现热温冷架构
1.概述 [Elasticsearch]Elasticsearch 索引生命周期管理 转载:使用索引生命周期管理实现热温冷架构 索引生命周期管理 (ILM) 是在 Elasticsearch 6.6( ...
最新文章
- element 使用阿里图标变形了_web前端大厂面试题(阿里云笔试篇)
- java与与短路与_Java中短路运算符与逻辑运算符示例详解
- java 反射 注解 运用_Java注解与反射的使用
- 缓存穿透、缓存击穿、缓存雪崩及其解决方案
- 在Ubuntu 16.10 安装 git 并上传代码至 git.oschina.net
- 一次线上redis报障处理过程
- Linux .bin安装文件制作
- zabbix在configure时候遇到的问题(Ubuntu\debian)
- CTSCAPIO被教做人记
- 速读训练软件_记忆宫殿记忆力训练教程-第八天
- 实用网址(平时记下的)
- MySQL Workbench出现:Error Code: 2013. Lost connection to MySQL server during query的问题解决
- Asp.Net Mvc4分页,扩展HtmlHelper类
- Javascript:通过服务器相对路径下载文件到本地
- Spring Boot 2.0.3 使用外置 Tomcat 服务器
- 怎么设置浏览器默认搜索引擎,设置默认搜索引擎的方法步骤
- Apache服务器下载
- RDIFramework.NET 框架之组织机构权限设置
- 2022 QS世界大学榜:十年了,世界排名第一还是它...中国大陆大学取得历史最佳...
- 听完网易大佬描述 “ 软件测试工程师的一生 ”,我哭了!