仅索引层面调优手段：
1.1、设计阶段调优
（1）根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引；
（2）使用别名进行索引管理；
（3）每天凌晨定时对索引做 force_merge 操作，以释放空间；
（4）采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink操作，以缩减存储；
（5）采取 curator 进行索引的生命周期管理；
（6）仅针对需要分词的字段，合理的设置分词器；
（7）Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。……..
1.2、写入调优
（1）写入前副本数设置为 0；
（2）写入前关闭 refresh_interval 设置为-1，禁用刷新机制；
（3）写入过程中：采取 bulk 批量写入；
（4）写入后恢复副本数和刷新间隔；
（5）尽量使用自动生成的 id。
1.3、查询调优
（1）禁用 wildcard；
（2）禁用批量 terms（成百上千的场景）；
（3）充分利用倒排索引机制，能 keyword 类型尽量 keyword；
（4）数据量大时候，可以先基于时间敲定索引再检索；
（5）设置合理的路由机制。
1.4、其他调优
部署调优，业务调优等。
上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了。

elasticsearch 索引数据多了怎么办，如何调优，部署

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