微服务分布式搜索引擎 ElasticSearch 查询文档

浅浅的花香味﹌ 2024-05-01 04:46 61阅读 0赞

#### 文章目录 ####

*  ⛄引言
 *  一、DSL查询文档
 *   *  ⛅DSL 查询分类
 *  二、DSL查询实例
 *   *  ⛅全文检索查询
     *  ⏰精确查询
     *  ⚡地理坐标查询
     *  ⌚复合查询
 *  ⛵小结

## ⛄引言 ##

**本文参考黑马 分布式Elastic search**  
Elasticsearch是一款非常强大的开源搜索引擎，具备非常多强大功能，可以帮助我们从海量数据中快速找到需要的内容

## 一、DSL查询文档 ##

**ElasticSearch**的查询依然是基于**JSON风格的DSL**来实现的。

### ⛅DSL 查询分类 ###

Elasticsearch提供了基于JSON的DSL（[Domain Specific Language][]）来定义查询。常见的查询类型包括：

*  **查询所有**：查询出所有数据，一般测试用。例如：match\_all
 *  **全文检索（full text）查询**：利用分词器对用户输入内容分词，然后去倒排索引库中匹配。例如：
    
     *  match\_query
     *  multi\_match\_query
 *  **精确查询**：根据精确词条值查找数据，一般是查找keyword、数值、日期、boolean等类型字段。例如：
    
     *  ids
     *  range
     *  term
 *  **地理（geo）查询**：根据经纬度查询。例如：
    
     *  geo\_distance
     *  geo\_bounding\_box
 *  **复合（compound）查询**：复合查询可以将上述各种查询条件组合起来，合并查询条件。例如：
    
     *  bool
     *  function\_score

查询的语法基本一致：

GET /indexName/_search
    {
        
      "query": {
        
        "查询类型": {
        
          "查询条件": "条件值"
        }
      }
    }

我们以查询所有为例，其中：

*  查询类型为match\_all
 *  没有查询条件

// 查询所有
    GET /indexName/_search
    {
        
      "query": {
        
        "match_all": {
        
        }
      }
    }

其它查询无非就是**查询类型**、**查询条件**的变化。

## 二、DSL查询实例 ##

### ⛅全文检索查询 ###

全文检索查询的基本流程如下：

*  对用户搜索的内容做分词，得到词条
 *  根据词条去倒排索引库中匹配，得到文档id
 *  根据文档id找到文档，返回给用户

比较常用的场景包括：

*  商城的输入框搜索
 *  百度输入框搜索

**例如京东**

![在这里插入图片描述][d8538e9c11274711b5940c677a5a3301.png_pic_center]

因为是拿着词条去匹配，因此参与搜索的字段也必须是可分词的text类型的字段。

**基本语法**

常见的全文检索查询包括：

*  match查询：单字段查询
 *  multi\_match查询：多字段查询，任意一个字段符合条件就算符合查询条件

match查询语法如下：

GET /indexName/_search
    {
        
      "query": {
        
        "match": {
        
          "FIELD": "TEXT"
        }
      }
    }

mulit\_match语法如下：

GET /indexName/_search
    {
        
      "query": {
        
        "multi_match": {
        
          "query": "TEXT",
          "fields": ["FIELD1", " FIELD12"]
        }
      }
    }

**match查询实例**

![在这里插入图片描述][b393ac2f0e8842c2b1657a700ca9f13c.png_pic_center]

**mulit\_match查询实例**

![在这里插入图片描述][ff7f056a5f844a58973ac91c93a6ab35.png_pic_center]

可以看到，两种查询结果是一样的，为什么？

因为我们将brand、name、business值都利用copy\_to复制到了all字段中。因此你根据三个字段搜索，和根据all字段搜索效果当然一样了。

但是，搜索字段越多，对查询性能影响越大，因此建议采用copy\_to，然后单字段查询的方式。

match和multi\_match的区别

*  match：根据一个字段查询
 *  multi\_match：根据多个字段查询，参与查询字段越多，查询性能越差

### ⏰精确查询 ###

精确查询一般是查找keyword、数值、日期、boolean等类型字段。所以**不会**对搜索条件分词。常见的有：

*  term：根据词条精确值查询
 *  range：根据值的范围查询

term查询语法

// term查询
    GET /indexName/_search
    {
        
      "query": {
        
        "term": {
        
          "FIELD": {
        
            "value": "VALUE"
          }
        }
      }
    }

**term查询实例**

当我搜索的是精确词条时，能正确查询出结果：

![在这里插入图片描述][3ada1ff2891f494e9057e8785b9af004.png_pic_center]

但是，当我搜索的内容不是词条，而是多个词语形成的短语时，反而搜索不到：

![在这里插入图片描述][6fd140fe007544e0878d199dffe27f89.png_pic_center]

range查询 语法

// range查询
    GET /indexName/_search
    {
        
      "query": {
        
        "range": {
        
          "FIELD": {
        
            "gte": 10, // 这里的gte代表大于等于，gt则代表大于
            "lte": 20 // lte代表小于等于，lt则代表小于
          }
        }
      }
    }

**range实例**

![在这里插入图片描述][7d6fb95b242f483a8109044e68fc6985.png_pic_center]

精确查询常见的有哪些呢？

*  term查询：根据词条精确匹配，一般搜索keyword类型、数值类型、布尔类型、日期类型字段
 *  range查询：根据数值范围查询，可以是数值、日期的范围

### ⚡地理坐标查询 ###

所谓的地理坐标查询，其实就是根据经纬度查询，官方文档：**https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-queries.html**

常见的使用场景包括：

*  携程：搜索我附近的酒店
 *  滴滴：搜索我附近的出租车
 *  微信：搜索我附近的人

附近的酒店：

![在这里插入图片描述][1144df786eaa4a32b13cd6d2c4c300bc.png_pic_center]

附近的车：

![在这里插入图片描述][1c1d7f0b26fc4c0a91eb95a692c3a217.jpeg_pic_center]

**矩形范围查询**

矩形范围查询，也就是geo\_bounding\_box查询，查询坐标落在某个矩形范围的所有文档：

![在这里插入图片描述][93c9c0e93d1b49e8a03dd91b7b1e2924.gif_pic_center]

查询时，需要指定矩形的**左上**、**右下**两个点的坐标，然后画出一个矩形，落在该矩形内的都是符合条件的点。

语法如下：

// geo_bounding_box查询
    GET /indexName/_search
    {
        
      "query": {
        
        "geo_bounding_box": {
        
          "FIELD": {
        
            "top_left": {
         // 左上点
              "lat": 31.1,
              "lon": 121.5
            },
            "bottom_right": {
         // 右下点
              "lat": 30.9,
              "lon": 121.7
            }
          }
        }
      }
    }

这种并不符合“附近的人”这样的需求。

**附近查询**

附近查询，也叫做距离查询（geo\_distance）：查询到指定中心点小于某个距离值的所有文档。

换句话来说，在地图上找一个点作为圆心，以指定距离为半径，画一个圆，落在圆内的坐标都算符合条件：

![在这里插入图片描述][ea4501f8151f47078d637ab3a70806d7.gif_pic_center]

语法说明：

// geo_distance 查询
    GET /indexName/_search
    {
        
      "query": {
        
        "geo_distance": {
        
          "distance": "15km", // 半径
          "FIELD": "31.21,121.5" // 圆心
        }
      }
    }

示例：

我们先搜索陆家嘴附近15km的酒店：

![在这里插入图片描述][78e42704498a461e81b6dc01e22d8ef9.png_pic_center]

然后把半径缩短到3公里：

![在这里插入图片描述][937290640fa24f82851675dcf7996509.png_pic_center]

**缩小到 3 公里我们看到就剩下了5个符合条件的**

### ⌚复合查询 ###

复合（compound）查询：复合查询可以将其它简单查询组合起来，实现更复杂的搜索逻辑。常见的有两种：

*  fuction score：算分函数查询，可以控制文档相关性算分，控制文档排名
 *  bool query：布尔查询，利用逻辑关系组合多个其它的查询，实现复杂搜索

**相关性算分**

当我们利用match查询时，文档结果会根据与搜索词条的关联度打分（\_score），返回结果时按照分值降序排列。

例如，我们搜索 “虹桥如家”，结果如下：

[
      {
        
        "_score" : 17.850193,
        "_source" : {
        
          "name" : "虹桥如家酒店真不错",
        }
      },
      {
        
        "_score" : 12.259849,
        "_source" : {
        
          "name" : "外滩如家酒店真不错",
        }
      },
      {
        
        "_score" : 11.91091,
        "_source" : {
        
          "name" : "迪士尼如家酒店真不错",
        }
      }
    ]

在ElasticSearch中，早期使用的打分算法是TF-IDF算法，公式如下：

![在这里插入图片描述][03640aed41564d9b9942e6a9a8a56105.png_pic_center]

在后来的5.1版本升级中，ElasticSearch将算法改进为BM25算法，公式如下：

![在这里插入图片描述][0c0690a794f648c89ab7b314490ecb3c.png_pic_center]

TF-IDF算法有一各缺陷，就是词条频率越高，文档得分也会越高，单个词条对文档影响较大。而BM25则会让单个词条的算分有一个上限，曲线更加平滑：

![在这里插入图片描述][803be9dc09bf42af8f38822c3f4276b6.png_pic_center]

ElasticSearch会根据词条和文档的相关度做打分，算法由两种：

*  TF-IDF算法
 *  BM25算法，ElasticSearch5.1版本后采用的算法

**算分函数查询**

根据相关度打分是比较合理的需求，但**合理的不一定是产品经理需要**的。

以百度为例，你搜索的结果中，并不是相关度越高排名越靠前，而是谁掏的钱多排名就越靠前。如图：

![在这里插入图片描述][3b144b8da75747b6ad3da3ca5b0e3dc2.png_pic_center]

要想认为控制相关性算分，就需要利用ElasticSearch中的 Function Score 查询了。

**语法说明**

![在这里插入图片描述][ee0aadd4414f4febbd233f2237b080b3.png_pic_center]

Function Score 查询中包含四部分内容：

*  **原始查询**条件：query部分，基于这个条件搜索文档，并且基于BM25算法给文档打分，**原始算分**（query score)
 *  **过滤条件**：filter部分，符合该条件的文档才会重新算分
 *  **算分函数**：符合filter条件的文档要根据这个函数做运算，得到的**函数算分**（function score），有四种函数
    
     *  weight：函数结果是常量
     *  field\_value\_factor：以文档中的某个字段值作为函数结果
     *  random\_score：以随机数作为函数结果
     *  script\_score：自定义算分函数算法
 *  **运算模式**：算分函数的结果、原始查询的相关性算分，两者之间的运算方式，包括：
    
     *  multiply：相乘
     *  replace：用function score替换query score
     *  其它，例如：sum、avg、max、min

function score的运行流程如下：

*  1）根据**原始条件**查询搜索文档，并且计算相关性算分，称为**原始算分**（query score）
 *  2）根据**过滤条件**，过滤文档
 *  3）符合**过滤条件**的文档，基于**算分函数**运算，得到**函数算分**（function score）
 *  4）将**原始算分**（query score）和**函数算分**（function score）基于**运算模式**做运算，得到最终结果，作为相关性算分。

因此，其中的关键点是：

*  过滤条件：决定哪些文档的算分被修改
 *  算分函数：决定函数算分的算法
 *  运算模式：决定最终算分结果

**实例**

需求：给“如家”这个品牌的酒店排名靠前一些

翻译一下这个需求，转换为之前说的四个要点：

*  原始条件：不确定，可以任意变化
 *  过滤条件：brand = “如家”
 *  算分函数：可以简单粗暴，直接给固定的算分结果，weight
 *  运算模式：比如求和

因此最终的DSL语句如下：

GET /hotel/_search
    {
        
      "query": {
        
        "function_score": {
        
          "query": {
          .... }, // 原始查询，可以是任意条件
          "functions": [ // 算分函数
            {
        
              "filter": {
         // 满足的条件，品牌必须是如家
                "term": {
        
                  "brand": "如家"
                }
              },
              "weight": 2 // 算分权重为2
            }
          ],
          "boost_mode": "sum" // 加权模式，求和
        }
      }
    }

测试，在未添加算分函数时，如家得分如下：

![在这里插入图片描述][0d3c4ffd990c43f0a68e57f9456e99f6.png_pic_center]

添加了算分函数后，如家得分就提升了：

![在这里插入图片描述][9a7827b958274c1b97f31c77e3c992a4.png_pic_center]

**Function Score Query定义的三要素是什么？**

*  过滤条件：哪些文档要加分
 *  算分函数：如何计算Function Score
 *  加权方式：Function Score 与 Query Score如何运算

**布尔查询**

布尔查询是一个或多个查询子句的组合，每一个子句就是一个**子查询**。子查询的组合方式有：

*  must：必须匹配每个子查询，类似“与”
 *  should：选择性匹配子查询，类似“或”
 *  must\_not：必须不匹配，**不参与算分**，类似“非”
 *  filter：必须匹配，**不参与算分**

比如在搜索酒店时，除了关键字搜索外，我们还可能根据品牌、价格、城市等字段做过滤：

![在这里插入图片描述][1d1520b326e14f9fbba5d4f0db04bba5.png_pic_center]

每一个不同的字段，其查询的条件、方式都不一样，必须是多个不同的查询，而要组合这些查询，就必须用bool查询了。

需要注意的是，搜索时，参与**打分的字段越多，查询的性能也越差**。因此这种多条件查询时，建议这样做：

*  搜索框的关键字搜索，是全文检索查询，使用must查询，参与算分
 *  其它过滤条件，采用filter查询。不参与算分

**语法实例**

GET /hotel/_search
    {
        
      "query": {
        
        "bool": {
        
          "must": [
            {
        "term": {
        "city": "上海" }}
          ],
          "should": [
            {
        "term": {
        "brand": "皇冠假日" }},
            {
        "term": {
        "brand": "华美达" }}
          ],
          "must_not": [
            {
         "range": {
         "price": {
         "lte": 500 } }}
          ],
          "filter": [
            {
         "range": {
        "score": {
         "gte": 45 } }}
          ]
        }
      }
    }

**实例**

需求：搜索名字包含“如家”，价格不高于400，在坐标31.21,121.5周围10km范围内的酒店。

分析：

*  名称搜索，属于全文检索查询，应该参与算分。放到must中
 *  价格不高于400，用range查询，属于过滤条件，不参与算分。放到must\_not中
 *  周围10km范围内，用geo\_distance查询，属于过滤条件，不参与算分。放到filter中

![在这里插入图片描述][40cdb0fa6d184069b4839d8917e72ece.png_pic_center]

**bool查询有几种逻辑关系？**

*  must：必须匹配的条件，可以理解为“与”
 *  should：选择性匹配的条件，可以理解为“或”
 *  must\_not：必须不匹配的条件，不参与打分
 *  filter：必须匹配的条件，不参与打分

## ⛵小结 ##

以上就是【**Bug 终结者**】对 **微服务分布式搜索引擎 Elastic Search RestClient 操作文档** 的简单介绍，**ES搜索引擎无疑是最优秀的分布式搜索引擎，使用它，可大大提高项目的灵活、高效性！** **`技术改变世界！！！`**

> 如果这篇【文章】有帮助到你，希望可以给【**Bug 终结者**】点个赞?，创作不易，如果有对【**后端技术**】、【**前端领域**】感兴趣的小可爱，也欢迎关注❤️❤️❤️ 【**Bug 终结者**】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】???！

[Domain Specific Language]: https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html
[d8538e9c11274711b5940c677a5a3301.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/798c1436e1504922856b26bcf1469f95.png
[b393ac2f0e8842c2b1657a700ca9f13c.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/9b077dcd6dd84b76b5bd13b223e86318.png
[ff7f056a5f844a58973ac91c93a6ab35.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/c956fed2b33241fc9298f1c4445bb451.png
[3ada1ff2891f494e9057e8785b9af004.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/8030d0e0e081443eb79c97433b9a0323.png
[6fd140fe007544e0878d199dffe27f89.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/610c612ee2254a87a21b080f4db7a6b5.png
[7d6fb95b242f483a8109044e68fc6985.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/72b071f9315345a38293eb6d01c89a99.png
[1144df786eaa4a32b13cd6d2c4c300bc.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/014626fc742b448cbd9a928816ba6b77.png
[1c1d7f0b26fc4c0a91eb95a692c3a217.jpeg_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/44082e26212449328e35bba7cc579e17.jpeg
[93c9c0e93d1b49e8a03dd91b7b1e2924.gif_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/12159ecc42174ecca9889033a66ba8a6.gif
[ea4501f8151f47078d637ab3a70806d7.gif_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/6566044f2f414cccb8b1a5ccb9b5fc3c.gif
[78e42704498a461e81b6dc01e22d8ef9.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/427a432e8eae40a89c274f74d90caee6.png
[937290640fa24f82851675dcf7996509.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/5bb341b1c7bc4892a678f328ec92dd44.png
[03640aed41564d9b9942e6a9a8a56105.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/f2b66f880b0946b19e368b355dc4fd49.png
[0c0690a794f648c89ab7b314490ecb3c.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/ed7982590be74430b6096a6786d12397.png
[803be9dc09bf42af8f38822c3f4276b6.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/1d59149b283b4d57962f0d14a130a879.png
[3b144b8da75747b6ad3da3ca5b0e3dc2.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/9c83b69ffab248b1b83186b0154a83ae.png
[ee0aadd4414f4febbd233f2237b080b3.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/d8b1c715cc714d70a2d08d9bab347092.png
[0d3c4ffd990c43f0a68e57f9456e99f6.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/c7f414843ca841bc962a2da85dc64c31.png
[9a7827b958274c1b97f31c77e3c992a4.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/ae35a6fe6ee04234b1e52d36f446f4bb.png
[1d1520b326e14f9fbba5d4f0db04bba5.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/8f7f68607a0841a5a3a4527269bfe8fb.png
[40cdb0fa6d184069b4839d8917e72ece.png_pic_center]: https://image.dandelioncloud.cn/pgy_files/images/2024/05/01/f2982d570ba34503b3738d7ff7f7f776.png