elasticsearch相关2
1.数据聚合
1.1.聚合的种类
聚合常见的有三类：
- **桶（Bucket）**聚合：用来对文档做分组
- TermAggregation：按照文档字段值分组，例如按照品牌值分组、按照国家分组
- Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组
- **度量（Metric）**聚合：用以计算一些值，比如：最大值、最小值、平均值等
- Avg：求平均值
- Max：求最大值
- Min：求最小值
- Stats：同时求max、min、avg、sum等
- **管道（pipeline）**聚合：其它聚合的结果为基础做聚合
注意：**参加聚合的字段必须是keyword、日期、数值、布尔类型
1.2.DSL实现聚合
1.2.1.Bucket聚合语法
GET /hotel/_search { "size": 0, // 设置size为0，结果中不包含文档，只包含聚合结果 "aggs": { // 定义聚合 "brandAgg": { //给聚合起个名字 "terms": { // 聚合的类型，按照品牌值聚合，所以选择term "field": "brand", // 参与聚合的字段 "size": 20 // 希望获取的聚合结果数量 } } } }
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.3.限定聚合范围
默认情况下，Bucket聚合是对索引库的所有文档做聚合，但真实场景下，用户会输入搜索条件，因此聚合必须是对搜索结果聚合。那么聚合必须添加限定条件。
我们可以限定要聚合的文档范围，只要添加query条件即可：
GET /hotel/_search { "query": { "range": { "price": { "lte": 200 // 只对200元以下的文档聚合 } } }, "size": 0, "aggs": { "brandAgg": { "terms": { "field": "brand", "size": 20 } } } }
1.2.4.Metric聚合语法
现在我们需要对桶内的酒店做运算，获取每个品牌的用户评分的min、max、avg等值。
这就要用到Metric聚合了，例如stat聚合：就可以获取min、max、avg等结果。
GET /hotel/_search { "size": 0, "aggs": { "brandAgg": { "terms": { "field": "brand", "size": 20 }, "aggs": { // 是brands聚合的子聚合，也就是分组后对每组分别计算 "score_stats": { // 聚合名称 "stats": { // 聚合类型，这里stats可以计算min、max、avg等 "field": "score" // 聚合字段，这里是score } } } } } }
这次的score_stats聚合是在brandAgg的聚合内部嵌套的子聚合。因为我们需要在每个桶分别计算。
RestAPI实现聚合
聚合条件与query条件同级别，因此需要使用request.source()来指定聚合条件。
@SpringBootTest(classes = ElasticApplication.class) @RunWith(SpringRunner.class) public class HotelAggregationTest { private RestHighLevelClient client; @Test void testSearchAggRequest() throws IOException { SearchRequest request = new SearchRequest("hotel"); request.source().size(0); request.source().aggregation(AggregationBuilders.terms("brandAgg").field("brand").size(20)); SearchResponse response = client.search(request, RequestOptions.DEFAULT); Aggregations aggregations = response.getAggregations(); Terms brandAgg = aggregations.get("brandAgg"); List<? extends Terms.Bucket> buckets = brandAgg.getBuckets(); // 4.3.遍历 for (Terms.Bucket bucket : buckets) { String brandName = bucket.getKeyAsString(); System.out.println("brandName = " + brandName); long docCount = bucket.getDocCount(); System.out.println("docCount = " + docCount); } } @BeforeEach void setUp() { client = new RestHighLevelClient(RestClient.builder( HttpHost.create("http://localhost:9200") )); } @AfterEach void tearDown() throws IOException { client.close(); } }
2.自动补全
2.1.拼音分词器
要实现根据字母做补全，就必须对文档按照拼音分词。在GitHub上恰好有elasticsearch的拼音分词插件。地址：https://github.com/medcl/elasticsearch-analysis-pinyin
没安装成功..
3.数据同步
elasticsearch中的酒店数据来自于mysql数据库，因此mysql数据发生改变时，elasticsearch也必须跟着改变，这个就是elasticsearch与mysql之间的数据同步。
常见的数据同步方案有三种：
- 同步调用
- 异步通知
- 监听binlog
3.1.1.同步调用
3.1.2.异步通知
流程如下：
- hotel-admin对mysql数据库数据完成增、删、改后，发送MQ消息
- hotel-demo监听MQ，接收到消息后完成elasticsearch数据修改
3.1.3.监听binlog
流程如下：
- 给mysql开启binlog功能
- mysql完成增、删、改操作都会记录在binlog中
- hotel-demo基于canal监听binlog变化，实时更新elasticsearch中的内容
3.1.4.选择
方式一：同步调用
- 优点：实现简单，粗暴
- 缺点：业务耦合度高
方式二：异步通知
- 优点：低耦合，实现难度一般
- 缺点：依赖mq的可靠性
方式三：监听binlog
- 优点：完全解除服务间耦合
- 缺点：开启binlog增加数据库负担、实现复杂度高
3.2.实现数据同步
3.2.1.思路
当酒店数据发生增、删、改时，要求对elasticsearch中数据也要完成相同操作。
启动并测试酒店数据的CRUD
- 声明exchange、queue、RoutingKey
- 在listen中的增、删、改业务中完成消息发送
- 在elastic中完成消息监听，并更新elasticsearch中数据
- 启动并测试数据同步功能
项目代码：https://gitee.com/niror/myelastic.git
4.集群
单机的elasticsearch做数据存储，必然面临两个问题：海量数据存储问题、单点故障问题。
- 海量数据存储问题：将索引库从逻辑上拆分为N个分片（shard），存储到多个节点
- 单点故障问题：将分片数据在不同节点备份（replica ）
**ES集群相关概念**:
* 集群（cluster）：一组拥有共同的 cluster name 的 节点。
节点 ：集群中的一个 Elasticearch 实例
* 分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中
解决问题：数据量太大，单点存储量有限的问题。
浙公网安备 33010602011771号