本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 使用 DynamoDB 全域資料表
全域資料表以 Amazon DynamoDB 的全球佈局為基礎，提供全受管、多區域、多作用中的資料庫，能為大規模的全球應用程式提供快速且本機化的讀寫效能。全域資料表會自動複寫您選擇的 DynamoDB 資料表 AWS 區域。因為全域資料表使用現有的 DynamoDB API，所以不需要變更應用程式。使用全域資料表沒有前期成本或承諾，您僅需為使用的資源付費。
本指南說明如何有效使用 DynamoDB 全域資料表。本指南說明全域資料表的關鍵資訊、主要使用案例、兩種一致性模式、三種可考慮的寫入模型分類、四項可實作的請求路由選項、區域撤離 (不論線上或離線) 方法、輸送容量規劃考量，以及部署全域資料表時的核對清單。
本指南適用於 AWS 更大的多區域部署內容，如[AWS 多區域基礎](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html)白皮書和[含影片的資料彈性設計模式 AWS](https://www.youtube.com/watch?v=7IA48SOX20c)所述。
**Topics**
+ [有關 DynamoDB 全域資料表設計的關鍵事實](#bp-global-table-design.prescriptive-guidance.facts)
+ [關於 MREC 的重點說明](#bp-global-table-design-MREC-facts)
+ [關於 MRSC 的重點說明](#bp-global-table-design-MRSC-facts)
+ [MREC DynamoDB 全域資料表使用案例](#bp-global-table-design.prescriptive-guidance.usecases)
+ [使用 DynamoDB 全域資料表的寫入模式](bp-global-table-design.prescriptive-guidance.writemodes.md)
+ [DynamoDB 的路由策略](bp-global-table-design.prescriptive-guidance.request-routing.md)
+ [疏散程序](bp-global-table-design.prescriptive-guidance.evacuation.md)
+ [DynamoDB 全域資料表的輸送容量規劃](bp-global-table-design.prescriptive-guidance.throughput.md)
+ [DynamoDB 全域資料表部署前檢查清單](bp-global-table-design.prescriptive-guidance.checklist-and-faq.md)
+ [結論和資源](#bp-global-table-design.prescriptive-guidance-resources-conclusion)
## 有關 DynamoDB 全域資料表設計的關鍵事實
+ 全域資料表共有兩個版本：目前版本[全域資料表版本 2019.11.21 (目前版本)](GlobalTables.md) (又稱「V2」)，以及 [全域資料表 2017.11.29 版 (舊版)](globaltables.V1.md) (又稱「V1」)。本指南僅著重於目前版本。
+ DynamoDB (不含全域資料表) 為區域型服務，具備高可用性，並在設計上對基礎架構故障 (包含整個可用區域 AZ 的中斷) 具備內建彈性。單區域 DynamoDB 資料表設計為可達 99.99% 可用性。如需詳細資訊，請參閱 [DynamoDB 服務水準協議](https://aws.amazon.com/dynamodb/sla/) (SLA)。
+ DynamoDB 全域資料表會在兩個或多個區域間自動複寫資料。多區域 DynamoDB 資料表設計為可達 99.999% 可用性。透過適當規劃，全域資料表可協助建立具備區域故障復原能力的彈性架構。
+ DynamoDB 並未提供全域端點。所有請求皆傳送至區域端點，以存取該區域的本機全域資料表執行個體。
+ 不應跨區域對 DynamoDB 發出呼叫。最佳實務為：每個部署於單一區域的應用程式應僅存取該區域的本機 DynamoDB 端點。若在某區域偵測到問題 (無論位於 DynamoDB 層或相關堆疊)，應將終端使用者流量重新導向至位於其他區域的應用端點。全域資料表可確保各區域的應用程式均可存取相同資料。
### 一致性模式
建立全域資料表時，可設定其一致性模式。全域資料表支援兩種一致性模式：多區域最終一致性 (MREC) 與多區域高度一致性 (MRSC)，後者於 2025 年 6 月推出。
若您在建立全域資料表時未指定一致性模式，系統將預設使用 MREC。全域資料表不得包含使用不同一致性模式設定的副本。全域資料表建立後，其一致性模式無法再變更。
## 關於 MREC 的重點說明
+ 採用 MRSC 的全域資料表同樣使用主動-主動式複寫模型。從 DynamoDB 的角度來看，每個區域中的資料表具有相同地位，可以接受讀取和寫入請求。本機複本資料表在接收到寫入請求後，會於背景作業中將寫入操作複製至其他參與區域。
+ 單獨複製項目。同一交易內更新的項目可能不會同時被複寫。
+ 來源區域內的每個資料表分割區，會與其他分割區並行執行寫入複寫。遠端區域中的寫入操作順序，可能與來源區域的寫入順序不一致。如需有關資料表分割區的詳細資訊，請參閱部落格文章[擴展 DynamoDB：分割區、快捷鍵和熱分割會如何影響效能](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)。
+ 新寫入的項目通常會在一秒內傳播到所有複本列表。靠近區域的傳播速度往往更快。
+ Amazon CloudWatch 為每個區域對提供一個 `ReplicationLatency` 指標。該指標是根據項目的到達時間與初始寫入時間的差異計算平均值而得。計時會儲存在來源區域的 CloudWatch 當中。檢視平均值與最大值有助於評估複寫延遲的平均與最差情境。此延遲沒有 SLA。
+ 若相同項目在兩個不同區域幾乎同時 (於此 `ReplicationLatency` 視窗內) 更新，而第二次寫入發生於第一次寫入尚未複寫之前，則可能發生寫入衝突。採用 MREC 的全域資料表會根據寫入操作的時間戳記，以「最後寫入者獲勝」機制解決此類衝突。第一個操作將被第二個操作覆寫。這些衝突不會記錄於 CloudWatch 或 AWS CloudTrail。
+ 每個項目都有一個作為私有系統屬性保留的最後寫入時間戳記。「最後寫入者獲勝」機制透過條件式寫入實現，要求新項目的時間戳記必須大於現有項目的時間戳記。
+ 全域資料表會將所有項目複寫至所有參與的區域。若需不同複寫範圍，可建立多個全域資料表，並為各資料表指定不同參與區域。
+ 即使複本區域離線或 `ReplicationLatency` 延遲增加，本機區域仍可接受寫入操作。本機資料表會繼續嘗試將項目複製到遠端資料表，直到每個項目成功為止。
+ 萬一區域完全離線，當稍後重新上線時，所有待處理的輸出與輸入複寫都會自動重新嘗試。不需要特殊動作即可使資料表恢復同步。*最後寫入者獲勝*機制可確保資料最終達成一致狀態。
+ 您可隨時將新區域新增至 DynamoDB MREC 資料表。DynamoDB 會自動處理初始同步與持續的複寫作業。您亦可移除某個區域 (包含原始區域)，系統將刪除該區域內的本機資料表。
## 關於 MRSC 的重點說明
+ 採用 MRSC 的全域資料表同樣使用主動-主動式複寫模型。從 DynamoDB 的角度來看，每個區域中的資料表具有相同地位，可以接受讀取和寫入請求。在寫入操作傳回成功回應之前，MRSC 全域資料表複本中的項目變更會至少**同步**複寫到一個其他區域。
+ 任何 MRSC 複本上的高度一致性讀取操作，一律會傳回項目的最新版本。條件式寫入操作一律會依據項目的最新版本來評估條件運算式。更新操作一律會以項目的最新版本為基準執行。
+ MRSC 複本上的最終一致讀取操作，可能未包含最近在其他區域或同一區域中發生的變更。
+ 當寫入操作嘗試修改另一個區域中已被修改的項目時，系統會傳回 `ReplicatedWriteConflictException` 例外狀況並導致操作失敗。若寫入操作因 `ReplicatedWriteConflictException` 例外狀況而失敗，可重試；當項目不再於其他區域被修改時，操作將成功。
+ 使用 MRSC 時，寫入操作與高度一致性讀取操作的延遲較高。這些操作需要跨區域通訊。此類通訊會根據所存取區域與參與全域資料表中最近區域之間的往返延遲而增加額外延遲。如需詳細資訊，請參閱 AWS re：Invent 2024 簡報，[多區域與 DynamoDB 全域資料表的高度一致性](https://www.youtube.com/watch?v=R-nTs8ZD8mA)。最終一致讀取操作不會產生額外延遲。有一款開放原始碼的[測試工具](https://github.com/awslabs/amazon-dynamodb-tools/tree/main/tester)，可讓您針對各區域實驗性計算延遲。
+ 單獨複製項目。採用 MRSC 的全域資料表不支援交易 API。
+ MRSC 全域資料表必須剛好部署在三個區域中。您可將 MRSC 全域資料表設定為三個副本，或兩個副本搭配一個見證。見證是 MRSC 全域資料表中的一個元件，包含最近寫入各副本的資料。見證可作為完整複本的選用替代方案，並支援 MRSC 的高可用架構。見證不支援任何讀取或寫入操作。見證不會產生儲存或寫入的成本。見證部署於與兩個副本不同的區域中。
+ 若要建立 MRSC 全域資料表，可新增一個副本與一個見證，或將兩個副本新增至不含資料的現有 DynamoDB 資料表。無法在現有 MRSC 全域資料表中新增額外副本。無法從 MRSC 全域資料表刪除單一複本或見證。可從 MRSC 全域資料表刪除兩個副本，或刪除一個副本與一個見證。第二種情境會將剩餘複本轉換為單一區域的 DynamoDB 資料表。
+ 您可從 DescribeTable API 的輸出結果判斷 MRSC 全域資料表是否已設定見證，以及該見證所在的區域。見證由 DynamoDB 擁有和管理，不會出現在設定見證的區域中的 AWS 帳戶 中。
+ MRSC 全域資料表可在下列區域集內使用：
+ 美國區域集：美國東部 (維吉尼亞北部)、美國東部 (俄亥俄)、美國西部 (奧勒岡)
+ 歐洲區域集：歐洲 (愛爾蘭)、歐洲 (倫敦)、歐洲 (巴黎)、歐洲 (法蘭克福)
+ AP 區域集：亞太區域 （東京）、亞太區域 （首爾） 和亞太區域 （大阪）
+ MRSC 全域資料表無法跨越不同的區域集。例如，MRSC 全域資料表不能同時包含來自美國區域集與歐洲區域集的副本。
+ MRSC 全域資料表不支援存活時間 (TTL)。
+ MRSC 全域資料表不支援本機次要索引 (LSI)。
+ CloudWatch Contributor Insights 資訊僅會針對執行操作的區域回報。
+ 只要有第二個區域託管複本或見證以建立仲裁，本機區域便會接受所有讀取與寫入操作。若第二個區域無法使用，本機區域僅能提供最終一致讀取。
+ 萬一某個區域完全離線，稍後重新上線時，將自動追上進度。在追上進度之前，寫入操作和強式一致讀取操作*只會*傳回錯誤，而對其他區域的請求會繼續正常運作。對趕上區域的最終一致讀取操作將傳回到目前為止傳播到該區域的資料，並在領導節點和本機複本之間具有一般的本機一致性行為。不需要特殊動作即可使資料表恢復同步。
## MREC DynamoDB 全域資料表使用案例
MREC 全域資料表提供以下優點：
+ **低延遲讀取操作。**將資料複本部署於更接近終端使用者的位置，以降低讀取作業期間的網路延遲。資料會保持與 `ReplicationLatency` 值一致的新鮮度。
+ **低延遲寫入操作。**您可以寫入附近的區域，以減少網路延遲和寫入所花費的時間。必須小心路由寫入流量，以確保沒有衝突。路由技術在 [DynamoDB 的路由策略](bp-global-table-design.prescriptive-guidance.request-routing.md) 中有更詳細的討論。
+ **無縫區域移轉。**您可新增新區域並刪除舊區域，將部署從一個區域移轉至另一個區域，而不會造成資料層停機。
MREC 與 MRSC 全域資料表皆提供以下優點：
+ **提高彈性和災難復原。**若某區域效能降低或完全中斷，您可執行疏散程序。所謂疏散，指將部分或全部導向該區域的請求重新導向至其他區域。使用全域資料表可將 [DynamoDB SLA](https://aws.amazon.com/dynamodb/sla/) 的月度正常運作時間百分比從 99.99% 提升至 99.999%。使用 MREC 可支援以秒為單位的復原點目標 (RPO) 與復原時間點目標 (RTO)。使用 MRSC 可支援 RPO 為零。
例如，Fidelity 投資公司在 re:Invent 2022 中分享了其如何使用 DynamoDB 全域資料表實作訂單管理系統。他們的目標是在無法透過內部部署系統達成的規模下，實現可靠的低延遲處理，同時維持對可用區域及區域性故障的高彈性。
如果您的目標是提高系統韌性與災難復原能力，MRSC 資料表雖具有較高的寫入延遲與高度一致性讀取延遲，但可支援 RPO 為 0。MREC 全域資料表的 RPO 取決於副本之間的複寫延遲，通常為數秒，依各副本所在區域而異。
## 結論和資源
DynamoDB 全域資料表的控制項雖然不多，但仍需審慎規劃。您必須決定寫入模式、路由模型和疏散程序。您必須在每個區域檢測您的應用程式，並準備好調整路由或執行疏散以維護全域狀況。最終成果是可獲得具全球分散架構的資料集，提供低延遲的讀寫操作，並達到 99.999% 的可用性設計目標。
如需 DynamoDB 全域資料表的更多資訊，請參閱以下資源：
+ [DynamoDB 文件](https://docs.aws.amazon.com/dynamodb/)
+ [Amazon 應用程式復原控制器說明](https://aws.amazon.com/application-recovery-controller/)
+ [ARC 中的準備度檢查](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.html) (AWS 文件）
+ [Route 53 路由政策](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)
+ [DynamoDB 服務水準協議](https://aws.amazon.com/dynamodb/sla/)
+ [AWS 多區域基礎 ](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html)(AWS 白皮書）
+ [使用 的資料彈性設計模式 AWS](https://www.youtube.com/watch?v=7IA48SOX20c)(AWS re：Invent 2022 簡報）
+ [Fidelity 投資和 Reltio 如何使用 Amazon DynamoDB 進行現代化 ](https://www.youtube.com/watch?v=QUpV5MDu4Ys&t=706s)(AWS re：Invent 2022 簡報）
+ [多區域設計模式和最佳實務](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) (AWS re：Invent 2022 簡報）
+ [開啟災難復原 (DR) 架構 AWS，第 III 部分：指示燈和暖待命](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (AWS 部落格文章）
+ [使用區域鎖定為 Amazon DynamoDB 全域資料表中的項目設定主區域](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/) (AWS 部落格文章）
+ [監控 Amazon DynamoDB 的操作意識](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) (AWS 部落格文章）
+ [擴展 DynamoDB：分割區、熱鍵和分割如何影響效能 ](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/)(AWS 部落格文章）
+ [多區域與 DynamoDB 全域資料表的高度一致性 ](https://www.youtube.com/watch?v=R-nTs8ZD8mA)(AWS re：Invent 2024 簡報）