全局表:工作原理 - Amazon DynamoDB
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

全局表:工作原理

以下各节介绍 Amazon DynamoDB 中全局表的概念和行为。

全局表概念

全局表是一个或多个副本表的集合,它们都由单个 Amazon 账户所有。

副本表(或副本)是单个 DynamoDB 表,它作为全局表的一部分发挥作用。每个副本都存储相同的数据项目集。对于每个 Amazon 区域,任何给定的全局表只能有一个副本表。有关如何开始使用全局表的更多信息,请参阅 教程:创建全局表

创建 DynamoDB 全局表时,它包含多个副本表(每个区域一个),DynamoDB 将这些表视为单个单元。每个副本都具有相同的表名和相同的主键架构。当应用程序将数据写入一个区域中的副本表时,DynamoDB 会自动将写操作传播到其他 Amazon 区域的其他副本表。

您可以将副本表添加到全局表中,以便在其他区域中可用。

在版本 2019.11.21(当前版)中,当您在一个区域中创建全局二级索引时,它会自动复制到其他区域以及自动回填。

常见任务

全局表的常见任务如下所示。

您可以像删除常规表一样删除全局表的副本表。这将停止复制到该区域并删除保留在该区域的表副本。您无法在切断复制后,让表的副本作为独立实体存在。您可以改为将全局表复制到该区域的本地表中,然后删除该区域的全局副本。

注意

在使用源表启动新区域后的至少 24 小时之内,您无法删除该源表。如果您尝试过早将其删除,则会收到错误。

如果应用程序大约在同一时间更新不同区域中的同一项目,则可能会发生冲突。为了帮助确保最终一致性,DynamoDB 全局表使用“最后一个写入方为准”方法来协调并发更新。所有副本都将同意最新的更新,并收敛到它们都具有相同数据的状态。

注意

避免冲突的方法有几种,其中包括:

  • 仅允许写入一个区域中的表。

  • 根据您的写入策略将用户流量路由到不同的区域,以确保没有冲突。

  • 避免使用诸如 Bookmark = Bookmark + 1 之类的非幂等更新,转而使用诸如 Bookmark=25 之类的静态更新。

  • 请记住,当您需要将写入或读取路由到一个区域时,应由您的应用程序来确保该流程得到执行。

监控全局表

您可以使用 CloudWatch 来观察指标ReplicationLatency。这会跟踪从一个项目写入副本表到该项目出现在全局表中的另一个副本所经过的时间。它以毫秒表示,并针对每一对源区域和目标区域发出。该指标保存在源区域。这是全局表 v2 提供的唯一 CloudWatch 指标。

您将遇到的复制延迟取决于所选Amazon Web Services 区域内容之间的距离以及其他变量。如果您的原始表位于美国西部(加利福尼亚北部)(us-west-1)区域,那么与距离更远的区域(例如非洲(开普敦)(af-south-1)区域)的副本相比,距离更近的区域(例如非洲(开普敦)(af-south-1)区域的副本的复制延迟会更低。通常会看到彼此之间相隔Amazon Web Services 区域不到一公里的复制延迟 0.5 到 2.5 秒。

注意

复制延迟不会影响 API 延迟。如果您在区域 A 中有客户端和表,并且在区域 B 中添加了全局表副本,则区域 A 中的客户端和表的延迟将与添加区域 B 之前的延迟相同。如果您在区域 B 中调用 PutItemAPI 操作,则在延迟了大致相当于 Amazon 提供的ReplicationLatency统计数据之后,它最终可以在区域 A 中读取 CloudWatch。在它被复制之前,你会收到一个空的响应,在它被复制之后,你会收到该项目;两个调用的 API 延迟将大致相同。

生存时间(TTL)

您可以使用生存时间(TTL)来指定一个属性名称,其值表示项目的过期时间。此值以自 Unix 纪元开始以来的秒数给出。在该时间之后,DynamoDB 可以删除该项目而不会产生写入成本。

使用全局表,您可以在一个区域中配置 TTL,且该设置会自动复制到其他区域。通过 TTL 规则删除项目时,删除工作是在不消耗源表上的写入单位的情况下执行的,但目标表将产生复制的写入单位成本。

请注意,如果源表和目标表的预调配写入容量非常低,这可能会导致节流,因为 TTL 删除需要写入容量。

使用全局表的流和事务

每个全局表都基于其所有写入生成一个独立的流,而不考虑这些写入的起点。您可以选择在一个区域或在所有区域中单独使用此 DynamoDB 流。

如果您想要已处理的本地写入而不是复制的写入,则可以为每个项目添加您自己的区域属性。然后,您可以使用 Lambda 事件筛选条件,以仅调用 Lambda 在本地区域中进行写入。

事务操作仅在最初进行写入的区域内提供 ACID(原子性、一致性、隔离性和持久性)保证。全局表中不支持跨区域的事务。

例如,如果您有一个包含美国东部(俄亥俄州)和美国西部(俄勒冈)区域副本的全局表,并在美国东部(俄亥俄州)区域执行 TransactWriteItems 操作,则在复制更改时,您可能会观察到美国西部(俄勒冈)地区已部分完成的交易。更改仅在源区域中提交后才会复制到其他区域。

注意
  • 全局表通过直接更新 DynamoDB 来“绕过”DynamoDB Accelerator。因此,DAX 不会意识到它持有的是陈旧的数据。DAX 缓存只有在缓存的 TTL 过期时才会刷新。

  • 全局表上的标签不会自动传播。

读取和写入吞吐量

全局表通过以下方式管理读取和写入吞吐量。

  • 跨区域的所有表实例上的写入容量必须相同。

  • 在版本 2019.11.21(当前版)中,如果表设置为支持自动扩缩或处于按需模式,则写入容量会自动保持同步。这意味着对一个表的写入容量更改会复制到其他表。

  • 读取容量可能因区域而异,因为读取量可能不相等。在向表添加全局副本时,会传播源区域的容量。创建后,您可以调整一个副本的读取容量,而且此新设置不会传输到另一端。

一致性和冲突解决

对任何副本表中任何项目所做的任何更改都将复制到同一全局表中的所有其他副本。在全局表中,新写入的项目通常会在一秒钟内传播到所有副本表。

对于全局表,每个副本表都存储相同的数据项集。DynamoDB 不支持仅部分项目的部分复制。

应用程序可以读取数据和将数据写入任何副本表。如果您的应用程序只使用最终一致性读取,并且仅针对一个 Amazon 区域,它将无需任何修改工作。但是,如果您的应用程序需要强一致性读取,则必须在同一区域中执行其所有强一致性读取和写入。DynamoDB 不支持跨区域的强一致性读取。因此,如果您写入一个区域并从另一个区域读取,读取响应可能包含过时的数据,这些数据不反映最近在另一个区域中完成的写入的结果。

如果应用程序大约同时更新不同区域中的同一项目,则会出现冲突。为了帮助确保最终的一致性,DynamoDB 全局表使用最后一个写入方为准协调并发更新,其DynamoDB 尽最大努力确定最后一个写入方。这是在项目级别执行的。使用此冲突解决机制,所有副本都将同意最新的更新,并收敛到它们都具有相同数据的状态。

可用性与持久性

如果单个 Amazon 区域变得孤立或降级,您的应用程序可以重定向到不同的区域,并对其他副本表执行读取和写入操作。您可以应用自定义业务逻辑来确定何时将请求重定向到其他区域。

如果某个区域被隔离或降级,DynamoDB 会跟踪已执行但尚未传播到所有副本表的任何写入操作。当区域恢复联机时,DynamoDB 将继续将任何挂起的写入从该区域传播到其他区域中的副本表。它还会继续将写入从其他副本表传播到现在重新联机的区域。