场景是这样的,十几个Elasticsearch节点,每个节点标准的64g内存,32核心,5T ssd。 我们数据是按天维护索引的,每天一个索引,每个索引三个分片,累计90g数据。 我可以确定数据分布都是均匀的,没有倾斜的情况。并且集群测试阶段没有任何压力。cpu和负载都非常低。我们用query string去做phrase的检索,对六个字段做匹配。我们的一次检索的关键词个数大概一百一个。然后这个奇怪的问题在于。这个搜索需求,我放在一天的索引上执行,它耗时毫秒级别的,一秒以内。但是我别名搜一个月的数据,三十个索引的时候,我的整个搜索耗时在40s。起初我怀疑有排队。我算了下,能够落在每个节点上的请求命中的分片数小于10,所以我把每个节点上单个请求最大同时执行的并发度改成了10,这个已经让每个节点上的分片都去并行执行了。 但是耗时还是在30到是40s。我想不明白,为什么。大家有思路或者排查方向吗?
我给出一下步骤,你可以按照我的步骤检查一下: 首先,您可以检查Elasticsearch集群的状态,确保每个节点都处于正常状态。您可以使用_cat API查看集群的状态,确保每个节点都处于正常状态。 其次,您可以检查搜索查询的性能,确保查询的性能没有问题。您可以使用_explain API查看搜索查询的性能,确保查询的性能没有问题。 此外,您还可以检查Elasticsearch集群的配置,确保配置没有问题。您可以检查Elasticsearch集群的索引分片数量,确保每个索引都有足够的分片数量,以便搜索查询可以并行执行。 最后,您可以检查Elasticsearch集群的硬件资源,确保每个节点都有足够的硬件资源来支持搜索查询。您可以使用_nodes API查看每个节点的硬件资源,确保每个节点都有足够的硬件资源来支持搜索查询。
首先想到的是搜索的长尾效应,虽然说数据量是在es集群中分布均衡的,但是命中doc不一定是均衡的。有些index命中较多比较耗时。导致整体较差——该回答整理自钉群“Elasticsearch中文技术社区”
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。