ElasticSearch 是以始终可用和可按需扩容为目标来构建的。 它天生就是分布式的。 你可以将服务器(节点)添加到集群中以增加容量，Elasticsearch 会在所有可用节点上自动分配数据和查询负载。 无需大量调整应用程序，ElasticSearch 知道如何平衡多节点的集群以提供规模和高可用性。 节点越多越好。

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

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

一个索引中的主分片的数量在创建索引时就固定了，而副本分片的数量可以在任何时候改变，且不会中断索引或查询操作。

视情况而定 It depends…​

关于给索引配置的分片大小和主分片数量，有许多性能上的考虑和权衡。 分片越多，维护这些索引的开销就越大。 当 Elasticsearch 需要重新平衡集群时，分片的大小越大，移动分片的时间就越长。

查询大量的小分片可以加快每个分片的处理速度，但更多的查询意味着更多的开销，因此查询少量的较大分片可能会更快。 简而言之，要视情况而定。

作为一个起点：

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

万一发生灾害

出于性能考虑，集群中的节点需要位于同一个网络中。 在集群中的位于不同数据中心的节点之间平衡分片的时间实在是太长了。 但是高可用性架构要求要避免将所有鸡蛋都放在一个篮子里。 在一个位置发生重大宕机的情况下，另一个位置的服务器需要能够无缝地接管。 答案是什么? 跨集群复制(CCR, Cross-cluster replication)。

跨集群复制(CCR)提供了一种将索引从主集群自动同步到作为热备份的远程的副集群的方法。 如果主集群失效，则副集群可以接管。 你还可以使用 CCR 创建副集群，以提供查询用户的地理位置附近的相关信息用例下的读请求。

跨集群复制采用主备模式(active-passive)。 主集群上的索引是活动的处理领导地位的索引，处理所有的写请求。 复制到副集群的索引都是只读的跟随者。

护理和喂养

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