可伸缩性和弹性：集群、节点和分片
Elasticsearch 被构建为始终可用，并且能按需扩展。它是通过天然的分布式来实现的。你可以通过向集群添加服务器（节点）来增加容量，Elasticsearch 自动分布你的数据和查询到所有可用节点。无需改造你的应用，Elasticsearch 知道如何平衡多节点集群以提供规模和高可用性。节点越多越好。
这是如何工作的？实际来讲，一个 Elasticsearch 索引只是一个或多个物理分片的逻辑组，其中每个分片实际上是一个独立索引。通过将索引中的文档分布在多个分片上，并将这些分片分布在多个节点上，Elasticsearch 能确保冗余，这既能防止硬盘损坏也能在节点添加到集群时增加查询容量。随着集群的伸缩，Elasticsearch 自动迁移分片以重新平衡集群。
有两种类型的分片：主分片和副本。索引中的每个文档都属于一个主分片。一个副本分片是一个主分片的复制。副本提供了数据冗余复制，以防止硬件故障，并增加服务读取请求——如搜索或者检索文档——的容量。
索引中的主分片的数量是索引创建时固定的，但副本分片数量可以随时更改而不会中断索引或者查询操作。
看具体情况……
对于分片大小和索引主分片数量的配置，有许多性能的考虑和权衡。分片越多，仅维护这些索引的开销就越大。分片越大，在 Elasticsearch 需要重平衡集群时，移动分片的耗时越久。
查询大量的小分片，可以让每个分片的处理更快，但更多的查询也意味着开销，所以查询更少的大分片也可能更快。简而言之……这得看情况。
作为起点：
- 要保持平均分片大小在几
GB到几十GB。对于使用基于时间的数据用例，通常分片处于20 GB到40 GB的范围。 - 避免大量分片的问题。一个节点能容纳的分片数量与可用堆空间成比例。一般来讲，每
GB堆空间的分片数量应少于20。
确定你的用例的最优配置的最好方法，是用你自己的数据和查询进行测试。
容灾
出于性能的原因，集群中的节点需要在同一网络中。在不同数据中心平衡集群中的分片会花很长时间。但高可用的架构要求你要避免把所有鸡蛋放到一个篮子里。在一个位置发生重大停机的情况下，另一个位置的服务器需要能够无缝的接管。答案是什么呢？跨集群复制（CCR）。
CCR 提供了一种方式自动地从主集群同步索引到作为热备的备份远程集群。如果主集群失效了，备份集群就会接管。你也可以使用 CCR 创建备份集群，以便在地理上靠近用户时，为读请求提供服务。
跨集群备份（CCR）是 主动-被动模式（active-passive）。主集群上的索引是活动的领导者索引，且处理所有写请求。复制到备份集群的索引是只读的追随者。
维护保养
与任何企业系统一样，你需要工具来保护、管理和监控你的 Elasticsearch 集群。集成到 Elasticsearch 中的安全、监控和管理特性使你能使用 Kibana 作为管理集群的控制中心。数据汇总和索引生命周期管理等特性可帮助你随着时间的推移智能地管理数据。