搜索的业务里经常会有bool should查询，即条件1,2,3命中任一即可召回。按照es的默认算法，假如有一条文档同时满足条件1和条件2，它的最终分值会是（条件1分值+条件2分值）。但我们的业务要求只能取命中条件里分值最高的那个作为分值，所以似乎是用dis_max查询比较合适。但我尝试使用dis_max的时候发现它的性能很糟糕。原本我们的查询因为条件复杂、索引也比较大，本来速度就不怎么快，使用dis_max后一次查询要消耗数秒的时间。profile显示，dis_max自己这一步耗时最多：
想请教一下，是我使用dis_max的姿势有问题吗，有没有什么优化空间？我感觉dismax只是在分值累加的环节多了一步判断而已，按说不应该很耗时？
我的集群配置，平时IO资源比较紧张，但cpu和内存还好。没有配置协调节点，但直接请求data节点，平时性能也够用。会是这方面的问题吗？
想请教一下，是我使用dis_max的姿势有问题吗，有没有什么优化空间？我感觉dismax只是在分值累加的环节多了一步判断而已，按说不应该很耗时？
我的集群配置，平时IO资源比较紧张，但cpu和内存还好。没有配置协调节点，但直接请求data节点，平时性能也够用。会是这方面的问题吗？
4 个回复
God_lockin
赞同来自: xiaowuge
osborn
赞同来自:
从profile里看，总是有一部分节点计算dismax很慢，其他节点计算快，每次查找都不一样
这莫非是集群本身配置的问题？不知dismax这个计算主要消耗什么资源，是内存还是硬盘
God_lockin
赞同来自:
如果有可能就按我之前写的，把不需要打分的放在filter里面
然后把你dismax里面写的所有要算分的query拿出来分析一下，有哪些query会比较慢，因为不同的query影响的数据范围是不一样的，而且在存储端没做优化的话，也有可能因为数据倾斜、数据被换出缓存需要重新从磁盘读取等原因产生响应时间变长。
这部分你可以考虑比如sort store、prestore、query预热等方式看看有没有改善
Freeflying - 90后搜索
赞同来自:
并且放在bool的第一层，快。