无论才能、知识多么卓著,如果缺乏热情,则无异纸上画饼充饥,无补于事。

elasticsearch 2.3.1 使用long查询速度很慢,但是使用keyword很快。

Elasticsearch | 作者 code4j | 发布于2019年09月11日 | 阅读数:2888

版本:2.3.1
 
 
一个索引,1.3T大小,9个节点,18个分片。
 
索引结构如下:
{
"user-v3": {
"mappings": {
"profile": {
"properties": {
"convertDesc": {
"type": "string"
},
"convertName": {
"type": "string"
},
"convertReviewDesc": {
"type": "string",
"analyzer": "custom_analyzer"
},
"convertReviewName": {
"type": "string",
"analyzer": "custom_analyzer"
},
"demote": {
"type": "short"
},
"desc": {
"type": "string",
"fields": {
"raw": {
"type": "string",
"index": "not_analyzed"
}
},
"analyzer": "custom_analyzer"
},
"descTime": {
"type": "long"
},
"isolate": {
"type": "short"
},
"kuaishouId": {
"type": "string",
"fields": {
"raw": {
"type": "string",
"index": "not_analyzed"
}
},
"analyzer": "custom_analyzer"
},
"lastProfileIp": {
"type": "long"
},
"lastProfileIpv6": {
"type": "string",
"index": "not_analyzed"
},
"lastProfileTime": {
"type": "long"
},
"lastStartupIp": {
"type": "long"
},
"lastStartupIpv6": {
"type": "string",
"index": "not_analyzed"
},
"lastStartupTime": {
"type": "long"
},
"name": {
"type": "string",
"fields": {
"raw": {
"type": "string",
"index": "not_analyzed"
}
},
"analyzer": "custom_analyzer"
},
"nameTime": {
"type": "long"
},
"normalizedDesc": {
"type": "string",
"analyzer": "custom_analyzer"
},
"normalizedName": {
"type": "string",
"analyzer": "custom_analyzer"
},
"registerDeviceId": {
"type": "string",
"index": "not_analyzed"
},
"registerIp": {
"type": "long"
},
"registerIpv6": {
"type": "string",
"index": "not_analyzed"
},
"registerPhoneModel": {
"type": "string",
"index": "not_analyzed"
},
"registerTime": {
"type": "long"
},
"reviewDesc": {
"type": "string",
"fields": {
"raw": {
"type": "string",
"index": "not_analyzed"
}
},
"analyzer": "custom_analyzer"
},
"reviewName": {
"type": "string",
"fields": {
"raw": {
"type": "string",
"index": "not_analyzed"
}
},
"analyzer": "custom_analyzer"
},
"socialBannedStatus": {
"type": "short"
},
"status": {
"type": "integer"
},
"statusForWrite": {
"type": "long"
},
"transferDesc": {
"type": "string"
},
"transferName": {
"type": "string"
},
"userId": {
"type": "long"
}
}
}
}
}
}

 
一开始查询条件是这么写的:
{
"bool" : {
"filter" : [ {
"range" : {
"nameTime" : {
"from" : 151167613000,
"to" : 1568167613000,
"include_lower" : true,
"include_upper" : true
}
}
}, {
"term" : {
"status" : 0
}
}, {
"terms" : {
"userId" : [ 818608209 ]
}
} ]
}
}

命中结果1条。执行耗时; 500ms(不稳定,应该是缓存影响,有时候会比较快,但是时长执行耗时再500ms左右)
 
执行下面的查询:
{
"bool" : {
"filter" : [ {
"term" : {
"name.raw" : "刘较瘦233"
}
}, {
"range" : {
"nameTime" : {
"from" : 150167613000,
"to" : 1568167613000,
"include_lower" : true,
"include_upper" : true
}
}
}, {
"term" : {
"status" : 0
}
}, {
"terms" : {
"userId" : [ 818608209 ]
}
} ]
}
}
比起第一个查询多了一个精确匹配的条件,返回值还是1条。
但是这个查询语句耗时稳定在10-20ms。
 
 
就这个版本的情况来说,出现这种情况可能的原因是什么呢。  这个case比较有规律,只要加上keyword命中,返回相同的文档,速度就非常快。  求大佬们指点。
 
ps: 后面我试试把数据拉到6.x再试试看会不会有这种情况。
 
-----------------------------------------分割线---------------------------------------
发现一个很有意思的现象,应该是低版本会出现的。
我把时间条件放到后面,耗时长的问题缓解了很多,似乎问题并不在userId这个条件上,因为keyword这个条件总是排在第一位的,第二个是时间,所以没有keyword的时候时间成了第一个条件。 如果我把时间放到最后面,速度快了很多。很神奇。
 
还要进一步探索,另外有没有了解这个问题的同学?来发言呀
 
已邀请:

code4j - coder github: https://github.com/rpgmakervx

赞同来自:

顶一下

hufuman

赞同来自:

https://elasticsearch.cn/m/article/446
kenny的文章说明很详细了

要回复问题请先登录注册