本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
1 - 超過金鑰範圍輸送量 （熱分割區）
Amazon DynamoDB 在資料表和全域次要索引 (GSI) 的分割區層級強制執行特定輸送量限制。每個分割區都有每秒的最大讀取容量單位 (RCUs) 和寫入容量單位 WCUs)。當分割區接收到超過這些限制的集中流量時，它們會遇到限流，而其他操作可能會保持使用率過低，進而建立「熱分割區」。DynamoDB 的分割區層級調節會針對讀取和寫入獨立運作 - 分割區可能會在寫入繼續正常時調節讀取，反之亦然。即使您的資料表或 GSI 具有足夠的整體容量，也可能發生此限流。若要進一步了解：
-
DynamoDB 分割區限制和解決熱分割區預防的有效分割區索引鍵設計，請參閱在 DynamoDB 中有效設計和使用分割區索引鍵的最佳實務。
-
一般分割區概念和資料分佈，請參閱 DynamoDB 中的分割區。
-
管理分割區索引鍵和輸送量的其他指導和實際案例，請參閱 其他資源。
當個別分割區超過其輸送量限制時，DynamoDB KeyRangeThroughputExceeded 會在調節例外狀況中傳回調節原因類型。資訊會識別分割區的流量過高，以及導致此問題的操作類型 （讀取或寫入）。
金鑰範圍輸送量超過緩解措施
本節提供分割區層級限流案例的解析指引。使用本指南之前，請確定您已識別應用程式例外狀況處理的特定限流原因，並確定受影響資源的 Amazon Resource Name (ARN)。如需有關擷取限流原因和識別限流資源的資訊，請參閱 DynamoDB 限流診斷架構。
在深入探討特定的限流案例之前，請先檢查問題是否自動解決：
-
DynamoDB 通常會透過其自動split-for-heat機制來適應熱分割區。如果您看到調節事件在短時間內停止，您的資料表可能已透過分割熱分割區進行調整。當分割區分割時，每個新分割區都會處理金鑰空間的較小區段，這有助於更平均地分配負載。在許多情況下，不需要進一步的動作，因為 DynamoDB 已自動解決問題。
如需split-for-heat機制的詳細資訊，請參閱 其他資源。
如果限流持續存在，請參閱以下特定限流案例，了解目標修復選項：
TableReadKeyRangeThroughputExceeded
發生這種情況時
DynamoDB 資料表中一或多個分割區的消耗率超過分割區的讀取輸送量限制。無論您資料表的總佈建容量為何，都會發生此限流，並同時影響佈建資料表和隨需資料表。您可以在 中監控 CloudWatch 指標常見診斷和監控，以分析限流事件。
修復選項
請考慮這些步驟來處理您的限流事件：
對於佈建和隨需模式：
-
預熱容量：如果限流持續存在，請檢查您的資料表是否受限於其了解 DynamoDB 暖輸送量容量。針對預期的流量增加，預先使用暖輸送量或增加讀取佈建容量。提高暖輸送量可改善資料表在調節發生之前處理突然流量尖峰的能力。隨著時間的推移，如果您的實際輸送量持續接近暖輸送量層級，DynamoDB 可能會根據觀察到的用量模式分割忙碌的分割區。
-
識別您的熱鍵：如果資料表未自動解析它，且您的暖輸送量很高或提高它沒有幫助，您將需要識別特定的熱鍵。使用 使用 CloudWatch Contributor Insights 識別熱鍵 來判斷是否有任何特定的分割區索引鍵值很熱。這是有效鎖定緩解工作的第一步。請注意，識別不一定是直接的，尤其是滾動熱分割區 （不同分割區會隨時間變得熱） 或當調節是由掃描等操作觸發時。對於這些複雜的案例，您可能需要分析應用程式的存取模式，並將其與限流事件的時間相關聯。
-
根據您的使用案例，請考慮使用最終一致讀取：從強一致切換到最終一致讀取，這會耗用一半RCUs，並可立即將有效讀取容量加倍。如需實作最終一致讀取以減少讀取容量耗用量的最佳實務，請參閱 DynamoDB 讀取一致性。
-
改善分割區索引鍵設計：作為長期解決方案，請考慮改善分割區索引鍵設計跨分割區更平均地分配存取權。這種方法通常透過解決根本原因，為熱分割區問題提供最全面的解決方案。不過，它需要仔細規劃，因為它涉及重大的遷移挑戰。
TableWriteKeyRangeThroughputExceeded
發生這種情況時
DynamoDB 資料表中一或多個分割區的消耗率超過分割區的寫入輸送量限制。無論您資料表的總佈建容量為何，都會發生此限流，並同時影響佈建資料表和隨需資料表。您可以在 中監控 CloudWatch 指標常見診斷和監控，以分析限流事件。
修復選項
請考慮這些步驟來處理您的限流事件：
對於佈建和隨需模式：
-
預熱容量：如果限流持續存在，請檢查您的資料表是否受限於其了解 DynamoDB 暖輸送量容量。針對預期的流量增加，預先使用暖輸送量或增加寫入佈建容量。提高暖輸送量可改善資料表在調節發生之前處理突然流量尖峰的能力。隨著時間的推移，如果您的實際輸送量持續接近暖輸送量層級，DynamoDB 可能會根據觀察到的用量模式分割忙碌的分割區。
-
識別您的熱鍵：如果資料表未自動解決它，且您的暖輸送量很高或提高它沒有幫助，您將需要識別特定的熱鍵。使用 使用 CloudWatch Contributor Insights 識別熱鍵 來判斷是否有任何特定的分割區索引鍵值很熱。這是有效鎖定緩解工作的第一步。請考慮這些常見模式：
-
如果您看到調節資料中經常出現相同的分割區索引鍵，這表示集中的熱索引鍵。
-
如果您沒有看到重複的索引鍵，但以排序方式寫入資料 （例如循序時間戳記或遵循索引鍵空間順序的掃描型操作），則可能會滾動熱分割區，其中隨著您的寫入在索引鍵空間中移動，不同的索引鍵會隨時間變得很熱。
請注意，寫入限流也可能發生在同時影響多個項目的操作，例如
BatchWriteItem或 交易。當BatchWriteItem請求中的個別項目受到限流時，DynamoDB 不會將這些限流錯誤傳播到應用程式程式碼。相反地，DynamoDB 會傳回回應中未處理項目的相關資訊，您的應用程式必須透過重試這些特定項目來處理這些項目。對於交易，TransactionCanceledException如果任何項目遇到限流，整個操作會失敗。對於這些複雜的案例，您可能需要分析應用程式的寫入模式和資料擷取工作流程，將其與限流事件的時間相關聯，並實作適當的重試處理策略。 -
-
改善分割區索引鍵設計：作為長期解決方案，請考慮改善分割區索引鍵設計跨分割區更平均地分配存取權。這種方法通常透過解決根本原因，為熱分割區問題提供最全面的解決方案。不過，它需要仔細規劃，因為它涉及重大的遷移挑戰。
IndexReadKeyRangeThroughputExceeded
發生這種情況時
DynamoDB GSI 中一或多個分割區的消耗率超過分割區的讀取輸送量限制。無論您的 GSI 總佈建容量為何，都會發生此限流，並同時影響佈建資料表和隨需資料表。您可以在 中監控 CloudWatch 指標常見診斷和監控，以分析限流事件。
修復選項
請考慮這些步驟來處理您的限流事件：
-
預熱容量：如果限流持續存在，請檢查您的 GSI 是否受限於其了解 DynamoDB 暖輸送量容量。針對預期的流量增加，預先使用暖輸送量或增加讀取佈建容量。提高暖輸送量可改善 GSI 在調節發生之前處理突然流量峰值的能力。隨著時間的推移，如果您的實際輸送量一致接近暖輸送量層級，DynamoDB 可能會根據觀察到的用量模式分割忙碌的分割區。
-
識別您的熱鍵：如果 GSI 未自動解析它，且您的暖輸送量很高或提高它沒有幫助，您將需要識別特定的熱鍵。使用 使用 CloudWatch Contributor Insights 識別熱鍵 來判斷是否有任何特定的分割區索引鍵值很熱。這是有效鎖定緩解工作的第一步。請注意，對於 GSIs，分割區索引鍵分佈可能會與您的基礎資料表顯著不同，因此會產生不同的熱索引鍵模式。
-
重新設計 GSI 分割區索引鍵：考慮您的 GSI 索引鍵設計是否可能建立人工熱點 （例如狀態旗標、僅限日期索引鍵或布林屬性），以集中讀取少量分割區。考慮使用將低基數屬性與高基數屬性 （例如，「ACTIVE#customer123」而非僅「ACTIVE」) 結合的複合索引鍵，或將使用寫入碎片在 DynamoDB 資料表中平均分配工作負載技術套用至會影響 GSI 分佈的基礎資料表項目，以將寫入分散到多個分割區。雖然查詢碎片資料需要額外的應用程式邏輯來彙總結果，但此方法可透過更平均地分佈存取模式來防止限流。
IndexWriteKeyRangeThroughputExceeded
發生這種情況時
DynamoDB GSI 中一或多個分割區的消耗率超過分割區的寫入輸送量限制。無論您 GSI 的總佈建容量為何，都會發生此限流，且會影響佈建資料表和隨需資料表。您可以在 中監控 CloudWatch 指標常見診斷和監控，以分析限流事件。
修復選項
請考慮這些步驟來處理您的限流事件：
-
重新設計 GSI 分割區索引鍵：檢閱您的 GSI 分割區索引鍵設計，以確認其有足夠的基數 （唯一性） 可平均分配寫入。GSI 寫入限流的常見原因是使用低基數屬性做為 GSI 分割區索引鍵 （例如只有幾個可能值的狀態旗標）。即使您的基底資料表具有分佈良好的分割區索引鍵，如果 GSI 的分割區索引鍵集中寫入少量的值，您的 GSI 仍會遇到熱分割區。例如，如果 80% 的項目具有 status="ACTIVE"，這會在狀態型 GSI 中建立嚴重的熱分割區。考慮使用將低基數屬性與高基數屬性 （例如，「ACTIVE#customer123」而非僅「ACTIVE」) 結合的複合索引鍵，或將使用寫入碎片在 DynamoDB 資料表中平均分配工作負載技術套用至會影響 GSI 分佈的基礎資料表項目，以將寫入分散到多個分割區。雖然查詢碎片資料需要額外的應用程式邏輯來彙總結果，但此方法可透過更平均地分佈存取模式來防止限流。
-
預熱容量：檢查您的 GSI 是否受限於其了解 DynamoDB 暖輸送量容量。針對預期的流量增加，預先使用暖輸送量或增加讀取佈建容量。提高暖輸送量可改善 GSI 在調節發生之前處理突然流量尖峰的能力。隨著時間的推移，如果您的實際輸送量一致接近暖輸送量層級，DynamoDB 可能會根據觀察到的用量模式分割忙碌的分割區。
-
最佳化 GSI 投影：套用最佳化 GSI 投影技術以減少 GSIs寫入量。投影較少的屬性可大幅降低每次 GSI 更新耗用的寫入容量。
常見診斷和監控
疑難排解分割區層級限流時，數個 CloudWatch 指標可協助識別熱分割區並確認根本原因。
基本 CloudWatch 指標
監控這些關鍵指標以診斷分割區層級限流：
-
分割區層級調節事件：
ReadKeyRangeThroughputThrottleEvents和WriteKeyRangeThroughputThrottleEvents追蹤個別分割區何時超過其輸送量限制。ReadThrottleEvents和WriteThrottleEvents追蹤何時有任何讀取或寫入請求超過佈建的容量。 -
容量消耗：
ConsumedReadCapacityUnits和ConsumedWriteCapacityUnits顯示整體用量模式。
解決程序
使用 CloudWatch Contributor Insights 識別熱鍵
使用此程序來識別哪些分割區索引鍵導致限流。
-
在您的資料表或 GSI 上啟用 CloudWatch Contributor Insights，以追蹤最限流的金鑰。考慮使用調節金鑰模式，持續啟用 CloudWatch Contributor Insights 以進行即時限流警示。此模式僅著重於限流請求，方法是在限流發生時處理事件。此目標監控是維持調節問題持續可見性的一種經濟實惠的方式。
-
識別導致熱分割區問題的金鑰。
-
（如果啟用完整存取和限流金鑰模式) 分析一段時間內的存取模式，以確定熱金鑰是否一致或在特定期間發生。
改善分割區索引鍵設計
當您可以修改資料表結構描述，以在分割區之間更好地分配流量時，請使用此方法。如果可能，這是熱分割區問題最有效的長期解決方案。理想情況下，應在初始資料表設計階段仔細考慮分割區索引鍵設計。
分割區金鑰重新設計代表資料模型的基本變更，會影響整個應用程式生態系統。在繼續此方法之前，請仔細考慮這些重大限制：
-
資料遷移複雜性：重新設計分割區索引鍵需要遷移所有現有的資料，這對於大型資料表來說可能非常耗費資源且耗時。
-
應用程式碼變更：所有讀取或寫入資料表的應用程式碼都必須更新，才能使用新的金鑰結構。
-
生產影響：遷移到新的金鑰設計通常需要在轉換期間停機或複雜的雙寫入策略。
如需分割區索引鍵設計的完整指引和原則，請參閱 在 DynamoDB 中有效設計和使用分割區索引鍵的最佳實務和 設計分割區索引鍵以在 DynamoDB 中分配工作負載。
最佳化 GSI 投影
檢閱應用程式的查詢模式，以判斷查詢 GSI 時需要可用的屬性，並將您的投影限制為僅這些屬性。當您更新未投影到 GSI 的屬性時，該 GSI 上不會發生寫入操作，從而減少更新期間的寫入輸送量耗用量。此目標投影策略可最佳化效能和成本，同時仍支援應用程式的查詢需求。請注意，投影較少的屬性可減少寫入容量耗用，但可能需要額外的基底資料表讀取。
如需高效投影策略的詳細資訊，請參閱在 DynamoDB 中使用次要索引的最佳實務。
其他資源
下列部落格文章提供本指南所涵蓋概念的實作範例和實際詳細資訊：
-
如需使用 GSIs分佈讀取流量的詳細資訊，請參閱使用全域次要索引在 Amazon DynamoDB 中建立最終一致次要索引
。 -
如需擴展 DynamoDB 和管理熱分割區的實作指引，請參閱第 1 部分：擴展 DynamoDB - 如何分割分割區、熱鍵和分割，以取得熱影響效能
。 -
如需 DynamoDB split-for-heat機制的運作方式、其優點和實作詳細資訊，請參閱第 3 部分：摘要和最佳實務
。 -
如需詳細的寫入碎片策略，請參閱 使用寫入碎片在 DynamoDB 資料表中平均分配工作負載。
