本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
1 - 金鑰範圍輸送量超出上限 (熱分割區)
Amazon DynamoDB 會在資料表與全域次要索引 (GSI) 的分割區層級上強制執行特定的輸送量限制。每個分割區每秒可支援的最大讀取容量單位 (RCU) 與寫入容量單位 (WCU)。當分割區承受超出限制的集中流量時，會發生限流，而其他操作可能因使用率偏低而形成「熱分割區」。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 投影 技術以降低 GSI 寫入量。投影較少屬性可大幅降低每次 GSI 更新的寫入容量消耗。
常見診斷與監控
疑難排解分割區層級限流時，數個 CloudWatch 指標可協助識別熱分割區並確認根本原因。
主要 CloudWatch 指標
監控這些核心指標以診斷分割區層級限流：
-
分割區層級限流事件：
ReadKeyRangeThroughputThrottleEvents和WriteKeyRangeThroughputThrottleEvents追蹤個別分割區何時超過其輸送量限制。ReadThrottleEvents和WriteThrottleEvents追蹤任何讀或寫請求何時超過佈建容量。 -
容量耗用情形：
ConsumedReadCapacityUnits和ConsumedWriteCapacityUnits顯示整體使用模式。
解決步驟
使用 CloudWatch Contributor Insights 識別熱鍵
使用此程序識別哪些分割區索引鍵引起限流。
-
在資料表或 GSI 上啟用 CloudWatch Contributor Insights，以追蹤限流最嚴重的金鑰。考慮使用限流金鑰模式，持續啟用 CloudWatch 貢獻者洞察以進行即時限流警示。此模式僅針對限流請求，僅在發生限流時處理事件。此目標監控是以經濟有效的方式持續監控限流問題。
-
識別造成熱分割區問題的金鑰。
-
(若啟用完整存取和限流金鑰模式) 分析一段時間的存取模式，以判斷熱鍵是否持續存在或僅在特定時段出現。
改善分割區索引鍵設計
當您能修改資料表結構以更均衡地分配分割區流量時，請使用此方法。若可行，這是解決熱分割區問題最有效的長期方案。理想情況下，應在初始資料表設計階段仔細規劃分割區索引鍵設計。
分割區索引鍵重新設計是對資料模型的根本性變更，將影響整個應用程式生態系統。在採用此方法前，請仔細評估以下重大限制：
-
資料移轉複雜性：重新設計分割區索引鍵需移轉所有現有資料，對大型資料表而言可能非常耗費資源且耗時。
-
應用程式碼變更：所有與資料表讀寫相關的程式碼都需更新，以使用新的索引鍵結構。
-
生產影響：移轉至新索引鍵設計通常需停機或採用複雜的雙寫策略。
如需分割區索引鍵設計的完整指引與原則，請參閱 在 DynamoDB 中設計與有效運用分割區索引鍵的最佳實務 和 在 DynamoDB 中設計分割區索引鍵以有效分配工作負載。
最佳化 GSI 投影
檢視應用程式的查詢模式，確認查詢 GSI 時需要的屬性，並將投影限制為僅這些屬性。當您更新未投影到 GSI 的屬性時，該 GSI 不會執行寫入操作，從而減少更新期間的寫入輸送量消耗。此目標投影策略可同時最佳化效能與成本，並持續支援應用程式的查詢需求。請注意，投影較少屬性可降低寫入容量消耗，但可能需要額外讀取基礎資料表。
如需了解高效投影策略的詳細資訊，請參閱在 DynamoDB 中使用次要索引的最佳實務。
其他資源
下列部落格文章提供本指南涵蓋概念的實作範例與實務細節：
-
如需了解如何使用 GSI 分散讀取流量，請參閱使用全域次要索引在 Amazon DynamoDB 中建立最終一致次要索引
。 -
如需關於擴展 DynamoDB 及管理熱分割區的實作指引，請參閱第 1 部分：擴展 DynamoDB – 分割區、熱鍵及熱分割對效能的影響
。 -
如需了解 DynamoDB split-for-heat 機制的運作方式、優點與實作細節，請參閱第 3 部分：摘要與最佳實務
。 -
如需詳細寫入碎片策略，請參閱 使用寫入碎片以在 DynamoDB 資料表中平均分配工作負載。
