集群扩容
Elasticsearch 可以随时按需扩容。扩容的方式有水平扩容、垂直扩容。
- 水平扩容:添加更多的服务器,使集群的负载能力更强
- 垂直扩容:替换性能更强的机器,使集群的负载能力更强
显然垂直扩容需要大量资金,并且有瓶颈。水平扩容更合适用来提升集群的负载能力。
横向扩容则需要分布式技术来支持,对于大多数的数据库而言,通常需要对应用程序进行非常大的改动,才能利用上横向扩容的新增资源。而ElastiSearch天生就是 分布式的 ,它知道如何通过管理多节点来提高集群负载能力。
集群通信
- Elasticsearch 中的集群,无非就是一个或多个
cluster.name
相同的节点,它们共同承担数据和负载的压力。当有节点加入集群中或者从集群中移除节点时,集群将会重新平均分布所有的数据。 - Elasticsearch 的集群也有master节点,但是它只负责管理集群范围内的所有变更,例如增加、删除索引,或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作,所以当集群只拥有一个主节点的情况下,即使流量的增加它也不会成为瓶颈。
- 用户的请求可以发送到集群的任意节点中,每个节点都知道任意文档所处的位置,通过文档进行routing,能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点,它都能负责从这些节点收集回数据,并将最终结果返回給客户端。
集群状态
可以通过GET /_cluster/health
API查看集群的状态:
{
"cluster_name" : "docker-cluster",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 2,
"number_of_data_nodes" : 2,
"active_primary_shards" : 4,
"active_shards" : 6,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 100.0
}
这里主要关注status的值:
- green:所有的主分片和副本分片都正常运行。
- yellow:所有的主分片都正常运行,但不是所有的副本分片都正常运行。
- red:有主分片没能正常运行。
shard 详解
- 从客户端看来,数据插入、查询等操作都是基于 index 而言,index实际上是由一个或多个 shard 组成,而我们在查询的时候并没有关注数据应该去哪个 shard 查询,这是因为ES屏蔽掉了细节,这也是ES深受广大程序员青睐的原因之一,简单、易用。
- 而这一个个 shard 其实就是一个个Lucene实例。而我们在做数据插入时,存储document数据的具体容器也是 shard。ES会将shards尽可能的均匀分配到集群中的每个节点上。并且在集群节点的动态增减后也同样有效。
- shard 又分为 primary shard 和 replace shard,前面所说的基本是 primary shard 的功能,也就是说某一个document 数据其实是放在某一个 primary shard 中的,而一个 primary shard 是有存储上限(Integer.MAX_VALUE - 128)的,由此可以知道primary shard 数量能够大致决定 index 的数据存储上限。
- replace shard 的功能除了对其 primary shard 做数据备份以外,还能为搜索API提供服务。
- primary shard 只能在新建 index 时设置,且不允许对已经存在的 index 做修改。
- replace shard 可以随时修改。
- replace shard 不能和其备份的 primary shard 处于同一个节点,所以如果设置了 replace shard 数量,则集群中至少需要俩个节点,否则replace shard 会分配失败,ES存在数据丢失的风险。