Well,不要刷屏了

es中terms查询速度能否优化

Elasticsearch | 作者 computerwan | 发布于2018年08月07日 | 阅读数:8667

es表结构如下:PUT demo/
{
  "mappings": {
    "demo": {
      "_all": {
        "enabled": false
      },
      "properties": {
        "aId": {
          "type": "keyword"
        },
        "cId": {
          "type": "keyword"
        }
      }
    }
  }
}
插入:按照如上单独aId和cId存储为一个doc
查询:每次传入一个aId和1000个cId的列表,返回es中匹配的aId+cId的列表。
 
使用如下filter+terms查询:
GET demo/_search?routing=11147489
{
"size":1000,
  "query": {
    "bool": {
      "filter": {
        "term": {
          "aId": "11147489"
        }
      },
      "must": [
        {
          "terms": {
            "cId": [
              "11147494",
              "11147498",
              ....(1000个)
            ]
          }
        }
      ]
    }
  }
}
 
对于es中aId下cId数量小于100的情况性能比较理想大概在7ms左右,
但是对于aId下cId数量几千几万的情况下,响应时间达到40ms以上,但如果size设置为100,则有时候能降到10多ms。
以上插入和查询的时候使用了路由,返回结果_source也置为过false,使用过ids查询,用should里面套用1000个term替换terms,但效果都不理想。
 
请问下论坛里面的大神:
1. 为什么size=100和size=1000响应时间差距这么大,理论上查询条件带有aId和路由相同,只在一个分片上查询,协调节点只需要从一个分片上直接获取数据并返回即可,并没有分片之间结果合并,是因为fetch的过程比较耗时吗?我用profile去查看的时候几个耗时都不超过1ms。
2. 有没有其他方法优化aId下cId较大的情况,上述查询的响应时间。
 
谢谢。
 
已邀请:

rochy - rochy_he

赞同来自:

1. 看起来你的 routing 和 aid 是一一对应的,那么前面的 filter 操作是不是可以去掉?
2. 如果 ID 是确定的,可以使用 multiGet 直接获取结果即可;
3. mapping 设置 eager_global_ordinals: true

the_best

赞同来自:

你好,请问下你这个测试结果是在什么数据量级的情况下测试出来的,我们现在也有terms look up关联查询的需求,同样担心terms查询时id数组过大时的查询性能问题。

laoyang360 - 《一本书讲透Elasticsearch》作者,Elastic认证工程师 [死磕Elasitcsearch]知识星球地址:http://t.cn/RmwM3N9;微信公众号:铭毅天下; 博客:https://elastic.blog.csdn.net

赞同来自:

安装下xpack,看下profile具体耗时

要回复问题请先登录注册