本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
評估您是否具有適當大小的佈建容量
本節概述如何評估 DynamoDB 資料表是否有適當大小的佈建。隨著工作負載的演變,您應該適時修改操作程序,尤其是在佈建模式下設定 DynamoDB 資料表時,可能會有過度佈建或佈建不足的風險。
以下描述的程序需要統計資訊,這些資訊應從支援您生產應用程式的 DynamoDB 資料表擷取。若要瞭解您的應用程式行為,您應定義足以從應用程式擷取資料季節性的時段。例如,若應用程式顯示每週模式,三週時間便應足夠來分析應用程式輸送量需求。
若您不知道從何下手,請使用至少一個月的資料用量進行以下計算。
在評估容量時,DynamoDB 表可以獨立設定讀取容量單位 (RCUs) 和寫入容量單位 (WCU)。如果您的表格設定了任何全域次要索引 (GSI),您就必須指定它將使用的輸送量,這也會獨立於基底資料表的RCUs和WCUs。
注意
本機次要索引 (LSI) 會消耗基底資料表的容量。
如何擷取 DynamoDB 資料表上的耗用指標
若要評估表格和GSI容量,請監督下列 CloudWatch 測量結果,然後選取適當的維度來擷取表格或GSI資訊:
讀取容量單位 | 寫入容量單位 |
---|---|
|
|
|
|
|
|
您可以通過 AWS CLI 或 AWS Management Console.
如何識別佈建不足的 DynamoDB 資料表
針對多數工作負載,當資料表持續耗用超過其佈建容量的 80%,就會被視為佈建不足。
突發容量是 DynamoDB 的一項功能,可讓客戶暫時消耗WCUs比原始佈建的更多RCUs/(超過表格中定義的每秒佈建輸送量)。高載容量是為了吸收由於特殊事件或使用量尖峰而突增的流量。高載容量不會一直持續執行。一旦未使用RCUs和耗盡,如WCUs果您嘗試消耗的容量超過佈建的容量,就會受到限制。當應用程式流量接近 80% 使用率時,限流風險就會大幅提高。
80% 使用率規則會因資料的季節性和流量成長而有所不同。請考量下列情況:
-
如果您的流量在過去 12 個月內穩定保持約 90% 的使用率,那麼您的資料表容量剛好
-
如果您的應用程式流量在 3 個月內以每月 8% 的速度增加,您將達到 100%
-
如果您的應用程式流量在略多於 4 個月的期間以 5% 的速度增加,您仍會達到 100%
上述查詢結果能讓您得知使用率的情況。您可以使用這些結果做為指引,進一步評估其他指標,以協助您根據需要增加資料表容量 (例如:每月或每週成長率)。與您的營運團隊合作,為工作負載和資料表定義合理的百分比。
在部分特殊情況下,每天或每週進行分析時,資料會出現偏斜。例如,如果季節性應用程式在工作時間內使用量激增 (但在工作時間以外降到幾乎為零),您可以透過排程 auto 調整規模,在其中指定一天中的小時 (以及星期幾) 以增加佈建容量以及何時減少容量,從而獲益。如果您的季節性不太明顯,您也可以從 DynamoDB 表格 auto 擴展配置中受益,而不是瞄準更高的容量以滿足繁忙時間。
注意
當您為基礎資料表建立 DynamoDB auto 調整規模設定時,請記得針對與GSI該表格相關聯的任何組態加入其他組態。
如何識別過度佈建的 DynamoDB 資料表
從以上指令碼獲得的查詢結果提供了執行部分初始分析所需的資料點。若您的資料集在數個間隔內顯示的使用率低於 20%,表示資料表可能過度佈建。要進一步定義是否需要減少WCUs和的數量RCUS,您應該重新訪問間隔中的其他讀數。
當您的資料表包含數個較低的使用間隔時,您可以從使用 auto 資源調整規模政策中獲益,無論是排定 auto 調度資源調整規模,或只針對以使用率為基礎的資料表設定預設的 auto 調整資源調度
如果您的工作負載使用率低到高節流率 (間隔中的 Max (ThrottleEvents) /Min (ThrottleEvents)),則當您的工作負載非常尖銳,其中流量在某些日子 (或數小時) 增加很多時,可能會發生這種情況,但通常流量一直很低。在這些情況下,使用排程的 auto 調整可能會有所幫助。