场景是这样的，十几个Elasticsearch节点，每个节点标准的64g内存，32核心，5T ssd。 我们数据是按天维护索引的，每天一个索引，每个索引三个分片，累计90g数据。 我可以确定数据分布都是均匀的，没有倾斜的情况。并且集群测试阶段没有任何压力。cpu和负载都非常低。我们用query string去做phrase的检索，对六个字段做匹配。我们的一次检索的关键词个数大概一百一个。然后这个奇怪的问题在于。这个搜索需求，我放在一天的索引上执行，它耗时毫秒级别的，一秒以内。但是我别名搜一个月的数据，三十个索引的时候，我的整个搜索耗时在40s。起初我怀疑有排队。我算了下，能够落在每个节点上的请求命中的分片数小于10，所以我把每个节点上单个请求最大同时执行的并发度改成了10，这个已经让每个节点上的分片都去并行执行了。 但是耗时还是在30到是40s。我想不明白，为什么。大家有思路或者排查方向吗？
场景是这样的，十几个Elasticsearch节点，每个节点标准的64g内存耗时还是在30到是40s[阿里云检索分析服务 Elasticsearch版]
「点点赞赏，手留余香」
还没有人赞赏，快来当第一个赞赏的人吧！
我给出一下步骤，你可以按照我的步骤检查一下： 首先，您可以检查Elasticsearch集群的状态，确保每个节点都处于正常状态。您可以使用_cat API查看集群的状态，确保每个节点都处于正常状态。 其次，您可以检查搜索查询的性能，确保查询的性能没有问题。您可以使用_explain API查看搜索查询的性能，确保查询的性能没有问题。 此外，您还可以检查Elasticsearch集群的配置，确保配置没有问题。您可以检查Elasticsearch集群的索引分片数量，确保每个索引都有足够的分片数量，以便搜索查询可以并行执行。 最后，您可以检查Elasticsearch集群的硬件资源，确保每个节点都有足够的硬件资源来支持搜索查询。您可以使用_nodes API查看每个节点的硬件资源，确保每个节点都有足够的硬件资源来支持搜索查询。
首先想到的是搜索的长尾效应，虽然说数据量是在es集群中分布均衡的，但是命中doc不一定是均衡的。有些index命中较多比较耗时。导致整体较差——该回答整理自钉群“Elasticsearch中文技术社区”