选择分片数量

在您了解存储要求后，便可以调查您的索引策略。默认情况下，在 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每个节点上限为 1,000 个分片。要调整每个节点的最大分区数，请配置 cluster.max_shards_per_node 设置。有关示例，请参阅集群设置。

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