1. 背景

使用jvm-sandbox-repeater来录制测试环境中，所有业务线的HTTP,DUBBO,MQ,MYSQL等常用组件的请求参数 与返回结果，随着更多的业务线接入后，每天的数据总量在不断累积。

当天ES中的document数据也到了2000+万，用户使用查询出，肉眼可见的慢查询（超过了3秒）。所以需要进行查询的优化。

2. 分析

2.1. 数据总量过大

投入的机器成本(集群节点、CPU、内存容量)是有限，一直让运维同学增加数据硬件投入，只是临时应对突发的峰值。考虑到有些数据本身 存储的必要性不高。比如一个用户登陆态、权限检查等频繁访问 ，但是应用本不会像业务系统那样频繁迭代，接口一般不会有太多的变化。 所以这类数据量大，但本身没有存储价值的数据，进行限流。

通过分析，确实也符合八二原理，头部的几个DUBBO接口占了总量的超80%。所以请将这些接口按小时统计排序，进行动态性的限流， 可以降低数据的总量，最终的效果差不多是将每天的总量降低到1000+万的水准。

2.2. 单个索引拆分

按天来划分索引，每天一个索引，这个索引数量降低到1000万后，还是过大，为此，将这个索引在按片分片的基础上，又分成了4片，如

• repeater_20230101 分片成

  • repeater_2023010_1
  • repeater_2023010_2
  • repeater_2023010_3
  • repeater_2023010_4

使用RestHighLevelClient进行查询时，传入4个索引，相当于4个线程并行的查询原来的数据集。查询的时间得到的降低。

3. 参考文献

3.1. 这次优化的本质

这次慢查询的本质不是单条 DSL 写错，而是“数据规模增长后，索引组织方式和数据价值密度不再匹配”。

3.2. 优化思路总结

• 先做数据分层，把低价值高频数据限流。
• 再控制单索引规模，避免每天单索引过大。
• 最后通过并行查询多个分片索引降低单次查询时间。

3.3. 后续可继续优化的方向

• 索引模板和 mapping 精简。
• 热冷数据分层。
• 查询字段裁剪和条件前置过滤。
• 针对高频查询建立更贴近业务的索引模型。