Springcloud中间件-----分布式搜索引擎 Elasticsearch

该笔记是根据黑马程序员的课来自己写了一遍的,b站有对应教程和资料
第一部分
第二部分
第三部分

预计看完跟着练习5小时足够

1.初识elasticsearch

1.1.了解ES

1.1.1.elasticsearch的作用

elasticsearch是一款非常强大的开源搜索引擎，具备非常多强大功能，可以帮助我们从海量数据中快速找到需要的内容

例如：

• 在GitHub搜索代码

  外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

• 在电商网站搜索商品

  

• 在百度搜索答案

• 在打车软件搜索附近的车

都是搜索引擎的使用场景

1.1.2.ELK技术栈

elasticsearch结合kibana、Logstash、Beats，也就是elastic stack（ELK）。拥有专门的web页面,被广泛应用在日志数据分析、实时监控等领域：

而elasticsearch是elastic stack的核心，负责存储、搜索、分析数据。

1.1.3.elasticsearch和lucene

elasticsearch底层是基于lucene来实现的。

Lucene是一个Java语言的搜索引擎类库，是Apache公司的顶级项目，由DougCutting于1999年研发。官网地址：https://lucene.apache.org/ 。

elasticsearch的发展历史：

• 2004年Shay Banon基于Lucene开发了Compass
• 2010年Shay Banon 重写了Compass，取名为Elasticsearch。

1.1.4.为什么不是其他搜索技术？

目前比较知名的搜索引擎技术排名：

虽然在早期，Apache Solr是最主要的搜索引擎技术，但随着发展elasticsearch已经渐渐超越了Solr，独占鳌头：

1.1.5.总结

什么是elasticsearch？

• 一个开源的分布式搜索引擎，可以用来实现搜索、日志统计、分析、系统监控等功能

什么是elastic stack（ELK）？

• 是以elasticsearch为核心的技术栈，包括beats、Logstash、kibana、elasticsearch

什么是Lucene？

• 是Apache的开源搜索引擎类库，提供了搜索引擎的核心API

1.2.倒排索引

倒排索引的概念是基于MySQL这样的正向索引而言的。

1.2.1.正向索引

那么什么是正向索引呢？例如给下表（tb_goods）中的id创建索引：

如果是根据id查询，那么直接走索引，查询速度非常快。

但如果是基于title做模糊查询，只能是逐行扫描数据，流程如下：

1）用户搜索数据，条件是title符合"%手机%"

2）逐行获取数据，比如id为1的数据

3）判断数据中的title是否符合用户搜索条件

4）如果符合则放入结果集，不符合则丢弃。回到步骤1

逐行扫描，也就是全表扫描，随着数据量增加，其查询效率也会越来越低。当数据量达到数百万时，就是一场灾难,查找服务消耗的事件不可想象

1.2.2.倒排索引

倒排索引中有两个非常重要的概念：

• 文档（Document）：用来搜索的数据，其中的每一条数据就是一个文档。例如一个网页、一个商品信息
• 词条（Term）：对文档数据或用户搜索数据，利用某种算法分词，得到的具备含义的词语就是词条。例如：我是中国人，就可以分为：我、是、中国人、中国、国人这样的几个词条

创建倒排索引是对正向索引的一种特殊处理，流程如下：

• 将每一个文档的数据利用算法分词，得到一个个词条
• 创建表，每行数据包括词条、词条所在文档id、位置等信息
• 因为词条唯一性，可以给词条创建索引，例如hash表结构索引

如图：

倒排索引的搜索流程如下（以搜索"华为手机"为例）：

1）用户输入条件"华为手机"进行搜索。

2）对用户输入内容分词，得到词条：华为、手机。

3）拿着词条在倒排索引中查找，可以得到包含词条的文档id：1、2、3。

4）拿着文档id到正向索引中查找具体文档。

如图：

虽然要先查询倒排索引，再查询倒排索引，但是无论是词条、还是文档id都建立了索引，查询速度非常快！无需全表扫描。而向mysql的条件查找就会消耗过多的资源

1.2.3.正向和倒排

那么为什么一个叫做正向索引，一个叫做倒排索引呢？

• 正向索引是最传统的，根据id索引的方式。但根据词条查询时，必须先逐条获取每个文档，然后判断文档中是否包含所需要的词条，是根据文档找词条的过程。

• 而倒排索引则相反，是先找到用户要搜索的词条，根据词条得到保护词条的文档的id，然后根据id获取文档。是根据词条找文档的过程。

大部分的搜索引擎都采用倒排索引,先进行分词查询,在查找文档

那么两者方式的优缺点是什么呢？

正向索引：

• 优点：
  • 可以给多个字段创建索引
  • 根据索引字段搜索、排序速度非常快
• 缺点：
  • 根据非索引字段，或者索引字段中的部分词条查找时，只能全表扫描。

倒排索引：

• 优点：
  • 根据词条搜索、模糊搜索时，速度非常快
• 缺点：
  • 只能给词条创建索引，而不是字段
  • 无法根据字段做排序

1.3.es的一些概念

elasticsearch中有很多独有的概念，与mysql中略有差别，但也有相似之处。

1.3.1.文档和字段

elasticsearch是面向**文档（Document）**存储的，可以是数据库中的一条商品数据，一个订单信息。

文档数据格式都会被序列化为json格式后存储在elasticsearch中：

而Json文档中往往包含很多的字段（Field），类似于数据库中的列。

1.3.2.索引和映射

索引（Index），就是相同类型的文档的集合。

例如：

• 所有用户文档，就可以组织在一起，称为用户的索引 类似于同一张表；
• 所有商品的文档，可以组织在一起，称为商品的索引；
• 所有订单的文档，可以组织在一起，称为订单的索引；

因此，我们可以把索引当做是数据库中的表。

数据库的表会有约束信息，用来定义表的结构、字段的名称、类型等信息。因此，索引库中就有映射（mapping），是索引中文档的字段约束信息，类似表的结构约束。

1.3.3.mysql与elasticsearch

我们统一的把mysql与elasticsearch的概念做一下对比：

是不是说，我们学习了elasticsearch就不再需要mysql了呢？

并不是如此，两者各自有自己的擅长支出：

• Mysql：擅长事务类型操作，可以确保数据的安全和一致性

• Elasticsearch：擅长海量数据的搜索、分析、计算

因此在企业中，往往是两者结合使用：

• 对安全性要求较高的写操作，使用mysql实现
• 对查询性能要求较高的搜索需求，使用elasticsearch实现
• 两者再基于某种方式，实现数据的同步，保证一致性

1.4.安装es、kibana

1.4.1.安装

我这里采用的是 uabntu 使用docker 安装

1.部署单点es

1.1.创建网络

因为我们还需要部署kibana容器，因此需要让es和kibana容器互联。这里先创建一个网络：
1.

docker network create es-net
1

1.2.拉取镜像

1. 拉取Elasticsearch镜像：

docker pull docker.elastic.co/elasticsearch/elasticsearch:7.15.0
1

上述命令将拉取官方提供的Elasticsearch 7.15.0版本的镜像。

2. 拉取Kibana镜像：

docker pull docker.elastic.co/kibana/kibana:7.15.0
1

下载成功

1.3.运行

运行docker命令，部署单点es：

docker run -d \
	--name es \
    -e "ES_JAVA_OPTS=-Xms512m -Xmx512m" \
    -e "discovery.type=single-node" \
    -v es-data:/usr/share/elasticsearch/data \
    -v es-plugins:/usr/share/elasticsearch/plugins \
    --privileged \
    --network es-net \
    -p 9200:9200 \
    -p 9300:9300 \
 docker.elastic.co/elasticsearch/elasticsearch:7.15.0

1
2
3
4
5
6
7
8
9
10
11
12

命令解释：

• -e "cluster.name=es-docker-cluster"：设置集群名称
• -e "http.host=0.0.0.0"：监听的地址，可以外网访问
• -e "ES_JAVA_OPTS=-Xms512m -Xmx512m"：内存大小
• -e "discovery.type=single-node"：单点
• -v es-data:/usr/share/elasticsearch/data：挂载逻辑卷，绑定es的数据目录
• -v es-logs:/usr/share/elasticsearch/logs：挂载逻辑卷，绑定es的日志目录
• -v es-plugins:/usr/share/elasticsearch/plugins：挂载逻辑卷，绑定es的插件目录
• --privileged：授予逻辑卷访问权
• --network es-net ：加入一个名为es-net的网络中
• -p 9200:9200：端口映射配置

在浏览器中输入：http://ip:9200 即可看到elasticsearch的响应结果：

2.部署kibana

kibana可以给我们提供一个elasticsearch的可视化界面，便于我们学习。

2.1.部署

运行docker命令，部署kibana

docker run -d \
--name kibana \
-e ELASTICSEARCH_HOSTS=http://es:9200 \
--network=es-net \
-p 5601:5601  \
docker.elastic.co/kibana/kibana:7.15.0
1
2
3
4
5
6

• --network es-net ：加入一个名为es-net的网络中，与elasticsearch在同一个网络中
• -e ELASTICSEARCH_HOSTS=http://es:9200"：设置elasticsearch的地址，因为kibana已经与elasticsearch在一个网络，因此可以用容器名直接访问elasticsearch
• -p 5601:5601：端口映射配置

kibana启动一般比较慢，需要多等待一会，可以通过命令：

docker logs -f kibana
1

查看运行日志，当查看到下面的日志，说明成功：

此时，在浏览器输入地址访问：http://ip
:5601，即可看到结果

2.2.DevTools

kibana中提供了一个DevTools界面：

这个界面中可以编写DSL来操作elasticsearch。并且对DSL语句有自动补全功能。

1.4.2.分词器

因为es创建倒排索引时,需要对文档进行分词,默认没有中文分词（默认中文字符一字一分,根本达不到分词的效果）,所以需要自己下载

1.4.2.1 链接下载形式

要在Elasticsearch中安装中文分词器，您可以使用Elasticsearch的插件管理工具进行安装。以下是安装elasticsearch-analysis-ik插件的步骤：

1.运行Elasticsearch容器。确保您已经按照之前提供的方法成功拉取并启动了Elasticsearch容器。
2.进入Elasticsearch容器的命令行界面。可以使用以下命令：

 docker exec -it elasticsearch /bin/bash
1

这将进入运行中的Elasticsearch容器的命令行。

3.安装elasticsearch-analysis-ik插件。
在运行的Elasticsearch容器命令行中，执行以下命令来安装elasticsearch-analysis-ik插件：

bin/elasticsearch-plugin install https://github.com/medcl/elasticsearch-analysis-ik/releases/download/v7.15.0/elasticsearch-analysis-ik-7.15.0.zip
1

这将下载并安装elasticsearch-analysis-ik插件。插件的版本号与Elasticsearch版本相对应。在本例中，我们使用Elasticsearch 7.15.0，因此选择了elasticsearch-analysis-ik 7.15.0版本。

4.安装完成后，退出容器命令行。
输入 exit 命令退出Elasticsearch容器的命令行。

但是国内容易下载出错

1.4.2.2 手动下载形式

所以采用手动西在分词器,解压到插件库的操作

我的es版本对应的中文分词器插件地址

https://github.com/medcl/elasticsearch-analysis-ik/releases?page=5
1

查看创建时候的插件数据卷所在目录

docker volume inspect es-plugins
1

把上传的插件移动到一个新建立的ik文件夹

mkdir ik
 mv elasticsearch-analysis-ik-7.15.0.zip ik/
 cd ik/
1
2
3

解压zip文件

 unzip elasticsearch-analysis-ik-7.15.0.zip 
 rm elasticsearch-analysis-ik-7.15.0.zip #删除不需要的解压包

1
2
3

把这个ik包移动到插件数据卷所在的目录

sudo  mv ik/ /var/lib/docker/volumes/es-plugins/_data/
1

查看确实引进来了

重启容器

docker restart es
1

查看日志

# 查看es日志
docker logs -f es
1
2

测试

IK分词器包含两种模式：

• ik_smart：最少切分

• ik_max_word：最细切分
  
  我测试按照最细切分,发现不在是一个字一个字的切分说明成功

智能切分：

俩种模式差别不大,max会按照中文词语的最小程度划分,这样所搜的精度是提升了,但是消耗资源过大,并且返回数据会变多,一般只能模式即可

• get 后跟服务名,官方的实列是查找服务 我这里测试的是分词器服务
• 发送get请求给对应服务,携带参数构成完整请求
• 比如query 就是get请求的方式 match是匹配 而我访问分词器,需要指定模式,以及文本

扩展词词典

随着互联网的发展，“造词运动”也越发的频繁。出现了很多新的词语，在原有的词汇列表中并不存在。比如：“奥力给”，“哈基咪” 等。

所以我们的词汇也需要不断的更新，IK分词器提供了扩展词汇的功能。
可以看到,对于网络用于,连分词较粗的智能分词也无法将网络用词认为是词语,只能按照字裁开

所以我们在字典中添加词语

分词器插件目录有专门的配置文件设置词语,所以我才用ubantu来演示

可以看到有专门的config文件夹

其中的xml结尾的文件就是中心配置文件,使用gedit打开文本

贴心的著名了使用方法,所以跟着他的说明,解开一个注释,并且写一个文本文件名(以dic结尾表示是字典),比如myword.dir
![在这里插入图片描述](https://img-blog.csdnimg.cn/1eb796294188422b96a98e4d52a24281.png
建立这个名字对应文本文件 这里是dic

写添加的字典词语

重启容器

docker restart es
1

只smart智能模式分词成功

max最大精细度模式分词成功

同理,还有一个可以使用常用得停止词库,有一些的,得,in,还有禁忌词语应该不参与倒排分词处理，所以哦我们要使用停止分词得插件，使用方法也和上面一样

DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties>
        <comment>IK Analyzer 扩展配置comment>
        
        <entry key="ext_dict">ext.dicentry>
         
        <entry key="ext_stopwords">stopword.dicentry>
properties>
1
2
3
4
5
6
7
8
9

1.4.3.总结

分词器的作用是什么？

• 创建倒排索引时对文档分词
• 用户搜索时，对输入的内容分词

IK分词器有几种模式？

• ik_smart：智能切分，粗粒度
• ik_max_word：最细切分，细粒度

IK分词器如何拓展词条？如何停用词条？

• 利用config目录的IkAnalyzer.cfg.xml文件添加拓展词典和停用词典
• 在词典中添加拓展词条或者停用词条

2.索引库操作

索引库就类似数据库表，mapping映射就类似表的结构。

我们要向es中存储数据，必须先创建“库”和“表”。

2.1.mapping映射属性

mapping是对索引库中文档的约束，常见的mapping属性包括：

• type：字段数据类型，常见的简单类型有：
  • 字符串：text（可分词的文本）、keyword（精确值，例如：品牌、国家、ip地址）
  • 数值：long、integer、short、byte、double、float、
  • 布尔：boolean
  • 日期：date
  • 对象：object
• index：是否创建索引，默认为true ,也就是说所有字段都要参与倒排索引搜索,一般要设置那些参加或者不参加
• analyzer：使用哪种分词器
• properties：该字段的子字段

例如下面的json文档：

{
    "age": 21,
    "weight": 52.1,
    "isMarried": false,
    "info": "程序员Java讲师",
    "email": "zy@itcast.cn",
    "score": [99.1, 99.5, 98.9],
    "name": {
        "firstName": "云",
        "lastName": "赵"
    }
}
1
2
3
4
5
6
7
8
9
10
11
12

对应的每个字段映射（mapping）：

• age：类型为 integer；参与搜索，因此需要index为true；无需分词器
• weight：类型为float；参与搜索，因此需要index为true；无需分词器
• isMarried：类型为boolean；参与搜索，因此需要index为true；无需分词器
• info：类型为字符串，需要分词，因此是text；参与搜索，因此需要index为true；分词器可以用ik_smart
• email：类型为字符串，但是不需要分词，因此是keyword；不参与搜索，因此需要index为false；无需分词器
• score：虽然是数组，但是我们只看元素的类型，类型为float；参与搜索，因此需要index为true；无需分词器
• name：类型为object，需要定义多个子属性
  • name.firstName；类型为字符串，但是不需要分词，因此是keyword；参与搜索，因此需要index为true；无需分词器
  • name.lastName；类型为字符串，但是不需要分词，因此是keyword；参与搜索，因此需要index为true；无需分词器

比如我创建一个书籍索引

PUT /books
{
  "mappings": {
    "properties": {
      "content":{
        "type": "text",
        "analyzer": "ik_smart"
      },
      "authorname":{
        "type": "keyword",
        "index": "false"
      },
      
      "credit":{
      "type": "integer",
      "index": true
      }
  
   
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

2.2.索引库的CRUD

这里我们统一使用Kibana编写DSL的方式来演示。

2.2.1.创建索引库和映射

基本语法：

• 请求方式：PUT
• 请求路径：/索引库名，可以自定义
• 请求参数：mapping映射

格式：

PUT /索引库名称
{
  "mappings": {
    "properties": {
      "字段名":{
        "type": "text",
        "analyzer": "ik_smart"
      },
      "字段名2":{
        "type": "keyword",
        "index": "false"
      },
      "字段名3":{
        "properties": {
          "子字段": {
            "type": "keyword"
          }
        }
      },
      // ...略
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

示例：

PUT /heima
{
  "mappings": {
    "properties": {
      "info":{
        "type": "text",
        "analyzer": "ik_smart"
      },
      "email":{
        "type": "keyword",
        "index": "falsae"
      },
      "name":{
        "properties": {
          "firstName": {
            "type": "keyword"
          }
        }
      },
      // ... 略
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

2.2.2.查询索引库结构

基本语法：

• 请求方式：GET

• 请求路径：/索引库名

• 请求参数：无

格式：

GET /索引库名
1

示例：

)

2.2.3.修改索引库

倒排索引结构虽然不复杂，但是一旦数据结构改变（比如改变了分词器），就需要重新创建倒排索引，这简直是灾难。因此索引库一旦创建，无法修改mapping。

虽然无法修改mapping中已有的字段，但是却允许添加新的字段到mapping中，因为不会对倒排索引产生影响。

语法说明：

PUT /索引库名/_mapping
{
  "properties": {
    "新字段名":{
      "type": "integer"
    }
  }
}
1
2
3
4
5
6
7
8

示例：

查看索引结构

修改成功

2.2.4.删除索引库

语法：

• 请求方式：DELETE

• 请求路径：/索引库名

• 请求参数：无

格式：

DELETE /索引库名
1

在kibana中测试：

2.2.5.总结

索引库操作有哪些？

• 创建索引库：PUT /索引库名
• 查询索引库：GET /索引库名
• 删除索引库：DELETE /索引库名
• 添加字段：PUT /索引库名/_mapping

3.文档操作

3.1.新增文档

语法：

POST /索引库名/_doc/文档id
{
    "字段1": "值1",
    "字段2": "值2",
    "字段3": {
        "子属性1": "值3",
        "子属性2": "值4"
    },
    // ...
}
1
2
3
4
5
6
7
8
9
10

示例：

POST /books/_doc/23
{
  "authorname":"老帅",
  "content":"我现在也太帅了"
  
}
  
1
2
3
4
5
6
7

响应：

3.2.查询文档

根据rest风格，新增是post，查询应该是get，不过查询一般都需要条件，这里我们把文档id带上。

语法：

GET /{索引库名称}/_doc/{id}
1

通过kibana查看数据：

get /books/_doc/23
1

查看结果：

source 插入时候插入得元数据
version:文档被修改过几次的版本

3.3.删除文档

删除使用DELETE请求，同样，需要根据id进行删除：

语法：

DELETE /{索引库名}/_doc/id值
1

示例：

# 根据id删除数据
DELETE /books/_doc/23
1
2

结果：

3.4.修改文档

修改有两种方式：

• 全量修改：直接覆盖原来的文档
• 增量修改：修改文档中的部分字段

3.4.1.全量修改

全量修改是覆盖原来的文档，其本质是：

• 根据指定的id删除文档
• 新增一个相同id的文档

注意：如果根据id删除时，id不存在，第二步的新增也会执行，也就从修改变成了新增操作了。

语法：
和新增文档一样的格式,只是请求方式不变
put=delete+post的方式

PUT /{索引库名}/_doc/文档id
{
    "字段1": "值1",
    "字段2": "值2",
    // ... 略
}

1
2
3
4
5
6
7

示例：

PUT /books/_doc/23
{
  "authorname":"updatedname",
  "content":"我先在是修改过的帅",
  "credit":67
  
}
1
2
3
4
5
6
7
8

3.4.2.增量修改

增量修改是只修改指定id匹配的文档中的部分字段。

语法：

POST /{索引库名}/_update/文档id
{
    "doc": {
         "字段名": "新的值",
    }
}
1
2
3
4
5
6

示例：

#修改单列
POST /books/_update/23
{
  "doc": {
  "authorname":"又又又又又被修改了"  
  } 
  
}

1
2
3
4
5
6
7
8
9

返回相应,再次查看

再次查看

3.5.总结

文档操作有哪些？

• 创建文档：POST /{索引库名}/_doc/文档id { json文档 }
• 查询文档：GET /{索引库名}/_doc/文档id
• 删除文档：DELETE /{索引库名}/_doc/文档id
• 修改文档：
  • 全量修改：PUT /{索引库名}/_doc/文档id { json文档 }
  • 增量修改：POST /{索引库名}/_update/文档id { “doc”: {字段}}

4.RestAPI

ES官方提供了各种不同语言的客户端，用来操作ES。这些客户端的本质就是组装DSL语句，通过http请求发送给ES。官方文档地址：https://www.elastic.co/guide/en/elasticsearch/client/index.html
其实就是es官方为各种编程语言写的客户端工具

其中的Java Rest Client又包括两种：

• Java Low Level Rest Client
• Java High Level Rest Client

我们学习的是Java HighLevel Rest Client客户端API

4.0.1.导入数据

导入到数据库
数据结构如下：

CREATE TABLE `tb_hotel` (
  `id` bigint(20) NOT NULL COMMENT '酒店id',
  `name` varchar(255) NOT NULL COMMENT '酒店名称；例：7天酒店',
  `address` varchar(255) NOT NULL COMMENT '酒店地址；例：航头路',
  `price` int(10) NOT NULL COMMENT '酒店价格；例：329',
  `score` int(2) NOT NULL COMMENT '酒店评分；例：45，就是4.5分',
  `brand` varchar(32) NOT NULL COMMENT '酒店品牌；例：如家',
  `city` varchar(32) NOT NULL COMMENT '所在城市；例：上海',
  `star_name` varchar(16) DEFAULT NULL COMMENT '酒店星级，从低到高分别是：1星到5星，1钻到5钻',
  `business` varchar(255) DEFAULT NULL COMMENT '商圈；例：虹桥',
  `latitude` varchar(32) NOT NULL COMMENT '纬度；例：31.2497',
  `longitude` varchar(32) NOT NULL COMMENT '经度；例：120.3925',
  `pic` varchar(255) DEFAULT NULL COMMENT '酒店图片；例:/img/1.jpg',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

4.0.3.mapping映射分析

创建索引库，最关键的是mapping映射，而mapping映射要考虑的信息包括：

• 字段名
• 字段数据类型
• 是否参与搜索
• 是否需要分词
• 如果分词，分词器是什么？

其中：

• 字段名、字段数据类型，可以参考数据表结构的名称和类型
• 是否参与搜索要分析业务来判断，例如图片地址，就无需参与搜索
• 是否分词呢要看内容，内容如果是一个整体就无需分词，反之则要分词
• 分词器，我们可以统一使用ik_max_word

来看下酒店数据的索引库结构:

PUT /hotel
{
  "mappings": {
    "properties": {
      "id": {
        "type": "keyword"
      },
      "name":{
        "type": "text",
        "analyzer": "ik_max_word",
        "copy_to": "all"
      },
      "address":{
        "type": "keyword",
        "index": false
      },
      "price":{
        "type": "integer"
      },
      "score":{
        "type": "integer"
      },
      "brand":{
        "type": "keyword",
        "copy_to": "all"
      },
      "city":{
        "type": "keyword",
        "copy_to": "all"
      },
      "starName":{
        "type": "keyword"
      },
      "business":{
        "type": "keyword"
      },
      "location":{
        "type": "geo_point"
      },
      "pic":{
        "type": "keyword",
        "index": false
      },
      "all":{
        "type": "text",
        "analyzer": "ik_max_word"
      }
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

location：是俩个数据,经纬度拼接起来

几个特殊字段说明：

• location：地理坐标，里面包含精度、纬度

• all：一个组合字段，其目的是将多字段的值 利用copy_to合并，提供给用户搜索

主要是多个查询条件搜索的时候使用,比如我想查询多个条件,名字价格,es就会使用copy to 将多个字段的条件复制到一个新字段中进行倒排索引查找,这样就变成了一个字段进行优化,all采用精确分词来提供搜索效率

4.0.4.初始化RestClient

在elasticsearch提供的API中，与elasticsearch一切交互都封装在一个名为RestHighLevelClient的类中，必须先完成这个对象的初始化，建立与elasticsearch的连接。

分为三步：

1）引入es的RestHighLevelClient依赖：

<dependency>
    <groupId>org.elasticsearch.clientgroupId>
    <artifactId>elasticsearch-rest-high-level-clientartifactId>
dependency>
1
2
3
4

2）因为SpringBoot默认的ES版本是7.6.2，所以我们需要覆盖默认的ES版本：

<properties>
    <java.version>1.8java.version>
    <elasticsearch.version>7.15.0elasticsearch.version>
properties>
1
2
3
4

3）初始化RestHighLevelClient：

初始化的代码如下：
像服务器创建客户端对象

RestHighLevelClient client = new RestHighLevelClient(RestClient.builder(
        HttpHost.create("http://192.168.249.132:9200")
));
1
2
3

这里为了单元测试方便，我们创建一个测试类HotelIndexTest，然后将初始化的代码编写在@BeforeEach方法中：

package cn.itcast.hotel;

import org.apache.http.HttpHost;
import org.elasticsearch.client.RestHighLevelClient;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import java.io.IOException;

public class HotelIndexTest {
    private RestHighLevelClient client;

    @BeforeEach
    void setUp() {
        this.client = new RestHighLevelClient(RestClient.builder(
                HttpHost.create("http://192.168.150.101:9200")
        ));
    }

    @AfterEach
    void tearDown() throws IOException {
        this.client.close();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

4.1.创建索引库

4.1.1.代码解读

创建索引库的API如下：

代码分为三步：

• 1）创建Request对象。因为是创建索引库的操作，因此Request是CreateIndexRequest。
• 2）添加请求参数，其实就是DSL的JSON参数部分。因为json字符串很长，这里是定义了静态字符串常量MAPPING_TEMPLATE，让代码看起来更加优雅。
• 3）发送请求，client.indices()方法的返回值是IndicesClient类型，封装了所有与索引库操作有关的方法。

4.1.2.完整示例

在hotel-demo的cn.itcast.hotel.constants包下，创建一个类，定义mapping映射的JSON字符串常量：

package cn.itcast.hotel.constants;

public class HotelConstants {
    public static final String MAPPING_TEMPLATE = "{\n" +
            "  \"mappings\": {\n" +
            "    \"properties\": {\n" +
            "      \"id\": {\n" +
            "        \"type\": \"keyword\"\n" +
            "      },\n" +
            "      \"name\":{\n" +
            "        \"type\": \"text\",\n" +
            "        \"analyzer\": \"ik_max_word\",\n" +
            "        \"copy_to\": \"all\"\n" +
            "      },\n" +
            "      \"address\":{\n" +
            "        \"type\": \"keyword\",\n" +
            "        \"index\": false\n" +
            "      },\n" +
            "      \"price\":{\n" +
            "        \"type\": \"integer\"\n" +
            "      },\n" +
            "      \"score\":{\n" +
            "        \"type\": \"integer\"\n" +
            "      },\n" +
            "      \"brand\":{\n" +
            "        \"type\": \"keyword\",\n" +
            "        \"copy_to\": \"all\"\n" +
            "      },\n" +
            "      \"city\":{\n" +
            "        \"type\": \"keyword\",\n" +
            "        \"copy_to\": \"all\"\n" +
            "      },\n" +
            "      \"starName\":{\n" +
            "        \"type\": \"keyword\"\n" +
            "      },\n" +
            "      \"business\":{\n" +
            "        \"type\": \"keyword\"\n" +
            "      },\n" +
            "      \"location\":{\n" +
            "        \"type\": \"geo_point\"\n" +
            "      },\n" +
            "      \"pic\":{\n" +
            "        \"type\": \"keyword\",\n" +
            "        \"index\": false\n" +
            "      },\n" +
            "      \"all\":{\n" +
            "        \"type\": \"text\",\n" +
            "        \"analyzer\": \"ik_max_word\"\n" +
            "      }\n" +
            "    }\n" +
            "  }\n" +
            "}";
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

在hotel-demo中的HotelIndexTest测试类中，编写单元测试，实现创建索引：

@Test
void createHotelIndex() throws IOException {
    // 1.创建Request对象
    CreateIndexRequest request = new CreateIndexRequest("hotel");
    // 2.准备请求的参数：DSL语句
    request.source(MAPPING_TEMPLATE, XContentType.JSON);
    // 3.发送请求
    client.indices().create(request, RequestOptions.DEFAULT);
}
1
2
3
4
5
6
7
8
9

4.2.删除索引库

删除索引库的DSL语句非常简单：

DELETE /hotel
1

与创建索引库相比：

• 请求方式从PUT变为DELTE
• 请求路径不变
• 无请求参数

所以代码的差异，注意体现在Request对象上。依然是三步走：

• 1）创建Request对象。这次是DeleteIndexRequest对象
• 2）准备参数。这里是无参
• 3）发送请求。改用delete方法

在hotel-demo中的HotelIndexTest测试类中，编写单元测试，实现删除索引：

@Test
void testDeleteHotelIndex() throws IOException {
    // 1.创建Request对象
    DeleteIndexRequest request = new DeleteIndexRequest("hotel");
    // 2.发送请求
    client.indices().delete(request, RequestOptions.DEFAULT);
}
1
2
3
4
5
6
7

4.3.判断索引库是否存在

判断索引库是否存在，本质就是查询，对应的DSL是：

GET /hotel
1

因此与删除的Java代码流程是类似的。依然是三步走：

• 1）创建Request对象。这次是GetIndexRequest对象
• 2）准备参数。这里是无参
• 3）发送请求。改用exists方法

@Test
void testExistsHotelIndex() throws IOException {
    // 1.创建Request对象
    GetIndexRequest request = new GetIndexRequest("hotel");
    // 2.发送请求
    boolean exists = client.indices().exists(request, RequestOptions.DEFAULT);
    // 3.输出
    System.err.println(exists ? "索引库已经存在！" : "索引库不存在！");
}
1
2
3
4
5
6
7
8
9

4.4.总结

JavaRestClient操作elasticsearch的流程基本类似。核心是**client.indices()**方法来获取索引库的操作对象。

索引库操作的基本步骤：

• 初始化RestHighLevelClient
• 创建XxxIndexRequest。XXX是Create、Get、Delete
• 准备DSL（ Create时需要，其它是无参）
• 发送请求。调用RestHighLevelClient#indices().xxx()方法，xxx是create、exists、delete

5.RestClient操作文档

为了与索引库操作分离，我们再次参加一个测试类，做两件事情：

• 初始化RestHighLevelClient
• 我们的酒店数据在数据库，需要利用IHotelService去查询，所以注入这个接口

package cn.itcast.hotel;

import cn.itcast.hotel.pojo.Hotel;
import cn.itcast.hotel.service.IHotelService;
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;

import java.io.IOException;
import java.util.List;

@SpringBootTest
public class HotelDocumentTest {
    @Autowired
    private IHotelService hotelService;

    private RestHighLevelClient client;

    @BeforeEach
    void setUp() {
        this.client = new RestHighLevelClient(RestClient.builder(
                HttpHost.create("http://192.168.249.132:9200")
        ));
    }

    @AfterEach
    void tearDown() throws IOException {
        this.client.close();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

5.1.新增文档

我们要将数据库的酒店数据查询出来，写入elasticsearch中。

5.1.1.索引库实体类

数据库查询后的结果是一个Hotel类型的对象。结构如下：

@Data
@TableName("tb_hotel")
public class Hotel {
    @TableId(type = IdType.INPUT)
    private Long id;
    private String name;
    private String address;
    private Integer price;
    private Integer score;
    private String brand;
    private String city;
    private String starName;
    private String business;
    private String longitude;
    private String latitude;
    private String pic;
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

与我们的索引库结构存在差异：

• longitude和latitude需要合并为location

因此，我们需要定义一个新的类型，与索引库结构吻合：

package cn.itcast.hotel.pojo;

import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
public class HotelDoc {
    private Long id;
    private String name;
    private String address;
    private Integer price;
    private Integer score;
    private String brand;
    private String city;
    private String starName;
    private String business;
    private String location;
    private String pic;

    public HotelDoc(Hotel hotel) {
        this.id = hotel.getId();
        this.name = hotel.getName();
        this.address = hotel.getAddress();
        this.price = hotel.getPrice();
        this.score = hotel.getScore();
        this.brand = hotel.getBrand();
        this.city = hotel.getCity();
        this.starName = hotel.getStarName();
        this.business = hotel.getBusiness();
        this.location = hotel.getLatitude() + ", " + hotel.getLongitude();
        this.pic = hotel.getPic();
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

5.1.2.语法说明

新增文档的DSL语句如下：

POST /{索引库名}/_doc/1
{
    "name": "Jack",
    "age": 21
}
1
2
3
4
5

对应的java代码如图：

可以看到与创建索引库类似，同样是三步走：

• 1）创建Request对象
• 2）准备请求参数，也就是DSL中的JSON文档
• 3）发送请求

变化的地方在于，这里直接使用client.xxx()的API，不再需要client.indices()了。

5.1.3.完整代码

我们导入酒店数据，基本流程一致，但是需要考虑几点变化：

• 酒店数据来自于数据库，我们需要先查询出来，得到hotel对象
• hotel对象需要转为HotelDoc对象
• HotelDoc需要序列化为json格式

因此，代码整体步骤如下：

• 1）根据id查询酒店数据Hotel
• 2）将Hotel封装为HotelDoc
• 3）将HotelDoc序列化为JSON
• 4）创建IndexRequest，指定索引库名和id
• 5）准备请求参数，也就是JSON文档
• 6）发送请求

在hotel-demo的HotelDocumentTest测试类中，编写单元测试：

@Test
void testAddDocument() throws IOException {
    // 1.根据id查询酒店数据
    Hotel hotel = hotelService.getById(61083L);
    // 2.转换为文档类型
    HotelDoc hotelDoc = new HotelDoc(hotel);
    // 3.将HotelDoc转json
    String json = JSON.toJSONString(hotelDoc);

    // 1.准备Request对象
    IndexRequest request = new IndexRequest("hotel").id(hotelDoc.getId().toString());
    // 2.准备Json文档
    request.source(json, XContentType.JSON);
    // 3.发送请求
    client.index(request, RequestOptions.DEFAULT);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

5.2.查询文档

5.2.1.语法说明

查询的DSL语句如下：

GET /hotel/_doc/{id}
1

非常简单，因此代码大概分两步：

• 准备Request对象
• 发送请求

不过查询的目的是得到结果，解析为HotelDoc，因此难点是结果的解析。完整代码如下：

可以看到，结果是一个JSON，其中文档放在一个_source属性中，因此解析就是拿到_source，反序列化为Java对象即可。

与之前类似，也是三步走：

• 1）准备Request对象。这次是查询，所以是GetRequest
• 2）发送请求，得到结果。因为是查询，这里调用client.get()方法
• 3）解析结果，就是对JSON做反序列化

5.2.2.完整代码

在hotel-demo的HotelDocumentTest测试类中，编写单元测试：

@Test
void testGetDocumentById() throws IOException {
    // 1.准备Request
    GetRequest request = new GetRequest("hotel", "61082");
    // 2.发送请求，得到响应
    GetResponse response = client.get(request, RequestOptions.DEFAULT);
    // 3.解析响应结果
    String json = response.getSourceAsString();

    HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
    System.out.println(hotelDoc);
}
1
2
3
4
5
6
7
8
9
10
11
12

测试结果

5.3.删除文档

删除的DSL为是这样的：

DELETE /hotel/_doc/{id}
1

与查询相比，仅仅是请求方式从DELETE变成GET，可以想象Java代码应该依然是三步走：

• 1）准备Request对象，因为是删除，这次是DeleteRequest对象。要指定索引库名和id
• 2）准备参数，无参
• 3）发送请求。因为是删除，所以是client.delete()方法

在hotel-demo的HotelDocumentTest测试类中，编写单元测试：

  @SneakyThrows
    @Test
    void testDeleteDocument(){
        DeleteRequest request = new DeleteRequest("hotel","61083");
        client.delete(request, RequestOptions.DEFAULT);

        System.out.println("该数据是否存在"+client.exists(new GetRequest("hotel", "61083"),RequestOptions.DEFAULT));
        System.out.println();


    }
1
2
3
4
5
6
7
8
9
10
11

5.4.修改文档

5.4.1.语法说明

修改我们讲过两种方式：

• 全量修改：本质是先根据id删除，再新增
• 增量修改：修改文档中的指定字段值

在RestClient的API中，全量修改与新增的API完全一致，判断依据是ID：

• 如果新增时，ID已经存在，则修改
• 如果新增时，ID不存在，则新增

这里不再赘述，我们主要关注增量修改。
只演示局部更新
代码示例如图：

与之前类似，也是三步走：

• 1）准备Request对象。这次是修改，所以是UpdateRequest
• 2）准备参数。也就是JSON文档，里面包含要修改的字段
• 3）更新文档。这里调用client.update()方法

5.4.2.完整代码

在hotel-demo的HotelDocumentTest测试类中，编写单元测试：

    @Test
    void testUpdateDocument() throws IOException {
        UpdateRequest request = new UpdateRequest("hotel", "61083");
        Map<String, Object> fieldmap = new HashMap<String, Object>();
        fieldmap.put("address", "自由贸易试验区临港新片区南岛133号");
        request.doc(fieldmap);
        client.update(request, RequestOptions.DEFAULT);


    }
1
2
3
4
5
6
7
8
9
10

5.5.批量导入文档

案例需求：利用批量将数据库数据导入到索引库中。

步骤如下：

• 利用mybatis-plus查询酒店数据

• 将查询到的酒店数据（Hotel）转换为文档类型数据（HotelDoc）

• 利用JavaRestClient中的BulkRequest批处理，实现批量新增文档

5.5.1.语法说明

批量处理BulkRequest，其本质就是将多个普通的CRUD请求组合在一起发送。

其中提供了一个add方法，用来添加其他请求：

可以看到，能添加的请求包括：

• IndexRequest，也就是新增
• UpdateRequest，也就是修改
• DeleteRequest，也就是删除

因此Bulk中添加了多个IndexRequest，就是批量新增功能了。示例：

其实还是三步走：

• 1）创建Request对象。这里是BulkRequest
• 2）准备参数。批处理的参数，就是其它Request对象，这里就是多个IndexRequest
• 3）发起请求。这里是批处理，调用的方法为client.bulk()方法

我们在导入酒店数据时，将上述代码改造成for循环处理即可。

5.5.2.完整代码

在hotel-demo的HotelDocumentTest测试类中，编写单元测试：

//    批量新增加
        @Test
    void testAddbenchDocument() throws IOException {
            BulkRequest bulkRequest = new BulkRequest();

            List<Hotel> list = service.list();
            list.stream().forEach(hotelItem->
                    bulkRequest.add(new IndexRequest("hotel").id(hotelItem.getId().toString())
                            .source(JSON.toJSONString(new HotelDoc(hotelItem)),XContentType.JSON))
                    );
            client.bulk(bulkRequest, RequestOptions.DEFAULT);
    }
1
2
3
4
5
6
7
8
9
10
11
12

使用countapi查看批量操作是否成功

  @Test
    void testTotalDocument() throws IOException {
        CountRequest countRequest = new CountRequest("hotel");
        CountResponse response = client.count(countRequest, RequestOptions.DEFAULT);
        System.out.println(response.getCount());
    }
1
2
3
4
5
6

运行成功

5.6.小结

文档操作的基本步骤：

• 初始化RestHighLevelClient
• 创建XxxRequest。XXX是Index、Get、Update、Delete、Bulk
• 准备参数（Index、Update、Bulk时需要）
• 发送请求。调用RestHighLevelClient#.xxx()方法，xxx是index、get、update、delete、bulk
• 解析结果（Get时需要）

分布式搜索引擎02

在昨天的学习中，我们已经导入了大量数据到elasticsearch中，实现了elasticsearch的数据存储功能。但elasticsearch最擅长的还是搜索和数据分析。

所以今天，我们研究下elasticsearch的数据搜索功能。我们会分别使用DSL和RestClient实现搜索。

0.学习目标

1.DSL查询文档

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

1.1.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": {
    "查询类型": {
      "查询条件": "条件值"
    }
  }
}
1
2
3
4
5
6
7
8

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

• 查询类型为match_all
• 没有查询条件

// 查询所有
GET /indexName/_search
{
  "query": {
    "match_all": {
    }
  }
}
1
2
3
4
5
6
7
8

查询结果,默认只显示10条数据
hits :表示查询命中事件
max_score:查询得分

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

1.2.全文检索查询

1.2.1.使用场景

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

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

比较常用的场景包括：

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

例如京东：

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

1.2.2.基本语法

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

• match查询：单字段查询
• multi_match查询：多字段查询，任意一个字段符合条件就算符合查询条件

match查询语法如下：

GET /indexName/_search
{
  "query": {
    "match": {
      "FIELD": "TEXT"
    }
  }
}
1
2
3
4
5
6
7
8

mulit_match语法如下：

GET /indexName/_search
{
  "query": {
    "multi_match": {
      "query": "TEXT",
      "fields": ["FIELD1", " FIELD12"]
    }
  }
}
1
2
3
4
5
6
7
8
9

1.2.3.示例

match查询示例：
查询索引库,创建索引的时候是创建了一个all字段,并且把city,brand,name等字段的值复制给all字段,这样进行字段匹配查找的时候,直接匹配all字段,就可以做多个字段的查询了

get /hotel/_search
{
  "query":{
    "match": {
      "all": "上海外滩"
    }
  }
}
1
2
3
4
5
6
7
8

此时all分词查询到的数据 也就是city和name的文档

• _score：表示相关度得分

multi_match查询示例：

get /hotel/_search
{
  "query":{
    "multi_match": {
      "query": "如家",
      "fields": ["brand","name", "business"]
    }
    
  }
}
1
2
3
4
5
6
7
8
9
10

多条件匹配

这样多字段的效果和建立索引时专门专门创建一个查询字段,把查询的内容copy进去,方便条件匹配的时候进行分词检索的效果是一样的,但是多字段查询对检索效率有影响,涉及到链接操作,而通过把插叙字段全部复制在一起,进行分词检索不需要条件链接,效率快一些

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

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

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

1.2.4.总结

match和multi_match的区别是什么？

• match：根据一个字段查询
• multi_match：根据多个字段查询，参与查询字段越多，查询性能越差

1.3.精准查询

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

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

1.3.1.term查询

因为精确查询的字段搜是不分词的字段，因此查询的条件也必须是不分词的词条。查询时，用户输入的内容跟自动值完全匹配时才认为符合条件。如果用户输入的内容过多，反而搜索不到数据。

语法说明：

// term查询
GET /indexName/_search
{
  "query": {
    "term": {
      "FIELD": {
        "value": "VALUE"
      }
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11

示例：

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

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

1.3.2.range查询

范围查询，一般应用在对数值类型做范围过滤的时候。比如做价格范围过滤。

基本语法：

// range查询
GET /indexName/_search
{
  "query": {
    "range": {
      "FIELD": {
        "gte": 10, // 这里的gte代表大于等于，gt则代表大于
        "lte": 20 // lte代表小于等于，lt则代表小于
      }
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12

示例：

1.3.3.总结

精确查询常见的有哪些？

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

1.4.地理坐标查询

所谓的地理坐标查询，其实就是根据经纬度查询，官方文档：

常见的使用场景包括：

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

附近的酒店：

1.4.1.矩形范围查询

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

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

语法如下：

// 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
        }
      }
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

这种并不符合“附近的人”这样的需求，所以我们就不做了。一般都是根据自身半径内多少距离来进行开发的

1.4.2.附近查询

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

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

语法说明：

// geo_distance 查询
GET /indexName/_search
{
  "query": {
    "geo_distance": {
      "distance": "15km", // 半径
      "FIELD": "31.21,121.5" // 圆心
    }
  }
}
1
2
3
4
5
6
7
8
9
10

示例：

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

发现共有47家酒店。

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

可以发现，搜索到的酒店数量减少到了13家。

1.5.复合查询

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

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

1.5.1.相关性算分

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

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

[
  {
    "_score" : 17.850193,
    "_source" : {
      "name" : "虹桥如家酒店真不错",
    }
  },
  {
    "_score" : 12.259849,
    "_source" : {
      "name" : "外滩如家酒店真不错",
    }
  },
  {
    "_score" : 11.91091,
    "_source" : {
      "name" : "迪士尼如家酒店真不错",
    }
  }
]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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

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

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

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

• TF-IDF算法
• BM25算法，elasticsearch5.1版本后采用的算法

1.5.2.算分函数查询

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

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

要想认为控制相关性算分，就需要利用elasticsearch中的function score 查询了。

1）语法说明

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）基于运算模式做运算，得到最终结果，作为相关性算分。

因此，其中的关键点是：

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

2）示例

需求：给“如家”这个品牌的酒店排名靠前一些
实际应用也可以给某些字段写名等级,得分来进行排名操作

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

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

因此最终的DSL语句如下：

GET /hotel/_search
{
  "query": {
    "function_score": {
      "query": {  .... }, // 原始查询，可以是任意条件
      "functions": [ // 算分函数
        {
          "filter": { // 满足的条件，品牌必须是如家
            "term": {
              "brand": "如家"
            }
          },
          "weight": 2 // 算分权重为2
        }
      ],
      "boost_mode": "sum" // 加权模式，求和
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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

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

同理 我这里给city字段值在"上海"的文档加分

get /hotel/_search
{
  "query":{
    "function_score": {
      "query": {
        "match": {
          "all": "外滩"
        }
      },
      "functions": [
        {
          "filter": {
            "term": {
              "city": "上海"
            
            }
            
          },
           "weight": 3
        }
      ]
      , "boost_mode": "multiply"
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

得到评分最高

3）小结

function score query定义的三要素是什么？

• 过滤条件：哪些文档要加分
• 算分函数：如何计算function score
• 加权方式：function score 与 query score如何运算

1.5.3.布尔查询

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

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

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

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

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

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

1）语法示例：

GET /hotel/_search
{
  "query": {
    "bool": {
      "must": [
        {"term": {"city": "上海" }}
      ],
      "should": [
        {"term": {"brand": "皇冠假日" }},
        {"term": {"brand": "华美达" }}
      ],
      "must_not": [
        { "range": { "price": { "lte": 500 } }}
      ],
      "filter": [
        { "range": {"score": { "gte": 45 } }}
      ]
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

要求返回的结果一定在上海,并且brand字段一定是这俩个之一,价格一定不小于500,并且必须得分在大于45的文档

2）示例

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

分析：

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

filter是不参与算分的,所以这里的算分是根据es的算法来的,所以这里再次添加一个match匹配条件

GET /hotel/_search
{
  "query": {
    "bool": {
    "must": [
          {
          "geo_distance": {
            "distance": "10km",
            "location": {
              "lat": 31.21,
              "lon": 121.5
            }
          }
        },
      {
        "match": {
          "name": "如家"
        }
      }
    ], 
      "must_not": [
        {
          "range": {
            "price": {
              "gt": 400
            }
          }
        }
      ],
      "filter": [
    
        {
          "range": {
            "score": {
              "gte": 44
            }
          }
        }
      ]
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

此时,满足俩个检索条件的文档分数更高

3）小结

bool查询有几种逻辑关系？

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

2.搜索结果处理

搜索的结果可以按照用户指定的方式去处理或展示。

2.1.排序

elasticsearch默认是根据相关度算分（_score）来排序，但是也支持自定义方式对搜索结果排序。可以排序字段类型有：keyword类型、数值类型、地理坐标类型、日期类型等,当自定义排序过后es不会在对文档进行打分。

2.1.1.普通字段排序

keyword、数值、日期类型排序的语法基本一致。

语法：

GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "FIELD": "desc"  // 排序字段、排序方式ASC、DESC
    }
  ]
}
1
2
3
4
5
6
7
8
9
10
11

排序和条件检索的等级一样的,所以json格式中的所处等级一样
排序条件是一个数组，也就是可以写多个排序条件。按照声明的顺序，当第一个条件相等时，再按照第二个条件排序，以此类推

示例：

需求描述：酒店数据按照用户评价（score)降序排序，评价相同的按照价格(price)升序排序

2.1.2.地理坐标排序

地理坐标排序略有不同。

语法说明：

GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "_geo_distance" : {
          "FIELD" : "纬度，经度", // 文档中geo_point类型的字段名、目标坐标点
          "order" : "asc", // 排序方式
          "unit" : "km" // 排序的距离单位
      }
    }
  ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

这个查询的含义是：

• 指定一个坐标，作为目标点
• 计算每一个文档中，指定字段（必须是geo_point类型）的坐标 到目标点的距离是多少
• 根据距离排序

示例：

需求描述：实现对酒店数据按照到你的位置坐标的距离升序排序

提示：获取你的位置的经纬度的方式：https://lbs.amap.com/demo/jsapi-v2/example/map/click-to-get-lnglat/

假设我的位置是：31.034661，121.612282，寻找我周围距离最近的酒店。

比如,对所有酒店进行排序,按照价格升序,评分降序的顺序检索文档

get /hotel/_search
{
  "query":{
  "match_all": {}
  },
  "sort":{
    "score":"desc",
    "price":"asc"
  }
}
1
2
3
4
5
6
7
8
9
10

2.2.分页

elasticsearch 默认情况下只返回top10的数据。而如果要查询更多数据就需要修改分页参数了。elasticsearch中通过修改from、size参数来控制要返回的分页结果：

• from：从第几个文档开始
• size：总共查询几个文档

类似于mysql中的limit ?, ?

2.2.1.基本的分页

分页的基本语法如下：

GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "from": 0, // 分页开始的位置，默认为0
  "size": 10, // 期望获取的文档总数
  "sort": [
    {"price": "asc"}
  ]
}
1
2
3
4
5
6
7
8
9
10
11

2.2.2.深度分页问题

现在，我要查询990~1000的数据，查询逻辑要这么写：

GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "from": 990, // 分页开始的位置，默认为0
  "size": 10, // 期望获取的文档总数
  "sort": [
    {"price": "asc"}
  ]
}
1
2
3
4
5
6
7
8
9
10
11

这里是查询990开始的数据，也就是 第990~第1000条 数据。

不过，elasticsearch内部分页时，因为es底层是倒排索引,只能必须先查询 0~1000条，然后截取其中的990 ~ 1000的这10条：

查询TOP1000，如果es是单点模式，这并无太大影响。

但是elasticsearch将来一定是集群，例如我集群有5个节点，我要查询TOP1000的数据，并不是每个节点查询200条就可以了。

因为节点A的TOP200，在另一个节点可能排到10000名以外了。

因此要想获取整个集群的TOP1000，必须先查询出每个节点的TOP1000，汇总结果后，重新排名，重新截取TOP1000。

那如果我要查询9900~10000的数据呢？是不是要先查询TOP10000呢？那每个节点都要查询10000条？汇总到内存中？

当查询分页深度较大时，汇总数据过多，对内存和CPU会产生非常大的压力，因此elasticsearch会禁止from+ size 超过10000的请求。

针对深度分页，ES提供了两种解决方案，官方文档：

• search after：分页时需要排序，原理是从上一次的排序值开始，查询下一页数据。官方推荐使用的方式。
• scroll：原理将排序后的文档id形成快照，保存在内存。官方已经不推荐使用。

当使用 Elasticsearch 的 search_after 参数时，按照以下步骤进行详细演示：

GET /hotel/_search
{
  "size": 10,       
  "sort": [
    { "price": "asc" }   
  ],
  "search_after": [       
    20  
  ]
}
1
2
3
4
5
6
7
8
9
10

搜索查询的含义如下：

1. “size”: 10：每页返回的文档数量，这里设置为 10。
2. “sort”: [{ “price”: “asc” }]：按价格字段升序排序。
3. “search_after”: [20]：假如上一页的最后一个文档的价格值为 20，将其用作 search_after 值来比较排序获取下一页的数据。

执行这个搜索请求后，Elasticsearch 将会返回下一页的文档数据，按照价格字段的升序排列。结果将包含最接近上一页最后一个文档的价格值大于 20 的文档。
您可以重复这个过程，提取响应结果中最后一条文档的价格值，并将其用作下一页搜索请求的 search_after 值，以获取下一页的数据。这样，您可以通过不断更新 search_after 值来获取所需的所有分页数据。

2.2.3.小结

分页查询的常见实现方案以及优缺点：

• from + size：

  • 优点：支持随机翻页
  • 缺点：深度分页问题，默认查询上限（from + size）是10000
  • 场景：百度、京东、谷歌、淘宝这样的随机翻页搜索

• after search：

  • 优点：没有查询上限（单次查询的size不超过10000）
  • 缺点：只能向后逐页查询，不支持随机翻页
  • 场景：没有随机翻页需求的搜索，例如手机向下滚动翻页

• scroll：

  • 优点：没有查询上限（单次查询的size不超过10000）
  • 缺点：会有额外内存消耗，并且搜索结果是非实时的
  • 场景：海量数据的获取和迁移。从ES7.1开始不推荐，建议用 after search方案。

2.3.高亮

2.3.1.高亮原理

什么是高亮显示呢？

我们在百度，京东搜索时，关键字会变成红色，比较醒目，这叫高亮显示：

高亮显示的实现分为两步：

• 1）给文档中的所有关键字都添加一个标签，例如标签
• 2）页面给标签编写CSS样式
• 3）然后和前端约定好这个特殊标签修改样式即可

GET /hotel/_search
{
  "query": {
    "match": {
      "FIELD": "TEXT" // 查询条件，高亮一定要使用全文检索查询 分词到哪个部分高亮
    }
  },
  "highlight": {
    "fields": { // 指定要高亮的字段
      "FIELD": {
        "pre_tags": "",  // 用来标记高亮字段的前置标签
        "post_tags": "" // 用来标记高亮字段的后置标签
      }
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

GET /hotel/_search
{
  "query": {
    "match": {
      "all": "如家"
    }
  },
  "highlight": {
    "fields": {
      "name": {
        "require_field_match": "false"
      }
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

  "highlight": {
    "fields": {
      "your_field": {}
    },
    "pre_tags": [""],   // 自定义前置标签
    "post_tags": [""]  // 自定义后置标签
  }
1
2
3
4
5
6
7

    @Test
    void testSearchDocument() throws IOException {
        SearchRequest request = new SearchRequest("hotel");
        request.source().query(QueryBuilders.matchAllQuery());
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        SearchHits hits = response.getHits();
        System.out.println("返回的查询结果:");
   Arrays.stream(hits.getHits()).forEach(hit -> System.out.println("" +hit));

    }
1
2
3
4
5
6
7
8
9
10

@Test
void testMatchAll() throws IOException {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    request.source()
        .query(QueryBuilders.matchAllQuery());
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);

    // 4.解析响应
    handleResponse(response);
}

private void handleResponse(SearchResponse response) {
    // 4.解析响应
    SearchHits searchHits = response.getHits();
    // 4.1.获取总条数
    long total = searchHits.getTotalHits().value;
    System.out.println("共搜索到" + total + "条数据");
    // 4.2.文档数组
    SearchHit[] hits = searchHits.getHits();
    // 4.3.遍历
    for (SearchHit hit : hits) {
        // 获取文档source
        String json = hit.getSourceAsString();
        // 反序列化
        HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
        System.out.println("hotelDoc = " + hotelDoc);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

    @Test
    void testSearchName() throws IOException {
//        演示用户查找的是酒店名字 ,并且实际情况是酒店名字中带有品牌名 所以一般是检索内容匹配多个字段
        String nameByuser = "如家";
        SearchRequest request = new SearchRequest("hotel");
//        构造查询条件
        request.source().query(QueryBuilders.matchQuery("all",nameByuser));//这里用专门的匹配字段进行匹配
//        也可以多个字段匹配但是性能会下降
//        request.source().query(QueryBuilders.multiMatchQuery(nameByuser,"name","brand"));
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        handleResponse(response);


    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Test
void testBool() throws IOException {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    // 2.1.准备BooleanQuery
    BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
    // 2.2.添加term
    boolQuery.must(QueryBuilders.termQuery("city", "杭州"));
    // 2.3.添加range
    boolQuery.filter(QueryBuilders.rangeQuery("price").lte(250));

    request.source().query(boolQuery);
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    // 4.解析响应
    handleResponse(response);

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

//    演示复合查询 bool
    @Test
    void testBoolSearch()throws IOException{

        SearchRequest searchRequest = new SearchRequest("hotel");
//        因为boolquery要设置多个匹配,所以不直接放在queryapi中
        BoolQueryBuilder boolQuery= QueryBuilders.boolQuery();
        //boolquery的查询匹配条件和过滤条件
        boolQuery.must(QueryBuilders.termQuery("brand","如家"));//如家的品牌
//        大于200小于500
        boolQuery.must(QueryBuilders.rangeQuery("price").lte(500).gt(200));
        //上描述的条件 必须都是评分大于30的数据
        boolQuery.filter(QueryBuilders.rangeQuery("score").gt(30));
        searchRequest.source().query(
         boolQuery
                );
        SearchResponse response = client.search(searchRequest, RequestOptions.DEFAULT);
        handleResponse(response);


    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

//    演示复合查询 bool
    @Test
    void testBoolSearch()throws IOException{

        SearchRequest searchRequest = new SearchRequest("hotel");
//        因为boolquery要设置多个匹配,所以不直接放在queryapi中
        BoolQueryBuilder boolQuery= QueryBuilders.boolQuery();
        //boolquery的查询匹配条件和过滤条件
        boolQuery.must(QueryBuilders.termQuery("brand","如家"));//如家的品牌
//        大于200小于500
        boolQuery.must(QueryBuilders.rangeQuery("price").lte(500).gt(200));
        //上描述的条件 必须都是评分大于30的数据
        boolQuery.filter(QueryBuilders.rangeQuery("score").gt(30));
        searchRequest.source().query(
         boolQuery
                );
        //模拟前端传递过来的页面和排序需求

        searchRequest.source().from(10).size(20);
        searchRequest.source().sort("price", SortOrder.DESC);
        SearchResponse response = client.search(searchRequest, RequestOptions.DEFAULT);
        handleResponse(response);






    }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

@Test
       void testHighLight()throws IOException{


    SearchRequest searchRequest = new SearchRequest("hotel");
//    对检索出来的分词做高亮处理
    searchRequest.source().query(QueryBuilders.matchQuery("all","如家"));
//    指定哪个字段高亮
    searchRequest.source().highlighter(new HighlightBuilder().field("name").requireFieldMatch(false));//不进行字段匹配
    SearchResponse response = client.search(searchRequest, RequestOptions.DEFAULT);
    Arrays.stream(response.getHits().getHits()).forEach(hit ->
                    hit.getHighlightFields().entrySet().forEach(entry ->

                            System.out.println("命中数据的高亮的字段是:"+entry.getKey()
                                    +" 高亮的结果是:"+Arrays.toString(entry.getValue().getFragments()))
                    )

            );

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

{
  "took": 5,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 30,
      "relation": "eq"
    },
    "max_score": 2.7875905,
    "hits": [
      {
        "_index": "hotel",
        "_type": "_doc",
        "_id": "339952837",
        "_score": 2.7875905,
        "_source": {
          "address": "良乡西路7号",
          "brand": "如家",
          "business": "房山风景区",
          "city": "北京",
          "id": 339952837,
          "location": "39.73167, 116.132482",
          "name": "如家酒店(北京良乡西路店)",
          "pic": "https://m.tuniucdn.com/fb3/s1/2n9c/3Dpgf5RTTzrxpeN5y3RLnRVtxMEA_w200_h200_c1_t0.jpg",
          "price": 159,
          "score": 46,
          "starName": "二钻"
        },
        "highlight": {
          "name": [
            "如家酒店(北京良乡西路店)"
          ]
        }
      },
      {
        "_index": "hotel",
        "_type": "_doc",
        "_id": "2359697",
        "_score": 2.7183504,
        "_source": {
          "address": "清河小营安宁庄东路18号20号楼",
          "brand": "如家",
          "business": "上地产业园/西三旗",
          "city": "北京",
          "id": 2359697,
          "location": "40.041322, 116.333316",
          "name": "如家酒店(北京上地安宁庄东路店)",
          "pic": "https://m.tuniucdn.com/fb3/s1/2n9c/2wj2f8mo9WZQCmzm51cwkZ9zvyp8_w200_h200_c1_t0.jpg",
          "price": 420,
          "score": 46,
          "starName": "二钻"
        },
        "highlight": {
          "name": [
            "如家酒店(北京上地安宁庄东路店)"
          ]
        }
      },
      {
        "_index": "hotel",
        "_type": "_doc",
        "_id": "1455383931",
        "_score": 2.7183504,
        "_source": {
          "address": "西乡河西金雅新苑34栋",
          "brand": "如家",
          "business": "宝安商业区",
          "city": "深圳",
          "id": 1455383931,
          "location": "22.590272, 113.881933",
          "name": "如家酒店(深圳宝安客运中心站店)",
          "pic": "https://m.tuniucdn.com/fb3/s1/2n9c/2w9cbbpzjjsyd2wRhFrnUpBMT8b4_w200_h200_c1_t0.jpg",
          "price": 169,
          "score": 45,
          "starName": "二钻"
        },
        "highlight": {
          "name": [
            "如家酒店(深圳宝安客运中心站店)"
          ]
        }
      },
      {
        "_index": "hotel",
        "_type": "_doc",
        "_id": "728180",
        "_score": 2.6524668,
        "_source": {
          "address": "西乡大道298-7号（富通城二期公交站旁）",
          "brand": "如家",
          "business": "宝安体育中心商圈",
          "city": "深圳",
          "id": 728180,
          "location": "22.569693, 113.860186",
          "name": "如家酒店(深圳宝安西乡地铁站店)",
          "pic": "https://m.tuniucdn.com/fb3/s1/2n9c/FHdugqgUgYLPMoC4u4rdTbAPrVF_w200_h200_c1_t0.jpg",
          "price": 184,
          "score": 43,
          "starName": "二钻"
        },
        "highlight": {
          "name": [
            "如家酒店(深圳宝安西乡地铁站店)"
          ]
        }
      },
      {
        "_index": "hotel",
        "_type": "_doc",
        "_id": "2316304",
        "_score": 2.6524668,
        "_source": {
          "address": "龙岗街道龙岗墟社区龙平东路62号",
          "brand": "如家",
          "business": "龙岗中心区/大运新城",
          "city": "深圳",
          "id": 2316304,
          "location": "22.730828, 114.278337",
          "name": "如家酒店(深圳双龙地铁站店)",
          "pic": "https://m.tuniucdn.com/fb3/s1/2n9c/4AzEoQ44awd1D2g95a6XDtJf3dkw_w200_h200_c1_t0.jpg",
          "price": 135,
          "score": 45,
          "starName": "二钻"
        },
        "highlight": {
          "name": [
            "如家酒店(深圳双龙地铁站店)"
          ]
        }
      },
      {
        "_index": "hotel",
        "_type": "_doc",
        "_id": "1765008760",
        "_score": 2.6524668,
        "_source": {
          "address": "西直门北大街49号",
          "brand": "如家",
          "business": "西直门/北京展览馆地区",
          "city": "北京",
          "id": 1765008760,
          "location": "39.945106, 116.353827",
          "name": "如家酒店(北京西直门北京北站店)",
          "pic": "https://m.tuniucdn.com/fb3/s1/2n9c/4CLwbCE9346jYn7nFsJTQXuBExTJ_w200_h200_c1_t0.jpg",
          "price": 356,
          "score": 44,
          "starName": "二钻"
        },
        "highlight": {
          "name": [
            "如家酒店(北京西直门北京北站店)"
          ]
        }
      },
      {
        "_index": "hotel",
        "_type": "_doc",
        "_id": "416121",
        "_score": 2.589701,
        "_source": {
          "address": "莲花池东路120-2号6层",
          "brand": "如家",
          "business": "北京西站/丽泽商务区",
          "city": "北京",
          "id": 416121,
          "location": "39.896449, 116.317382",
          "name": "如家酒店(北京西客站北广场店)",
          "pic": "https://m.tuniucdn.com/fb3/s1/2n9c/42DTRnKbiYoiGFVzrV9ZJUxNbvRo_w200_h200_c1_t0.jpg",
          "price": 275,
          "score": 43,
          "starName": "二钻"
        },
        "highlight": {
          "name": [
            "如家酒店(北京西客站北广场店)"
          ]
        }
      },
      {
        "_index": "hotel",
        "_type": "_doc",
        "_id": "441836",
        "_score": 2.589701,
        "_source": {
          "address": "西坝河东里36号",
          "brand": "如家",
          "business": "国展中心地区",
          "city": "北京",
          "id": 441836,
          "location": "39.966238, 116.450142",
          "name": "如家酒店(北京国展三元桥店)",
          "pic": "https://m.tuniucdn.com/fb2/t1/G6/M00/52/39/Cii-TF3eRTGITp1UAAYIilRD7skAAGLngIuAnQABgii479_w200_h200_c1_t0.png",
          "price": 458,
          "score": 47,
          "starName": "二钻"
        },
        "highlight": {
          "name": [
            "如家酒店(北京国展三元桥店)"
          ]
        }
      },
      {
        "_index": "hotel",
        "_type": "_doc",
        "_id": "517915",
        "_score": 2.589701,
        "_source": {
          "address": "布吉路1036号",
          "brand": "如家",
          "business": "田贝/水贝珠宝城",
          "city": "深圳",
          "id": 517915,
          "location": "22.583191, 114.118499",
          "name": "如家酒店·neo(深圳草埔地铁站店)",
          "pic": "https://m.tuniucdn.com/fb3/s1/2n9c/228vhBCQmFRFWQBYX1cgoFQb6x58_w200_h200_c1_t0.jpg",
          "price": 159,
          "score": 44,
          "starName": "二钻"
        },
        "highlight": {
          "name": [
            "如家酒店·neo(深圳草埔地铁站店)"
          ]
        }
      },
      ........
      }}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234

  hit.getHighlightFields().entrySet().forEach(entry ->

                            System.out.println("命中数据的高亮的字段是:"+entry.getKey()
                                    +" 高亮的结果是:"+Arrays.toString(entry.getValue().getFragments()))
1
2
3
4

private void handleResponse(SearchResponse response) {
    // 4.解析响应
    SearchHits searchHits = response.getHits();
    // 4.1.获取总条数
    long total = searchHits.getTotalHits().value;
    System.out.println("共搜索到" + total + "条数据");
    // 4.2.文档数组
    SearchHit[] hits = searchHits.getHits();
    // 4.3.遍历
    for (SearchHit hit : hits) {
        // 获取文档source
        String json = hit.getSourceAsString();
        // 反序列化
        HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
        // 获取高亮结果
        Map<String, HighlightField> highlightFields = hit.getHighlightFields();
        if (!CollectionUtils.isEmpty(highlightFields)) {
            // 根据字段名获取高亮结果
            HighlightField highlightField = highlightFields.get("name");
            if (highlightField != null) {
                // 获取高亮值
                String name = highlightField.getFragments()[0].string();
                // 覆盖非高亮结果
                hotelDoc.setName(name);
            }
        }
        System.out.println("hotelDoc = " + hotelDoc);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

{
    "key": "搜索关键字",
    "page": 1,
    "size": 3,
    "sortBy": "default"
}
1
2
3
4
5
6

package cn.itcast.hotel.pojo;

import lombok.Data;

@Data
public class RequestParams {
    private String key;
    private Integer page;
    private Integer size;
    private String sortBy;
}
1
2
3
4
5
6
7
8
9
10
11

package cn.itcast.hotel.pojo;

import lombok.Data;

import java.util.List;

@Data
public class PageResult {
    private Long total;
    private List<HotelDoc> hotels;

    public PageResult() {
    }

    public PageResult(Long total, List<HotelDoc> hotels) {
        this.total = total;
        this.hotels = hotels;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19