## 可扩展性和弹性：集群，节点和碎片 Elasticsearch旨在始终可用并根据您的需求扩展。它是通过自然分布来实现的。您可以将服务器（节点）添加到集群以增加容量，Elasticsearch会自动在所有可用节点之间分配数据和查询负载。无需大修您的应用程序，Elasticsearch知道如何平衡多节点集群以提供扩展性和高可用性。节点越多，越好。 这是如何运作的？在幕后，Elasticsearch索引实际上只是一个或多个物理碎片的逻辑分组，其中每个碎片实际上是一个独立的索引。通过将文档分布在多个分片中的索引中，然后将这些分片分布在多个节点中，Elasticsearch可以确保冗余，这既可以防止硬件故障，又可以在将节点添加到集群中时提高查询能力。随着集群的增长（或收缩），Elasticsearch会自动迁移碎片以重新平衡集群。 分片有两种类型：主数据库和副本数据库。索引中的每个文档都属于一个主分片。副本分片是主分片的副本。副本可提供数据的冗余副本，以防止硬件故障并提高处理读取请求（例如搜索或检索文档）的能力。 创建索引时，索引中主碎片的数量是固定的，但是副本碎片的数量可以随时更改，而不会中断索引或查询操作。 ### 这取决于... ... 在分片大小和为索引配置的主分片数量方面，存在许多性能方面的考虑和权衡取舍。碎片越多，维护这些索引的开销就越大。分片大小越大，当Elasticsearch需要重新平衡集群时，移动分片所需的时间就越长。 查询很多小的分片会使每个分片的处理速度更快，但是更多的查询意味着更多的开销，因此查询较小数量的大分片可能会更快。简而言之...要视情况而定。 作为起点： * 旨在将平均分片大小保持在几GB到几十GB之间。对于具有基于时间的数据的用例，通常会看到20GB到40GB范围内的碎片。 * 避免庞大的碎片问题。节点可以容纳的分片数量与可用堆空间成比例。通常，每GB堆空间中的分片数量应少于20。 确定用例最佳配置的最佳方法是通过[使用自己的数据和查询](https://www.elastic.co/elasticon/conf/2016/sf/quantitative-cluster-sizing)进行[测试](https://www.elastic.co/elasticon/conf/2016/sf/quantitative-cluster-sizing)。 ### 在灾难的情况下 出于性能原因，群集内的节点必须位于同一网络上。跨不同数据中心中的节点的群集中的碎片平衡太简单了。但是高可用性架构要求您避免将所有鸡蛋都放在一个篮子里。如果一个位置发生重大故障，则另一个位置的服务器需要能够接管。无缝地。答案？跨集群复制（CCR）。 CCR提供了一种方法，可以自动将索引从主群集同步到可以用作热备份的辅助远程群集。如果主群集出现故障，则辅助群集可以接管。您还可以使用CCR创建辅助群集，以接近地理位置的方式向您的用户提供读取请求。 跨集群复制是主动-被动的。主群集上的索引是活动的领导者索引，并处理所有写请求。复制到辅助群集的索引是只读关注者。 ### 照顾和喂养 与任何企业系统一样，您需要工具来保护，管理和监视Elasticsearch集群。集成到Elasticsearch中的安全性，监视和管理功能使您可以将[Kibana](https://www.elastic.co/guide/en/kibana/7.6/introduction.html)用作控制中心来管理集群。类似的特征[数据汇总](https://www.elastic.co/guide/en/elasticsearch/reference/current/rollup-overview.html "汇总概述")和[指标生命周期管理](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html "管理索引生命周期")可帮助您明智随着时间的推移管理您的数据。