目录
写在前面
本人目前是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. 存多少 的问题了
呃,未完待续吧....
后面有思路了,再把链接贴过来