对Elasticsearch生命周期的思考

什么是es索引的生命周期？有啥用？能够怎么用？用了有什么好处呢？

在现实的生产环境中有没有以为本身刚开始设计的索引的分片数刚恰好，可是随着时间的增加，数据量增大，增加速度增大的状况下，你的es索引的设计是否还合理呢？

在现实的生产存储中，有没有一些数据时间长了就没价值了，不必浪费存储了，就能够删除了，有些数据变得再也不重要了，能够存放在低性能的磁盘上，节约公司的机器硬件成本呢？

es生产环境，有没有经历过经过人工去管理索引的中部分数据的删除呢，知道es删除数据原理的都知道，这样对性能有很大的影响，刚开始并无真正的删除数据。

这篇文章纯属于我的经过别人的博客和官网的学习，结合本身公司业务场景的一个思考，有些是没有实际验证的。本篇也是基于elasticsearch7.8.1的一个版本的知识点。

1、引起思考的背景

一、首先业务场景，es的业务场景是真的普遍，目前咱们只是用来作搜索查询，虽然如今在研究elk，对日志的进行索引，可是肯能还只是用到es的一点点的功能

二、在es安装的时候，如何设计节点，如何根据现有的机器作es的集群，配置好集群后，怎么设计索引，通常都会有一个时间的字段，根据数据量的大小和增加速度能够根据天，月，年等时间间隔切分索引，使用别名管理，那么多索引，可是又如何去管理这些索引呢，还要根据本身公司的业务场景，而不是纯粹的设计理论，我觉的符合公司状况，符合业务场景的设计才是最好的设计吧，可是不是一味的强耦合的只考虑单个业务，应该考虑多个，可以作到模板化，这样就能很好的作扩展了，以及要考虑对将来的规划和数据增加的容忍度吧

三、固然咱们目前没有巨量的数据，可是不少事情也必须考虑进去，根据公司业务，好比数据只有一年的常用，后面的数据基本不用，三年前的数据能够删除，机器设备性能，有些机器磁盘性能好ssd，有些通常吧机械硬盘，还有cpu，内存的因素都要考虑。

四、公司管理人员少，怎么去管理这些呢，也没这个精力去开发索引的管理界面，不少因素都要考虑进去

2、冷热架构

冷热架构就是有冷的有热的（这是玩笑话），就是常常须要使用（热）和不常用的数据（冷），有了这样的却别，存储方面确定也要区别对待吧，把热数据存放在性能好的机器上，把冷的数据存放在性能较差的机器上，这个就是所谓的合理利用资源，节约公司硬件成本，也就是在硬件成本必定的条件下，提高集群的性能。可是描述是这么描述了，怎么实现热数据就存在好的机器上，冷数据就存在差点的机器上呢，能够映射呀，打标签呀，方法不少嘛，es就是打标签。----如上描述都是我的理解（这里只说我的的）

好，接下来就给每一个es集群的节点打标签咯，说A集群性能好，用来存热数据，说B机器性能差一些，用来存冷数据，在他们每一个机器上挂个牌牌，方便数据根据本身的冷热程度对号入座。es是这么打标签的：

在elasticsearch.yml文件中增长

node.attr.{attribute}: {value}

好比能够给机器配置冷热的标签：

node.attr.temperature: hot //热节点
node.attr.temperature: warm //冷节点

如今是机器的标签打好了，那索引数据怎么打标签，而且一一对应呢？就是对索引有以下的设置（_settings）就能够对应好啦：

index.routing.allocation.include.{attribute} 　　//表示索引能够分配在包含多个值中其中一个的节点上。
index.routing.allocation.require.{attribute}　　 //表示索引要分配在包含索引指定值的节点上（一般通常设置一个值）。
index.routing.allocation.exclude.{attribute}　　 //表示索引只能分配在不包含全部指定值的节点上。

详细的部署这里不说了，大概只聊聊思想，部署能够参考下其余博主的博客：

https://www.elastic.co/guide/en/elasticsearch/reference/7.8/shard-allocation-filtering.html  

https://zhuanlan.zhihu.com/p/97098781

http://www.javashuo.com/article/p-bkjvpufa-hx.html

3、生命周期

聊了背景，说了冷热架构，那咱们怎么怎么自动的管理呢？这样生命周期就派上用处了，好比一个索引的数据通过10天就从热数据转为了冷数据，这样能够经过一系列的action和设置进行操做，自动根据时间把冷数据转移到性能较差的机器上。这样岂不是很方便，接下来咱们就了解下索引的生命周期，以及怎么使用。

二话不说，上官网：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/index-lifecycle-management.html

能够配置索引生命周期管理(ILM)策略，以根据您的性能、弹性和保留需求自动管理索引。好比当索引达到必定大小或文档数量时，旋转新索引，天天、每周或每个月建立一个新索引，并归档之前的索引，删除过期的索引以执行数据保留标准。能够经过API配置和kibana配置进行生命周期的管理。

ES索引生命周期管理分为4个阶段：hot、warm、cold、delete，其中hot主要负责对索引进行rollover操做，warm、cold、delete分别对rollover后的数据进一步处理（前提是配置了hot）

阶段	描述
hot	主要处理时序数据的实时写入
warm	索引再也不被更新，但仍在被查询
cold	索引再也不被更新，而且不多被查询。这些信息仍然须要可搜索
delete	索引再也不须要，能够安全地删除

那这些索引是根据什么条件去从一个阶段转到另外一个阶段的呢？好比能够根据时间呀，文档数据呀，索引大小呀做为判断条件转到下一个阶段。

一、当索引达到50GB时，将鼠标移至新索引。
二、将旧索引移至热阶段，将其标记为只读，而后将其缩小为单个碎片。
三、7天后，将索引移至冷阶段，而后将其移至较便宜的硬件上。
四、达到所需的30天保留期后，删除索引

那咱们在索引的每个阶段能够作什么样的操做呢，好比增长索引的设置，修改副本数量等。

阶段	操做（action）
Hot	Set Priority，Unfollow，Rollover
Warm	Set Priority，Unfollow，Read-Only，Allocate，Shrink，Force Merge
Cold	Set Priority，Unfollow，Allocate，Freeze
Delete	Wait For Snapshot，Delete

具体如上的每个动做（action）是什么，你们参考官网https://www.elastic.co/guide/en/elasticsearch/reference/7.8/ilm-actions.html

咱们知道索引生命的周期的阶段，也知道根据什么条件从一个周期跳转到另外一个阶段，也知道在每个阶段能够作什么操做了，那么就成了呀，更具本身的业务场景设计索引的生命周期吧！！！接下来就看看什么实用呢？

来，官网：https://www.elastic.co/guide/en/elasticsearch/reference/7.8/set-up-lifecycle-policy.html

https://www.elastic.co/guide/en/elasticsearch/reference/7.8/getting-started-index-lifecycle-management.html

经过索引生命周期策略管理索引的基本步骤以下：
1. 建立定义适当阶段和操做的生命周期策略
2. 建立索引模板，将策略应用于每一个新索引
3. 引导一个索引做为初始写索引
4. 验证索引按预期在生命周期阶段中移动

如上四个步骤根据官网来一步一步操做很简单，若是要结合冷热架构的话，能够在某一个阶段根据本身的需求经过索引的设置（_settings）指定打好标签机器的标签就行了

固然索引的生命周期还能够经过kibana进行配置：

 

 根据图一步一步的操做很简单的！

生命周期管理策略真的是一个很好管理索引的技术，很灵活，可以减小人工的介入。均可以根据公司的业务场景好好使用，本文的冷热架构这里没有实践过，可是索引的生命周期仍是实践过，挺好用的，特别是一些日志数据，保留7天或者一个月就够了，能够经过生命周期策略配置自动删除知足条件的数据，这样集群的数据也不会无限的增加，也不须要人工管理。

愿每个努力的人都积极思考，而不是知识的搬运工