本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 評估 DynamoDB 資料表的容量模式
本節概述如何為 DynamoDB 資料表選取適當的容量模式。每種模式都經過調整，以滿足不同工作負載在回應輸送量變化以及該用量計費方式方面的需求。在做出決策時，必須平衡考量這些因素。
**Topics**
+ [有哪些可用的資料表容量模式](#CostOptimization_TableCapacityMode_Overview)
+ [何時選取隨需容量模式](#CostOptimization_TableCapacityMode_OnDemand)
+ [何時選取佈建容量模式](#CostOptimization_TableCapacityMode_Provisioned)
+ [選擇資料表容量模式時應考慮的其他因素](#CostOptimization_TableCapacityMode_AdditionalFactors)
## 有哪些可用的資料表容量模式
建立 DynamoDB 資料表時，您必須選取隨需或佈建容量模式。
您可在 24 小時滾動期間內，最多將資料表從佈建容量模式切換至隨需模式四次。您可隨時將資料表從隨需模式切換回佈建容量模式。
**隨需容量模式**
[隨需容量模式](on-demand-capacity-mode.md)旨在讓使用者無須規劃或佈建 DynamoDB 資料表容量。在此模式下，資料表不需擴充或縮減任何資源，就能立即容納資料表收到的請求 (最多可達到先前資料表尖峰輸送量的兩倍)。
DynamoDB 隨需模式提供按請求付費的定價機制，讓您僅需為實際用量付費。
**佈建容量模式**
[佈建容量](provisioned-capacity-mode.md)模式是一種較傳統的模式，使用者必須直接或透過自動擴展功能，定義資料表可用的請求容量。由於在任一時間點都會為資料表佈建固定容量，因此計費依據為總佈建容量，而非實際請求次數。超過配置的容量也可能導致資料表拒絕請求，並降低應用程式使用者的體驗。
佈建容量模式需持續監控，以在避免過度或不足佈建間取得平衡，確保限流最小化並最佳化成本。
## 何時選取隨需容量模式
在進行成本最佳化時，若您的工作負載與下列圖表所示相似，隨需模式即為最佳選擇。
下列因素會造成此類型的工作負載：
+ 隨時間變化的流量模式
+ 變動的請求量 (由批次工作負載導致)
+ 無法預測的請求時機 (導致流量尖峰)
+ 在特定時段流量降至零或低於峰值的 30%
![\[描述不可預測的可變工作負載，其流量具有尖峰與低活動期。\]](http://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/images/choose-on-demand-1.png)![\[描述不可預測的可變工作負載，其流量具有尖峰與低活動期。\]](http://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/images/choose-on-demand-2.png)
對於具上述特性的工作負載，若透過自動擴展維持足夠容量以應對流量尖峰，可能導致資料表過度佈建、成本增加，或因佈建不足造成不必要的限流。隨需容量模式更為理想，因其可自動應對流量波動，無需預測或手動調整容量。
採用隨需模式的「按請求付費」定價模型時，您無需擔心閒置容量，因為僅需為實際使用的輸送量付費。系統會依每次讀取或寫入請求向您收費，因此成本能直接反映實際用量，讓您更容易在成本與效能之間取得平衡。您也可以選擇為各個隨需資料表與全域次要索引設定每秒最大讀取或寫入 (或兩者) 輸送量，以協助控制成本與用量界限。如需詳細資訊，請參閱[隨需資料表的最大輸送量](on-demand-capacity-mode-max-throughput.md)。
## 何時選取佈建容量模式
對於佈建容量模式而言，理想的工作負載應具備穩定且可預測的使用模式，如下圖所示。
**注意**
我們建議在對佈建容量進行調整前，先檢視細分期間 (例如 14 天) 的指標。
下列因素會造成此類型的工作負載：
+ 在特定時段 (如每小時或每日) 的穩定、可預測且具循環性的流量
+ 限制性的短期流量高峰
![\[此圖顯示一個流量尖峰有限、具可預測與週期性特徵的工作負載。\]](http://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/images/choose-provisioned-1.png)
由於在特定時段內流量相對穩定，因此可將資料表的佈建容量設定得接近實際消耗容量。基本上，佈建容量資料表的成本最佳化必須藉由實際操作，盡量使佈建容量 (藍線) 接近實際使用容量 (橘線)，同時不增加資料表上的 `ThrottledRequests`。兩條線之間的空間表示浪費的容量，但同時也是預防因限流而影響使用者體驗的保障。若您能預測應用程式的輸送量需求，並希望透過控制讀寫容量維持成本的可預測性，建議持續使用佈建資料表。
DynamoDB 為佈建容量資料表提供自動擴展功能，將代表您自動平衡佈建容量。如此可讓您追蹤全天的使用容量，並根據少數幾項變數來設定資料表的容量。使用自動擴展時，資料表可能出現過度佈建，您需微調限流事件數與過度佈建容量單位的比例，以符合工作負載需求。
![\[DynamoDB 主控台。已啟用佈建容量與自動擴展功能。目標使用率已設定為 70。\]](http://docs.aws.amazon.com/zh_tw/amazondynamodb/latest/developerguide/images/CostOptimization/TableCapacityModeAutoScaling.png)
**容量單位下限**
您可以設定資料表的容量下限，藉此限制限流的程度，但這麼做不會降低資料表的成本。如果資料表會在低用量期間之後出現突發高用量，則可以設定用量下限以預防自動擴展功能將資料表容量設定得過低。
**容量單位上限**
您可以設定資料表的容量上限，以避免資料表的規模調整到高於預期的程度。如果不需要進行大規模負載測試，請考慮為開發或測試資料表套用上限。您可以為任何資料表設定上限，但是在生產環境中使用時，請務必定期依據資料表基準評估此設定，以預防意外限流的狀況。
**目標使用率**
對於佈建容量資料表，設定資料表的目標使用率是實現成本最佳化的主要方法。對此設定較低的百分比值，將會增加資料表過度佈建程度而提高成本，但同時降低限流的風險。對此設定較高的百分比值，將會降低資料表過度佈建程度，但同時提高限流的風險。
## 選擇資料表容量模式時應考慮的其他因素
在兩種模式之間進行抉擇時，還有一些其他因素值得納入考量。
**佈建容量使用率**
若要判斷隨需模式的成本是否低於佈建容量，建議檢視佈建容量使用率，該指標反映已配置 (或「佈建」) 資源的使用效率。若工作負載的平均佈建容量使用率低於 35%，隨需模式的成本通常更低。在許多情況下，即使佈建容量使用率高於 35%，若工作負載包含低活動期與偶發高峰，採用隨需模式仍可能更具成本效益。
**預留容量**
對於佈建容量資料表，DynamoDB 提供預留容量的購買功能，適用於讀取和寫入容量 (目前不適用於複寫寫入容量單位 (rWCU) 和標準 - IA 資料表)。預留容量可比標準佈建容量定價享有更高折扣。
在兩種資料表模式之間進行抉擇時，請考慮這項額外的折扣因素對資料表成本的影響程度。在部分情況下，即使是難以預測的工作負載，若於具預留容量的過度佈建資料表上執行，成本仍可能更低。
**改善工作負載的可預測性**
在某些情況下，工作負載可能顯得同時具有可預測和無法預測的模式。雖然隨需資料表可以輕鬆支援這種情況，但若可改善無法預測的工作負載模式，可能會有助於提高成本效益。
造成這些模式的最常見原因之一是批次匯入。這種類型的流量可能經常超過資料表的基準容量，導致執行時期間發生限流。若要在佈建容量資料表上執行這類工作負載，請考慮下列選項：
+ 如果批次發生在排程時間，則可排程在其執行之前增加自動擴展的容量。
+ 如果批次是隨機發生，請考慮嘗試延長執行時期，而不是盡速執行
+ 為匯入程序新增「逐步提升期」，使匯入速率從低速開始，並在數分鐘內逐漸增加，直到自動擴展開始調整資料表容量。