我们有以下的Query,多次查询发现tag_id、status、isaudited几个字段都可能是性能瓶颈
求问有什么可以优化的手段吗?
ES:5.3.2
DocCount:1,2434,9270
CPU:32*6
Mem: 128*6
查询、排序的字段,均为long类型
profile结果内容太多,我放在附件里了
Query:
{
"profile": true,
"size": 20,
"query": {
"bool": {
"must": [
{
"term": {
"tag_id": 84220
}
},
{
"term": {
"status": 6
}
},
{
"term": {
"is_audited": 0
}
}
]
}
},
"from": 0,
"_source": [
"PublishTime"
],
"sort": [
{
"Weighting": {
"order": "desc"
}
},
{
"CustomRank": {
"order": "desc"
}
},
{
"PublishTime": {
"order": "desc"
}
}
]
}
求问有什么可以优化的手段吗?
ES:5.3.2
DocCount:1,2434,9270
CPU:32*6
Mem: 128*6
查询、排序的字段,均为long类型
profile结果内容太多,我放在附件里了
Query:
{
"profile": true,
"size": 20,
"query": {
"bool": {
"must": [
{
"term": {
"tag_id": 84220
}
},
{
"term": {
"status": 6
}
},
{
"term": {
"is_audited": 0
}
}
]
}
},
"from": 0,
"_source": [
"PublishTime"
],
"sort": [
{
"Weighting": {
"order": "desc"
}
},
{
"CustomRank": {
"order": "desc"
}
},
{
"PublishTime": {
"order": "desc"
}
}
]
}
4 个回复
kennywu76 - Wood
赞同来自: hufuman 、laoyang360 、napoleonu 、pqy 、Xiaoming 、ghsy158 、wkdx更多 »
改用keyword字段来索引就快了, 深层次原因还在看代码探寻。
huganle
赞同来自: hufuman
kennywu76 - Wood
赞同来自:
其一: 5.0以后number类型改为block k-d tree索引,对于低cardinality的number类型字段做conjuntion性能差。
其二: Build cache的逻辑。
等我有空的时候写篇博客详细解释一下。
spoofer
赞同来自: