背景

对于搜索集群而言，小节点多节点化一般是最佳实践。对于OLAP/日志集群而言，难以避免使用大节点（单节点高配置），因为太多节点容易造成master的压力。对于OLAP集群而言单节点可能存在数百甚至数千shard。此时我们就需要考虑一个问题，当我们增大shard数量，想利用ES的并发能力提高性能的时候，是否可以达到预期？

注：不考虑增加配置/节点带来的性能收益

结论

1.单个请求（一次检索），单个索引在一个节点上命中的分片数只能有5个（默认），如果大于5，此时就需要串行了。

Search API | Elasticsearch Guide [7.17] | Elastic

2.不考虑增加配置/节点带来的性能收益，增加分片并不一定会性能提升

   -  考虑单节点的并发限制

   -  聚合场景下，GC的压力相对较大，多个分片可能会带来更多的YGC压力，导致CPU上升，并且抵消分布式带来的性能提升

   - 聚合是使用 search 线程池

   - 单个分片，聚合不会并发执行（可知大分片对性能并不友好）

分析

1. 如何理解max_concurrent_shard_requests

例如test索引有12分片，1副本，分布在2个节点上（此时每个节点都有test索引的12个分片）；

查询时，由于max_concurrent_shard_requests限制了为5，也就是超过5就需要等待，在一个节点中需要串行，2次等待，第一次查询5个分片，第二次查询5个分片，第三次查询2个分片。串行带来性能损失。

如何解决：

1. 增加节点数，横向扩容

2. 调整单请求的max_concurrent_shard_requests配置

GET test/_search?max_concurrent_shard_requests=24
{}

3. 对整个集群调整max_concurrent_shard_requests参数

PUT /_cluster/settings
{"persistent" : {"max_concurrent_shard_requests : "24"}
}

2. 聚合性能如何提升？

对于聚合来说，当max_concurrent_shard_requests合理之后，提升性能只能依赖足够的配置。

1. 增大内存（防止GC导致损失性能）

2. 增多节点数（利用分布式能力）