Elasticsearch搜索调优

Posted zhq1007

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Elasticsearch搜索调优相关的知识,希望对你有一定的参考价值。

最近把搜索后端从AWS cloudsearch迁到了AWS ES和自建ES集群。测试发现search latency高于之前的benchmark,可见模拟数据远不如真实数据来的实在。这次在产线的backup ES上直接进行测试和优化,通过本文记录search调优的主要过程。

问题1:发现AWS ES shard级别的search latency是非常小的,符合期望,但是最终的查询耗时却非常大(ES response的took), 整体的耗时比预期要高出200ms~300ms。

troubleshooting过程:开始明显看出问题在coordinator node收集数据排序及fetch阶段。开始怀疑是因为AWS ES没有dedicated coordinator节点,data node的资源不足导致这部分耗时较多,后来给所有data node进行来比较大的升级,排除了CPU,MEM, search thread_pool等瓶颈,并且通过cloud watch排除了EBS IOPS配额不够的可能,但是,发现search latency并没有减少。然后就怀疑是network的延时, 就把集群从3个AV调整到1个AV,发现问题依旧。无奈,联系了AWS的support,AWS ES team拿我们的数据和query语句做了benchmark,发现没有某方面的资源瓶颈。这个开始让我们很疑惑,因为在自建ES集群上search latency明显小于AWS ES,两个集群的版本,规格,数据量都差不多。后来AWS回复说是他们那边的架构问题,比之自建集群,AWS ES为了适应公有云上的security, loadbalance要求,在整个请求链路上加了一些组件,导致了整体延时的增加。

确定方案:限于ES cluster不受控,我们只能从自身的数据存储和查询语句上去优化。

存储优化:

1. index sort。我们的查询结果都是按时间(created_time)排序的,所以存储的时候即按created_time进行有序存储,方便提前中断查询。

2. segment merge。索引是按季度存储的,把2019年之前的索引进行了force merge,进行段合并,2019年之前的索引确定都是只读的。

3. 索引优化。合并了一些小索引,2016,2017年的数据量比较少,把这两年的索引进行合并,减少总shard数。通过创建原索引的别名指向新索引,保证search和index的逻辑不用改动。

查询优化。

先通过profile API定位耗时的子查询语句。

1. 合并查询字段。一个比较耗时子查询查询如下,通常session_id的list size>100,receiver_id和sender_id也会匹配到n多条记录。

{
    "minimum_should_match": "1"
    "should": [
        {
            "terms": {
                "session_id": [
                    "ab",
                    "cd"
                ],
                "boost": 1
            }
        },
        {
            "term": {
                "receiver_id": {
                    "value": "efg",
                    "boost": 1
                }
            }
        },
        {
            "term": {
                "sender_id": {
                    "value": "hij",
                    "boost": 1
                }
            }
        }
    ]
}

新开一个字段session_receiver_sender_id,通过copy_to把每条记录的session_id,receiver_id, sender_id都放到这个字段上。把query语句改为

{
    "terms": {
        "session_receiver_sender_id": [
            "ab",
            "cd",
            "efg",
            "hij"
        ],
        "boost": 1
    }
}

不过,测试结论显示,合并之后query耗时并没有明显缩短,感觉改动意义不大。推测可能是我们的BoolQuery字段并不多(就3个),但是terms的size很多(100以上),因为不管是多个字段每个对应一个termQuery,还是一个terms query, 都是转成BoolQuery,最终都是多个termQuery做or。

 

2. 优化date range查询。另外一个比较耗时的查询是date range。Lucene会rewrite成一个DocValuesFieldExistsQuery。

"filter": [
    {
        "range": {
            "created_time": {
                "from": 1560993441118,
                "to": null,
                "include_lower": true,
                "include_upper": true,
                "boost": 1
            }
        }
    },
    ...
]

这里匹配到的docId的确非常多,date range结果在构造docIdset与别的子查询语句做conjunction耗时较大。

采用的一个解决方案是尽量对这个子查询进行缓存,把这个date range查询拆成两段,分为3个月前到昨天,昨天到今天两段,一般昨天的数据不再变化,在没有触发segment merge的情况下3个月前到昨天到查询结果应该能缓存较长时间。

"constant_score": {
  "filter": {
    "bool": {
      "should": [
        {
          "range": {
            "created_time": {
              "gte": "now-3M/d",
              "lte": "now-1d/d"
            }
          }
        },
        {
          "range": {
            "created_time": {
              "gte": "now-1d/d",
              "lte": "now/d"
            }
          }
        }
      ]
    }
  }
}

相应的,在用户可接受的前提下,调大索引的refresh_interval。

问题2: 在自建ES集群上,发现某个索引500ms以上的搜索耗时占比较多。

这个索引每日大概30w次查询,落在100ms以内的查询超过90%,但是依旧有1%的查询落在500ms以上。发现同样的query语句模版,但如果某些子查询条件匹配到的数据比较多,查询会变对特别慢。

troubleshooting过程:同样是通过profile参数分析比较耗时的查询子句。发现一个PointInSetQuery非常耗时,这个子查询是对一个名为user_type的Integer字段做terms查询,子查询内部又耗时在build_score阶段。

通过查找lucene的代码和相关文章,发现lucene把numeric类型的字段索引成BKD-tree,内部的docId是无序的,与其他查询结果做交集前构造Bitset比较耗时,从而把Integer类型改成keyword,把这个查询转成TermQuery,这样哪怕命中的数据很多,在build_score的时候因为倒排链的docId有序性,利用skiplist,可以更快速的构建一个Bitset。在把这个字段改成keyword后,50th的查询耗时并没有多大差异,但是90th、99th的search latency明显小于之前。

技术图片

 

另一个优化,这个索引里的每条数据都是一个非空的accout_id字段,accout_id在query语句里会用于terms查询。遂把这个accout_id字段作为routing进行存储。同时可以对查询语句进行修改:

#原query
"filter": [
    {
        "terms": {
            "account_id": [
                "abc123"
            ],
            "boost": 1
        }
    }
...
]
#改为
"filter": [
    {
        "terms": {
            "_routing": [
                "abc123"
            ]
        }
    }
...
]

查询改为_routing之后,发现整体的search latency大幅降低。

技术图片

经过这两次改动,针对这个索引的search latency基本满足需求。

另外,还有一个小改动,通过preload docvalue, 可以减少首次查询的耗时。

 

以上是关于Elasticsearch搜索调优的主要内容,如果未能解决你的问题,请参考以下文章

Elasticsearch搜索调优

Elasticsearch 基础理论 & 配置调优

Elasticsearch电商搜索分词效果调优

干货|eBay的Elasticsearch性能调优实践(上)

eBay的Elasticsearch性能调优实践

ElasticsearcheBay上的Elasticsearch性能调优实践