1.背景
- 小组项目在搭建属于自己的业务定制搜索服务;
- 项目原先接入了平台部门的通用搜索服务,在进行全链路压测时,es搜索成为瓶颈;
- 故统一在业务定制搜索服务中进行整改优化;
2.现象
1.压测条件:并发线程数 10 * 30
(并发线程数 * 节点数)下,出现大量查询超时(>500ms
),基本一压就挂;
2.通过日志查询执行dsl语句,如下,在多查询条件下,包含大量match
条件的bool
评分查询语句:
3.手动执行dsl,进一步确认dsl语句本身执行就很慢:
4. es在对该请求进行分片缓存后,时延降低:
5.但压测条件下仍然出现大量时延(分片级别缓存失效条件,后面会分析),该dsl本身具有很大的优化空间:
6.而平常生产环境偶发延迟,本身原搜索平台的qps较低(15左右),所以问题没有被放大出来,但风险仍在:
3.问题分析
1.从日志中获取慢dsl语句如下:
(业务字段用field1,field2,field3
表示)
{
"query":{
"bool":{
"filter":[
{
"match":{
"field1":"111"
}
},
{
"match":{
"field2":"0"
}
},
{
"match":{
"field3":"3"
}
}
],
"must":[
{
"bool":{
"should":[
{
"match":{
"field1":"222"
}
},
{
"match":{
"field1":"333"
}
},
{
"match":{
"field1":"444"
}
}
],
"minimum_should_match":"1"
}
},
{
"bool":{
"should":[
{
"match":{
"field2":"555"
}
},
{
"match":{
"field2":"666"
}
},
{
"match":{
"field2":"777"
}
},
{
"match":{
"field2":"888"
}
},
{
"match":{
"field2":"999"
}
}
],
"minimum_should_match":"1"
}
},
{
"bool":{
"should":[
{
"match":{
"field2":"111"
}
},
{
"match":{
"field2":"222"
}
}
]