es 的match query底层原理

博客介绍了match query底层会自动转换为term+should/must方式,并进行实例剖析,包括普通match转换为term+should、operator:and转换为term+must以及minimum_should_match的转换。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1、知识点:match query底层会自动转换为term+should/must方式

2、实例剖析

(1)普通match如何转换为term+should

{
  "match" : {"title" : "java elasticsearch"}
}

ES会自动给我们转换为如下

{
  "bool" : {
    "should" : [
        {"term" : {"title" : "java"}},
        {"term" : {"title" : "elasticsearch"}}
    ]
  }
}

(2)operator:and如何转换为term+must

{
  "match" : {
    "title" : {
       "query" : "java elasticsearch",
       "operator" : and
    }
  }
}
{
  "bool" : {
    "must" : [
       { "term": { "title": "java" }},
       { "term": { "title": "elasticsearch"   }}
    ]
  }
}

(3)minimum_should_match如何转换

{
  "match" : {
    "title" : {
      "query" : "java elasticsearch hadoop spark",
      "minimum_should_match" : "75%"
    }
  }
}
{
  "bool" : {
    "should" : [
      {"term" : {"title" : "java"}},
      {"term" : {"title" : "elasticsearch"}},
      {"term" : {"title" : "hadoop"}},
      {"term" : {"title" : "spark"}}
    ],
    "minimum_should_match" : 3
  }
}



转自于:https://www.jianshu.com/p/3c4f98bffb34

转载于:https://www.cnblogs.com/parent-absent-son/p/11065276.html

<think>嗯,用户想比较Elasticsearch中like查询和match查询的性能。首先,我需要回忆一下这两种查询的区别。 记得like查询属于模糊查询的一种,底层用的是Wildcard Query,也就是通配符查询。这种查询在处理时可能需要扫描大量的倒排索引,特别是当通配符在开头的时候,比如“*abc”,这样会导致性能问题,因为无法有效利用索引结构[^1]。而match查询则是基于分词后的词项进行精确匹配,可以利用倒排索引的高效检索,尤其是在有合适分析器和分词策略的情况下,性能通常会更好[^2]。 用户可能在使用like查询时遇到了性能问题,所以想了解是否有更优的替代方案。需要详细解释两者的工作原理,以及为什么性能会有差异。比如,Wildcard Query需要遍历所有可能的词项,而match查询直接查找分词后的结果,减少了不必要的扫描。 另外,用户可能想知道具体的优化建议。例如,避免在like查询中使用前导通配符,或者改用match_phrase_prefix来实现前缀匹配,这样可以利用索引的优势。同时,索引设计也很重要,比如使用ngram分词器来优化部分匹配场景。 还要考虑实际应用中的测试方法,建议用户在自己的数据集上进行基准测试,因为数据量和结构的不同会影响查询性能。此外,引用相关的文档或最佳实践来支持这些建议,比如Elasticsearch官方对通配符查询的警告,以及推荐使用match查询的情况[^1]。 最后,确保回答结构清晰,分点说明差异、性能影响和优化建议,帮助用户全面理解问题,并提供可行的解决方案。</think>关于Elasticsearch中`like`查询(通配符查询)和`match`查询的性能对比,以下是关键分析: --- ### 一、查询类型与底层实现差异 1. **`like`查询(通配符查询)** - 属于`wildcard`查询,支持`*`和`?`通配符,例如`"query": "elast*"` - **性能瓶颈**:需要遍历倒排索引中的词项列表,尤其是`*`出现在词项开头时(如`*search`)会触发全索引扫描,时间复杂度为$O(n)$ - **资源消耗**:高内存占用(需缓存候选词项)+ 高CPU计算(正则匹配) 2. **`match`查询** - 基于分词后的词项进行精确匹配,例如`"query": "elasticsearch"`会被拆分为词项列表 - **性能优势**:直接利用倒排索引的哈希表定位词项,时间复杂度接近$O(1)$ - **优化机制**:支持分词策略(如`standard`/`keyword`)、相关性评分优化 --- ### 二、性能对比指标 | 查询类型 | 响应时间 | CPU占用 | 适用场景 | |----------------|----------|---------|------------------------| | `wildcard` | 高 | 高 | 模糊匹配、无分词字段 | | `match` | 低 | 低 | 分词后的精确/近似匹配 | --- ### 三、优化建议 1. **避免`wildcard`查询的滥用** - 禁止前导通配符(如`*elastic`),改用`match_phrase_prefix`实现前缀匹配 - 对固定模式查询使用`keyword`类型字段+`edge_ngram`分词器 2. **`match`查询增强** - 结合`fuzziness`参数实现模糊匹配(如拼写纠错) - 使用`synonyms`同义词词典扩展匹配范围 3. **索引设计优化** - 对需要模糊查询的字段单独设置`fields`多字段类型 - 采用`index_prefixes`参数预生成前缀词项(Elasticsearch 7.0+) --- ### 四、验证方法 建议通过`_profile`API进行查询执行分析: ```json POST /index/_search { "profile": true, "query": { "wildcard": { "field": "*search" } } } ``` 观察返回结果中的`time_in_nanos`和`breakdown`字段,对比两种查询的实际执行耗时。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值