Elasticsearch核心知识篇(28)
什么是distributed document store
distributed document store
Elasticsearch在跑起来以后，其实起到的第一个最核心的功能，就是一个分布式的文档数据存储系统。ES是分布式的。文档数据存储系统。文档数据，存储系统。
- 文档数据：es可以存储和操作json文档类型的数据，而且这也是es的核心数据结构。
- 存储系统：es可以对json文档类型的数据进行
存储，查询，创建，更新，删除等等操作。其实ES满足了这些功能，就可以说已经是一个NoSQL的存储系统了。
围绕着document在操作，其实就是把es当成了一个NoSQL存储引擎，一个可以存储文档类型数据的存储系统，在操作里面的document。
es可以作为一个分布式的文档存储系统，所以说，我们的应用系统，是不是就可以基于这个概念，去进行相关的应用程序的开发了。
- 适合应用程序类型
- 数据量较大，es的分布式本质，可以帮助你快速进行扩容，承载大量数据
- 数据结构灵活多变，随时可能会变化，而且数据结构之间的关系，非常复杂，如果我们用传统数据库，那是不是很坑，因为要面临大量的表
- 对数据的相关操作，较为简单，比如就是一些简单的增删改查，用我们之前讲解的那些document操作就可以搞定
- NoSQL数据库，适用的也是类似于上面的这种场景
举个例子，比如说像一些网站系统，或者是普通的电商系统，博客系统，面向对象概念比较复杂，但是作为终端网站来说，没什么太复杂的功能，就是一些简单的CRUD操作，而且数据量可能还比较大。这个时候选用ES这种NoSQL型的数据存储，比传统的复杂的功能务必强大的支持SQL的关系型数据库，更加合适一些。无论是性能，还是吞吐量，可能都会更好。
Elasticsearch核心知识篇(29)
分布式文档系统_深度图解剖析document数据路由原理
document路由到shard上是什么意思？
- 数据路由
- 一个index的数据会被分成多片，每片都在一个shard中，一个document只能存在于一个shard中
- 当客户端创建document的时候，es此时就要决定说这个document是放在这个index的哪个shard上。
- 这个过程，就称之为document routing 数据路由。
路由算法
路由算法：shard = hash(routing) % number_of_primary_shards
- 计算过程：
- 举个例子，一个index有3个primary shard，P0，P1，P2
- 每次增删改查一个document的时候，都会带过来一个routing number，默认就是这个document的_id（可能是手动指定，也可能是自动生成） routing = _id，假设_id=1
- 会将这个routing值，传入一个hash函数中，产出一个routing值的hash值，hash(routing) = 21 , 然后将hash函数产出的值对这个index的primary shard的数量求余数，21 % 3 = 0 , 就决定了，这个document就放在P0上。
- 规则：
- 决定一个document在哪个shard上，最重要的一个值就是routing值，默认是_id，也可以手动指定，相同的routing值，每次过来，从hash函数中，产出的hash值一定是相同的
- 无论hash值是几，无论是什么数字，对number_of_primary_shards求余数，结果一定是在0~number_of_primary_shards-1之间这个范围内的。0,1,2。
_id or custom routing value
默认的routing就是_id，也可以在发送请求的时候，手动指定一个routing value，比如说put /index/type/id?routing=user_id
- 手动指定routing value是很有用的，可以保证说，某一类document一定被路由到一个shard上去，那么在后续进行应用级别的负载均衡，以及提升批量读取的性能的时候，是很有帮助的
primary shard数量不可变的谜底
- 主要就是和路由的公式有关，我们存入数据之后，路由就已经确定了，假设primary shard的数量变了，在计算路由的时候原本计算的是3，改变后计算的是4，最终我们不能找到数据，影响了数据的正确性
Elasticsearch核心知识篇(30)
分布式文档系统_document增删改内部原理图解揭秘
- 客户端选择一个node发送请求过去，这个node就是
coordinating node（协调节点） - coordinating node，对document进行路由，将请求转发给对应的node（有primary shard）
- 实际的node上的primary shard处理请求，然后将数据同步到replica node
- coordinating node，如果发现primary node和所有replica node都搞定之后，就返回响应结果给客户端
- 额外总结：
- 增删改的操作，请求只能由primary shard进行处理，不能由replica shard进行处理
Elasticsearch核心知识篇(31)
分布式文档系统_图解写一致性原理以及quorum机制深入剖析
写一致性
consistency，one（primary shard），all（all shard），quorum（default）
我们在发送任何一个增删改操作的时候，比如说put /index/type/id，都可以带上一个consistency参数，指明我们想要的写一致性是什么？
put /index/type/id?consistency=quorum- one：要求我们这个写操作，只要有一个primary shard是active活跃可用的，就可以执行
- all：要求我们这个写操作，必须所有的primary shard和replica shard都是活跃的，才可以执行这个写操作
- quorum：默认的值，要求所有的shard中，必须是大部分的shard都是活跃的，可用的，才可以执行这个写操作
quorum机制
- 写之前必须确保大多数shard都可用
quroum = int( (primary + number_of_replicas) / 2 ) + 1
举个例子
3个primary shard，number_of_replicas=1，总共有3 + 3 * 1 = 6个shard quorum = int( (3 + 1) / 2 ) + 1 = 3 所以，要求6个shard中至少有3个shard是active状态的，才可以执行这个写操作
- 如果节点数少于quorum数量，可能导致quorum不齐全，进而导致无法执行任何写操作
3个primary shard，replica=1，要求至少3个shard是active，3个shard按照之前学习的shard&replica机制，必须在不同的节点上，如果说只有2台机器的话，是不是有可能出现说，3个shard都没法分配齐全，此时就可能会出现写操作无法执行的情况
1个primary shard，replica=3，quorum=((1 + 3) / 2) + 1 = 3，要求1个primary shard + 3个replica shard = 4个shard，其中必须有3个shard是要处于active状态的。如果这个时候只有2台机器的话，会出现什么情况呢？(补充一个知识点：就是同一个primary shard的多个replic shard也是不能放在同一个节点上面的)
对于下面图片的理解：我们有1个primary shard 和3个replic shard和2个node,将shard放在node中，遵循原则：replic不能和primary放一起，primary独占一个node;同时同一primary的不同replic不能放在同一个node上，这样r0单独站一个node,其余的两个replic shard失效，只有两个shard 是active的状态，但是大多数原则，至少要3个及以上活跃才能保证写可以进行，但是只有两个active,现在写操作不能执行
es提供了一种特殊的处理场景
就是说当number_of_replicas>1时才生效，因为假如说，你就一个primary shard，replica=1，此时就2个shard
(1 + 1 )/2 + 1 = 2，要求必须有2个shard是活跃的，但是可能就1个node，此时就1个shard是活跃的，如果你不特殊处理的话，导致我们的单节点集群就无法工作
- quorum不齐全时，wait，默认1分钟，timeout，100，30s
- 等待期间，期望活跃的shard数量可以增加，最后实在不行，就会timeout
- 我们其实可以在写操作的时候，加一个timeout参数，比如说
put /index/type/id?timeout=30，这个就是说自己去设定quorum不齐全的时候，es的timeout时长，可以缩短，也可以增长
