Elasticsearch是为满足您的需要而构建的。这是通过自然的分布来实现的。您可以向集群中添加服务器(节点)来增加容量，Elasticsearch会自动将您的数据和查询负载分布到所有可用节点上。无需彻底修改您的应用程序，Elasticsearch知道如何平衡多节点集群以提供伸缩性和高可用性。节点越多越好。

    这是怎么做到的呢?实际上，Elasticsearch索引只是一个或多个物理碎片的逻辑分组，其中每个碎片实际上是一个自包含的索引。通过跨多个碎片将文档分布在一个索引中，并将这些碎片分布在多个节点上，Elasticsearch可以确保冗余，这既可以防止硬件故障，又可以在节点添加到集群时增加查询能力。随着集群的增长(或收缩)，Elasticsearch会自动迁移碎片来重新平衡集群。

    有两种类型的碎片:初级碎片和复制碎片。索引中的每个文档都属于一个主碎片。复制碎片是主碎片的副本。副本提供数据的冗余副本，以防止硬件故障，并增加处理读取请求(如搜索或检索文档)的能力。

    索引中主碎片的数量在创建索引时是固定的，但是复制碎片的数量可以在任何时候更改，而不会中断索引或查询操作。

    看情况而定…
    在切分大小和为索引配置的主切分数量方面，有许多性能考虑因素和权衡。碎片越多，维护这些索引的开销就越大。当Elasticsearch需要重新平衡集群时，碎片大小越大，碎片移动所需的时间越长。

    查询大量的小碎片会使每个碎片的处理速度更快，但是更多的查询意味着更多的开销，因此查询较少数量的较大碎片可能会更快。简而言之，这要看情况。

    作为一个起点：

    • 目标是将碎片的平均大小保持在几GB到几十GB之间。对于具有基于时间的数据的用例，通常会看到20GB到40GB范围内的碎片。
    • 避免大量碎片的问题。一个节点可以容纳的碎片的数量与可用的堆空间成比例。一般来说，每GB堆空间的碎片数应该小于20。

    确定用例的最佳配置的最佳方法是使用您自己的数据和查询进行测试。

    万一发生灾难
    出于性能原因，集群中的节点需要位于相同的网络上。在不同数据中心的节点之间平衡集群中的碎片花费的时间太长了。但是高可用性架构要求您避免将所有鸡蛋放在一个篮子里。在一个位置发生重大停机时，另一个位置的服务器需要能够接管。无缝。答案吗?Cross-cluster复制(CCR)。

    CCR提供了一种方法，可以将主集群的索引自动同步到可作为热备份的辅助远程集群。如果主集群失败，则可以由辅助集群接管。您还可以使用CCR来创建辅助集群，以便为用户提供地理位置接近的读请求。

    跨集群复制是主动-被动的。主集群上的索引是活动的leader索引，它处理所有的写请求。复制到辅助集群的索引是只读的关注者。

    Care and feeding
    与任何企业系统一样，您需要一些工具来保护、管理和监视您的Elasticsearch集群。与Elasticsearch集成的安全性、监视和管理特性使您能够使用Kibana作为管理集群的控制中心。像数据滚动和索引生命周期管理这样的特性可以帮助您在一段时间内智能地管理数据。