本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 选择分片数量
<a name="bp-sharding"></a>

在您了解存储要求后，便可以调查您的索引策略。默认情况下，在 S OpenSearch ervice 中，每个索引分为五个主分片和一个副本（总共 10 个分片）。这种行为不同于开源 OpenSearch，后者默认为一个主分片和一个副本分片。由于无法轻松更改现有索引的主分片的数量，在为第一个文档编制索引*之前*，应决定分片数量。

选择分片数量的总体目标是跨集群中的所有数据节点均匀分配索引。但是，这些分片不应该太大或太多。一般准则是，对于搜索延迟属于关键性能目标的工作负载，建议尽量将分片大小保持在 10-30GiB 之间；而对于写入密集型工作负载（如日志分析），则建议尽量将分片大小保持在 30-50GiB 之间。

较大的分片可能难以从故障中恢复，但是由于每个分片会占用一定数量的 CPU 和内存，因此拥有过多的小分片可能会导致性能问题和内存不足错误。 OpenSearch 换句话说，分片应该足够小，以便底层 S OpenSearch ervice 实例可以处理它们，但不能太小以至于给硬件带来不必要的压力。

例如，假设您有 66GiB 的数据。您不希望该数字随着时间的推移而增加，您希望将每个分片保持在 30GiB 左右。因此，您的分片数量应大约为 66 \* 1.1 / 30 = 3。您可以将此计算一般化，如下所示：

 **（源数据 \+ 增长空间）\*（1 \+ 索引开销）/所需的分片大小 = 主分片的大约数量**

此等式可帮助补偿今后的数据增长。如果您预计这相同的 66GiB 数据将在下一年增长到原来的四倍，则分片的数量大约为 (66 \+ 198) \* 1.1 / 30 = 10。但是，请记住，您*还没有* 这额外的 198GiB 数据。检查以确保为未来所做的这一准备不会创建目前消耗大量 CPU 和内存的多余微小分片。在这种情况下，66 \* 1.1 / 10 分片 = 7.26GiB/分片，将消耗额外的资源且小于建议的大小范围。你可以考虑六个分片的更多 middle-of-the-road方法，这样你今天就有 12-GiB 的分片，将来有 48-GiB 的分片。而且，您可能更愿意从 3 个分片开始且在分片超过 50GiB 时为您的数据重新编制索引。

一个不太常见的问题涉及限制每个节点的分片数量。如果您适当地调整分片大小，您通常会在遇到此限制之前，很长时间才会用完磁盘空间。例如，`m6g.large.search` 实例的最大磁盘大小为 512 GiB。如果您的磁盘利用率低于 80%，并且分片大小为 20 GiB，则可容纳大约 20 个分片。Elasticsearch 7 *x* 及更 OpenSearch高版本，以及所有不超过 2.15 的版本，每个节点的分片上限为 *1,000* 个。要调整每个节点的最大分区数，请配置 `cluster.max_shards_per_node` 设置。对于 OpenSearch 2.17 及更高版本， OpenSearch 服务支持每 16GB 的 JVM 堆内存使用 1000 个分片，每个节点最多支持 4000 个分片。有关示例，请参阅[集群设置](https://opensearch.org/docs/latest/opensearch/rest-api/cluster-settings/#request-body)。有关分片计数的更多信息，请参阅 [分片计数限额](limits.md#shard-count)。

适当调整分片大小几乎总是使您低于此限制，但您也可以考虑针对每 GiB 的 Java 堆的分片数。在给定节点上，每 GiB 的 Java 堆不超过 25 个分片。例如，一个 `m5.large.search` 实例有一个 4 GiB 堆，因此每个节点应该有不超过 100 个分片。对于该分片计数，每个分片的大小大约为 5 GiB，远低于我们建议的大小。