1)Cluster:集群
ES可以作为一个独立的单个搜索服务器。不过,为了处理大型数据集,实现容错和高可用性,ES可以运行在许多互相合作的服务器上。这些服务器的集合称为集群,集群内的节点的cluster.name相同。
2)Node:节点
形成集群的每个服务器称为节点。
ES 为分配不同的任务,定义了以下几个节点角色:Master,Data Node,Coordinating Node,Ingest Node
Master 节点:每个 ES 节点启动之前都会有个默认配置 node.master:true ,也就是说每个节点都有可能成为 Master 节点,这些节点被称作 Master-eligible nodes ,就是合格的有资格成为 Master 节点的节点。
当然 Master 只能有一个,所以会通过选举的方法对这启动的节点选举,被选中的节点才会成为 Master 节点。
Master 节点主要是负责维护集群的状态,像所有节点的信息,所有的索引和它相关的 Mapping 关系,配置信息,分片的路由等。
既然 Master 节点维护了这么重要的信息,玩意它挂了怎么办?
挂了的话,将会对其他的有资格成为 Master 节点的节点重新选举出另一个 Master 节点,因此这就说明了其他 Master-eligible nodes 也会保存集群信息,但是只有 Master 节点有权限能够修改,试想如果其他节点也能修改的话,这将会导致数据不一致的问题。
Data Node 节点:数据节点,这个节点主要负责数据的存储,在数据扩展上起到了至关重要的作用。也就是说读写数据都会找到相应的 Data Node 节点。
Coordinating Node 节点:协调节点主要负责协调客户端的请求,将接收到的请求分发给合适的节点,并把结果汇集到一起。比如客户端请求查询某个索引的数据,协调节点将会把请求分发给保存相关的数据的 DataNode 节点,找到相应的分片,并把查询到的结果都汇集返回。并且每个节点都默认起到了 Coordinating Node 的职责。
Ingest Node节点: Ingest node 专门对索引的文档做预处理,发生在对真实文档建立索引之前。在建立索引对文档预处理之前,先定义一个管道(pipeline),管道里指定了一系列的处理器。每个处理器能够把文档按照某种特定的方式转换。比如在管道里定义一个从某个文档中移除字段的处理器,紧接着一个重命名字段的处理器。集群的状态也会被存储到配置的管道内。定义一个管道,简单的在索引或者bulk request(一种批量请求方法)操作上定义 pipeline 参数,这样 ingest node 就会知道哪个管道在使用。这个节点在使用过程中用的也不多,所以大概了解一下就行。
说明:
- 一个节点可以充当一个或多个角色,默认三个角色都有。
- 协调节点:一个节点只作为接收请求、转发请求到其他节点、汇总各个节点返回数据等功能的节点。就叫协调节点。
3)Index:索引
在 ES 中, 索引是一组文档的集合。索引的作用相当于图书的目录,可以根据目录中的页码快速找到所需的内容。当表中有大量记录时,若要对表进行查询,第一种搜索信息方式是全表搜索,是将所有记录一一取出,和查询条件进行一一对比,然后返回满足条件的记录,这样做会消耗大量数据库系统时间,并造成大量磁盘I/O操作;第二种就是在表中建立索引,然后在索引中找到符合查询条件的索引值,最后通过保存在索引中的ROWID(相当于页码)快速找到表中对应的记录。
4)Shard:分片
当有大量的文档时,由于内存的限制、磁盘处理能力不足、无法足够快的响应客户端的请求等,一个节点可能不够。
这种情况下,数据可以分为较小的分片。每个分片放到不同的服务器上。
当你查询的索引分布在多个分片上时,ES会把查询发送给每个相关的分片,并将结果组合在一起,而应用程序并不知道分片的存在。即:这个过程对用户来说是透明的。
说明:
- 创建索引的时候就确定好主分片的数量,除非重索引。
- 分片对应的存储实体是索引。
- 一个分片就是一个 Lucene 实例
![](/qrcode.jpg)
5)路由
Elasticsearch 如何知道一个文档应该存放到哪个分片中呢?当我们创建文档时,它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢?
首先这肯定不会是随机的,否则将来要获取文档的时候我们就不知道从何处寻找了。实际上,这个过程是根据下面这个公式决定的:
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 的路由参数 ,通过这个参数我们可以自定义文档到分片的映射。一个自定义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。
6)Replia:副本
在创建某个索引之前,需要指定分配这个索引多少个分片?多少个副本?副本就这这个分片的备胎,当分片挂掉了,它的副本就会随时准备上位,因此副本也是个分片只不过不负责主要功能。
不仅仅如此,ES 如何能够提高数据吞吐量呢?增加副本个数就是个不错的选择,比如说读写分离,读数据的时候从副本上读,写数据的时候只用主分片去写。需要注意的是,主分片的个数实在建立索引之前要确定,建立完索引之后,是不能够进行修改的,除非重新建索引。因此在建索引之前,一定要合理的配置分片个数,副本个数的话后期是可以改动的。
为提高查询吞吐量或实现高可用性,可以使用分片副本。
副本是一个分片的精确复制,每个分片可以有零个或多个副本。ES中可以有许多相同的分片,其中之一被选择更改索引操作,这种特殊的分片称为主分片。
当主分片丢失时,如:该分片所在的数据不可用时,集群将副本提升为新的主分片。
Elasticsearch 禁止同一个分片的主分片和副本分片在同一个节点上,所以如果是一个节点的集群是不能有副本的。
它在节点失败的情况下提供高可用性。由于这个原因,需要注意的是,副本分片永远不会分配到与主分片相同的节点上。
如何设置副本
启动 2 个 ES 节点,配置分片个数为 3,副本个数为 1(每个分片有一个副本)。如下图,蓝色的代表主分片,绿色的是副本,仔细一点不难发现,分片与其副本不在同一个节点内。这是非常合理的,因为副本本来就是主分片的备胎,当主分片节点挂了,另外一个节点的副本将会充当主分片,如果它们在同一个节点内,副本将发挥不到作用。
水平扩展原理
单个节点的容量是有限的,如果后期两个节点的容量不能够支持三个分片,那么另外启动一个节点就可以了,ES 会自动的重新规划分片,如下图:可以看到 A3 节点已经被自动的分配到 Node3 节点里面了,另外副本 B1 从 Node2 移动到 Node3 节点,B3 分片从 Node1 节点被分配到 Node2 节点。这里想一下,如果再启动一个节点呢?是的,再启动一个节点将不会对主分片起到任何作用,因为主分片不可以修改,只有三个,但是副本可以修改,能够起到扩容的作用。