ElasticSearch学习(八)--深入理解分片操作

本文转载自:https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html,ES版本号6.3.0
本文转载自:https://blog.csdn.net/qq_23536449/article/details/90898718

路由文档到分片
当你索引一个文档,它被存储在单独一个主分片上。Elasticsearch是如何知道文档属于哪个分片的呢?当你创建一个新文档,它是如何知道是应该存储在分片1还是分片2上的呢?
进程不能是随机的,因为我们将来要检索文档。事实上,它根据一个简单的算法决定:

shard = hash(routing) % number_of_primary_shards

routing值是一个任意字符串,它默认是_id但也可以自定义。这个routing字符串通过哈希函数生成一个数字,然后除以主切片的数量得到一个余数(remainder),余数的范围永远是0到number_of_primary_shards - 1,这个数字就是特定文档所在的分片。这也解释了为什么主分片的数量只能在创建索引时定义且不能修改:如果主分片的数量在未来改变了,所有先前的路由值就失效了,文档也就永远找不到了
所有的文档API(get、index、delete、bulk、update、mget)都接收一个routing参数,它用来自定义文档到分片的映射。自定义路由值可以确保所有相关文档——例如属于同一个人的文档——被保存在同一分片上。我们将在《扩展》章节说明你为什么需要这么做。

notes:有时用户认为固定数量的主分片会让之后的扩展变得很困难。现实中,有些技术会在你需要的时候让扩展变得容易。我们将在《扩展》章节讨论。

主分片和复制分片如何交互
为了阐述意图,我们假设有三个节点的集群。它包含一个叫做bblogs的索引并拥有两个主分片。每个主分片有两个复制分片。相同的分片不会放在同一个节点上,所以我们的集群是这样的:
在这里插入图片描述

我们能够发送请求给集群中任意一节点。每个节点都有能力处理任意请求。每个节点都知道任意文档所在的节点,所以可以将请求转发到需要的节点。下面的例子中,我们将请求发送给Node1,这个节点我们将会称之为请求节点。

notes:当我们发送请求,最好的做法是循环通过所有节点请求,这样可以平衡负载。

新建、索引和删除文档
新建、索引和删除请求都是写(write)操作,它们必须在主分片上成功完成才能复制到相关的复制分片上。
在这里插入图片描述

下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤:

  • 1.客户端给Node1发送新建、索引或删除请求。

  • 2.节点使用文档的_id确定文档属于分片0。他转发请求到Node3,分片0位于这个节点上

  • 3.Node3在主分片上执行请求,如果成功,它转发请求到相应的位于Node1和Node2的复制节点上。当所有复制节点报告成功,Node3报告成功到请求的节点;请求的节点在报告给客户端。

客户端接收到成功响应的时候,文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。
有很多可选的请求参数允许你更改这一过程。你可能想牺牲一些安全来提高性能。这一选项很少使用因为Elasticsearch已经足够快,不过为了内容的完整我们将做一些阐述。
replication(复制)
默认的值是sync。这将导致主分片得到复制分片的成功响应后才返回。
如果你设置replication为async,请求在主分片上被执行后就会返回给客户端。它依旧会转发请求给复制节点,但你将不知道复制节点的成功与否。上面的这个选项不建议使用。默认的sync复制允许Elasticsearch强制反馈传输。async复制可能会因为在不等待其它分片就绪的情况下发送过多的请求而使Elasticsearch过载。
consistency(一致性)
默认主分片在尝试写入时需要规定数量(quorum)或过半的分片(可以是主节点或复制节点)可用。这是防止数据被写入到错的网络分区。规定的数量计算公式如下:
int( (primary + number_of_replicas) / 2 ) + 1
consistency允许的值为one(只有一个主分片),all(所有主分片和复制分片)或者默认的quorum或过半分片。
注意number_of_replicas是在索引中的的设置,用来定义复制分片的数量,而不是现在活动的复制节点的数量。如果你定义了索引有3个复制节点,那规定数量是:
int( (primary + 3 replicas) / 2 ) + 1 = 3
但如果你只有2个节点,那你的活动分片不够规定数量,也就不能索引或删除任何文档。
timeout(超时)
当分片副本不足时会怎样?Elasticsearch会等待更多的分片出现。默认等待一分钟。如果需要,你可以设置timeout参数让它终止的更早:100表示100毫秒,30s表示30秒。

note:新索引默认有1个复制分片,这意味着为了满足quorum的要求需要两个活动的分片。当然,这个默认设置将阻止我们在单一节点集群中进行操作。为了避开这个问题,规定数量只有在number_of_replicas大于一时才生效。

检索文档
文档能够从主分片或任意一个复制分片被检索。
在这里插入图片描述

下面我们罗列在主分片或复制分片上检索一个文档必要的顺序步骤:

  • 1.客户端给Node1发送get请求
  • 2.节点使用文档的_id确定文档属于分片0。分片0对应的复制分片在三个节点上都有。此时它转发请求到Node2。
  • 3.Node2返回文档给Node1然后返回给客户端,对于过多请求,为了平衡负载,请求节点会为每个请求选择不同的分片–他会循环所有分片副本,可能的情况是,一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到,主分片会成功返回文档。一旦索引请求成功返回给用户,文档则在主分片和复制分片都是可用的。

局部更新文档
update API 结合了之前提到的读和写的模式。
在这里插入图片描述

下面我们罗列执行局部更新必要的顺序步骤:

  • 1.客户端给Node1发送更新请求
  • 2.它转发请求到主分片所在节点Node3
  • 3.Node3从主分片检索出文档,修改_source字段JSON,然后在主分片上重建索引。如果有其他进程修改了文档,他将按照retry_on_conflict设置的次数重复步骤3,都为成功则放弃
  • 4.如果Node3成功更新文档,他同时转发文档的新版本到Node1和Node2上的复制节点以重建索引。当所有复制节点报告成功,Node3返回成功给请求节点,然后返回给客户端。

update API还接受《ElasticSearch学习之路-day09》章节提到的routing、replication、consistency和timeout参数。
note:基于文档的复制
当主分片转发更改给复制分片时,并不是转发更新请求,而是转发整个文档的新版本。记住这些修改转发到复制节点是异步的,它们并不能保证到达的顺序与发送相同。如果Elasticsearch转发的仅仅是修改请求,修改的顺序可能是错误的,那得到的就是个损坏的文档

多文档模式
mget和bulk API与单独的文档类似。差别是请求节点知道每个文档所在的分片。它把多文档请求拆成每个分片的对文档请求,然后转发每个参与的节点。
一旦接收到每个节点的应答,然后整理这些响应组合为一个单独的响应,最后返回给客户端
在这里插入图片描述

下面我们将罗列通过一个mget请求检索多个文档的顺序步骤

  • 1.客户端向Node1发送mget请求
  • 2.Node1位每个分片构建一个或者多条数据检索请求,然后转发到这些请求所需的主分片或者复制分片上。
  • 3.当所有回复被接收,Node1构建响应并返回给客户端

routing参数可以被docs中的每个文档设置

下面我们将罗列使用一个bulk执行多个create、index、delete和update请求的顺序步骤:
在这里插入图片描述

  • 1.客户端向Node1发送bulk请求

  • 2.Node1为每个分片构建批量请求,然后转发到这些请求所需的分片上。

  • 3.主分片一个接一个有序的执行操作。当一个操作执行完,主分片转发新文档(或删除部分)给对应的复制节点,然后执行下一个操作。一旦所有复制节点报告所有操作已成功完成,节点就报告success给请求节点后者整理响应并返回给客户端

    bulk API还可以在最上层使用replication和consistency参数,routing参数则在每个请求的元数据中使用。

为什么是奇怪的格式?
当我们在《批量》一章中学习了批量请求之后,你可能会问:“为什么bulkAPI需要带换行符的奇怪格式,而不是像mget API一样使用JSON数组?”
为了回答这个问题,我们需要简单的介绍一下背景
批量中每个引用的文档属于不同的主分片,每个分片可能被分布于集群中的某个节点上。这意味着批量中的每个操作(action)需要被转发到对应的分片和节点上。
如果每个单独的请求被包装到JSON数组中,那意味着我们需要:
1.解析JSON为数组(包括文档数据,可能非常大)
2.检查每个请求决定应该到那个分片上
3.为每个分片创建一个请求的数组
4.序列化这些数组为内部传输格式
5.发送请求到每个分片上
这可行,但需要大量的RAM来承载本质上相同的数据,还要创建更多的数据结构使得JVM花更多的时间执行垃圾回收。
取而代之的,Elasticsearch则是从网络缓冲区中一行一行的直接读取数据。它使用换行符识别和解析action/metadata行,以决定哪些分片来处理这个请求。
这些行请求直接转发到对应的分片上。这些没有冗余复制,没有多余的数据结构。整个请求过程使用最小的内存在进行。

下一篇:ElasticSearch学习(九)–核心概念及基本操作

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值