DynamoDB 全域資料表和常見問題的準備檢查清單 - Amazon DynamoDB
FAQ

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

DynamoDB 全域資料表和常見問題的準備檢查清單

部署全域資料表時，請使用下列檢查清單來制定決策和執行任務。

  • 決定有多少以及哪些區域應參與全域資料表。

  • 決定應用程式的寫入模式。如需詳細資訊，請參閱使用 DynamoDB 全域資料表的寫入模式。

  • 根據您的寫入模式計畫 使用 DynamoDB 全域資料表請求路由 策略。

  • 根據您的寫入模式和路由策略定義疏散計劃。

  • 擷取每個區域的運作狀態、延遲和錯誤的指標。如需 DynamoDB 指標的清單，請參閱 AWS 部落格文章監控 Amazon DynamoDB for Operational Awareness，以取得要觀察的指標清單。您還應該使用 Synthetic Canaries (旨在檢測故障的人工請求，以煤礦中的金絲雀命名)，以及即時觀察客戶流量。並非所有問題都會出現在 DynamoDB 指標中。

  • 為 ReplicationLatency 中任何持續增加設定警示。增加可能表示意外設定錯誤，而全域資料表在不同區域中有不同的寫入設定，這會導致複寫請求失敗並增加延遲。這也可能表示存在區域中斷。一個很好的例子是如果最近的平均值超過 180,000 毫秒，則發出警示。您也可能會留意ReplicationLatency是否下降至 0，這表示複寫停止。

  • 為每個全域資料表指派充足的最大讀取和寫入設定值。

  • 事先確定疏散區域的原因。如果決定涉及人為判斷，請記錄所有考量因素。這項工作應提前仔細完成，而不是在壓力下進行。

  • 為每個動作維護執行手冊，作為當疏散區域時必須採取的措施。通常，全域資料表涉及的工作很少，但移動堆疊的其餘部分可能很複雜。

    注意

    最佳實務是僅依賴資料平面操作，而非控制平面操作，因為在區域故障期間，某些控制平面操作可能會遭到降級。

    如需詳細資訊，請參閱 AWS 部落格文章使用 Amazon DynamoDB 全域資料表建置彈性應用程式：第 4 部分。

  • 定期測試執行手冊的各個方面，包括區域疏散。未經測試的執行手冊是不可靠的執行手冊。

  • 請考慮使用 Resilience Hub 來評估整個應用程式 (包括全域資料表) 的彈性。它透過儀表板提供整體應用程式產品組合彈性狀態的全面檢視。

  • 考慮使用ARC整備檢查來評估應用程式的目前組態，並追蹤最佳實務的任何偏差。

  • 撰寫用於 Route 53 或 Global Accelerator 使用的運作狀態檢查時，僅通過延時來確定 DynamoDB 端點是否已啟動是不夠的。這不涵蓋許多失敗模式，例如IAM組態錯誤、程式碼部署問題、DynamoDB 外部堆疊中的失敗、高於平均讀取或寫入延遲等。最好執行一組執行完整資料庫流程的呼叫。

部署全域資料表的常見問答集 （FAQ）

DynamoDB 全域資料表的整體使用方式有哪些實用原則？

DynamoDB 全域資料表的控制項很少，但仍需要考慮很多因素。您必須決定寫入模式、路由模型和疏散程序。您必須在每個區域檢測您的應用程式，並準備好調整路由或執行疏散以維護全域狀況。獲得的好處是擁有全球分佈式的資料集，具有低延遲讀取和寫入，以及 99.999% 的服務等級協議。

全域資料表的定價為何？

寫入傳統 DynamoDB 資料表的定價單位為寫入容量單位 （WCUs，適用於佈建資料表） 或寫入請求單位 （WRUs，適用於隨需資料表）。如果您寫入一個 5 KB 的項目，則會產生 5 個單位的費用。對全域資料表的寫入會以複寫寫入容量單位 （rWCUs，適用於佈建資料表） 或複寫寫入請求單位 （rWRUs，適用於隨需資料表） 定價。

rWCUs 和 rWRUs 包含管理複寫所需的串流基礎設施成本。因此，價格比 WCUs和 高 50%WRUs。需支付跨區域資料傳輸費用。

直接寫入或複寫寫入項目的每個區域都會產生複寫寫入單位費用。

寫入全域次要索引 （GSI） 會被視為本機寫入，並使用一般寫入單位。

rWCUs 目前沒有 可用的預留容量。購買預留容量可能仍然有利於GSIs使用寫入單位的資料表。

將新區域新增至全域資料表時，初始啟動程序的費用如同每 GB 還原的資料一樣，再加上跨區域資料傳輸費用。

全域資料表支援哪些區域？

Global Tables 2019.11.21 版 （目前） 適用於大多數 區域。當您新增複本時，您可以在 DynamoDB 主控台的區域下拉式清單中看到最新的清單。

如何使用全域資料表GSIs處理 ？

在 Global Tables 2019.11.21 版 （目前） GSI中，當您在一個區域中建立 時，它會自動在其他參與區域中建立並自動回填。

如何停止全域資料表的複寫？

刪除複本資料表的方式，與刪除其他資料表相同。刪除全域資料表將停止複寫到該區域，並刪除保留在該區域中的資料表複本。不過，您不能在將表的複本作為獨立實體保留的同時停止複制，也無法暫停複寫。

DynamoDB 串流如何與全域資料表互動？

每個全域資料表都會根據其寫入資料表產生獨立串流，無論是從哪裡開始。您可以選擇在一個區域或所有區域中 (獨立) 使用此 DynamoDB 串流。如果您想要處理本機寫入，而不是複寫的寫入操作，可以將自己的區域屬性新增至每個項目。然後，您可以使用 Lambda 事件篩選條件，呼叫 Lambda 函數在本機區域中進行寫入。這有助於插入和更新操作，可惜不能用於刪除操作。

全域資料表如何處理交易？

交易操作提供原子度、一致性、隔離和耐久性 （ACID） 保證，僅在原始執行寫入操作的 區域中提供。全域資料表不支援跨區域交易。例如，如果您有一個全域資料表，其在美國東部 (俄亥俄) 和美國西部 (奧勒岡) 區域有複本，並且在美國東部 (俄亥俄) 區域執行 TransactWriteItems 操作，在這些變更進行複寫之後，您可能會在美國西部 (奧勒岡) 區域看到部分完成的交易。當變更已在來源區域遞交後，這些變更才會複寫至其他區域。

全域資料表如何與 DynamoDB Accelerator 快取 （） 互動DAX？

全域資料表會直接更新 DynamoDB DAX來略過，因此 DAX 不知道它持有過時的資料。只有在DAX快取TTL過期時，才會重新整理快取。

是否會傳播資料表上的標籤？

否，標籤不會自動傳播。

我應該備份所有區域中的資料表還是只備份一個？

答案是取決於備份的目的。如果您想要確保資料耐久性，則 DynamoDB 已適當提供該保護。該服務確保的就是耐久性。如果您想要保留歷史記錄的快照 (例如，為了符合法規要求)，則在一個區域中進行備份應該就足夠了。您可以使用 將備份複製到其他區域 AWS Backup。如果您想要復原錯誤刪除或修改的資料，請在一個區域中使用 DynamoDB point-in-time 復原 （PITR）。

如何使用 部署全域資料表 AWS CloudFormation？

CloudFormation 代表 DynamoDB 資料表和全域資料表作為兩個單獨的資源： AWS::DynamoDB::Table和 AWS::DynamoDB::GlobalTable。其中一種方法是使用 GlobalTable 建構模組來建立可能是全域資料表的所有資料表。然後，您可以將它們保留為獨立資料表來啟動，並在稍後視需要新增至區域。

在 中 CloudFormation，每個全域資料表都由單一 區域中的單一堆疊控制，無論複本數量為何。部署範本時， 會 CloudFormation 建立和更新所有複本，做為單一堆疊操作的一部分。您不應在多個區域中部署相同的 AWS：：DynamoDB ：：GlobalTable 資源。這會導致錯誤且不支援。如果您在多個區域中部署應用程式範本，則可以使用條件在單一區域中建立 AWS::DynamoDB::GlobalTable 資源。您也可以選擇在與應用程式分開的堆疊中定義 AWS::DynamoDB::GlobalTable 資源，並確保其部署到單一區域。

如果您有一般資料表，而且想要將其轉換為全域資料表，同時透過將刪除政策 CloudFormation 設定為保留來加以管理、從堆疊中移除資料表、將資料表轉換為主控台中的全域資料表，然後將全域資料表作為堆疊的新資源匯入。

目前不支援跨帳戶複寫。