Elastic search fragmentation and replication strategy

Elastic search Basic Concepts

Cluster

集群，一个ES集群是由多个节点(Node)组成的，每个集群都有一个cluster name 作为标识
`cluster.name: 【elastic search cluster name】`
在同一网段下的Elastic search实例会通过cluster name 决定加入哪个集群下。
复制代码

node

节点，一个ES实例就是一个node，一个机器可以有多个实例，所以并不是说一台机器就是一个node，大多数情况下，每个node运行在一个独立的环境或者虚拟机上。
复制代码

index

索引，即一系列documents的集合
复制代码

shard

1.分片，ES是分布式搜索引擎，每个索引有一个或多个分片，索引的数据被分配到各个分片上，相当于一桶水   用了N个杯子装
2.分片有助于横向扩展，N个分片会被尽可能平均地（rebalance）分配在不同的节点上（例如你有2个节点，4个主分片(不考虑备份)，那么每个节点会分到2个分片，后来你增加了2个节点，那么你这4个节点上都会有1个分片，这个过程叫relocation，ES感知后自动完成)
3.分片是独立的，对于一个Search Request的行为，每个分片都会执行这个Request.另外
4.每个分片都是一个Lucene Index，所以一个分片只能存放 Integer.MAX_VALUE - 128 = 2,147,483,519个docs。
复制代码

replica

1.复制，可以理解为备份分片，相应地有primary shard（主分片）
2.主分片和备分片不会出现在同一个节点上（防止单点故障），默认情况下一个索引创建5个分片一个备份（即5primary+5replica=10个分片）
3.如果你只有一个节点，那么5个replica都无法分配（unassigned），此时cluster status会变成Yellow。replica的作用主要包括:
复制代码

Partitioning Strategies

Transparent 1.1 distributed architecture hidden attribute

Elasticsearch是一个分布式架构，隐藏了复杂的处理机制
复制代码

Fragmentation mechanism

我们不用关心数据是按照什么机制分片的，最后放到哪个分片中
复制代码

A copy of the slice

为了提升访问压力过大是单机无法处理所有请求的问题，Elasticsearch集群引入了副本策略replica。副本策略对index中的每个分片创建冗余的副本，处理查询时可以把这些副本当做主分片来对待（primary shard），此外副本策略提供了高可用和数据安全的保障，当分片所在的机器宕机，Elasticsearch可以使用其副本进行恢复，从而避免数据丢失。
复制代码

Cluster discovery mechanism (cluster discovery)

比如当前我们启动了一个es进程，当启动了第二个es进程是，这个进程作为一个node自动就发现了集群，并加入进去。

Shard负载均衡：比如现在有10个shard，集群中有3个节点，es会均衡的进行分配，以保证每个节点均衡的负载请求，

请求路由：当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢？当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢？

首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的：

`shard = hash(routing) % number_of_primary_shards`

routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到 余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
复制代码

Expansion mechanism

Vertical expansion

采购更强大的服务器
复制代码

Level expansion

采购越来越多的普通服务器，性能比较一般，但是很多普通服务器组织在一起，就能构成强大的计算和存储能力
复制代码

How to choose the way of expansion

es一般采用方式二水平扩容的方式进行扩容。从成本上来说，内存容量小，并且性能相对较低的服务器相比较与内存容量大，性能好的服务器，在价格上的差距不是一个量级的。
从另一方面来说，elasticSearch是一套分布式的系统，分布式的存在也是为存放大量的数据。讲到elasticSearch的扩容，自然就会想到shard和replica shard。
elasticSearch拥有cluster discovery(集群发现机制),当我们启动一个新的节点，该节点会发现集群并且自动加入到集群中。并且es集群会自动进行各个shard之间的数据均衡处理。
并且当节减少时，es集群也会自动将减少的节点中的数据移到其他正在运行的节点中。
所以elasticSearch一般选择水平扩容的方式。
复制代码

Expansion beyond the limit for expansion

现在有6个shard，3个primary shard 3个replica shard ，6个shard存放在6台服务器中，如何进行扩容，扩容到9台服务器中？
复制代码

因为primary shard在索引创建后就无法进行修改，所以需要将6台服务器扩容到9台服务器只能对replica shard进行增加，可以修改索引配置，将replica shard的数量修改为2，此时replica shard的数量变为6个，加上3个 primary shard 就是9个 shard
复制代码

Rebalance: Auto EQ:

增加节点时会自动均衡
创建一个index
`PUT 60.205.176.135:9200/product
{
"settings" : {
    "index" : {
        "number_of_shards" : 5, 
        "number_of_replicas" : 1 
    }
}
复制代码

} `When only one node:

Then start a node:

Start the third node:

Master node

（1）创建或删除索引
（2）增加或删除节点
主节点的主要职责是和集群操作相关的内容，如创建或删除索引，跟踪哪些节点是集群的一部分，并决定哪些分片分配给相关的节点，稳定的主节点对集群的健康是非常重要的
复制代码

Peer node

（1）节点对等，每个节点都能接收所有的请求
（2）自动请求路由
（3）响应收集
每个节点都能接收请求，每个节点接收到请求后都能把该请求路由到有相关数据的其他节点上，接收原始请求的节点负责采集数据并返回给客户端
复制代码

And a copy of the fragmentation mechanism

1.一个index中包含多个shard
2.每个shard都是一个最小工作单元，承载部分数据；每个shard都是一个Lucene实例，有完整的建立索引和处理请求的能力
3.增减节点时，shard会自动在nodes中负载均衡
4.primary shard 和 relica shard,每个document只会存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard中
5.replica shard 是primary shard 的副本，负责容错，以及承担读请求的负载均衡
6.primary shard在创建索引的时候就固定了，relica shard的数量可以随时更改
7.primary shard 和 它对应的replica shard 不能放在同一台机器上，不然起不了容错的作用
复制代码

shard & replica mechanism Summarization

1. index包含多个shard
2. 每个shard都是一个最小工作单元，承载部分数据，lucene实例，完整的建立索引和处理请求的能力
3. 增减节点时，shard会自动在nodes中负载均衡
4. primary shard和replica shard，每个document肯定只存在于某一个primary shard以及其对应的replica   shard中，不可能存在于多个primary shard
5. replica shard是primary shard的副本，负责容错，以及承担读请求负载
6. primary shard的数量在创建索引的时候就固定了，replica shard的数量可以随时修改
7. primary shard的默认数量是5，replica默认是1，默认有10个shard，5个primary shard，5个replica shard
8. primary shard不能和自己的replica shard放在同一个节点上（否则节点宕机，primary shard和副本都丢失，起不到容错的作用），但是可以和其他primary shard的replica shard放在同一个节点上，因此，这个index是由6个shard组成的
复制代码

How is a multi-shard queries

一个 CRUD 操作只对单个文档进行处理，文档的唯一性由 _index, _type, 和 routing values （通常默认是该文档的 _id ）的组合来确定。 这表示我们确切的知道集群中哪个分片含有此文档。

搜索需要一种更加复杂的执行模型因为我们不知道查询会命中哪些文档: 这些文档有可能在集群的任何分片上。 一个搜索请求必须询问我们关注的索引（index or indices）的所有分片的某个副本来确定它们是否含有任何匹配的文档。

但是找到所有的匹配文档仅仅完成事情的一半。 在 search 接口返回一个 page 结果之前，多分片中的结果必须组合成单个排序列表。 为此，搜索被执行成一个两阶段过程，我们称之为 query then fetch 
复制代码

Queries stage

查询阶段包含以下三个步骤:
复制代码

客户端发送一个 search 请求到 Node 3 ， Node 3 会创建一个大小为 from + size 的空优先队列。
Node 3 将查询请求转发到索引的每个主分片或副本分片中。每个分片在本地执行查询并添加结果到大小为 from + size 的本地有序优先队列中。
每个分片返回各自优先队列中所有文档的 ID 和排序值给协调节点，也就是 Node 3 ，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
当一个搜索请求被发送到某个节点时，这个节点就变成了协调节点。 这个节点的任务是广播查询请求到所有相关分片并将它们的响应整合成全局排序后的结果集合，这个结果集合会返回给客户端。

第一步是广播请求到索引中每一个节点的分片拷贝。就像 document GET requests 所描述的， 查询请求可以被某个主分片或某个副本分片处理， 这就是为什么更多的副本（当结合更多的硬件）能够增加搜索吞吐率。 协调节点将在之后的请求中轮询所有的分片拷贝来分摊负载。

每个分片在本地执行查询请求并且创建一个长度为 from + size 的优先队列—也就是说，每个分片创建的结果集足够大，均可以满足全局的搜索请求。 分片返回一个轻量级的结果列表到协调节点，它仅包含文档 ID 集合以及任何排序需要用到的值，例如 _score 。

协调节点将这些分片级的结果合并到自己的有序优先队列里，它代表了全局排序结果集合。至此查询过程结束。
复制代码

Getting Results stage

分布式阶段由以下步骤构成：
协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求
每个分片加载并 丰富 文档，如果有需要的话，接着返回文档给协调节点。
一旦所有的文档都被取回了，协调节点返回结果给客户端。
协调节点首先决定哪些文档 确实 需要被取回。例如，如果我们的查询指定了 { "from": 90, "size": 10 } ，最初的90个结果会被丢弃，只有从第91个开始的10个结果需要被取回。这些文档可能来自和最初搜索请求有关的一个、多个甚至全部分片。

协调节点给持有相关文档的每个分片创建一个 multi-get request ，并发送请求给同样处理查询阶段的分片副本。

分片加载文档体-- _source 字段--如果有需要，用元数据和 search snippet highlighting 丰富结果文档。 一旦协调节点接收到所有的结果文档，它就组装这些结果为单个响应返回给客户端。
复制代码

Creating a single-node index

1. Single-node environment, create an index, there are three primary shard, 3 Ge replica shard
2. Cluster status is yellow
3. This time, three primary shard will only be assigned to only one node up, the other three replica shard is not allocated
4. Clusters can work, but once the node goes down occurs, all the data is lost, but the cluster is unavailable, you can not undertake any request

PUT /test_index { "settings" : { "number_of_shards" : 3, "number_of_replicas" : 1 } }

2 node to create index

1. replica shard distribution: three primary shard, 3 th replica shard, 1 node
2. primary ---> replica synchronization