Elasticsearch架构原理

一. Elasticsearch架构原理

1、Elasticsearch的节点类型

在Elasticsearch主要分成两类节点，一类是Master，一类是DataNode。

1.1 Master节点

在Elasticsearch启动时，会选举出来一个Master节点。当某个节点启动后，然后使用Zen Discovery机制找到集群中的其他节点，建立连接，并从候选主节点中选举出一个主节点。
Master节点主要负责：

1. 处理创建，删除索引等请求，负责索引的创建与删除
2. 决定分片被分配到哪个节点
3. 维护并且更新Cluster State

Master Node的最佳实践

1. Master节点非常重要，在部署上需要考虑解决单点的问题
2. 为一个集群设置多个Master节点，每个节点只承担Master 的单一角色

选主的过程

1. 互相Ping对方，Node ld 低的会成为被选举的节点
2. 其他节点会加入集群，但是不承担Master节点的角色。一旦发现被选中的主节点丢失，就会选举出新的Master节点

1.2 DataNode节点

在Elasticsearch集群中，会有N个DataNode节点。DataNode节点主要负责：数据写入、数据检索，大部分Elasticsearch的压力都在DataNode节点上在生产环境中，内存最好配置大一些。
可以保存数据的节点，叫做Data Node，负责保存分片数据。在数据扩展上起到了至关重要的作用。
节点启动后，默认就是数据节点，可以设置node.data: false 禁止。
由Master Node决定如何把分片分发到数据节点上，通过增加数据节点可以解决数据水平扩展和解决数据单点问题。

1.3 Coordinating Node

1. 负责接受Client的请求， 将请求分发到合适的节点，最终把结果汇集到一起。
2. 每个节点默认都起到了Coordinating Node的职责。

1.4 其他节点

1. Master eligible nodes：可以参与选举的合格节点
   Master eligible nodes和Master Node
   每个节点启动后，默认就是一个Master eligible节点
   ○ 可以设置 node.master: false禁止
2. Master-eligible节点可以参加选主流程，成为Master节点
   当第一个节点启动时候，它会将自己选举成Master节点
   每个节点上都保存了集群的状态，只有Master节点才能修改集群的状态信息
   ○ 集群状态(Cluster State) ，维护了一个集群中，必要的信息
   ■ 所有的节点信息
   ■ 所有的索引和其相关的Mapping与Setting信息
   ■ 分片的路由信息
3. Hot & Warm Node
   ○ 不同硬件配置 的Data Node,用来实现Hot & Warm架构，降低集群部署的成本
4. Ingest Node
   ○ 数据前置处理转换节点，支持pipeline管道设置，可以使用ingest对数据进行过滤、转换等操作
5. Machine Learning Node
   ○ 负责跑机器学习的Job，用来做异常检测
6. Tribe Node
   ○ Tribe Node连接到不同的Elasticsearch集群，并且支持将这些集群当成一个单独的集群处理

二 、分片和副本机制

2.1 分片（Primary Shard & Replica Shard）

Elasticsearch是一个分布式的搜索引擎，索引的数据也是分成若干部分，分布在不同的服务器节点中。分布在不同服务器节点中的索引数据，就是分片（Shard）。Elasticsearch会自动管理分片，如果发现分片分布不均衡，就会自动迁移一个索引（index）由多个shard（分片）组成，而分片是分布在不同的服务器上的

2.1.1 主分片（Primary Shard）

• 用以解决数据水平扩展的问题。通过主分片，可以将数据分布到集群内的所有节点之上
• 一个分片是一个运行的Lucene的实例
• 主分片数在索引创建时指定，后续不允许修改，除非Reindex

2.1.2 副本分片（Replica Shard）

• 用以解决数据高可用的问题。 副本分片是主分片的拷贝
• 副本分片数，可以动态调整
• 增加副本数，还可以在一定程度上提高服务的可用性(读取的吞吐)
  分片的设定

对于生产环境中分片的设定，需要提前做好容量规划

2.1.3 分片数设置过小

• 导致后续无法增加节点实现水平扩展
• 单个分片的数据量太大，导致数据重新分配耗时

2.1.4 分片数设置过大，

7.0 开始，默认主分片设置成1，解决了over-sharding（分片过度）的问题

• 影响搜索结果的相关性打分，影响统计结果的准确性
• 单个节点上过多的分片，会导致资源浪费，同时也会影响性能

指定索引的主分片和副本分片数

PUT /blogs
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1 // 0或1 
  }
}
1
2
3
4
5
6
7

#查看集群的健康状况
GET _cluster/health

2.2 副本

为了对Elasticsearch的分片进行容错，假设某个节点不可用，会导致整个索引库都将不可用。所以，需要对分片进行副本容错。每一个分片都会有对应的副本。在Elasticsearch中，默认创建的索引为1个分片、每个分片有1个主分片和1个副本分片。每个分片都会有一个Primary Shard（主分片），也会有若干个Replica Shard（副本分片）
Primary Shard和Replica Shard不在同一个节点上

2.3 指定分片、副本数量

// 创建指定分片数量、副本数量的索引

2.4 集群status

● Green: 主分片与副本都正常分配
● Yellow: 主分片全部正常分配，有副本分片未能正常分配
● Red: 有主分片未能分配。例如，当服务器的磁盘容量超过85%时,去创建了一个新的索引
CAT API查看集群信息：

GET /_cat/nodes?v   #查看节点信息
GET /_cat/health?v    #查看集群当前状态：红、黄、绿
GET /_cat/shards?v        #查看各shard的详细情况  
GET /_cat/shards/{index}?v     #查看指定分片的详细情况
GET /_cat/master?v          #查看master节点信息
GET /_cat/indices?v         #查看集群中所有index的详细信息
GET /_cat/indices/{index}?v      #查看集群中指定index的详细信息 
1
2
3
4
5
6
7

三、Elasticsearch重要工作流程

3.1 Elasticsearch文档写入原理

1.选择任意一个DataNode发送请求，例如：node2。此时，node2就成为一个coordinating node（协调节点）
2.计算得到文档要写入的分片 shard = hash(routing) % number_of_primary_shards routing 是一个可变值，默认是文档的 _id
3.coordinating node会进行路由，将请求转发给对应的primary shard所在的DataNode（假设primary shard在node1、replica shard在node2）
4.node1节点上的Primary Shard处理请求，写入数据到索引库中，并将数据同步到Replica shard
5.Primary Shard和Replica Shard都保存好了文档，返回client.

注意：es路由分片规则是 shard = hash(routing) % number_of_primary_shards，其中number_of_primary_shards为分片数。

3.2 Elasticsearch检索原理

1. client发起查询请求，某个DataNode接收到请求，该DataNode就会成为协调节点（Coordinating Node）
   2.协调节点（Coordinating Node）将查询请求广播到每一个数据节点，这些数据节点的分片会处理该查询请求
   3.每个分片进行数据查询，将符合条件的数据放在一个优先队列中，并将这些数据的文档ID、节点信息、分片信息返回给协调节点 协调节点将所有的结果进行汇总，并进行全局排序
   4.协调节点向包含这些文档ID的分片发送get请求，对应的分片将文档数据返回给协调节点，最后协调节点将数据返回给客户端

如何对集群的容量进行规划

一个集群总共需要多少个节点?一个索引需要设置几个分片？规划上需要保持一定的余量，当负载出现波动，节点出现丢失时，还能正常运行。
做容量规划时，一些需要考虑的因素：
● 机器的软硬件配置
● 单条文档的大小│文档的总数据量│索引的总数据量（(Time base数据保留的时间)|副本分片数
● 文档是如何写入的(Bulk的大小)
● 文档的复杂度，文档是如何进行读取的(怎么样的查询和聚合)

评估业务的性能需求：
● 数据吞吐及性能需求
○ 数据写入的吞吐量，每秒要求写入多少数据?
○ 查询的吞吐量?
○ 单条查询可接受的最大返回时间?
● 了解你的数据
○ 数据的格式和数据的Mapping
○ 实际的查询和聚合长的是什么样的

ES集群常见应用场景：
● 搜索: 固定大小的数据集
○ 搜索的数据集增长相对比较缓慢
● 日志: 基于时间序列的数据
○ 使用ES存放日志与性能指标。数据每天不断写入，增长速度较快
○ 结合Warm Node 做数据的老化处理

硬件配置：
● 选择合理的硬件，数据节点尽可能使用SSD
● 搜索等性能要求高的场景，建议SSD
○ 按照1∶10的比例配置内存和硬盘
● 日志类和查询并发低的场景，可以考虑使用机械硬盘存储
○ 按照1:50的比例配置内存和硬盘
● 单节点数据建议控制在2TB以内，最大不建议超过5TB
● JVM配置机器内存的一半，JVM内存配置不建议超过32G
● 不建议在一台服务器上运行多个节点

内存大小要根据Node 需要存储的数据来进行估算
● 搜索类的比例建议: 1:16
● 日志类: 1:48——1:96之间
假设总数据量1T，设置一个副本就是2T总数据量
● 如果搜索类的项目，每个节点3116 = 496 G，加上预留空间。所以每个节点最多400G数据，至少需要5个数据节点
● 如果是日志类项目，每个节点3150= 1550 GB，2个数据节点即可