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

# 計算儲存需求
<a name="bp-storage"></a>

大多數的 OpenSearch 工作負載為兩大類別之一：
+ **長效索引**：您編寫程式碼將資料處理到一個或多個 OpenSearch 索引，然後在來源資料變更時定期更新這些索引。一些常見的範例是網站、文件和電子商務搜尋。
+ **動態索引**：資料持續流入一組臨時索引，具有建立索引期和保留時段 (例如一組保留兩週的每日索引)。一些常見的範例是日誌分析、時間序列處理和點擊流分析。

對於長效索引的工作負載，您可以在磁碟上檢查來源資料並輕鬆判斷它會消耗多少儲存空間。如果資料來自多個來源，只要一起新增這些來源。

對於動態索引，您可以保留期乘上在代表時段產生的資料量。例如，若您每小時產生 200 MiB 的日誌資料，也就是每天 4.7 GiB，假設您的保留期間為兩週，則在任何指定時間的資料為 66 GiB。

您的來源資料的大小，不過是您的儲存需求的一個面向。您還必須有考量：
+ **複本數量**：每個複本都是主要碎片的完整複本，索引的存放大小會顯示主要碎片和複本碎片所採用的大小。在預設情況下，每個 OpenSearch 索引都有一個複本。建議您至少有一個以防資料遺失。複本也可提升搜尋效能，因此如果您的讀取工作負載繁重，您也許想要更多複本。使用 `PUT /my-index/_settings` 以更新索引的 `number_of_replicas` 設定。
+ **OpenSearch 索引負荷**：索引在磁碟上的大小各不相同。來源資料加上索引的總大小通常是來源的 110%，索引最多可達來源資料的 10%。在您對資料編製索引之後，您可以使用 `_cat/indices?v` API 和 `pri.store.size` 值計算確切的負荷。`_cat/allocation?v` 也提供實用的摘要。
+ **作業系統預留空間**：在預設情況下，Linux 會保留 5% 的檔案系統供 `root` 使用者用於關鍵程序、系統復原，以及防止磁碟分段問題。
+ **OpenSearch Service 負荷**：OpenSearch Service 會保留每個執行個體 20% 的儲存空間 (最多 20 GiB) 以用於區段合併、日誌和其他內部操作。

  由於此 20 GiB 上限，預留空間的總量可能依您網域內的執行個體數目而大不相同。例如，網域可能有三個 `m6g.xlarge.search` 執行個體，各有 500 GiB 的儲存空間，總計 1.46 TiB。在這種情況下，總預留空間僅 60 GiB。另一網域可能有 10 個 `m3.medium.search` 執行個體，各有 100 GiB 的儲存空間，總計 0.98 TiB。在這種情況下，總預留空間是 200 GiB，即使第一個網域大 50%。

  在以下公式中，我們對開銷套用「最壞情況」預估值。此預估值包含額外的可用空間，有助於將節點故障和可用區域中斷的影響降到最低。

總之，如果您在任何指定的時間有 66 GiB 的資料，並且想要一個複本，您的*最低*儲存需求為接近 66 \* 2 \* 1.1 / 0.95 / 0.8 = 191 GiB。您可以將此計算一般化，如下所示：

 **來源資料 \* (1 \+ 複本的數量) \* (1 \+ 索引負荷) / (1 – Linux 預留空間) / (1 – OpenSearch Service 負荷) = 最低儲存需求**

或者，您可以使用此簡化版本：

 **來源資料 \* (1 \+ 複本的數量) \* 1.45 = 最低儲存需求**

儲存空間不足是造成叢集不穩定的最常見原因之一。因此，您應在[選擇執行個體類型、執行個體計數和儲存磁碟區](bp-instances.md)時反復檢查數字。

也存在其他儲存考量事項：
+ 如果您的最低儲存需求超過 1 PB，請參閱 [Amazon OpenSearch Service 的 PB 規模](petabyte-scale.md)。
+ 如果您有輪流更新的索引，而且想要使用熱暖架構，請參閱[Amazon OpenSearch Service 的 UltraWarm 儲存](ultrawarm.md)。