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(分片过度)的问题

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

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

java 复制代码
PUT /blogs
{
  "settings": {
    "number_of_shards": 3,
    "number_of_replicas": 1 // 0或1 
  }
}

#查看集群的健康状况

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查看集群信息:

java 复制代码
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的详细信息 

三、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个数据节点
● 如果是日志类项目,每个节点31
50= 1550 GB,2个数据节点即可

相关推荐
不是笨小孩i4 小时前
Git常用指令
大数据·git·elasticsearch
+码农快讯+7 小时前
Git入门学习(1)
git·学习·elasticsearch
码爸11 小时前
java 执行es中的sql
java·sql·elasticsearch
学习使我快乐——玉祥13 小时前
es查询语法
大数据·elasticsearch·搜索引擎
徐*红16 小时前
Elasticsearch 8.+ 版本查询方式
大数据·elasticsearch
码爸16 小时前
flink 例子(scala)
大数据·elasticsearch·flink·scala
txtsteve17 小时前
es由一个集群迁移到另外一个集群es的数据迁移
大数据·elasticsearch·搜索引擎
工作中的程序员17 小时前
ES 索引或索引模板
大数据·数据库·elasticsearch
Lill_bin1 天前
深入理解ElasticSearch集群:架构、高可用性与数据一致性
大数据·分布式·elasticsearch·搜索引擎·zookeeper·架构·全文检索
RwTo1 天前
Elasticsearch 聚合搜索
大数据·elasticsearch·搜索引擎·全文检索