本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
下列各節說明 Amazon DynamoDB 中全域資料表的概念和行為。
全域資料表概念
全域資料表是一或多個複本資料表的集合，所有複本資料表皆由單一 AWS 帳戶所擁有。
複本列表 (簡稱複本) 是單一 DynamoDB資料表，可作為全域資料表的一部分運作。每個複本會存放相同的資料項目集。任何特定全域資料表的每個 AWS 區域只能有一個複本列表。如需如何開始使用全域資料表的詳細資訊，請參閱 教學課程：建立全域資料表。
在建立 DynamoDB 全域資料表時，該資料表包含 DynamoDB 會將其視為單一單位的多個複本列表 (每個區域一個)。每個複本都有相同的資料表名稱和相同的主索引鍵結構描述。當應用程式將資料寫入一個區域中的複本資料表時，DynamoDB 會自動將寫入傳播到其他 AWS 區域中的其他複本資料表。
您可以將複本列表新增到全域資料表，以便在其他區域中使用該複本列表。
使用 2019.11.21 版 (目前)，當您在一個區域中建立全域次要索引時，它會自動複製到另一個區域並自動回填。
一般任務
全域資料表的一般任務如下。
您可以刪除全域資料表的複本資料表，方式與一般資料表相同。這將停止複寫到該區域，並刪除保留在該區域中的資料表複本。您無法切斷複寫，且資料表複本以獨立實體的形式存在。您可以將全域資料表複製到該區域的本機資料表，然後刪除該區域的全域複本。
注意
在來源資料表用於啟動新區域後至少 24 小時之後，您才能刪除來源資料表。若您嘗試刪除，很快便會收到錯誤。
如果應用程式大約在同一時間更新不同區域中的相同項目，則可能會發生衝突。為了協助確保最終一致性，DynamoDB 全域資料表會在並行更新間使用「最後寫入者獲勝」方法，在並行更新間使用最後寫入者。所有的複本都會同意最新的更新，並朝它們都具有相同資料的狀態收斂。
注意
有幾種方式可以避免衝突，包括：
僅允許在一個區域中寫入資料表。
根據您的寫入策略將使用者流量路由到不同的區域，以確保沒有衝突。
避免使用非等冪更新，例如書籤 = 書籤 + 1，以支援靜態更新，例如書籤 = 25。
請記住，當您將寫入或讀取路由到一個區域時，取決於您的應用程式，以確保流程強制執行。
監控全域資料表
您可以使用 CloudWatch 來觀察指標 ReplicationLatency。這會追蹤一個項目寫入至複本清單，到項目出現在全域資料表的另一個複本中的經過時間。延遲以毫秒為單位表示，並針對每個來源區域和目標區域成對發出。此指標會保留在來源區域中。這是 Global Tables v2 CloudWatch 提供的唯一指標。
您將經歷的複寫延遲取決於您選擇的距離 AWS 區域，以及其他變數。如果您的原始資料表位於美國西部 （加利佛尼亞北部） (us-west-1) 區域，則較近區域的複本，例如美國西部 （奧勒岡） (us-west-2) 區域，與較遠的複本相比，複寫延遲會較低，例如非洲 （開普敦） (af-south-1) 區域。
注意
複寫延遲不會影響API延遲。如果您在區域 A 中有用戶端和資料表，並在區域 B 中新增全域資料表複本，則區域 A 中的用戶端和資料表將具有與新增區域 B 之前相同的延遲。如果您在區域 B 中呼叫 PutItemAPI操作，在延遲大約 Amazon ReplicationLatency 中可用的統計資訊之後，最終可以在區域 A 中讀取 CloudWatch。複寫之前，您會先收到空的回應，而複寫之後，您會收到項目；這兩個呼叫的API延遲大約相同。
存留時間 (TTL)
您可以使用存留時間 (TTL) 指定屬性名稱，其值表示項目的過期時間。自 Unix epoch 開始以來，此值都以秒為單位。之後，DynamoDB 可刪除項目，而不會產生寫入成本。
使用您在TTL一個 區域中設定的全域資料表，該設定會自動複寫到另一個 （些） 區域。當透過TTL規則刪除項目時，該工作會在來源資料表 （但目標資料表） 上不耗用寫入單位的情況下執行 - 但會產生複寫的寫入單位成本。
請注意，如果來源和目標資料表的佈建寫入容量非常低，這可能會導致限流，因為TTL刪除需要寫入容量。
使用全域資料表的串流和交易
每個全域資料表都會根據其所有寫入作業產生獨立的串流，無論這些寫入的起始點為何。您可以選擇在一個區域或所有區域中獨立使用此 DynamoDB 串流。
如果您想要已處理的本機寫入，但未複寫寫入，您可以將自己的區域屬性新增至每個項目。然後，您可以使用 Lambda 事件篩選條件，只叫用 Lambda 在本機區域中進行寫入。
交易操作提供 ACID（原子性、一致性、隔離和耐久性） 保證，僅限於最初進行寫入的區域中。全域資料表中的區域不支援交易。
例如，如果您在美國東部 （俄亥俄） 和美國西部 （奧勒岡） 區域有一個具有複本的全域資料表，並在美國東部 （俄亥俄） 區域執行TransactWriteItems操作，則您可能會看到在美國西部 （奧勒岡） 區域中複寫變更時部分完成的交易。變更只有在來源區域中遞交之後，才會複寫到其他區域。
注意
全域資料表透過直接更新 DynamoDB 來「寫入」DynamoDB 加速器。因此， DAX不會知道它持有過時的資料。DAX 快取只會在快取TTL過期時重新整理。
全域資料表上的標籤不會自動傳播。
讀取和寫入輸送量
全域資料表會以下列方式管理讀取和寫入輸送量。
跨區域的所有表格執行個體的寫入容量必須相同。
使用 2019.11.21 版 （目前），如果資料表設定為支援自動擴展或處於隨需模式，則寫入容量會自動保持同步。這表示一個資料表的寫入容量變更會複寫到其他資料表。
區域之間的讀取容量可能會有所不同，因為讀取可能不相等。將全域複本新增至資料表時，會傳播來源區域的容量。建立之後，您可以調整一個複本的讀取容量，而且不會將此新設定傳輸到另一側。
一致性和衝突解決
對任何複本列表中任何項目所做的任何變更都會複寫到相同全域資料表中的所有其他複本。在全域資料表中，新寫入的項目通常會在一秒內傳播到所有複本列表。
使用全域資料表，每個複本列表會存放相同的資料項目集。DynamoDB 不支援僅對某些項目進行部分複寫。
應用程式可以讀取資料和將資料寫入至任何複本列表。如果您的應用程式只使用最終一致讀取，且只針對一個 AWS 區域讀取的問題，則其將運作，而不會進行任何修改。不過，如果您的應用程式需要強烈一致讀取，則必須在相同區域中執行所有強烈一致讀取和寫入。DynamoDB 不支援跨 區域的強烈一致讀取。因此，如果您對某個區域進行寫入並從另一個區域進行讀取，則讀取回應可能包含過時資料，這些資料不會反映最近在另一個區域中完成的寫入結果。
如果應用程式大約在同一時間更新不同區域中的相同項目，則可能會發生衝突。為了協助確保最終一致性，DynamoDB 全域資料表會在並行更新間使用最後寫入者獲勝核對機制，其中 DynamoDB 會在並行更新間盡最大努力判斷最後寫入者。這會在項目層級執行。有了這個衝突解決機制，所有的複本都會同意最新的更新，並朝它們都具有相同資料的狀態收斂。
可用性與持久性
如果單一 AWS 區域遭到隔離或降級，您的應用程式可以重新導向至不同的區域，並針對不同的複本資料表執行讀取和寫入。您可以套用自訂商業邏輯來決定何時將請求重新導向至其他區域。
如果區域遭到隔離或降級，DynamoDB 會追蹤已執行但尚未傳播至所有複本資料表的任何寫入。當區域重新回到線上的狀態時，DynamoDB 會繼續將該區域的任何擱置寫入傳播到其他區域的複本列表中。它也會繼續將來自其他複本資料表的寫入傳播到現在恢復線上的區域。
