索引数据的规划，应在前期做好规划，正所谓 “ 设计先行，编码在后 ” ，这样才能有效的避免突如
其来的数据激增导致集群处理能力不足引发的线上客户检索或者其他业务受到影响。
所以在设计阶段就需要结合自身的业务特点来提前做好规划。
3.1 动态索引层面
基于模板 + 时间 +rollover api 滚动创建索引，举例：设计阶段定义： blog 索引的模板格式为：
blog_index_ 时间戳的形式，每天递增数据。这样做的好处：不至于数据量激增导致单个索引数据量非 常大，接近于上线 2 的 32 次幂 -1 ，索引存储达到了 TB+ 甚至更大。
一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑 及早避免。
3.2 存储层面
冷热数据分离存储，热数据（比如最近 3 天或者一周的数据），其余为冷数据。
对于冷数据不会再写入新数据，可以考虑定期 force_merge 加 shrink 压缩操作，节省存储空间和检索 效率。
3.3 部署层面
一旦之前没有规划，这里就属于应急策略。
结合 ES 自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注意：如果之前主节点 等规划合理，不需要重启集群也能完成动态新增的。
