3- 超過帳戶限制 - Amazon DynamoDB
超過帳戶限制的緩解措施常見診斷和監控解決程序

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

3- 超過帳戶限制

隨需資料表沒有要管理的佈建容量層級，但 DynamoDB 會強制執行帳戶層級輸送量限制，以防止失控執行並確保所有客戶的公平資源使用。這些每個資料表帳戶限制可做為可調整的保護措施，為每個帳戶和區域組合設定 。當您的讀取或寫入耗用率超過這些限制時，DynamoDB AccountLimitExceeded 會在調節例外狀況中傳回調節原因類型。當資料表未設定自訂最大輸送量設定時，預設每個資料表帳戶限制會自動套用。您可以選擇性地設定最大輸送量設定，以提高成本控制和可預測性，或者如果您的應用程式需求超過預設限制，也可以透過Amazon DynamoDB 中的配額主控台請求增加配額。

超過帳戶限制的緩解措施

本節提供帳戶限制限流案例的解析指引。使用本指南之前，請確定您已識別應用程式例外狀況處理的特定限流原因，並確定受影響資源的 Amazon Resource Name (ARN)。如需擷取限流原因和識別限流資源的相關資訊，請參閱 DynamoDB 限流診斷架構。

在深入探討特定限流案例之前，請先判斷是否實際需要採取動作：

  • 評估效能影響：檢查您的應用程式是否仍然符合其效能需求，即使限流。許多應用程式會在帳戶限制或接近帳戶限制時成功運作，尤其是在大量操作或資料遷移期間。

  • 檢閱限流模式：如果限流是間歇性的，且您的應用程式有效地處理重試，則目前的限制可能足以滿足您的工作負載。

如果即使偶爾達到帳戶限制，應用程式仍會以可接受的方式執行，您可以選擇只監控情況，而不是實作立即變更。

如果您判斷限流造成無法接受的效能問題或可靠性問題，請選取以下特定的限流原因，以尋找建議的緩解選項：

TableReadAccountLimitExceeded

發生這種情況時

資料表的讀取耗用量已超過您區域的每個資料表讀取輸送量配額的帳戶層級。您可以在 中監控 CloudWatch 指標常見診斷和監控，以分析限流事件。

解決方法

使用下列步驟來解決此限流：

  • 請求增加配額：

    請求提高每個資料表的讀取輸送量限制 (Quota 程式碼 L-CF0CBE56)。如需如何提交請求的詳細步驟，請參閱請求每個資料表配額增加。

TableWriteAccountLimitExceeded

發生這種情況時

您資料表的寫入耗用量已超過您 區域的每資料表帳戶層級寫入輸送量配額。您可以在 中監控 CloudWatch 指標常見診斷和監控，以分析限流事件。

解決方法

使用下列步驟來解決此限流：

  • 請求增加配額：請求提高每個資料表的寫入輸送量限制 (Quota 程式碼 L-AB614373)。如需如何提交請求的詳細步驟，請參閱請求每個資料表配額增加。

IndexReadAccountLimitExceeded

發生這種情況時

以全域次要索引 (GSI) 為目標的讀取操作會耗用比您帳戶在目前 AWS 區域中允許的每個資料表讀取配額更多的輸送量。每個資料表的帳戶層級讀取輸送量配額會集體套用至資料表及其所有 GSIs合併。您可以在 中監控 CloudWatch 指標常見診斷和監控，以分析限流事件。

解決方法

根據帳戶的容量分佈選擇適當的解決方案：

IndexWriteAccountLimitExceeded

發生這種情況時

對基底資料表的寫入操作會產生對應的 GSI 更新，這些 GSI 總和超過您 AWS 區域的帳戶層級每個資料表寫入輸送量配額。每次寫入包含以 GSI 編製索引之屬性的基礎資料表項目時，都會觸發對該 GSI 的對應寫入操作。這些合併寫入操作會計入您的每個資料表寫入輸送量配額。您可以在 中監控 CloudWatch 指標常見診斷和監控，以分析這些限流事件的模式和時間，並識別哪些操作導致過多的 GSI 寫入活動。

解決方法

根據帳戶的容量分佈選擇適當的解決方案：

常見診斷和監控

當疑難排解超過帳戶限制調節事件時，數個 CloudWatch 指標有助於識別您是達到每個資料表還是整個帳戶的限制，並了解您的容量分佈模式。

基本 CloudWatch 指標

監控這些關鍵指標以診斷帳戶限制限流：

解決程序

請求增加每個資料表配額

如果您的應用程式需要操作超過目前的每個資料表輸送量限制，您應該使用以下程序提交配額增加請求。您 AWS 帳戶中的每個 DynamoDB 資料表 （連同其所有相關聯的 GSIs) 都受到特定區域內這些輸送量配額的約束。這些配額代表任何個別資料表及其 GSIs 可共同使用的讀取或寫入容量上限，它們可獨立套用至每個資料表，而不是做為您帳戶中所有資料表的彙總。

或者，您也可以設定每個資料表或每個 GSI 的最大隨需輸送量設定，以設定較低的限制。

  1. 識別需要增加的特定配額：

    • 每個資料表讀取輸送量限制 (Quota 程式碼 L-CF0CBE56)：每個資料表預設 40，000 RCUs

    • 每個資料表寫入輸送量限制 (Quota 程式碼 L-AB614373)：每個資料表預設 40，000 WCUs

  2. 使用 AWS Service Quotas 主控台請求提高：

    • 導覽至 Service Quotas 中的 DynamoDB 服務

    • 使用配額代碼尋找適當的配額

    • 根據您的預測尖峰用量請求增加

  3. 提供增加的合理性，包括：

    • 目前的使用模式和尖峰流量需求

    • 增加容量的業務理由

    • 需要增加容量的時間表

注意

配額增加通常需要 24-48 小時來處理。相應地規劃您的請求，並在等待核准時考慮暫時緩解策略。

最佳化 GSI 投影和設計

最佳化您的全域次要索引 (GSI) 投影和設計，以減少容量消耗並改善效能。

選擇性投影策略

如果您的查詢只需要存取幾個屬性，則當基礎資料表項目變更時，僅投影這些屬性會減少寫入 GSI 的資料量。如需投影類型的詳細資訊，請參閱全域次要索引的投影。

  1. 分析查詢模式：檢閱應用程式的查詢模式，以識別透過 GSI 實際存取的屬性。

  2. 使用選擇性投影：只有查詢中實際需要的專案屬性，才能減少寫入磁碟區。

  3. 考慮 KEYS_ONLY：如果您的查詢只需要關鍵屬性，請使用KEYS_ONLY投影將寫入磁碟區降至最低。

  4. 平衡讀取與寫入權衡：投影較少的屬性可減少寫入容量耗用，但可能需要額外的基礎資料表讀取。

稀疏 GSI 實作

稀疏 GSIs僅包含具有索引屬性的項目，而不是基礎資料表中的所有項目。當您經常查詢特定資料子集時，這可降低分割區密度並改善效能。

  1. 設計 GSIs只包含具有特定屬性值的項目。

  2. 僅對應編製索引的項目設定 GSI 分割區索引鍵屬性，以實作條件式索引。

  3. 在稀疏 GSIs （例如 status#timestamp) 中使用複合索引鍵，進一步分配索引項目子集內的流量。

如需實作這些策略的詳細資訊，請參閱在 DynamoDB 中使用次要索引的最佳實務。