Elasticsearch虽然搜索很快，但如果分片设置不当，当数据量达到一个量级后，查询速度也会直线下降。
如果一个索引具有很大的数据量，它的数据量可能会超出单个节点的容量限制（硬盘容量），而且单个节点数据量过大，执行性能也会随之下降，每个搜索请求的执行效率都会降低。 为了解决上述问题， Elasticsearch 提出了分片的概念，索引将划分成多份，称为分片。当创建索引时，可以很简单的指定想要的分片数量。每个分片都是功能齐全的，独立的“索引”，驻留在集群的各个节点中。
分片的作用
Elasticsearch 中的分片其实就是 Lucene 索引。
分片有两个主要的用处：
- 水平划分数据
- 多个分片分发工作，并行执行，从而提高性能，吞吐量
分片分为主分片和副本分片。副本分片主要功能如下：
- 高可用性：副本分片作为数据备份，当某个主分片发生故障时，副本分片能够成为新的主分片，保证服务的可用性。
- 提高性能：副本分片本身也是一个功能齐全的独立的分片（所以才能够随时取代故障的主分片），当有查询请求时，既可以在主分片中完成查询，也可以在副本分片中完成查询，当然数据添加、更新的操作只能在主分片中完成。
副本分片与主分片需要分配在不同的节点上，一是为了更好的均衡负载，不同节点上二是节点发生故障时，主分片和副本分片一起故障，没法保证高可用性。所以 Elasticsearch 集群最好要有 2 个节点或以上。
一个索引默认有 5 个主分片，每个主分片默认有 1 个副本分片，即创建一个索引默认会有 10 个分片。
实际应用举例
场景1：数据量大小约为10GB, 用于输入时自动提示场景，数据每天定时更新部分字段。ES集群有5台机器。
方案一：主分片数=1，副分片数=4，每个节点持有一个分片。
- 优点：每个节点持有一个分片，读请求可以在一个分片获取结果，不需要合并结果等操作。
- 缺点：索引写入的时候，全部请求到主分片的机器，再由主分片同步到副分片，由于副分片较多，写入过程变慢。
方案二：主分片数=2，副分片数=4，每个节点持有一个主分片和一个副分片。
- 优点：副分片变少，对写入操作友好。
- 缺点：多个分片分散在不同节点上，请求会发布到各个分片号上取topN汇总。由于评分是在各个分片内进行，在本场景中存在TF/IDF评分差异，导致返回结果排序问题。
考虑业务场景，最终选择方案一。
场景2：在ELK(ELK是Elasticsearch、Logstash、Kibana的简称)中，想一下, 大部分的 Logstash 用户并不会频繁的进行搜索, 甚至每分钟都不会有一次查询. 所以这种场景, 推荐更为经济使用的设置. 在这种场景下, 搜索性能并不是第一要素, 所以并不需要很多副本。
总结
- 读远大于写的场景，可以减少主分片个数，增加副本数，提升读吞吐率，前提是写的优先级不高。极端情况下单分片多副本可以最大程度提升总的读吞吐。
- 写远大于读的场景，最大程度分配主分片个数，一个机器一个，并最大程度减少副本数（极端情况下集群规模不大且可用性优先级较低时可以不要副本）。
分片的大小和数量怎么设定？
注1：小的分片会造成小的分段，从而会增加开销。我们的目的是将平均分片大小控制在几 GB 到几十 GB 之间。对于基于时间的数据的使用场景来说，通常将分片大小控制在 20GB 到 40GB 之间。
注2：由于每个分片的开销取决于分段的数量和大小，因此通过 forcemerge 操作强制将较小的分段合并为较大的分段，这样可以减少开销并提高查询性能。 理想情况下，一旦不再向索引写入数据，就应该这样做。 请注意，这是一项比较耗费性能和开销的操作，因此应该在非高峰时段执行。
注3：我们可以在节点上保留的分片数量与可用的堆内存成正比，但 Elasticsearch 没有强制的固定限制。 一个好的经验法则是确保每个节点的分片数量低于每GB堆内存配置20到25个分片。 因此，具有30GB堆内存的节点应该具有最多600-750个分片，但是低于该限制可以使其保持更好。 这通常有助于集群保持健康。
注4：如果担心数据的快速增长, 建议根据这条限制: ElasticSearch推荐的最大JVM堆空间是 30~32G, 把分片最大容量限制为 30GB, 然后再对分片数量做合理估算。例如, 如果的数据能达到 200GB, 则最多分配7到8个分片。
开源地址
https://github.com/qfjiaoyan/elasticsearch-examples
閱讀更多 Java教研組 的文章
