大参林亿级Elasticsearch搜索性能调优实践

推荐语

大参林通过优化Elasticsearch查询策略，将CPU使用率从90%降至25%，大幅提升搜索性能。

核心内容：
1. 亿级商品数据搜索面临的性能瓶颈分析
2. 定位并解决wildcard查询导致的慢查询问题
3. 采用multi_match查询优化方案的实际效果

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

大参林针对亿级商品数据的Elasticsearch搜索进行性能调优，通过定位慢查询问题并替换wildcard查询为multi_match查询，成功将CPU使用率从90%大幅降至25%，显著提升了搜索性能和系统稳定性。

大参林搜索Elasticsearch承载着门店运营和加盟业务的日常商品搜索，Elasticsearch集群存储着超过十亿级的商品数据，CPU使用率平均达到75%以上，业务峰值超过90%，为能承载更多门店的日常使用，急需解决性能和成本等问题。本文通过介绍如何排查CPU过高的原因，优化方案的选择，最后将Elasticsearch的CPU使用率降低至25%。

阿里云集群监控

为什么Elasticsearch集群的CPU使用率这么高呢？通过监控发现：查询线程reject数、慢查询条数、集群总体写入QPS、集群总体查询QPS、磁盘IOUtil使用率都在正常水位，只有慢查询的数量过多，在30分钟内有4900多条慢查询，如下截图：

为何会有这么多的慢查询呢？通过对Searching慢日志内容进行分析，发现绝大部的慢查询都是使用了wildcard进行查询，如下截图：

图片来源：信息中心内部

那为什么使用wildcard查询会如此慢呢？看看它的查询原理：Elasticsearch中的wildcard查询是通过构建DFA（确定性有限状态机）来实现的。构建DFA的时间复杂度是O(2^n)，其中n是输入的字符串长度。如果要查询的关键字越长，则查询消耗的时间越长，而且构建的过程也非常的消耗服务器CPU。如果字符串带有通配符如*或者?则构建出来的DFA会更复杂且耗时更大，构建的DFA会与索引中的所有term进行匹配，来判断哪些文档符合查询条件，并将匹配的文档ID返回。

ES的Profile API

通过使用Profile API解析查看下wildcard查询的相关信息，DSL查询语句如下：

GET store_goods_xxx/_search?human=true{"_source": ["goods_name", "goods_no", "stock"], "profile": "true", "query": {"bool": {"must": [{"term": {"store_code": {"value": "1005012029"}}}, {"bool": {"should": [{"wildcard": {"goods_name.keyword": {"value": "*感冒灵*"}}}]

查询请求内容中新增"profile": "true", 则开启profile分析；查询url后添加参数?human=true则是方便查看耗时，如下截图返回的profile内容中新增 "time" : "2ms"内容,增加了ms、micros的单位。下图可以看出wildcard查询是term查询耗时的几十倍。

图片来源：信息中心内部

由于使用Profile API分析查询语句，返回profile的json成百上千行，涉及wildcard查询通配符时，返回内容更多，成千上万行的内容，不能直观看到性能瓶颈在哪里。有没有类似Skywalking监控接口一样能直观看到相关过程的耗时呢？答案是肯定的，有。

Kibana的Search Profile

图片来源：信息中心内部

通过上述的排查与分析，定位到造成Elasticsearch集群CPU使用率较高的问题根源在于使用wildcard查询，那如何进行优化呢？通过检索相关的资料，发现替代wildcard查询的常用方案有两种：ngram分词器、wildcard字段类型。

➢ ngram分词器

ngram分词器适用于自动补全、下拉联想词、模糊搜索等场景，ngram分词器可以支持左右匹配的模糊搜索。在大数据量下相较于wildcard匹配，ngram分词器可以提供更好的性能，但可能会生成大量的分词，导致索引过大而影响搜索性能。

在当前4个数据节点规模的Elasticsearch集群下，索引的文档数有10亿+的数据量，占用1TB的存储空间，如果再继续使用ngram分词器，索引将会更大，同样会有性能问题。

➢ wildcard字段类型

wildcard字段类型适用于下拉联想词、模糊搜索等场景，wildcard 字段类型从7.9版本开始引入使用，其目的主要是想优化提升模糊查询的性能。它底层同样是使用ngram分词，但它对分词进行了压缩，使得分词过后并没有占用更大的一个空间。

但是当前Elasticsearch集群是7.7.1版本，wildcard 字段类型从7.9版本才开始引入使用，显然不支持wildcard字段类型。

上述两个方案都不适合我们的搜索业务，那是否还有其它的方案呢？经过调研自身的业务，最终采用的是全文搜索multi_match和模糊搜索wildcard查询的组合。

图片来源：信息中心内部

方案时序图流程如下：

1、新增一个使用ngram分词器以商品名称作为数据源的小索引，用于用户输入关键字时做下拉联想使用，因为商品数量不大且商品名称长度不常，构建出来索引所占磁盘存储小于100MB，能支撑5000/s的QPS。

2、通过下拉联想词选择对应的商品名称进行关键字搜索，在全文检索进行分词时，可以按照数据在写入索引构建倒排索引时，分成相同的词项，提高了搜索的精度。如果用户不选择下拉联想词，则按用户输入的关键字进行分词进行全文检索。

3、针对不常见的商品，兜底方案是使用wildcard模糊查询。虽然wildcard模糊查询存在性能问题，据统计不常见的商品搜索请求量占比不到1%，对Elasticsearch集群的压力并不会产生影响。

4、针对使用multi_match全文搜索出来较多的商品，采取使用内存过滤的方式，只有包含搜索关键的内容才进行返回给用户。

将multi_match查询替换掉wildcard查询后，单次查询耗时由原来的3.3秒降至440ms，性能提升了7倍以上。

图片来源：信息中心内部

那为何multi_match查询比wildcard查询快呢？

multi_match查询是基于match查询，而match查询会对查询字符串进行分词，然后与目标字段进行匹配。它比wildcard查询快主要有以下3点优势：

1、match查询利用倒排索引来快速查询包含特定词项的文档，这种索引结构可以使得term查询非常快速。

2、match查询通过使用分析器对输入查询的关键字进行分词优化，从而提高搜索的性能和准确性。

3、match查询不需要对每个可能的词条进行匹配，与wildcard查询相比，它避免全字段扫描，提高了查询效率。

使用multi_match替换wildcard部分DSL，其它内容与上述的DSL保持一致。

{    "bool": {        "should": [            {                "multi_match": {                    "query": "感冒灵",                    "fields": [                        "goods_name^1.5"                    ],                    "type": "most_fields",                    "operator": "OR",                    "minimum_should_match": "4<90%",                    "tie_breaker": 0.3,                    "boost": 1                }            }        ]    }}

‍

通过使用multi_match和wildcard组合查询，Elasticsearch集群的CPU使用下降了300%，由原来90%下降至25%以内。

图片来源：信息中心内部

在技术方案的选择上，可以学习和借鉴他人的成功方案，但我们必须清醒地意识到每个企业的业务模式和资源配置都是独一无二的，需要根据自身的业务特点和实际情况，审慎地选择和定制技术方案。