選取您的 Cookie 偏好設定

我們使用提供自身網站和服務所需的基本 Cookie 和類似工具。我們使用效能 Cookie 收集匿名統計資料,以便了解客戶如何使用我們的網站並進行改進。基本 Cookie 無法停用,但可以按一下「自訂」或「拒絕」以拒絕效能 Cookie。

如果您同意,AWS 與經核准的第三方也會使用 Cookie 提供實用的網站功能、記住您的偏好設定,並顯示相關內容,包括相關廣告。若要接受或拒絕所有非必要 Cookie,請按一下「接受」或「拒絕」。若要進行更詳細的選擇,請按一下「自訂」。

評估 DynamoDB 資料表的容量模式

焦點模式
評估 DynamoDB 資料表的容量模式 - Amazon DynamoDB

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

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

本節概述如何為 DynamoDB 資料表選取適當的容量模式。每種模式都經過調整,以滿足不同工作負載在回應輸送量變化以及該用量計費方式方面的需求。您必須在做出決策時平衡這些因素。

有哪些可用的資料表容量模式

建立 DynamoDB 資料表時,您必須選取隨需或佈建容量模式。您可以在容量模式之間切換,每 24 小時一次。唯一的例外情況是,如果您將佈建模式資料表切換為隨需模式,則可以在相同的 24 小時期間內切換回佈建模式。

隨需容量模式

隨需容量模式旨在消除規劃或佈建 DynamoDB 資料表容量的需求。在此模式下,資料表不需擴充或縮減任何資源,就能立即容納資料表收到的請求 (最多可達到先前資料表尖峰輸送量的兩倍)。

DynamoDB 隨需提供讀取和寫入請求pay-per-request定價,因此您只需支付使用量的費用。

佈建容量模式

佈建容量模式是較傳統的模型,您必須定義資料表可直接或在自動擴展的協助下可用於請求的容量。由於特定容量是在任何指定時間佈建給資料表,因此計費是根據佈建的總容量,而不是已使用的請求數。超過配置的容量也可能導致資料表拒絕請求,並降低應用程式使用者的體驗。

佈建容量模式需要持續監控,才能在未過度佈建或佈建不足資料表之間找到平衡,以保持調節低廉和成本調整。

何時選取隨需容量模式

當您有類似下列圖表的工作負載時,最佳選擇是最佳化成本時,隨需模式。

下列因素會造成此類型的工作負載:

  • 隨著時間發展的流量模式

  • 變動的請求量 (由批次工作負載導致)

  • 無法預測的請求時機 (導致流量尖峰)

  • 降至指定小時峰值的零或低於峰值的 30%

無法預測的可變工作負載圖形,具有尖峰和活動量低的期間。 無法預測的可變工作負載圖形,具有尖峰和活動量低的期間。

對於具有上述因素的工作負載,使用自動擴展在資料表上維持足夠的容量來回應流量激增,可能會導致資料表過度佈建,並且成本超過所需,或資料表佈建不足,以及請求不必要地調節。隨需容量模式是更好的選擇,因為它可以處理波動的流量,而無需您預測或調整容量。

使用隨需模式pay-per-request定價模型,您不需要擔心閒置容量,因為您只需要支付實際使用的輸送量。每個使用的讀取或寫入請求都會向您收費,因此您的成本會直接反映您的實際用量,讓您輕鬆平衡成本和效能。您也可以選擇性地為個別隨需資料表和全域次要索引設定每秒的最大讀取或寫入 (或兩者) 輸送量,以協助保持成本和用量的限制。如需詳細資訊,請參閱隨需資料表的最大輸送量

何時選取佈建容量模式

佈建容量模式的理想工作負載是具有更穩定且可預測用量模式的工作負載,如下圖所示。

注意

我們建議您在對佈建容量採取動作之前,先檢閱精細期間的指標,例如 14 天。

下列因素會造成此類型的工作負載:

  • 特定小時或天的穩定、可預測和循環流量

  • 有限的短期流量暴增

圖表描述流量尖峰有限的可預測、週期性工作負載。

由於特定小時或一天內的流量量更為穩定,因此您可以設定資料表的佈建容量,相對接近資料表的實際使用容量。基本上,佈建容量資料表的成本最佳化必須藉由實際操作,盡量使佈建容量 (藍線) 接近實際使用容量 (橘線),同時不增加資料表上的 ThrottledRequests。兩條線之間的空間表示浪費的容量,但同時也是預防因限流而影響使用者體驗的保障。如果您可以預測應用程式的輸送量需求,而且偏好控制讀取和寫入容量的成本可預測性,則您可能想要繼續使用佈建的資料表。

DynamoDB 為佈建容量資料表提供自動調整規模功能,將代表您自動平衡佈建容量。如此可讓您追蹤全天的使用容量,並根據少數幾項變數來設定資料表的容量。使用自動擴展時,您的資料表會過度佈建,而且您需要微調調節器數量與過度佈建容量單位之間的比率,以符合工作負載需求。

DynamoDB 主控台。佈建容量和自動擴展已啟用。目標使用率設定為 70。
容量單位下限

您可以設定資料表的容量下限,藉此限制限流的程度,但這麼做不會降低資料表的成本。如果資料表會在低用量期間之後出現突發高用量,則可以設定用量下限以預防自動調整規模功能將資料表容量設定得過低。

容量單位上限

您可以設定資料表的容量上限,以避免資料表的規模調整到高於預期的程度。如果不需要進行大規模負載測試,請考慮為開發或測試資料表套用上限。您可以為任何資料表設定上限,但是在生產環境中使用時,請務必定期依據資料表基準評估此設定,以預防意外限流的狀況。

目標使用率

對於佈建容量資料表,設定資料表的目標使用率是實現成本最佳化的主要方法。對此設定較低的百分比值,將會增加資料表過度佈建程度而提高成本,但同時降低限流的風險。對此設定較高的百分比值,將會降低資料表過度佈建程度,但同時提高限流的風險。

選擇資料表容量模式時應考慮的其他因素

在兩種模式之間進行抉擇時,還有一些其他因素值得納入考量。

佈建的容量使用率

為了判斷隨需模式的成本低於佈建容量,查看佈建容量使用率會很有幫助,這是指配置 (或「佈建) 資源的使用效率。對於平均佈建容量使用率低於 35% 的工作負載,隨需模式成本較低。在許多情況下,即使對於佈建容量使用率高於 35% 的工作負載,使用隨需模式可能更具成本效益,特別是在工作負載具有低活動期與偶爾峰值混合的情況下。

預留容量

對於佈建容量資料表,DynamoDB 提供預留容量的購買功能,適用於讀取和寫入容量 (目前不適用於複寫寫入容量單位 (rWCU) 和標準 - IA 資料表)。預留容量比標準佈建容量定價提供大幅折扣。

在兩種資料表模式之間進行抉擇時,請考慮這項額外的折扣因素對資料表成本的影響程度。在某些情況下,執行相對不可預測的工作負載的成本可能較低,因此在具有預留容量的過度佈建佈建容量資料表上執行成本可能較低。

改善工作負載的可預測性

在某些情況下,工作負載可能顯得同時具有可預測和無法預測的模式。雖然隨需資料表可以輕鬆支援這種情況,但若可改善無法預測的工作負載模式,可能會有助於提高成本效益。

造成這些模式的最常見原因之一是批次匯入。這種類型的流量可能經常超過資料表的基準容量,導致執行期間發生限流。若要在佈建容量資料表上執行這類工作負載,請考慮下列選項:

  • 如果批次發生在排程時間,則可排程在其執行之前增加自動調整規模的容量。

  • 如果批次是隨機發生,請考慮嘗試延長執行時間,而不是盡速執行

  • 在匯入中新增緩衝期間,匯入的速度會開始很小,但會在幾分鐘內緩慢增加,直到自動擴展有機會開始調整資料表容量為止

隱私權網站條款Cookie 偏好設定
© 2025, Amazon Web Services, Inc.或其附屬公司。保留所有權利。