計算儲存需求 - Amazon OpenSearch Service

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

計算儲存需求

大多數 OpenSearch 工作負載屬於兩個廣泛的類別之一：

  • 長期索引：您會編寫程式碼，將資料處理成一或多個 OpenSearch 索引，然後隨著來源資料變更定期更新這些索引。一些常見的範例是網站、文件和電子商務搜尋。

  • 動態索引：資料持續流入一組臨時索引，具有建立索引期和保留時段 (例如一組保留兩週的每日索引)。一些常見的範例是日誌分析、時間序列處理和點擊流分析。

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

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

您的來源資料的大小，不過是您的儲存需求的一個面向。您還必須有考量：

  • 複本數量：每個複本都是主要碎片的完整複本，索引的存放大小會顯示主要碎片和複本碎片所採用的大小。根據預設，每個 OpenSearch 索引都有一個複本。建議您至少有一個以防資料遺失。複本也可提升搜尋效能，因此如果您的讀取工作負載繁重，您也許想要更多複本。使用 PUT /my-index/_settings 以更新索引的 number_of_replicas 設定。

  • OpenSearch 索引額外負荷：索引的磁碟上大小有所不同。來源資料加上索引的總大小通常是來源的 110%，索引最多可達來源資料的 10%。為資料編製索引後，您可以使用 _cat/indices?vAPI和 pri.store.size值來計算確切的額外負荷。 _cat/allocation?v也提供有用的摘要。

  • 作業系統預留空間：在預設情況下，Linux 會保留 5% 的檔案系統供 root 使用者用於關鍵程序、系統復原，以及防止磁碟分段問題。

  • OpenSearch 服務開銷： OpenSearch 服務保留每個執行個體 （最多 20 GiB) 20% 的儲存空間，用於區段合併、日誌和其他內部操作。

    由於此 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 服務額外負荷） = 最低儲存需求

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

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

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

也存在其他儲存考量事項：