全域資料表：運作方式
重要
本文件適用於全域資料表 2017.11.29 版 (舊版)，新的全域資料表應避免使用此文件。客戶應盡可能使用 2019.11.21 版全域資料表 (目前版本)，因為相較於 2017.11.29 (舊版)，其提供更大的彈性、更高的效率，且消耗的寫入容量更少。
若要判斷您使用的是哪個版本，請參閱 判斷全域資料表版本。若要將現有全域資料表從 2017.11.29 版 (舊版) 更新至 2019.11.21 版 (目前版本)，請參閱 DynamoDB 全域資料表版本。
以下各節可協助您了解 Amazon DynamoDB 中全域資料表的概念和行為。
2017.11.29 版 (舊版) 的全域資料表概念
全域資料表是一或多個複本列表的集合，全由單個 AWS 帳戶擁有。
複本列表 (簡稱複本) 是單一 DynamoDB 資料表，可作為全域資料表的一部分運作。每個複本會存放相同的資料項目集。任何特定全域資料表的每個 AWS 區域只能有一個複本列表。
以下是如何建立全域資料表的概念性概觀。
-
在啟用 DynamoDB Streams 的情況下，在 AWS 區域建立一般 DynamoDB 資料表。
-
針對要複寫資料的每個其他區域重複步驟 1。
-
根據您建立的資料表定義 DynamoDB 全域資料表。
AWS Management Console 會自動執行這些任務，因此您可以更快速、更輕鬆地建立全域資料表。如需詳細資訊，請參閱 建立全域資料表。
產生的 DynamoDB 全域資料表由多個複本列表組成，DynamoDB 會將其視為單一單位 (每個區域一個)。每個複本都有相同的資料表名稱和相同的主索引鍵結構描述。當應用程式將資料寫入某個區域的複本列表時，DynamoDB 會自動將寫入傳播到另一個 AWS 區域的其他複本列表。
重要
為了讓資料表資料保持同步，全域資料表會自動為每個項目建立下列屬性：
-
aws:rep:deleting -
aws:rep:updatetime -
aws:rep:updateregion
請勿修改這些屬性或建立具有相同名稱的屬性。
您可以將複本列表新增到全域資料表，以便在其他區域中使用該複本列表。(若要執行這項操作，全域資料表必須是空的。換句話說，任何複本列表中都不得包含任何資料。)
您也可以從全域資料表中移除複本列表。如果您執行這項操作，則資料表與全域資料表的關聯會完全取消。這個新的獨立資料表不再與全域資料表互動，而且資料不再傳播至全域資料表或從全域資料表傳播。
警告
請注意，移除複本不是自動的。為了確保一致的行為和已知狀態，您可能需要考慮事先將應用程序寫入流量從要移除的複本轉移。移除後，請等候所有複本區域端點將複本顯示為已解除關聯，再將其作為自己的隔離區域表進行進一步的寫入操作。
一般任務
全域資料表的一般任務如下。
您可以刪除全域資料表的複本資料表，方式與一般資料表相同。這將停止複寫到該區域，並刪除保留在該區域中的資料表複本。您無法中斷複寫，並讓資料表的複本以獨立實體的形式存在。
注意
在來源資料表用於啟動新區域後至少 24 小時之後，您才能刪除來源資料表。若您嘗試刪除，很快便會收到錯誤。
如果應用程式大約在同一時間更新不同區域中的相同項目，則可能會發生衝突。為了協助確保最終一致性，DynamoDB 全域資料表會在並行更新間使用「最後寫入者獲勝」方法，在並行更新間使用最後寫入者。所有的複本都會同意最新的更新，並朝它們都具有相同資料的狀態收斂。
注意
有幾種方式可以避免衝突，包括：
使用 IAM 政策，只允許寫入一個區域中的資料表。
使用 IAM 政策，將使用者路由到單一區域，並將另一個區域保持為閒置待命狀態，或者交替將奇數使用者路由到一個區域，將偶數使用者路由到另一個區域。
避免使用非等冪更新，例如書籤 = 書籤 + 1，以支援靜態更新，例如書籤 = 25。
監控全域資料表
您可以使用 CloudWatch 觀察 ReplicationLatency 指標。假設某個更新項目出現在 DynamoDB 串流的複本資料表，此指標可追蹤該項目出現在全域資料表中其他複本時經過的時間。ReplicationLatency 會以毫秒表示，並會針對每對來源及目的地區域對發送。這是全域資料表 v2 提供的唯一 CloudWatch 指標。
您觀察到的延遲取決於所選擇區域之間的距離以及其他變數。區域的 0.5 到 2.5 秒範圍內的延遲在同一地理區域內可能很常見。
存留時間 (TTL)
您可以使用存留時間 (TTL) 來指定屬性名稱，其值表示項目的到期時間。自 Unix epoch 開始以來，此值都以秒為單位。
使用全域資料表舊版時，系統不會自動將 TTL 刪除作業複寫到其他複本。透過 TTL 規則刪除項目時，該工作執行時不會耗用寫入單位。
請注意，如果來源和目標資料表的佈建寫入容量非常低，這可能會造成限流，因為 TTL 刪除需要寫入容量。
使用全域資料表的串流和交易
每個全域資料表都會根據其所有寫入作業產生獨立的串流，無論這些寫入的起始點為何。您可以選擇在一個區域或所有區域中獨立使用此 DynamoDB 串流。
如果您想要處理本機寫入，但不要複製寫入，可以將自己的區域屬性新增至每個項目。然後，您可以使用 Lambda 事件篩選條件，只調用 Lambda 在本機區域中進行寫入。
交易操作僅在最初進行寫入的區域內提供 ACID (不可分割性、一致性、隔離性和耐久性) 保證。全域資料表不支援跨區域交易。
例如，如果您有一個全域資料表，其在美國東部 (俄亥俄) 和美國西部 (奧勒岡) 區域有複本，並且在美國東部 (俄亥俄) 區域執行 TransactWriteItems 操作，在這些變更進行複寫之後，您可能會在美國西部 (奧勒岡) 區域看到部分完成的交易。只有當變更已在來源區域遞交的情況下，這些變更才會複寫至其他區域。
注意
全域資料表透過直接更新 DynamoDB 來「寫入」DynamoDB 加速器。因此，DAX 不會意識到它持有過時的資料。只有在快取的 TTL 到期時，才會重新整理 DAX 快取。
全域資料表上的標籤不會自動傳播。
讀取和寫入輸送量
全域資料表會以下列方式管理讀取和寫入輸送量。
跨區域的所有資料表執行個體的寫入容量必須相同。
使用版本 2019.11.21 (目前版本) 時，如果資料表設為支援自動擴展或處於隨需模式，則寫入容量會自動保持同步。在這些同步的自動擴展設定中，每個區域目前佈建的寫入容量可獨立增減。如果將資料表置於隨需模式，則該模式將同步至其他複本。
區域之間的讀取容量可能會有所不同，因為讀取可能不相等。將全域複本新增至資料表時，會傳播來源區域的容量。建立之後，您可以調整某個複本的讀取容量，而這個新設定不會傳輸到另一端。
一致性和衝突解決
對任何複本列表中任何項目所做的任何變更都會複寫到相同全域資料表中的所有其他複本。在全域資料表中，新寫入的項目通常會在幾秒鐘內傳播到所有複本列表。
使用全域資料表，每個複本列表會存放相同的資料項目集。DynamoDB 不支援僅對某些項目進行部分複寫。
應用程式可以讀取資料和將資料寫入至任何複本列表。DynamoDB 支援跨區域的最終一致讀取，但不支援跨區域的高度一致性讀取。如果應用程式只使用最終一致讀取，並且只對一個 AWS 區域發出讀取，則該應用程式不需任何修改即可運作。不過，如果您的應用程式需要強式一致讀取，則必須在相同區域中執行所有高度一致性讀取和寫入。否則，如果您對某個區域進行寫入並從另一個區域進行讀取，則讀取回應可能包含過時資料，這些資料不會反映最近在另一個區域中完成的寫入結果。
如果應用程式大約在同一時間更新不同區域中的相同項目，則可能會發生衝突。為了協助確保最終一致性，DynamoDB 全域資料表會在並行更新間使用最後寫入者獲勝核對機制，其中 DynamoDB 會在並行更新間盡最大努力判斷最後寫入者。有了這個衝突解決機制，所有的複本都會同意最新的更新，並朝它們都具有相同資料的狀態收斂。
可用性與持久性
如果單一 AWS 區域變得孤立或降級，您的應用程式可以重新導向到不同的區域，並對不同的複本列表執行讀取和寫入。您可以套用自訂商業邏輯來決定何時將請求重新導向至其他區域。
如果區域變得孤立或降級，DynamoDB 會追蹤已執行但尚未傳播到所有複本列表的任何寫入。當區域重新回到線上的狀態時，DynamoDB 會繼續將該區域的任何擱置寫入傳播到其他區域的複本列表中。其也會繼續將寫入從其他複本列表傳播到目前已重回到線上狀態的區域。無論區域隔離多長時間，所有之前成功的寫入都將最終傳播。
