ES的中文官方文档

转载

架构领航员 2025-01-07 14:08:13

对ES官网的reference的翻译，同时也是备忘，ES版本为7.5

下面是正文翻译，附上原文链接

https://www.elastic.co/guide/en/elasticsearch/reference/current/scalability.html

==================================================================================================

可扩展性和弹性：集群、节点和分片

ES旨在始终可用并且能够根据你的需要进行扩展，ES通过分布式的本质来实现的。你能够在集群中增加服务器(即节点node)来扩容，ES能够自动分发你的数据和查询负载到所有可用的节点。不需要翻修你的应用，ES了解如何平衡多节点的集群来提供规模和高可用性。节点越多越开心。

这背后的原理是什么呢？在底层，ES索引仅仅只是一个或者多个物理分片的逻辑分组，每个分片实际上是一个独立索引。通过把索引中的文档分发到多个分片，并且把这些分片分布到多个节点，ES能够保证冗余度，随着节点被加入到集群中，这能够防止硬件故障也能增强查询能力。随着集群增长或者收缩，ES能够自动迁移分片来使集群重新平衡。

有两种类型的分片：主分片和副本。索引中的每个文档都属于一个主分片，副本分片是主分片的copy。副本能够提供数据的冗余备份来防止硬件故障并且提高服务读请求(比如搜索或者检索一个文档)的能力。

索引中主分片的个数在索引创建的时候就固定了，但副本分片的数量可以随时改变而不需要中断索引或者查询操作

依赖于...

索引中主分片的个数以及分片的大小涉及到一系列性能考虑和权衡。分片越多，维护这些分片的开销越大；分片越大，当需要重新平衡集群时移动分片的时间越长。

查询大量小分片会让每个分片的处理更快，但更多的查询意味着更大的开销，因此查询小数量的更大的分片kennel更快。总之，得看情况。

作为一个出发点：

1）旨在保证平均的分片大小在几GB到几十GB之间。当使用基于时间的数据时，分片大小在20GB-40GB是正常的

2）避免庞大的分片问题。单个节点能够负载的分片数量跟可用的堆空间成正比。作为一个通用规则，每GB堆空间承载的分片数量应该小于20

针对你的用例，决定最优配置的最好的方式就是通过你自己的数据和查询来测试。

灾难场景

出于性能的考虑，集群中的节点需要位于同一个网络上，平衡同一个集群内位于不同网络中心的节点上的分片需要花费很长时间。但是高可用架构要求你不能把所有的鸡蛋放在同一个篮子里，当某个地点发生重大事故时，另一个地点的服务器能够无缝的取而代之。解决方法？跨集群复制(Cross-cluster replication (CCR))

CCR提供了一种可以自动从主集群同步索引到二级远程集群(可以用来作为热备)的方式，如果主集群故障，二级集群可以取而代之。你也可以使用CCR来创建二级集群以服务地理距离更优的用户的读请求。

CCR是主动-被动的。主集群的索引是主动领导索引并处理所有写请求，复制到二级集群的索引是只读的跟随者。