数据量增长，当前存在的问题：
- 查询与写入越来越慢，聚合的速度慢的离谱，聚合的数据量大一些的话，可能出现超时失败，甚至OOM
- 磁盘和内存资源以肉眼可见的速度快速消耗，甚至出现满载的情况
- JVM频繁GC，fullGC的频率逐渐变高，甚至由于GC卡顿导致系统不可用的情况发生
阶段一方案：
- 将索引按照某些条件由一个拆分成多个，配合模板和别名机制按条件生成索引
- 在这种操作下，按照时间段的search就会被限制在一个或者几个index中，减少了数据扫描范围，查询以及聚合的效率都会提升，消耗的资源也变少了
- 根据数据的特点，将数据分为冷热温数据，进行分级管理：热数据配备较好的硬件资源，如较大的内存和性能更好的CPU，SSD硬盘等；温数据和冷数据使用相对较差的硬件，这样在整个硬件消耗可控的情况下，尽量充分利用硬件资源
- 对部分温冷数据执行 shrink 以及 forcemerge 操作，暂时不用的数据可以close甚至delete掉（delete的时候尽量使用delete index，不用使用delete_by_query，delete_by_query的效率以及资源占用实在太感人了）
- 对数据定期做snapshot，保证数据的安全性
随着业务需求的推进以及集群数据的演进，index 越来越多，模板越来越多，各种 elasticsearch 的需求也越来越多，随之而来的就是维护的脚本越来越多，运维压力增大。
操作解释：
1、Open / Close Index API
- 索引关闭后，对集群的相关开销基本降低为 0
- 但是无法被读取和搜索
- 当需要的时候，可以重新打开
2、Shrink Index：可以将索引的主分片数收缩到较小的值
- ES 5.x 后推出的一个新功能，使用场景
- 索引保存的数据量比较小，需要重新设定主分片数
- 索引从 Hot 移动到 Warm 后，需要降低主分片数
- 会使用和源索引相同的配置创建一个新的索引，仅仅降低主分片数
- 源分片数必须是目标分片数的倍数。如果源分片数是素数，目标分片数只能为 1
- 如果文件系统支持硬链接，会将 Segments 硬连接到目标索引，所以性能好
- 完成后，可以删除源索引
3、forcemerge: 对于历史不变的数据，通过对小的segment文件进行 merge ，提升性能
阶段二方案： curator + rollover
在这套方案中，rollover 负责索引的迭代管理，别名的管理；curator负责在上层对rollover command以及其他支持的command进行管理：
rollover：
- 上面的按时间创建索引的方法虽然能够通过索引名称判断数据的新旧，能通过索引名称来过滤search数据的索引范围，提高search效率。
- 但是如果数据不是按照时间均匀分布，出现数据波动的话，数据过大则可能导致索引数据量超过设计标准，导致性能受到影响；
- 数据过小则会造成资源浪费。为了弥补和解决这个问题，引入了rollover api。
Rollover 的原理：是使用一个别名指向真正的索引（要求索引的后缀必须是可以递增的数值类型，默认是000001这6位数字），当指向的索引满足一定条件（文档数 或 时间 或 索引大小），会新创建一个前缀相同，后缀递增的新索引，并将别名更新到实际指向的索引。
使用步骤
- 1、创建一个模板方便后续管理
- 2、创建索引：设置允许写入 "is_write_index": true ，否则无法写入数据，集群只能规定一个写入的索引
- 3、插入测试数据（3条）
- 4、执行rollover，如下图：rollover命令指定了三个规则，即时间最长1天 ，数据最多3条，容量最大20GB，这三个条件是or的关系，有一条满足即触发rollover操作
-
查看执行结果：创建了新的索引taochy-000002,原因是最大数据条数已经达到3条了（"[max_docs: 3]" : true）,这里还有另外一个操作，就是rollover将别名指向了新生成的taochy-000002了，后续数据会写入taochy-000002中
curator：参见 ES Monitoring 整理笔记
curator + rollover 方案在功能上基本上能满足大部分场景的要求了，但是使用起来还是有些复杂，且不够自动化。
阶段三方案：ILM
在elasticsearch6.6版本开始，elasticsearch把这两个组件（curator + rollover ）进行了融合，搞出了个 ILM（Index Lifecycle Management ，简称 ILM），所谓 Lifecycle(生命周期)是把索引定义了四个阶段：
- Hot：索引可写入，也可查询，也就是我们通常说的热数据，为保证性能数据通常都是在内存中或者SSD上；
- Warm：索引不可写入，但可查询，介于热和冷之间，数据来源于hot层，可以进行数据周期设置，shrink，forcemerge，reduce replica 等操作，数据可以根据需求存在内存以及硬盘上；如果土豪玩家或者有特殊需求的场景，数据也可以按照需求放在内存以及SSD上；
- Cold：索引不可写入，但很少被查询，数据来源于warm层，可以进行数据周期设置，freeze 等操作，数据查询的慢点也可接受，基本不再使用的数据，数据通常存储在大容量的磁盘上；
- Delete：索引按照设置的数据时间规则可被安全的删除。
这 4 个阶段是 ES 定义的一个索引从生到死的过程, Hot -> Warm -> Cold -> Delete 4 个阶段只有 Hot 阶段是必须的，其他 3 个阶段根据业务的需求可选。
使用步骤：
- 1、创建ilm的policy，kibana上有图形界面可以操作，也可以通过脚本或代码进行预制，kibana操作界面如下：
-
上面规约了Hot阶段重新生成索引的规则，这部分功能其实就是对于rollover api的封装
- 2、建立索引模板，和上面rollover的时候大体一样，有两点不同：
- 在模板加上了全局查询别名 taochy_read_alias，方面后续数据跨索引查询
- 在setting里面关联了lifecycle相关的配置，配置成刚才创建的policy，以及rollover需要的写别名taochy_write_alias
- 3、创建索引：这个和阶段二的rollover一致
-
查看结果：可以看到刚才配置的lifecycle属性以及两个别名的配置
-
- 4、写入数据（3条）
- 注意：elasticsearch加载ilm周期的全局配置，默认是10分钟，可以改成3秒，否则没10分钟才会检查一次，在这十分钟之内所有数据都会写入到taochy-000001，配置项修改如下：
- 再查看索引结果如下：taochy-000001只剩下读索引，所以通过写别名写入的数据不会再写入到该索引；而taochy-000002既有读索引也有些索引，新数据会写入到该索引，符合上面 rollover api的特性。
小结：
随着elasticsearch版本的迭代以及功能场景的扩展，索引生命周期的管理变得重要且必须，所以在6.6版本之后推出了ilm的功能，这个功能在之前curator+rollover的基础上进行了功能的封装，方便了大家的使用，可以说是一个相当成熟且完善的功能，但是大家在使用的时候也要注意评估使用场景以及使用方法，目前在我看来ilm使用起码有两点需要注意：
- 由于写别名只能指向最新的index，所以有数据修改需求的场景该需求可能不合适，或者说不能直接使用，需要通过方案级别进行设计来达到目标。
Flag：
- 关注 ILM （完全可以在日志集上试点）
- 将历史订单插入到当前Hot 索引的影响？（业务无影响、性能？)
- 历史不变的索引，保用尽量小的分片数
参考资料
- https://blog.csdn.net/microGP/article/details/114362960
- ES ILM 功能的实际应用（二）
- https://blog.51cto.com/ghostwritten/5345159