Elasticsearch必知必会

最新推荐文章于 2024-08-09 11:02:43 发布

椰子Tyshawn

最新推荐文章于 2024-08-09 11:02:43 发布

阅读量611

点赞数

分类专栏： ElasticSearch笔记面试笔记文章标签： elasticsearch ES面试

本文链接：https://blog.csdn.net/litianxiang_kaola/article/details/104147340

版权

ElasticSearch笔记同时被 2 个专栏收录

19 篇文章 1 订阅

订阅专栏

面试笔记

7 篇文章 3 订阅

订阅专栏

前置知识:

Elasticsearch基本概念与核心原理
 Elasticsearch数据建模

1. Elasticsearch的分布式架构原理是什么?

Elasticsearch是分布式的, 在多台机器上启动ES进程实例, 组成一个ES集群. ES集群中的节点会选举出一个master节点来管理集群, 比如负责索引的创建与删除, 负责主分片与副本分片的身份切换等等. ES集群的master节点选举算法如下:

查找当前活跃的Master节点.
如果存在活跃的Master节点, 选择其中nodeId最小的那个作为Master节点. (脑裂问题可能导致多个Master节点)
如果不存在活跃的Master节点, 则获取集群中活跃的Master Eligible Nodes, 进行投票选举.
如果集群中活跃的候选节点数超过一半(正常情况下候选节点数的一半), 则选择clusterStateVersion(集群状态版本)最新的那个作为Master节点. 如果clusterStateVersion相同, 则选择nodeId最小的那个作为Master节点.
如果如果集群中活跃的候选节点数没有超过一半, 则无法选举.

ES存储数据的基本单位是索引, 每个索引都会被拆分为多个分片, 每个分片分布在不同节点上. 同时为了保证可用性, 每个分片都会设置副本, 主分片提供读写服务, 副本分片提供读服务. 当主分片所在的节点宕机后, master节点会从副本分片中选出一个作为主分片, 然后当宕机的节点修复后, master节点会将缺失的副本分片分配过去, 同步数据后, 集群恢复正常.

2. Elasticsearch写入数据的工作原理, 查询数据的工作原理, 搜索数据的工作原理分别是什么?

Elasticsearch写入数据的工作原理

客户端发送请求到任意一个协调节点(Coordinating Node), 然后协调节点将请求转发给master节点.
master节点对document进行路由, 将document写入主分片.
document写入主分片后, 将数据同步到副本分片.
主分片和副本分片都写入成功后, 返回响应结果给客户端.

(1) document写入主分片的详细过程

Document写入Index Buffer(ES进程缓冲), 同时将写命令记录到Transaction Log.
每隔1秒或Index Buffer空间被占满后, Index Buffer中的数据被写入新的Segment中, 并进入OS Cache, 这个过程叫Refresh. (此时倒排索引已创建, 存在OS Cache中, 数据可被搜索)
重复前面两个步骤.
每隔30分钟或Transaction Log占满后, 先进行Refresh操作, 然后将OS Cache中的Segment刷入磁盘, 这个过程叫Flush.
删除旧Transaction Log, 创建一个新的Transaction Log.
ES定期合并磁盘中的Segment File, 同时清除那些被标记为delete的文档.

(2) ES被称为近实时(Near Realtime)的原因

从上文"document写入主分片的详细过程"中可以知道, Refresh操作每秒执行一次, 只有执行Refresh操作之后, 倒排索引才会被创建, 数据才能被搜索, 这就是ES被称为近实时的原因.

(3) ES存在数据丢失的问题

从上文"document写入主分片的详细过程"中可以知道, document写入Index Buffer的同时会将写命令记录到Transaction Log, 目的是如果数据落盘之前机器宕机了, 可以从Transaction Log中恢复数据. 但在旧版本中Transaction Log不是默认落盘的, 它会先写入OS Cache中, 每隔5s才会被刷入磁盘, 所以如果在Transaction Log落盘前机器宕机了, 数据就完全丢失了.

在新版本7.x中, Transaction Log是默认落盘的, 也就不会有数据丢失的问题. (index.translog.durability, index.translog.sync_interval)

Elasticsearch查询数据的工作原理(Get查询)

客户端发送请求到任意一个协调节点(Coordinating Node).
协调节点根据id进行路由, 找到对应的分片.
根据round-robin随机轮询算法, 在主分片和其他副本分片中随机选择一个, 进行查询.
将对应的document返回给协调节点.
协调节点返回document给客户端.

Elasticsearch搜索数据的工作原理

客户端发送请求到任意一个协调节点(Coordinating Node).
协调节点将搜索请求转发给所有分片(主分片和副本分片采用随机轮询算法选一个)
每个分片将自己的搜素结果(这里只有id)返回给协调节点
协调节点对搜索结果进行合并, 排序, 分页等操作, 得出最终结果.
协调节点根据最终结果的id去各个分片上拉取document, 返回给客户端.

3. Elasticsearch在数据量很大的情况下（数十亿级别）如何提高搜索性能?

(1) 善于利用OS Cache

如果Elasticsearch的每次搜索都要落盘, 那搜索性能肯定很差, 将达到秒级. 但如果ES集群中的数据量等于OS Cache的容量, 那每次搜索都会直接走OS Cache, 这样性能就会很高, 达到毫秒级.

ES集群中的数据量最好不要超过OS Cache的容量, 最低要求也不能超过OS Cache的两倍. 比如我们ES集群有3台机器, 每台机器64G内存, 为每个节点的ES JVM Heap分配32G内存, 最终集群的OS Cache为 32G * 3 = 96G内存. 我们ES集群中的数据量最优情况是不超过96G, 最低要求的情况是不超过192G.

(2) 数据建模

从上文"善于利用OS Cache"中我们知道, 我们要保证ES集群中的数据量不超过OS Cache的容量, 那么我们在数据建模的时候就要注意两点:

不要将MySQL表中的所有字段都写入ES, 只写入一部分会被搜索的字段.
对于MySQL中具有关联关系的表, 我们直接将关联字段写入ES中或在应用端处理关联关系, 禁止在ES中处理关联关系.

(3) 数据预热

如果我们无法做到让ES集群中的数据量不超过OS Cache的容量, 那我们做一个缓存预热子系统, 定时搜索"热数据", 让其进入OS Cache.

(4) 冷热分离

在数据预热的基础上我们还可以进行冷热数据分离, 比如我们有6台机器, 创建两个索引, 每个索引3个分片, 一个索引放热数据, 一个索引放冷数据. 热数据量一般只占总数据量的10%, 这样我们就能保证热数据都在OS Cache中. 而冷数据虽然占总数据的90%, 但却只有10%的用户访问, 性能差点是可以接受的.

(5) 分页性能优化

深度分页的性能是很差的, 我们要防止出现深度分页的情况, 用滚动翻页来代替深度分页.