Elasticsearch可以扩展到上百(甚至上千) 的服务器来处理PB级的数据 ,Elasticsearch为分布式而生, 而且它的设计隐藏了分布式本身的复杂性 :
一个节点(node)就是一个Elasticsearch实例,而一个集群(cluster)由一个或多个节点组成, 它们具有相同的 cluster.name ,它们协同工作, 分享数据和负载。 当加入新的节点或者删除一个节点时, 集群就会感知到并平衡数据
集群中一个节点会被选举为主节点(master),它将临时管理集群级别的一些变更, 例如新建或删除索引、 增加或移除节点等。主节点不参与文档级别的变更或搜索, 这意味着在流量增长的时候, 该主节点不会成为集群的瓶颈。 任何节点都可以成为主节点。
做为用户, 我们能够与集群中的任何节点通信, 包括主节点。 每一个节点都知道文档存在于哪个节点上, 它们可以转发请求到相应的节点上。 我们访问的节点负责收集各节点返回的数据, 最后一起返回给客户端。 这一切都由Elasticsearch处理
分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分
分片就是一个Lucene实例, 并且它本身就是一个完整的搜索引擎
文档存储在分片中, 并且在分片中被索引, 但是我们的应用程序不会直接与它们通信, 取而代之的是, 直接与索引通信
分片是Elasticsearch在集群中分发数据的关键。 把分片想象成数据的容器。 文档存储在分片中, 然后分片分配到你集群中的节点上。 当你的集群扩容或缩小, Elasticsearch将会自动在你的节点间迁移分片, 以使集群保持平衡
每个文档属于一个单独的主分片, 所以主分片的数量决定了索引最多能存储多少数据,分片的最大容量完全取决于你的使用状况: 硬件存储的大小、 文档的大小和复杂度、 如何索引和查询你的文档, 以及你期望的响应时间
索引创建完成的时候, 主分片的数量就固定了, 但是复制分片的数量可以随时调整
主要分片(primary shard)和复制分片(replica shard)
复制分片只是主分片的一个副本, 它可以防止硬件故障导致的数据丢失, 同时可以提供读请求, 比如搜索或者别的shard取回文档
PUT /blogs
{
"settings" : {
"number_of_shards" : 3, //设置主分片数量
"number_of_replicas" : 1 //设置副本分片数量
}
}
集群健康有三种状态:
GET /_cluster/health
返回信息
{
"cluster_name": "elasticsearch",
"status": "yellow", <1>
"timed_out": false,
"number_of_nodes": 1,
"number_of_data_nodes": 1,
"active_primary_shards": 3,
"active_shards": 3,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 3 <2>
}
三个主分片都被分配到 Node 1 ,检查集群状态发现是"yellow",这是因为复制分片还没有节点分配,主要分片和复制分片不能存在同一Node上,因为如果这样分配,就不能进行数据冗余。
第二个节点加入集群, 三个复制分片(replica shards)也已经被分配了——分别对应三个主分片, 这意味着在丢失任意一个节点的情况下依旧可以保证数据的完整性
cluster-health 现在的状态是 green , 这意味着所有的6个分片(三个主分片和三个复制分片) 都已可用
从 Node 1 和 Node 2 来的分片已经被移动到新的 Node 3 上, 这样每个节点就有两个分片, 以代替之前的三个。 这意味着每个节点的硬件资源(CPU、 RAM、 I/O) 被较少的分片共享, 这样每个分片就会有更好的表现
分片本身就是一个完整成熟的搜索引擎, 它可以使用单一节点的所有资源。 使用这6个分片(3个主分片和三个复制分片) 我们可以扩展最多到6个节点, 每个节点上有一个分片, 这样就可以100%使用这个节点的资源了
我们可以让Node数量大于6吗?
主分片的数量在创建索引时已经给定 ,不可更改,这时我们可以增加复制分片的数量,让replica shard数量变为2
PUT /blogs/_settings
{
"number_of_replicas" : 2
}
blogs 索引现在有9个分片: 三个主分片和6个复制分片。 这意味着我们能够扩展到9个节点, 再次的变成每个节点一个分片。 这样使我们的搜索性能相比标准的三节点集群扩展三倍
假设集群Node1宕机,必须有一个主节点来让集群的功能可用,就会在Node2和Node3中选举一个新的主节点,主分片P1,P2,R0分片丢失,但是其他另外两个节点依然保留完整数据,同时在剩下两个节点的复制分片中选举新的primary shard
整个过程瞬间完成,集群依然可以正常对外提供服务,此时集群还可以容忍一个节点宕机,也就是说3个primary shard,6个replica shard,3个Node,最多可以容忍两个节点的宕机。如果这里的repilca shard为3个,最多容忍1个节点宕机,可见副本数和节点的数量决定了集群容错的上限