本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 選擇碎片數
<a name="bp-sharding"></a>

在您了解您的儲存需求之後，您可以調查您的索引策略。在預設情況下，在 OpenSearch Service 中，每個索引會分成五個主要碎片和一個複本 (共 10 個碎片)。這種行為不同於開放原始碼 OpenSearch，它預設為一個主要碎片和一個複本碎片。由於您無法輕易變更現有索引的主要碎片數，所以您應該在建立第一個文件的索引*之前*，決定好碎片計數。

選擇一些碎片的整體目標是要將索引平均分佈到叢集中的所有資料節點。不過，這些碎片不應該是太大或太多。一般指導方針是，針對搜尋延遲是關鍵效能目標的工作負載，嘗試將碎片大小保持在 10-30 GiB 之間，對於寫入操作繁重的工作負載 (例如日誌分析)，保持在 30-50 GiB。

大型碎片會造成 OpenSearch 難以從故障恢復，但因為每個碎片使用 CPU 和記憶體的一些量，擁有太多碎片可能導致效能問題和記憶體不足的錯誤。換言之，碎片應該夠小到基底 OpenSearch Service 執行個體能夠處理的程度，但又不會小到對硬體形成不必要的負擔。

例如，假設您有 66 GiB 的資料。您不希望該數量隨著時間增加，並且您想要保持每個碎片大約在 30 GiB 的大小。因此，您的碎片數應該大約為 66 \* 1.1 / 30 = 3 個。您可以將此計算一般化，如下所示：

 **(來源資料 \+ 成長空間) \* (1 \+ 索引負荷) / 所需碎片大小 = 主要碎片的大約數量**

這個方程式有助於補償資料隨時間的成長。如果您預期同樣皆為 66 GiB 的資料到明年成為四倍，大約碎片數則會是 (66 \+ 198) \* 1.1 / 30 = 10 個。不過請記住，您*尚未*擁有那些額外的 198 GiB 資料。請進行檢查以確保這個對未來的準備不會產生不必要的微小碎片，大量消耗眼前的 CPU 和記憶體。在這種情況下，66 \* 1.1 / 10 個碎片 = 每個碎片 7.26 GiB，這會消耗額外的資源且低於建議的大小範圍。您可以考慮中庸之道的六個碎片，讓您目前擁有 12 GiB 的碎片且爾後擁有 48 GiB 的碎片。接著，您可能希望再次以三個碎片開始並在碎片超過 50 GiB 時重新建立資料的索引。

有個較不常見的問題包含限制每個節點的碎片數量。如果您適當地調整碎片大小，通常要過很久一段時間才會用完磁碟空間，然後達到此限制。例如，一個 `m6g.large.search` 執行個體具有最大 512 GiB 的磁碟大小。如果您保持在低於 80% 的磁碟用量並將碎片大小調整為 20 GiB，即可容納大約 20 個碎片。Elasticsearch 7.*x* 和更新版本，以及截至 2.15 的所有 OpenSearch 版本，每個節點有 *1，000* 個碎片的限制。若要調整每個節點的最大碎片，請設定 `cluster.max_shards_per_node` 設定。對於 OpenSearch 2.17 和更新版本，OpenSearch Service 支援每 16GB JVM 堆積記憶體 1000 個碎片，每個節點最多 4000 個碎片。如需範例，請參閱[叢集設定](https://opensearch.org/docs/latest/opensearch/rest-api/cluster-settings/#request-body)。如需碎片計數的詳細資訊，請參閱 [碎片計數配額](limits.md#shard-count)。

只要適當地調整碎片大小，幾乎一律可保持低於此限制，但您也可以考慮 Java 堆積的每個 GiB 的碎片數量。在指定的節點上，Java 堆積的每 GiB 擁有不超過 25 個碎片。例如，一個 `m5.large.search` 執行個體具有 4 GiB 堆積，因此每個節點都應擁有不超過 100 個碎片。在該碎片計數，每個碎片的大小約為 5 GiB，這遠低於我們的建議。