嘿~ 今天天气不错嘛

dis_max查询速度慢的问题

Elasticsearch | 作者 osborn | 发布于2021年12月08日 | 阅读数:144

搜索的业务里经常会有bool should查询,即条件1,2,3命中任一即可召回。按照es的默认算法,假如有一条文档同时满足条件1和条件2,它的最终分值会是(条件1分值+条件2分值)。但我们的业务要求只能取命中条件里分值最高的那个作为分值,所以似乎是用dis_max查询比较合适。但我尝试使用dis_max的时候发现它的性能很糟糕。原本我们的查询因为条件复杂、索引也比较大,本来速度就不怎么快,使用dis_max后一次查询要消耗数秒的时间。profile显示,dis_max自己这一步耗时最多:
QQ图片20211208134858.png

想请教一下,是我使用dis_max的姿势有问题吗,有没有什么优化空间?我感觉dismax只是在分值累加的环节多了一步判断而已,按说不应该很耗时?
我的集群配置,平时IO资源比较紧张,但cpu和内存还好。没有配置协调节点,但直接请求data节点,平时性能也够用。会是这方面的问题吗?
已邀请:

God_lockin

赞同来自: xiaowuge

如果你不需要算分,可以直接 bool: filter:should,把条件作为过滤项

osborn

赞同来自:

需要算分的呀,毕竟都用上了dis_max这么精确控分的手段 ToT
从profile里看,总是有一部分节点计算dismax很慢,其他节点计算快,每次查找都不一样
这莫非是集群本身配置的问题?不知dismax这个计算主要消耗什么资源,是内存还是硬盘
 

God_lockin

赞同来自:

dismax 是对你多个query 进行综合算分的方式,但是它会把你所有放里面的query都纳入计算
 
如果有可能就按我之前写的,把不需要打分的放在filter里面
 
然后把你dismax里面写的所有要算分的query拿出来分析一下,有哪些query会比较慢,因为不同的query影响的数据范围是不一样的,而且在存储端没做优化的话,也有可能因为数据倾斜、数据被换出缓存需要重新从磁盘读取等原因产生响应时间变长。
 
这部分你可以考虑比如sort store、prestore、query预热等方式看看有没有改善
 

要回复问题请先登录注册