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个线程并行的查询原来的数据集。查询的时间得到的降低。