ELK之elasticsearch基本使用教程_elk使用教程

文章目录

• ELK包含技术
• elasticsearch基本介绍
• • 倒排索引
  • • 正向索引
    • 倒排索引
    • 正向和倒排
  • es的一些概念
  • • 文档和字段
    • 索引和映射
    • mysql与elasticsearch
• 安装es、kibana
• • 创建网络
  • 加载镜像
  • 安装分词插件
• 索引库操作
• • mapping映射属性
  • 索引库的CRUD
  • • 创建索引库和映射
    • • 基本语法：
      • 示例：
    • 查询索引库
    • 修改索引库
    • 删除索引库
    • 总结
• 文档操作
• • 新增文档
  • 查询文档
  • 删除文档
  • 修改文档
  • • 全量修改
    • 增量修改
  • 总结
• 查询操作
• • DSL查询分类
  • 全文检索查询
  • • 使用场景
    • 基本语法
    • 示例
    • 总结
  • 精准查询
  • • term查询
    • range查询
    • 总结
  • 地理坐标查询
  • • 矩形范围查询
    • 附近查询
  • 复合查询
  • • 相关性算分
    • 算分函数查询
    • • 1）语法说明
      • 2）示例
      • 3）小结
    • 布尔查询
    • • 1）语法示例：
      • 2）示例
      • 3）小结
• 搜索结果处理
• • 排序
  • • 普通字段排序
    • 2.1.2.地理坐标排序
  • 分页
  • • 基本的分页
    • 深度分页问题
    • 小结
  • 高亮
  • • 高亮原理
    • 实现高亮
  • 总结
• 数据聚合
• • DSL实现聚合
  • • Bucket聚合语法
    • 聚合结果排序
    • 限定聚合范围
    • Metric聚合语法
    • 小结
• 自定义分词器
• • 自动补全查询
• 和MySQL数据同步
• • 思路分析
  • • 同步调用
    • 异步通知
    • 监听binlog
    • 选择

ELK包含技术

elasticsearch基本介绍

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

倒排索引

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

正向索引

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

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

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

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

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

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

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

逐行扫描，也就是全表扫描，随着数据量增加，其查询效率也会越来越低。当数据量达到数百万时，就是一场灾难。

倒排索引

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

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

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

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

如图：

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

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

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

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

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

如图：

虽然要先查询倒排索引，再查询正向索引，但是无论是词条、还是文档id都建立了索引，查询速度非常快！无需全表扫描。

正向和倒排

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

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

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

是不是恰好反过来了？

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

正向索引：

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

倒排索引：

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

es的一些概念

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

文档和字段

elasticsearch是面向**文档(Document)**存储的，可以是数据库中的一条商品数据，一个订单信息。文档数据会被序列化为json格式后存储在elasticsearch中：

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

索引和映射

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

例如：

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

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

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

mysql与elasticsearch

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

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

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

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

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

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

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

安装es、kibana

创建网络

通过网络让es和kibana容器互联

docker network create es-netdocker network inspect es-net # 查看网络Commands: connect Connect a container to a network create Create a network disconnect Disconnect a container from a network inspect Display detailed information on one or more networks ls List networks prune Remove all unused networks rm Remove one or more networksRun \'docker network COMMAND --help\' for more information on a command.

加载镜像

docker pull elasticsearch:7.12.1docker pull kibana:7.12.1

docker run -d \\--name elasticsearch \\ -e \"ES_JAVA_OPTS=-Xms1024m -Xmx1024m\" \\ -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 \\elasticsearch:7.12.1

命令解释：

• -e \"cluster.name=es-docker-cluster\"：设置集群名称
• -e \"http.host=0.0.0.0\"：监听的地址，可以外网访问
• -e \"ES_JAVA_OPTS=-Xms1024m -Xmx1024m\"：内存大小
• -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访问的入口
• -p 9300:9300：tcp协议端口，用于集群模式下节点与节点之间的心跳检查的

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

docker run -d \\--name kibana \\-e ELASTICSEARCH_HOSTS=http://elasticsearch:9200 \\--network=es-net \\-p 5601:5601 \\kibana:7.12.1

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

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

安装分词插件

分词器下载地址

1. 查看es容器的配置挂载目录

docker volume inspect es-plugins

[ { \"CreatedAt\": \"2025-02-22T21:05:06+08:00\", \"Driver\": \"local\", \"Labels\": null, \"Mountpoint\": \"/var/lib/docker/volumes/es-plugins/_data\", \"Name\": \"es-plugins\", \"Options\": null, \"Scope\": \"local\" }]

说明plugins目录被挂载到了：/var/lib/docker/volumes/es-plugins/_data 这个目录中。

2. 把下载的压缩包解压并重命名为 ik py 然后上传到挂载目录下

3. 重启容器

docker restart elasticsearch

索引库操作

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

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

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\": \"hebut@edu.cn\", \"score\": [99.1, 99.5, 98.9], \"name\": { \"firstName\": \"云\", \"lastName\": \"赵\" }}

对应的每个字段映射（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；无需分词器

索引库的CRUD

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

创建索引库和映射

基本语法：

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

格式：

PUT /索引库名称{ \"mappings\": { \"properties\": { \"字段名\":{ \"type\": \"text\", \"analyzer\": \"ik_smart\" }, \"字段名2\":{ \"type\": \"keyword\", \"index\": \"false\" }, \"字段名3\":{ \"properties\": { \"子字段\": { \"type\": \"keyword\" } } }, // ...略 } }}

示例：

PUT /hebut{ \"mappings\": { \"properties\": { \"info\":{ \"type\": \"text\", \"analyzer\": \"ik_smart\" }, \"email\":{ \"type\": \"keyword\", \"index\": \"false\" }, \"name\":{ \"properties\": { \"firstName\": { \"type\": \"keyword\" } } } } }}

查询索引库

基本语法：

• 请求方式：GET

• 请求路径：/索引库名

• 请求参数：无

格式：

GET /索引库名

示例：

修改索引库

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

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

语法说明：

PUT /索引库名/_mapping{ \"properties\": { \"新字段名\":{ \"type\": \"integer\" } }}

示例：

删除索引库

语法：

• 请求方式：DELETE

• 请求路径：/索引库名

• 请求参数：无

格式：

DELETE /索引库名

总结

索引库操作有哪些？

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

文档操作

新增文档

语法：

POST /索引库名/_doc/文档id{ \"字段1\": \"值1\", \"字段2\": \"值2\", \"字段3\": { \"子属性1\": \"值3\", \"子属性2\": \"值4\" }, // ...}

示例：

POST /hebut/_doc/1{ \"info\": \"河工大Java讲师\", \"email\": \"hebut@edu.cn\", \"name\": { \"firstName\": \"云\", \"lastName\": \"赵\" }}

响应：

查询文档

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

语法：

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

通过kibana查看数据：

GET /hebut/_doc/1

查看结果：

删除文档

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

语法：

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

示例：

# 根据id删除数据DELETE /hebut/_doc/1

结果：

修改文档

修改有两种方式：

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

全量修改

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

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

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

语法：

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

示例：

PUT /hebut/_doc/1{ \"info\": \"河工大Java高级讲师\", \"email\": \"hebut@edu.cn\", \"name\": { \"firstName\": \"云\", \"lastName\": \"赵\" }}

结果：

增量修改

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

语法：

POST /{索引库名}/_update/文档id{ \"doc\": { \"字段名\": \"新的值\", }}

示例：

POST /hebut/_update/1{ \"doc\": { \"email\": \"ZhaoYun@edu.cn\" }}

结果：

总结

文档操作有哪些？

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

查询操作

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 /索引库名称/_search{ \"query\": { \"查询类型\": { \"查询条件\": \"条件值\" } }}

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

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

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

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

全文检索查询

使用场景

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

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

比较常用的场景包括：

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

因为是拿着词条去匹配，因此参与搜索的字段也必须是可分词的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查询示例：

multi_match查询示例：

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

因为我们将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\" } } }}

示例：

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

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

range查询

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

基本语法：

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

示例：

总结

精确查询常见的有哪些？

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

地理坐标查询

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

常见的使用场景包括：

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

附近的酒店：

附近的车：

矩形范围查询

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

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

语法如下：

GET hotel/_search{ \"query\":{ \"geo_bounding_box\":{ \"location\":{ \"top_left\": { \"lat\": 31.1, \"lon\": 121.5 }, \"bottom_right\":{ \"lat\": 30.9, \"lon\": 121.7 } } } }}

这种并不符合“附近的人”这样的需求，所以我们就不做了。

附近查询

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

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

语法说明：

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

示例：

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

发现共有47家酒店。

然后把半径缩短到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算法，公式如下：

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

参考：https://zhuanlan.zhihu.com/p/79202151

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

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

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

算分函数查询

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

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

要想认为控制相关性算分，就需要利用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\" // 加权模式，求和 } }}

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

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

3）小结

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

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

布尔查询

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

• 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 } }} ] } }}

2）示例

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

分析：

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

3）小结

bool查询有几种逻辑关系？

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

搜索结果处理

排序

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

普通字段排序

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

语法：

GET /indexName/_search{ \"query\": { \"match_all\": {} }, \"sort\": [ { \"FIELD\": \"desc\" // 排序字段、排序方式ASC、DESC } ]}

排序条件是一个数组，也就是可以写多个排序条件。按照声明的顺序，当第一个条件相等时，再按照第二个条件排序，以此类推

示例：

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

2.1.2.地理坐标排序

地理坐标排序略有不同。

语法说明：

GET /indexName/_search{ \"query\": { \"match_all\": {} }, \"sort\": [ { \"_geo_distance\" : { \"FIELD\" : \"纬度，经度\", // 文档中geo_point类型的字段名、目标坐标点 \"order\" : \"asc\", // 排序方式 \"unit\" : \"km\" // 排序的距离单位 } } ]}

这个查询的含义是：

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

示例：

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

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

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

分页

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

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

类似于mysql中的limit ?, ?

基本的分页

分页的基本语法如下：

GET /hotel/_search{ \"query\": { \"match_all\": {} }, \"from\": 0, // 分页开始的位置，默认为0 \"size\": 10, // 期望获取的文档总数 \"sort\": [ {\"price\": \"asc\"} ]}

深度分页问题

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

GET /hotel/_search{ \"query\": { \"match_all\": {} }, \"from\": 990, // 分页开始的位置，默认为0 \"size\": 10, // 期望获取的文档总数 \"sort\": [ {\"price\": \"asc\"} ]}

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

不过，elasticsearch内部分页时，必须先查询 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的请求。

GET hotel/_search{ \"query\": { \"match\": { \"all\": \"外滩如家\" } }, \"size\": 3, \"search_after\": [379, \"433576\"], \"sort\": [ { \"price\": { \"order\": \"desc\" } }, { \"id\": { \"order\": \"asc\" } } ]}

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

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

小结

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

• from + size：

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

• after search：

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

• scroll：

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

高亮

高亮原理

什么是高亮显示呢？

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

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

• 1）给文档中的所有关键字都添加一个标签，例如标签
• 2）页面给标签编写CSS样式

GET /hotel/_search{ \"query\": { \"match\": { \"FIELD\": \"TEXT\" // 查询条件，高亮一定要使用全文检索查询 } }, \"highlight\": { \"fields\": { // 指定要高亮的字段 \"FIELD\": { \"pre_tags\": \"\", // 用来标记高亮字段的前置标签 \"post_tags\": \"\" // 用来标记高亮字段的后置标签 } } }}

GET /hotel/_search{ \"size\": 0, // 设置size为0，结果中不包含文档，只包含聚合结果 \"aggs\": { // 定义聚合 \"brandAgg\": { //给聚合起个名字 \"terms\": { // 聚合的类型，按照品牌值聚合，所以选择term \"field\": \"brand\", // 参与聚合的字段 \"size\": 20 // 希望获取的聚合结果数量 } } }}

GET /hotel/_search{ \"size\": 0, \"aggs\": { \"brandAgg\": { \"terms\": { \"field\": \"brand\", \"order\": { \"_count\": \"asc\" // 按照_count升序排列 }, \"size\": 20 } } }}

GET /hotel/_search{ \"query\": { \"range\": { \"price\": { \"lte\": 200 } } }, \"size\": 0, \"aggs\": { \"brandAgg\": { \"terms\": { \"field\": \"brand\", \"size\": 20 } } }}

GET /hotel/_search{ \"size\": 0, \"aggs\": { \"brandAgg\": { \"terms\": { \"field\": \"brand\", \"size\": 20 }, \"aggs\": { // 是brands聚合的子聚合，也就是分组后对每组分别计算 \"score_stats\": { // 聚合名称 \"stats\": { // 聚合类型，这里stats可以计算min、max、avg等 \"field\": \"score\" // 聚合字段，这里是score } } } } }}

PUT /test{ \"settings\": { \"analysis\": { \"analyzer\": { // 自定义分词器 \"my_analyzer\": { // 分词器名称 \"tokenizer\": \"ik_max_word\", \"filter\": \"py\" } }, \"filter\": { // 自定义tokenizer filter \"py\": { // 过滤器名称 \"type\": \"pinyin\", \"keep_full_pinyin\": false,  \"keep_joined_full_pinyin\": true, \"keep_original\": true, \"limit_first_letter_length\": 16, \"remove_duplicated_term\": true, \"none_chinese_pinyin_tokenize\": false } } } }, \"mappings\": { \"properties\": { \"name\": { \"type\": \"text\", \"analyzer\": \"my_analyzer\", # 保存文档内容时，使用自定义分词器-》写 \"search_analyzer\": \"ik_smart\" # 搜索时使用id_smart ---》读 } } }}

PUT test{ \"mappings\": { \"properties\": { \"title\":{ \"type\": \"completion\" } } }}

POST test/_doc{ \"title\": [\"Sony\", \"WH-1000XM3\"]}POST test/_doc{ \"title\": [\"SK-II\", \"PITERA\"]}POST test/_doc{ \"title\": [\"Nintendo\", \"switch\"]}

// 自动补全查询GET /test/_search{ \"suggest\": { \"title_suggest\": { \"text\": \"s\", // 关键字 \"completion\": { \"field\": \"title\", // 补全查询的字段 \"skip_duplicates\": true, // 跳过重复的 \"size\": 10 // 获取前10条结果 } } }}