我是这么理解es基本概念的

目录

 

写在前面

一、基本概念

1. 节点 node

1.1 主节点 master

1.2 数据节点 data

1.3 协调节点 coordinating

1.4 预处理节点 ingest

2. 集群 cluster

3. 索引 index

3.1 mapping

3.2 setting

4. 分片 shard

4.1 主分片 和 副本 replica

5. 路由 routing

---

写在前面

本人目前是es入门，刚刚尝试着搭建了es集群，还没有实际经验，所以是纯理论

看着配置文件中各项配置，和一些基本概念，去看数据怎么存储的

所以，想从基本的概念入手（结果这些个基本概念也折磨了好久，怎么都理不清）

一、基本概念

网上查资料的时候，发现很多内容都是重复的，而且我理解能力有限，总是不明白他们到底说的是啥（很多时候是名词解释名词，各种嵌套查资料，而且看他们解释一个东西总是有种断层的感觉，后来发现是解释的角度不同）

1. 节点 node

安装一个es，启动起来，一个节点就好了，然后它也可以叫做启动了一个es实例

然后它就可以存储、查找数据了，至于怎么存储和查找后面结合别的概念说

反正es能干啥，节点就能干啥，换句话说不考虑性能问题，单节点具备es的所有功能

为啥说到es，都要搞集群呢

为了高性能，而且es的设计思路就是按照集群来的，并且es吃内存啊，如果就一台机器，随着数据量的增加，早晚不都会满了吗，所以就多台机器上都安装es，让它们一起存数据，这样撑的久一点。。。（数据一直增加，满是早晚的事，只是这个时间可能是几年，十几年，上百年。。。）

从功能上讲，节点一般分为：

1.1 主节点 master

es集群的皇帝，所以只能有一个，但是会有一群皇子等着继承它的位置呢

皇帝干吗的？统筹指挥的，处理整体规划的，维护帝国稳定的

所以master主要负责维护集群的稳定，各种配置--索引、分片、路由等等，而且只有它能修改

累不累？累，没日没夜的收集很多奏章，批改完再发下去

能干具体活吗（存数据）？能，但是人家已经很累了

所有不推荐master节点用来存储数据

1.1.1 备选主节点 Master-eligible

皇太子们

配置中设置该种节点的数量后，从此种节点中选举出master节点

1.2 数据节点 data

具体干活的---存储、读取数据，也是性能优化的重点

1.3 协调节点 coordinating

分发请求到合适的节点，同时把结果汇集

1.4 预处理节点 ingest

对索引文档做预处理

 

这些叫es的角色划分，一个es实例可以是多种节点，比如：master可以同时具备data节点功能

需要在配置中对节点角色做具体划分

后面基本都是基于数据节点说的，因为平常的操作都是操作数据节点

2. 集群 cluster

就是一堆节点加一起的一个群体，一个整体

从外部看，它们是一个整体，而且外部（比如：我们部署的项目）使用它们的时候，不用管这个整体内部是怎么运作的，能用就行

至于怎么保证这个群体稳定的运行，就涉及到es的性能优化问题，这不在研究中吗，名词先搞懂

3. 索引 index

网上的说法是一个文档，类比于关系数据库的库或者表

啥意思，就是个存数据的盒子，容器呗，只是别把它当成规则形状的，想象成蚂蚁城堡中的窝或者地道战房子的形状----一个个小窝或者一个个房子，彼此之间有“暗道”链接起来的

这么说来，索引理解为 网状容器 比较贴切

然后有mapping，setting。。。这都啥呀，对比关系型数据库我还是理解半天（真的我理解能力有问题）

还是用我自己的话说吧

3.1 mapping

数据不是人为的分成了很多种类型吗，什么string、Integer、long等等的

mapping就是把索引网状容器各个内部捏一捏，规定一下内部形状，也就是这个网状容器中能存这种、这种和那种类型的数据

3.2 setting

上面说了，索引这个容器是网状的

为什么是网状的，就是setting决定的

这么理解：索引一开始是一个规则的盒子，然后setting对这个盒子做出一些规定

比如：

把盒子切除4份，这样数据进来之后，这4份就可以各自存这批数据的一部分，同时彼此之间知道其他部分存了什么数据（至于怎么知道的，就是es内部自己实现的了），它们也能联系到彼此（暗道），这4份就叫分片

详细一点就是：我把一首绝句，每次一句存到同一个索引中，这样正好每个分片存一句，并且存的时候当前分片知道后面一句在哪个分片中

4. 分片 shard

分片是存储和查询实际干活的单元

查资料的时候，这个概念都会说是把数据存储在不同的地方

我觉得这种解释是对的，但是我理解能力有限，或者说不符合我的理解思路

这个时候还在创建，或者说规定索引的形状呢，哪来的数据！！！用它的功能来解释概念，我思维转不过来

所以我的理解是： 预先把索引这个容器，按照setting，分成不同的部分，以便数据进来时，就可以分开存储了，也就是上面说的把容器切分后的小部分，索引是对它们合起来之后的总称

这里进阶一下，当是集群或者说多个节点的时候，分片们被分布到各个节点，就像许完愿的七龙珠，setting完之后，就散开到各个地方（节点）了

所以index这个网状容器，是纵观各个节点之后的形状

所以既然节点之间能知道彼此，分片之间也能知道彼此（心跳检测？）

回顾下的话，从框架上来说，es集群由节点组成；而从数据上来说，es集群由分片组成

当整个集群只有一个索引的时候，一个分片一个节点；有两个索引，两个分片一个节点

（别扯setting怎么配置问题，我是在帮助理解名词）

分片 其实也是一个整体概念，由两部分组成： 主分片 和 副本（副分片、副本分片）

4.1 主分片 和 副本 replica

主分片作用是存储数据，副本作用提高查询吞吐量以及实现高可用

一般说的分片，指的就是主分片，副本是对主分片的精确复制

它俩结合在一起才是es高性能的体现：能存数据，能很快的给出需要的数据

主分片是实际的小容器，副本是皇太子（不是皇子，主分片和副本是一一对应的）

就等着主分片驾崩：主分片能干的事它都能干，就差一个名分

至于为啥要副本

这么说吧，主分片应该好理解。那么如果节点中只有主分片会怎么样？

不怎么样，之前说的一首诗照样能存进来，照样能给出去，因为4个主分片每个存一句，并且知道彼此。所以查的时候把每个节点都走一遍，然后结果合并一下给出去就行了。看起来没问题，实际呢？

问题一：每个分片或者说节点都查一遍是不是要时间？

问题二：每次查询都会把所有的节点走一遍，所有分片是不是都有同样的压力？并且访问量大的话，这个压力是不是也大？

问题三：在这个压力下，或者网络不稳定时，有分片或节点不能用了，数据是不是就凑不齐了？

所以怎么办？

所以又搞出来了一个副本

还是那首诗，4句存完之后，在第一个分片搞3个副本，是另外3个分片中那三句诗的备份。并且es内部算法，让这3个副本一定是另外3句诗的备份，而不是这句诗的备份。其他三个同上设置副本

相当于存数据的时候，存一遍，再copy一遍

这样不就可只查一个分片或者节点就能给出整首诗了！

问题一问题二直接解决

问题三，如果有分片或者节点不能用。所以赋予了副本另一个能力--它对应的主分片失效时，它成为主分片，这样数据没丢，照样只查一个节点就能提供完整数据

5. 路由 routing

路由牵扯到数据往哪存，从拿取的问题

上面那首诗，这个4节点的集群为什么能够一个节点只存一句（数据均匀分布）？

在数据存入es之前，计算好这批数据将往哪个分片放

有个公式：

shard = hash(routing) % number_of_primary_shards

shard：分片，数据将要存到这个分片

hash：hash函数，得到hash数值

routing：路由变量，一个唯一值，默认文档id，可以配置

number_of_primary_shards：主分片数，来自配置

根据这个存取数据就知道往哪里存，从哪里取了

 

到这来的话，我个人是对这么东西有了个自己的理解，那么后面要研究的就是：

数据 1. 存哪里   2. 存多少 的问题了

呃，未完待续吧....

后面有思路了，再把链接贴过来