聚合可以让我们及其方便的实现对数据的统计、运算、分析

  • 什么品牌的手机最受欢迎？
  • 这些手机的平均价格、最高价格、最低价格？
  • 这些手机每月的销售情况如何？

实现这些统计功能的比数据库的sql要方便的多,而且查询速度非常快,可以实现近实时搜索效果.

1.1.聚合的种类

聚合常见的有三类:

  • 桶（Bucket）聚合：用来对文档做分组
    • TermAggregation：按照文档字段值分组，例如按照品牌值分组、按照国家分组
    • Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组
  • 度量（Metric）聚合：用以计算一些值，比如：最大值、最小值、平均值等
    • Avg：求平均值
    • Max：求最大值
    • Min：求最小值
    • Stats：同时求max、min、avg、sum等

  • 管道（pipeline）聚合：其它聚合的结果为基础做聚合

    1.2.DSL实现聚合

    现在,我们要统计所有数据中的酒店品牌有几种,其实就是按照品牌对数据分组.此时可以根据酒店品牌的
    名称做聚合,也就是Bucket聚合.

    1.2.1.Bucket聚合语法

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

    1.2.2.聚合结果排序

    默认情况下，Bucket聚合会统计Bucket内的文档数量，记为_count，并且按照_count降序排序。
    我们可以指定order属性，自定义聚合的排序方式：
    GET /hotel/_search
    {
    “size”: 0,
    “aggs”: {
    “brandAgg”: {
    “terms”: {
    “field”: “brand”,
    “order”: {
    “_count”: “asc” // 按照_count升序排列
    },
    “size”: 20
    }
    }
    }
    }

    1.2.5.小结

    aggs代表聚合，与query同级，此时query的作用是？

  • 限定聚合的的文档范围

聚合必须的三要素：

  • 聚合名称
  • 聚合类型
  • 聚合字段

聚合可配置属性有：

  • size：指定聚合结果数量
  • order：指定聚合结果排序方式
  • field：指定聚合字段

    1.3.RestAPI实现聚合

    聚合条件与query条件同级别，因此需要使用request.source()来指定聚合条件。
    聚合条件的语法：
    image.png
    聚合的结果也与查询结果不同，API也比较特殊。不过同样是JSON逐层解析：
    image.png

在cn.itcast.hotel.web包的HotelController中添加一个方法，遵循下面的要求：

  • 请求方式：POST
  • 请求路径：/hotel/filters
  • 请求参数：RequestParams，与搜索文档的参数一致
  • 返回值类型：Map>

代码：
@PostMapping(“filters”)
public Map> getFilters(@RequestBody RequestParams params){
return hotelService.getFilters(params);
}

2.2.自定义分词器

elasticsearch中分词器(anakyzer)的组成包含三部分:

  • character filters：在tokenizer之前对文本进行处理。例如删除字符、替换字符
  • tokenizer：将文本按照一定的规则切割成词条（term）。例如keyword，就是不分词；还有ik_smart
  • tokenizer filter：将tokenizer输出的词条做进一步处理。例如大小写转换、同义词处理、拼音处理等
  • 文档分词时会依次有三部分来处理文档:
  • image.png
  • 声明自定义分词器的语法如下:
  • PUT /test

{
“settings”: {
“analysis”: {
“analyzer”: { // 自定义分词器
“my_analyzer”: { // 分词器名称
“tokenizer”: “ik_max_word”,
“filter”: “py”
}
},
“filter”: { // 自定义tokenizer filter
“py”: { // 过滤器名称
“type”: “pinyin”, // 过滤器类型，这里是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”
}
}
}
}
测试：
image.png

2.4.实现酒店搜索框自动补全

现在,我们的hotel索引库还有设置拼音分词器,需要修改索引库中的配置.但是我们知道索引库时无法修改的,只能删除然后重新创建.
另外,我们需要添加一个字段,用来做自动不全,将brand,suggestion,city等都放进,作为自动不全的提示.
因此,总结一下,我们需要做的事情包括:
1.修改hotel索引库结构,设置自定义拼音分词器
2.修改索引库的name,all字段,使用自定义分词器
3.索引库添加一个新字段suggestion,类型为completion类型,使用自定义的分词器
4.给HotelDoc类添加suggestion字段,内容包含brand,business
5.重新导入数据到hotel库

3.1.思路分析

常见的数据同步方案有三种:
同步调用
异步通知
监听binlog

3.1.1.同步调用

image.png
基本步骤如下:
hotel-demo对外提供接口,用来修改elasticsearch中的数据
酒店管理服务在完成数据库操作后,直接调用hotel-demo提供的接口.

3.1.2.异步通知

方案二：异步通知
image.png
流程如下:
hotel-admin对mysql数据库数据完成增、删、改后,发送MQ消息
hotel-demo监听MQ,接收到消息后完成elasticsearch数据修改

3.1.3.监听binlog

方案三：监听binlog
image.png
流程如下:
给mysql开启binlog功能
mysql完成增、删、改操作都会记录在binlog中
hotel-demo基于canal监听binlog变化,实时更新elasticsearch中的内容

3.1.4.选择

方式一:同步调用
优点:实现简单,粗暴
缺点:业务耦合度高

方式二:异步通知
优点:低耦合,实现难度一般
缺点:依赖mq的可靠性

方式三:监听binlog
优点: 完全解除服务间耦合
缺点: 开启binlog增加数据负担、实现复杂度高

3.2.实现数据同步

3.2.1.思路

利用课前资料提供的hotel-admin项目作为酒店管理的微服务,当酒店数据发生增、删、改时,
要求对elasticsearch中数据也要完成相同操作.

步骤:
导入课前资料提供的hotel-admin项目,启动并测试酒店数据的CRUD

声明exchange、queue、RoutingKey

在hotel-admin中的增、删、改业务中完成消息发送

在hotel-demo中完成消息监听,并更新elasticsearch中数据

启动并测试数据同步功能

3.2.5.接收MQ消息

hotel-demo接收到MQ消息要做的事情包括：

  • 新增消息：根据传递的hotel的id查询hotel信息，然后新增一条数据到索引库

  • 删除消息：根据传递的hotel的id删除索引库中的一条数据

    4.集群

    单机的elasticsearch做数据存储，必然面临两个问题：海量数据存储问题、单点故障问题。

海量数据存储问题:将索引库从逻辑上拆分为N个分片(shard),存储到多个节点

单点故障问题:将分片数据在不同节点备份(replinca)

ES集群相关概念:
集群 (cluster) : 一组拥有共同的cluster name 的节点

节点 (node) : 集群中的一个Elasticearch实列

分片 (shard) : 索引可以被拆分为不同的部分进行存储,称为分片.在集群环境下,一个索引的不同分片可以拆分到不同的节点中
解决问题: 数据量太大,单点存储量有限的问题
image.png
主分片 (Primary shard) : 相对于副本分片的定义

副本分片 (Replica shard) : 每个主分片可以有一个或者多个副本,数据和主分片一样.

4.2.集群脑裂问题

elasticsearch中集群节点有不同的职责划分：
image.png

默认情况下，集群中的任何一个节点都同时具备上述四种角色。

但是真实的集群一定要将集群职责分离:

master节点: 对CPU要求高,但是内存要求低

data节点: 对CPU和内存要求高

coordinating节点 : 对网络带宽、CPU要求高

职责分离可以让我们根据不同节点的需求分配不同的硬件去部署.而且避免业务之间
的互相干扰.
一个典型的es集群职责划分如图：
image.png

4.2.2.脑裂问题

脑裂是因为集群中的节点失联导致的

master eligible 节点的作用是什么?
参与集群选主
主节点可以管理集群状态、管理分片信息、处理创建和删除索引库请求

data节点的作用是什么?
数据的CRUD

cooedinator节点的作用是什么?
路由请求到其它节点
合并查询到的结果,返回给用户