elastic search(二)

es用途

elastic search作为一个近实时搜索引擎，功能是很强大的，她有很多RDBMS（传统数据库管理系统）所没有的功能（各自处理的领域不同，各有各的特色）。那么，什么是近实时搜索？默认情况下它能在1秒内，完成文档的索引构建以及被搜索到。虽然不是硬实时，但已经很快了，因此称为近实时搜索引擎。

像传统数据库所不擅长处理的like语句，es能够很快的完成检索处理，至于为什么，上篇《elastic search(一)》中已经讲到了lucene核心组件，大家感兴趣的可以往回看看那篇文章。本篇将继续讲解分布式情况下，es的应用及工作原理。

es架构介绍

首先来看下elastic search分布式下的架构：

 

 

 

可以看到，各个节点概念如下：

节点类型：

1. master node:

   1. 主节点

   2. es集群中，需要有一个节点作为leader角色，来做整体数据分配的计算、节点维护等

2. coordinator node

   1. 协调节点

   2. 能够转发客户端请求到实际分片

3. data node

   1. 数据节点

   2. 存储、查询lucene的节点

shard:

1. 分片

2. 索引的一部分，多个分片（shard）组合成为1个完整的索引（可以理解为传统数据库中的表）

分片(shard)类型：

1. 主分片

2. 副分片

   1. 对主分片的备份（完整拷贝）

   2. 一个主分片可以有0个副分片，也可以有N个副分片

   3. 为了分片数据的高可用性，类似hadoop fs机制

split:

1. 如果某索引大了，可以进行索引拆分来减少单个分片的大小

merge:

1. 可以合并索引

es应用简介

那么，根据es的特点，在东泽，有哪些领域应用到了呢？

最典型的就是elk（或者efk），elastic 生态原厂开源推荐方案：

 

 

不管是elk还是efk都是elastic原厂推荐方案，是优秀的原生方案之一。

题外话：最近也有另一种搭配方式：kfc

k: kibana
f: filebeat
c: clickhouse(大数据分析领域数据库) 

ELK的用途有哪些？

1. 提供开发人员以及运维人员生产系统的日志查询

2. 提供业务运营人员业务监控统计dashboard

可以看出，1. 偏向非结构化数据存储、查询、以及带点数据分析的特色在里面。

下面展示下电商业务监控，基于EFK的样子，还是很好看的（数据已隐藏）：

 

 

 

其次，电商商品查询场景：

初级的电商数据库用法如下所示：

 

 

上图是原始架构，经压测后，前端性能极差，qps很低，经排查，主要瓶颈出现在mysql查询，因此又出现了如下架构：

 

 

此时会把前台高并发的查询转到mysql读库中来做流量分流，性能确实上升了些。但是对like语句的性能依然很慢。急需解决，因此再改为如下架构：

 

 

此时，高并发的查询流量主要是打到了es搜索引擎，业务操作修改新增等流量依然转入mysql中。此时，存储维度的优化可以先缓缓了，可以暂时转向其他方向优化了。

在电商后台会将商品保存到关系型数据库的同时，同步的将数据塞到elastic search内进行索引的构建，然后小程序端或者web端就能进行近实时的搜索，而且搜索方式很丰富，2. 比mysql的like查询丰富很多，并且3. 性能极高。

 

再就是审计系统场景，需要根据关键字搜索，速度要快，而且4.略微带点数据分析的功能（统计功能较好）：

 

 

以上都是es可以发挥的场景，用的比较广泛。

原理-es索引构建

下面说下当一个文档（其实就是JSON数据）发送到es某节点后的处理逻辑。

<!-- https://mvnrepository.com/artifact/org.elasticsearch.client/elasticsearch-rest-high-level-client -->
<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-rest-high-level-client</artifactId>
    <version>7.14.1</version>
</dependency>

大家可以参考这个url编写客户端demo：https://www.cnblogs.com/ginb/p/8716485.html

 

在业务应用服务端用上述java库构建请求发送到es集群后，大致的处理管道逻辑如下图所示：

 

 

能看出，es在分布式场景下，在基于lucene组件之上，分布式层面做了很多工作。比如分片的路由如何计算（这个其实像分表分库，传统的应用也是有的，再比如spring mvc的action路由，都是某种程度的路由机制；这个路由机制很多很多），找到分片后数据如何写入，又如何尽快的能让查询能够看到这条新数据，同时又不能被慢速磁盘系统拖累降低处理速率等，都是很好的最佳实践。

最后，相信通过两篇介绍es的文章后，应该能激发起很多小伙伴对elastic search的学习兴趣。

感谢大家观看。