全域資料表：運作方式 - Amazon DynamoDB
2017.11.29 版 (舊版) 的全域資料表概念一般任務監控全域資料表生存時間 (TTL)使用全域資料表的串流和交易讀取和寫入輸送量一致性和衝突解決可用性與持久性

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

全域資料表：運作方式

重要

本文件適用於全域資料表 2017.11.29 版 (舊版)，新的全域資料表應避免使用此文件。客戶應盡可能使用全域表版本 2019.11.21 (目前版本)，因為它比 2017.11.29 (舊版) 提供更大的彈性、更高的效率以及更少的寫入容量。

若要判斷您使用的是哪個版本，請參閱 判斷您正在使用的 DynamoDB 全域資料表版本。若要將現有全域資料表從 2017.11.29 版更新至 2019.11.21 版 (目前)，請參閱 升級全域資料表。

以下各節可協助您了解 Amazon DynamoDB 中全域資料表的概念和行為。

2017.11.29 版 (舊版) 的全域資料表概念

全域表是一或多個複本表格的集合，全部由單一 AWS 帳戶擁有。

複本列表 (簡稱複本) 是單一 DynamoDB資料表，可作為全域資料表的一部分運作。每個複本會存放相同的資料項目集。任何特定全域資料表的每個 AWS 區域只能有一個複本列表。

以下是如何建立全域資料表的概念性概觀。

  1. 在區域中建立一個普通 DynamoDB 表格，並啟用 DynamoDB 串流。 AWS

  2. 針對要複寫資料的每個其他區域重複步驟 1。

  3. 根據您建立的資料表定義 DynamoDB 全域資料表。

AWS Management Console 會自動執行這些任務，因此您可以更快速輕鬆地建立全域資料表。如需詳細資訊，請參閱建立全域資料表。

產生的 DynamoDB 全域資料表由多個複本列表組成，DynamoDB 會將其視為單一單位 (每個區域一個)。每個複本都有相同的資料表名稱和相同的主索引鍵結構描述。當應用程式將資料寫入某個區域的複本列表時，DynamoDB 會自動將寫入傳播到另一個 AWS 區域的其他複本列表。

重要

為了讓資料表資料保持同步，全域資料表會自動為每個項目建立下列屬性：

  • aws:rep:deleting

  • aws:rep:updatetime

  • aws:rep:updateregion

請勿修改這些屬性或建立具有相同名稱的屬性。

您可以將複本列表新增到全域資料表，以便在其他區域中使用該複本列表。(若要執行這項操作，全域資料表必須是空的。換句話說，任何複本列表中都不得包含任何資料。)

您也可以從全域資料表中移除複本列表。如果您執行這項操作，則資料表與全域資料表的關聯會完全取消。這個新的獨立資料表不再與全域資料表互動，而且資料不再傳播至全域資料表或從全域資料表傳播。

警告

請注意，刪除複本不是一個原子過程。為了確保一致的行為和已知狀態，您可能需要考慮事先將應用程序寫入流量從要移除的複本轉移。移除複本之後，請等到所有複本 Region 端點將複本顯示為已取消關聯，然後再進一步寫入複本做為其自己的隔離區域資料表。

一般任務

全域資料表的一般任務如下。

您可以刪除全域資料表的複本資料表，方式與一般資料表相同。這將停止複寫到該區域，並刪除保留在該區域中的資料表複本。您無法中斷複寫，並讓資料表的複本以獨立實體的形式存在。

注意

在來源資料表用於啟動新區域後至少 24 小時之後，您才能刪除來源資料表。若您嘗試刪除，很快便會收到錯誤。

如果應用程式大約在同一時間更新不同區域中的相同項目，則可能會發生衝突。為了協助確保最終一致性，DynamoDB 全域資料表會在並行更新間使用「最後寫入者獲勝」方法，在並行更新間使用最後寫入者。所有的複本都會同意最新的更新，並朝它們都具有相同資料的狀態收斂。

注意

有幾種方式可以避免衝突，包括：

  • 使用IAM政策只允許寫入一個區域中的資料表。

  • 使用IAM政策將使用者路由到一個區域，並將另一個區域保持為閒置待命狀態，或者交替將奇怪的使用者路由到一個區域，甚至將使用者路由到另一個區域。

  • 避免使用非等冪更新，例如書籤 = 書籤 + 1，以支援靜態更新，例如書籤 = 25。

監控全域資料表

您可以使用 CloudWatch 來觀察度量標準ReplicationLatency。此量度會追蹤一個複本表格的 DynamoDB 串流中出現更新項目，以及該項目出現在全域表格的另一個複本之間的經過時間。 ReplicationLatency以毫秒為單位表示，並針對每個來源-區域和目的地-區域配對發出。這是全域表 v2 提供的唯一 CloudWatch 測量結果。

您觀察到的延遲取決於所選擇區域之間的距離以及其他變數。區域的 0.5 到 2.5 秒範圍內的延遲在同一地理區域內可能很常見。

生存時間 (TTL)

您可以使用存留時間 (TTL) 來指定屬性名稱，其值表示項目的到期時間。這個值被指定為自 Unix 紀元開始以來的秒數。

使用全域資料表舊版本時，TTL刪除作業不會自動跨其他複本複寫。當透過TTL規則刪除項目時，系統會執行該工作，而不會使用「寫入單位」。

請注意，如果來源和目標資料表的佈建寫入容量非常低，這可能會造成節流，因為TTL刪除作業需要寫入容量。

使用全域資料表的串流和交易

每個全域資料表都會根據其所有寫入作業產生獨立的串流，無論這些寫入的起始點為何。您可以選擇在一個區域或所有區域中獨立使用此 DynamoDB 串流。

如果您想要處理本機寫入，但不要複製寫入，可以將自己的區域屬性新增至每個項目。然後，您可以使用 Lambda 事件篩選條件，只叫用 Lambda 在本機區域中進行寫入。

交易操作在最初寫入的區域ONLY內提供ACID（原子性，一致性，隔離和耐久性）保證。全域資料表中不支援跨區域的交易。

例如，如果您在美國東部 (俄亥俄) 和美國西部 (奧勒岡) 區域有一個包含複本的全域表格，並且在美國東部 (俄亥俄) 區域執行 TransactWriteItems 作業，則在複寫變更時，您可能會在美國西部 (奧勒岡) 區域觀察部分完成的交易。只有當變更已在來源區域遞交的情況下，這些變更才會複寫至其他區域。

注意

  • 全域資料表透過直接更新 DynamoDB 來「寫入」DynamoDB 加速器。因此，它不DAX會意識到它持有陳舊的數據。DAX緩存只有在緩存TTL過期時才會刷新。

  • 全域資料表上的標籤不會自動傳播。

讀取和寫入輸送量

全域資料表會以下列方式管理讀取和寫入輸送量。

  • 跨區域的所有表格執行個體的寫入容量必須相同。

  • 使用版本 2019.11.21（目前版本），如果表格設定為支援 auto 動調整或處於隨選模式，則寫入容量會自動保持同步。目前在每個區域中佈建的寫入容量將在這些同步的 auto 擴展設定中獨立增加和下降。如果將資料表置於隨需模式，則該模式將同步至其他複本。

  • 區域之間的讀取容量可能會有所不同，因為讀取可能不相等。將全域複本新增至資料表時，會傳播來源區域的容量。建立之後，您可以調整一個複本的讀取容量，而這個新設定不會傳輸到另一端。

一致性和衝突解決

對任何複本列表中任何項目所做的任何變更都會複寫到相同全域資料表中的所有其他複本。在全域資料表中，新寫入的項目通常會在幾秒鐘內傳播到所有複本列表。

使用全域資料表，每個複本列表會存放相同的資料項目集。DynamoDB 不支援僅對某些項目進行部分複寫。

應用程式可以讀取資料和將資料寫入至任何複本列表。DynamoDB 支援跨區域的最終一致讀取，但不支援跨區域的高度一致性讀取。如果您的應用程序僅使用最終一致性讀取，並且僅針對一個 Re AWS gion 讀取問題，則它將無需任何修改即可工作。不過，如果您的應用程式需要強式一致讀取，則必須在相同區域中執行所有高度一致性讀取和寫入。否則，如果您對某個區域進行寫入並從另一個區域進行讀取，則讀取回應可能包含過時資料，這些資料不會反映最近在另一個區域中完成的寫入結果。

如果應用程式大約在同一時間更新不同區域中的相同項目，則可能會發生衝突。為了協助確保最終一致性，DynamoDB 全域資料表會在並行更新間使用最後寫入者獲勝核對機制，其中 DynamoDB 會在並行更新間盡最大努力判斷最後寫入者。有了這個衝突解決機制，所有的複本都會同意最新的更新，並朝它們都具有相同資料的狀態收斂。

可用性與持久性

如果單一 AWS 區域變成隔離或降級，您的應用程式可以重新導向至不同的區域，並針對不同的複本表格執行讀取和寫入。您可以套用自訂商業邏輯來決定何時將請求重新導向至其他區域。

如果區域變得孤立或降級，DynamoDB 會追蹤已執行但尚未傳播到所有複本列表的任何寫入。當區域重新回到線上的狀態時，DynamoDB 會繼續將該區域的任何擱置寫入傳播到其他區域的複本列表中。其也會繼續將寫入從其他複本列表傳播到目前已重回到線上狀態的區域。無論區域隔離多長時間，所有之前成功的寫入都將最終傳播。