什么是es索引的生命周期？有啥用？可以怎么用？用了有什么好处呢？
在现实的生产环境中有没有觉得自己刚开始设计的索引的分片数刚刚好，但是随着时间的增长，数据量增大，增长速度增大的情况下，你的es索引的设计是否还合理呢？
在现实的生产存储中，有没有一些数据时间长了就没价值了，没必要浪费存储了，就可以删除了，有些数据变得不再重要了，可以存放在低性能的磁盘上，节约公司的机器硬件成本呢？
es生产环境，有没有经历过通过人工去管理索引的中部分数据的删除呢，知道es删除数据原理的都知道，这样对性能有很大的影响，刚开始并没有真正的删除数据。
这篇文章纯属于个人通过别人的博客和官网的学习，结合自己公司业务场景的一个思考，有些是没有实际验证的。本篇也是基于elasticsearch7.8.1的一个版本的知识点。
一、引发思考的背景1、首先业务场景，es的业务场景是真的广泛，目前我们只是用来做搜索查询，虽然现在在研究elk，对日志的进行索引，但是肯能还只是用到es的一点点的功能
2、在es安装的时候，如何设计节点，如何根据现有的机器做es的集群，配置好集群后，怎么设计索引，一般都会有一个时间的字段，根据数据量的大小和增长速度可以根据天，月，年等时间间隔切分索引，使用别名管理，那么多索引，但是又如何去管理这些索引呢，还要根据自己公司的业务场景，而不是纯粹的设计理论，我觉的符合公司情况，符合业务场景的设计才是最好的设计吧，但是不是一味的强耦合的只考虑单个业务，应该考虑多个，能够做到模板化，这样就能很好的做扩展了，以及要考虑对未来的规划和数据增长的容忍度吧
3、当然我们目前没有巨量的数据，但是很多事情也必须考虑进去，根据公司业务，比如数据只有一年的经常使用，后面的数据基本不用，三年前的数据可以删除，机器设备性能，有些机器磁盘性能好ssd，有些一般吧机械硬盘，还有cpu，内存的因素都要考虑。
4、公司管理人员少，怎么去管理这些呢，也没这个精力去开发索引的管理界面，很多因素都要考虑进去
二、冷热架构冷热架构就是有冷的有热的（这是玩笑话），就是经常需要使用（热）和不经常使用的数据（冷），有了这样的却别，存储方面肯定也要区别对待吧，把热数据存放在性能好的机器上，把冷的数据存放在性能较差的机器上，这个就是所谓的合理利用资源，节约公司硬件成本，也就是在硬件成本一定的条件下，提升集群的性能。但是描述是这么描述了，怎么实现热数据就存在好的机器上，冷数据就存在差点的机器上呢，可以映射呀，打标签呀，方法很多嘛，es就是打标签。----如上描述都是个人理解（这里只说个人的）
好，接下来就给每个es集群的节点打标签咯，说A集群性能好，用来存热数据，说B机器性能差一些，用来存冷数据，在他们每个机器上挂个牌牌，方便数据根据自己的冷热程度对号入座。es是这么打标签的：
在elasticsearch.yml文件中增加
node.attr.{attribute}: {value}