ElasticSearch文档操做介绍三

ElasticSearch文档的操做

 

文档存储位置的计算公式:

shard = hash(routing) % number_of_primary_shards

上面公式中，routing 是一个可变值，默认是文档的 _id ，也能够设置成一个自定义的值。 routing 经过 hash 函数生成一个数字，而后这个数字再除以 number_of_primary_shards （主分片的数量）后获得 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是咱们所寻求的文档所在分片的位置。

这就解释了为何咱们要在建立索引的时候就肯定好主分片的数量 而且永远不会改变这个数量：由于若是数量变化了，那么全部以前路由的值都会无效，文档也再也找不到了。

全部的文档 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一个叫作 routing 的路由参数 ，经过这个参数咱们能够自定义文档到分片的映射。一个自定义的路由参数能够用来确保全部相关的文档——例如全部属于同一个用户的文档——都被存储到同一个分片中。

ElasticSearch中，新建、删除、索引文档都属于写操做，必须在主分片上面完成以后才能被复制到相关的副本分片。

写一个文档:

下图是官网的一个例子，假设集群中有三个节点，一个索引，两个主分片，每一个主分片有两个副本。写操做一个文档的过程以下:

一、客户端向 Node 1 发送新建、索引或者删除请求。
二、节点使用文档的 _id 肯定文档属于分片 0 。请求会被转发到 Node 3`，由于分片 0 的主分片目前被分配在 `Node 3 上。
三、Node 3 在主分片上面执行请求。若是成功了，它将请求并行转发到 Node 1 和 Node 2 的副本分片上。一旦全部的副本分片都报告成功, Node 3 将向协调节点(接受客户端请求的节点)报告成功，协调节点向客户端报告成功。

在客户端收到成功响应时，文档变动已经在主分片和全部副本分片执行完成，变动是安全的。

 

读一个文档:

检索(读取)一个文档时，能够从主分片或者其余任意副本分区检索。

如下是从主分片或者副本分片检索文档的步骤顺序：

一、客户端向 Node 1 发送获取请求。

二、节点使用文档的 _id 来肯定文档属于分片 0 。分片 0 的主、副分片存在于全部节点上。 在这种状况下，它将请求转发到 Node 2 。

三、Node 2 将文档返回给 Node 1 ，而后将文档返回给客户端。

在处理读取请求时，协调结点在每次请求的时候都会经过轮询全部的副本分片来达到负载均衡。

在文档被检索时，已经被索引的文档可能已经存在于主分片上可是尚未复制到副本分片。 在这种状况下，副本分片可能会报告文档不存在，可是主分片可能成功返回文档。 一旦索引请求成功返回给用户，文档在主分片和副本分片都是可用的。

 

部分更新一个文档: 

 

如下是部分更新一个文档的步骤：

一、客户端向 Node 1 发送更新请求。二、它将请求转发到主分片所在的 Node 3 。三、Node 3 从主分片检索文档，修改 _source 字段中的 JSON ，而且尝试从新索引主分片的文档。 若是文档已经被另外一个进程修改，它会重试步骤 3 ，超过 retry_on_conflict 次后放弃。四、若是 Node 3 成功地更新文档，它将新版本的文档并行转发到 Node 1 和 Node 2 上的副本分片，从新创建索引。 一旦全部副本分片都返回成功， Node 3 向协调节点也返回成功，协调节点向客户端返回成功。