elasticsearch分布式文档存储

分布式文档存储

路由一个文档到一个分片中

• 索引一个文档时，文档会存储在一个主分片中，该主分片的确定公示如下， routing是一个可变值，默认为文档_id，可设置成一个自定义值，routing的hash函数生成一个数字，余上主分片数得到的余数，则为文档存储分片的位置；这也是为什么主分片数在创建索引的时候就确定好且不能改变的原因。

shard = hash(routing) % number_of_primary_shards

• 所有的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射.一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中

主副分片交互

• 每个节点都有能力处理任意请求，每个节点都知道集群中任一文档位置

• 写操作处理请求流程, Node1为协调节点，写操作必须在主分片上面完成之后才能被复制到相关的副本分片
  

• consistency(一致性) 参数能够影响到以上流程(很少使用)，可能以数据安全为代价提升性能

  1. 默认情况(参数为quorum)： 执行写操作前，主分区都会要求有规定数量(大多数)的分片副本处于活跃可用状态,才会执行写操作(为了避免发生在网络分区故障进行写操作导致数据不一致)，计算方式为int( (primary + number_of_replicas) / 2 ) + 1,number_of_replicas 指的是在索引设置中的设定副本分片数，而不是指当前处理活动状态的副本分片数；（要求只有当 number_of_replicas 大于1的时候，规定数量才会执行）
  2. 参数设置为one,只要主分区状态ok就运行写操作
  3. 参数设置为all，必须要主分片和所有副本状态没问题才运行写操作

• timeout: 如果没有足够的副本分片,Elasticsearch会等待，希望更多的分片出现。默认情况下，它最多等待1分钟

取回单个文档

• 取回单个文档流程如下
  

• 在处理请求时，协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均衡

局部更新文档

• 局部更新文档流程如下
  
• 更新步骤
  
  1. 客户端向 Node 1 发送更新请求
  2. 它将请求转发到主分片所在的 Node 3
  3. Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，并且尝试重新索引主分片的文档。 如果文档已经被另一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次后放弃
  4. 如果 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的副本分片，重新建立索引。 一旦所有副本分片都返回成功， Node 3 向协调节点也返回成功，协调节点向客户端返回成功（注意是发送全新的文档到副本分片，而不是发送更改）

mget取多个文档

• 流程如下
  
• 步骤
  
  1. 客户端向 Node 1 发送 mget 请求
  2. Node 1 为每个分片构建多文档获取请求，然后并行转发这些请求到托管在每个所需的主分片或者副本分片的节点上。一旦收到所有答复， Node 1 构建响应并将其返回给客户端

使用 bulk 修改多个文档

• 流程图如下
  
• 步骤
  
  1. 客户端向 Node 1 发送 bulk 请求
  2. Node 1 为每个节点创建一个批量请求，并将这些请求并行转发到每个包含主分片的节点主机
  3. 主分片一个接一个按顺序执行每个操作。当每个操作成功时，主分片并行转发新文档（或删除）到副本分片，然后执行下一个操作。 一旦所有的副本分片报告所有操作成功，该节点将向协调节点报告成功，协调节点将这些响应收集整理并返回给客户端