一文带你彻底搞懂Elasticsearch中的模糊查询

最新推荐文章于 2024-08-02 16:51:25 发布

Eternally1024

最新推荐文章于 2024-08-02 16:51:25 发布

阅读量2.3k

点赞数 1

分类专栏： ES 文章标签： elasticsearch

原文链接：https://cloud.tencent.com/developer/article/1797423

版权

ES 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

写在前面

Elasticsearch（以下简称ES）中的模糊查询官方是建议慎用的，因为的它的性能不是特别好。不过这个性能不好是相对ES自身的其它查询（term，match）而言的，如果跟其它的搜索工具相比ES的模糊查询性能还是不错的。

ES都多种方法可以支持模糊查询，比如wildcard，query_string等，这篇文章可能是全网最全的关于模糊查询的技术博客（哈哈）。

可以支持模糊查询的方案

wildcard

wildcard的用法是这样的，

GET kibana_sample_data_flights/_search
{
  "query": {
    "wildcard": {
      "OriginCityName": {
        "value": "Frankfurt*"
      }
    }
  }
}

*或者?也可以放在前面，但是不建议这么做，最好是前缀开始避免太大的性能消耗。查询的字段可以是text类型也可以是keyword类型，两种都支持。

大小写的话默认情况下，是根据字段本身是否对大小写敏感决定的。什么意思呢？比如上面那个查询，OriginCityName字段是keyword类型，我们知道keyword是要求精确匹配，自然就是大小写敏感的。所以如果用下面的这个查询，结果是不一样的：

GET kibana_sample_data_flights/_search
{
  "query": {
    "wildcard": {
      "OriginCityName": {
        "value": "frankfurt*"
      }
    }
  }
}

如果查询的字段是text类型，wildcard模糊查询的时候就是大小写不敏感的。

前面说过，模糊查询的性能都不高，wildcard也不例外。不过在ES7.9中引入了一种新的wildcard 字段类型，该字段类型经过优化，可在字符串值中快速查找模式。

PUT my-index
{
  "mappings": {
    "properties": {
      "my_wildcard": {
        "type": "wildcard"
      }
    }
  }
}

在引入这个字段类型之前，wildcard要么是在text类型字段查找，要么是keyword类型。而wildcard类型做了特殊的处理，如果某个字段指定了wildcard类型，

与 text 字段不同，它不会将字符串视为由标点符号分隔的单词的集合。
与 keyword 字段不同，它可以快速地搜索许多唯一值，并且没有大小限制。

wildcard字段类型通过两种优化的数据结构提高模糊查询的性能，一种使用n-gram分词器，这个分词器不打算在这里详细讲，只需要知道它会把单词在继续细分存储就行，比如，

POST _analyze
{
  "tokenizer": "ngram",
  "text": "Quick Fox"
}

输出的是，

[ Q, Qu, u, ui, i, ic, c, ck, k, "k ", " ", " F", F, Fo, o, ox, x ]

相当于把可能用于模糊查询的词项都提前拆分好存储了，这样就减少了查询阶段需要比较的词项。

第二种数据结构是binary doc value，可以自动查询验证由 n-gram 语法匹配产生的匹配候选，关于它的具体介绍可以参考下面这篇文章：

https://www.amazingkoala.com.cn/Lucene/DocValues/2019/0412/49.html

fuzzy

fuzzy也是一种模糊查询，我理解它其实属于比较轻量级别的模糊查询。fuzzy中有个编辑距离的概念，编辑距离是对两个字符串差异长度的量化，及一个字符至少需要处理多少次才能变成另一个字符，比如lucene和lucece只差了一个字符他们的编辑距离是1。

因为可以限制编辑距离，它的性能相对会好一些，毕竟它不是完全的“模糊”。

这样说可能有点抽象，看个例子，

先写入一些测试数据，

POST /my_index/_bulk
{ "index": { "_id": 1 }}
{ "text": "Surprise me!"}
{ "index": { "_id": 2 }}
{ "text": "That was surprising."}
{ "index": { "_id": 3 }}
{ "text": "I wasn't surprised."}

然后我们可以这样查询，

GET /my_index/_search
{
  "query": {
    "fuzzy": {
      "text": "surprize"
    }
  }
}

查询结果是文档1和文档3会被查询出来，surprise 比较 surprise 和 surprised 都在编辑距离 2 以内。为什么默认值2呢，其实fuzzy有个fuzziness参数，可以赋值为0，1，2和AUTO，默认其实是AUTO。

AUTO的意思是，根据查询的字符串长度决定允许的编辑距离，规则是：

0..2 完全匹配（就是不允许模糊）
3..5 编辑距离是1
大于5 编辑距离是2

其实我们仔细想一下，即使限制了编辑距离，查询的字符串比较长的情况下需要查询的词项也是非常巨大的。所以fuzzy还有一个选项是prefix_length，表示不能被 “模糊化” 的初始字符数，通过限制前缀的字符数量可以显著降低匹配的词项数量。

query string

query string query是ES的一种高级搜索，它支持复杂的搜索方式比如操作符，可以用类似

"query": "this AND that"

这样的组合操作语法。

query string支持wildcard，并且查询的字段名和查询字符串都可以使用wildcard，比如：

GET /_search
{
  "query": {
    "query_string" : {
      "fields" : ["city.*"],
      "query" : "this AND that OR thus"
    }
  }
}

GET /_search
{
  "query": {
    "query_string" : {
      "query" : "city.\\*:(this AND that OR thus)"
    }
  }
}

所以query string对模糊搜索的支持本质上还是wildcard。

prefix 前缀查询

这种只支持前缀查询，属于模糊查询的子集。比如要查找所有以 W1 开始的邮编，可以使用简单的 prefix 查询。

GET /my_index/_search
{
    "query": {
        "prefix": {
            "postcode": "W1"
        }
    }
}

prefix的工作原理这里也简单说下。我们知道文档在写入ES时会建立倒排索引，倒排索引都会将包含词的文档 ID 列入倒排表（postings list），下面是一个示例：

Term	Doc IDs
"SW5 0BE"	5
"W1F 7HW"	3
"W1V 3DG"	1
"W2F 8HW"	2
"WC1N 1LZ"	4

查询的步骤是：

扫描postings list并查找到第一个以 W1 开始的词。
搜集关联的文档 ID 。
移动到下一个词。如果这个词也是以 W1 开头，查询跳回到第二步再重复执行，直到下一个词不以 W1 为止。

可以看到，如果倒排表比较大，满足前缀的词项比较多的情况下，查询的代价也是非常大的。不过对于前缀查询ES提供了一种名叫index_prefixes的机制来提高查询性能。

原理也比较简单，就是字段在mapping中指定index_prefixes，然后ES在索引的时候就会把指定范围的前缀都先存起来，这样查询的时候需要比较的次数就会大大降低。

PUT my-index-000001
{
  "mappings": {
    "properties": {
      "body_text": {
        "type": "text",
        "index_prefixes": { }    
      }
    }
  }
}

regexp正则表达式模糊查询

regexp对模糊查询的支持更智能，它能支持更为复杂的匹配模式。比如下面这个示例

GET /my_index/_search
{
    "query": {
        "regexp": {
            "postcode": "W[0-9].+" 
        }
    }
}

这个正则表达式要求词必须以 W 开头，紧跟 0 至 9 之间的任何一个数字，然后接一或多个其他字符。

regexp 查询的工作方式与 prefix 查询基本是一样的，需要扫描倒排索引中的词列表才能找到所有匹配的词，然后依次获取每个词相关的文档 ID。

参考:

https://www.elastic.co/guide/en/elasticsearch/reference/7.11/index.html
https://www.elastic.co/cn/blog/find-strings-within-strings-faster-with-the-new-elasticsearch-wildcard-field

注：以上内容来源于一文带你彻底搞懂Elasticsearch中的模糊查询 - 云+社区 - 腾讯云

Eternally1024

关注

1
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
一文带你彻底搞懂Elasticsearch中的模糊查询

写在前面Elasticsearch（以下简称ES）中的模糊查询官方是建议慎用的，因为的它的性能不是特别好。不过这个性能不好是相对ES自身的其它查询（term，match）而言的，如果跟其它的搜索工具相比ES的模糊查询性能还是不错的。ES都多种方法可以支持模糊查询，比如wildcard，query_string等，这篇文章可能是全网最全的关于模糊查询的技术博客（哈哈）。可以支持模糊查询的方案wildcardwildcard的用法是这样的，GET kibana_sample_data_
复制链接

扫一扫

专栏目录