DynamoDB 全局表设计的最佳实践 - Amazon DynamoDB

DynamoDB 全局表设计的最佳实践

全局表基于遍布全球的 Amazon DynamoDB 而构建,可提供完全托管式、多区域和多活动数据库,为大规模扩展的全局应用程序提供快速本地读写性能。借助全局表,数据可在您选择的 AWS 区域间自动复制。由于全局表使用现有的 DynamoDB API,因此不需要对应用程序进行任何更改。使用全局表无需支付任何预付费用,也没有任何承诺,您只需为实际使用的资源付费。

DynamoDB 全局表设计的规范性指南

高效率使用全局表需要仔细考虑各种因素,例如您的首选写入模式、路由模型和撤离过程。您必须针对每个区域对应用程序进行检测,并准备好调整路由或执行撤离,以维护全局运行状况。您获得的回报是拥有一个具有低延迟读写和 99.999% 服务水平协议的全局分布式数据集。

关于 DynamoDB 全局表设计的关键事实

  • 全局表有两个版本:当前版本全局表版本 2019.11.21(当前版)(有时称为“V2”)和 全局表版本 2017.11.29(旧版)(有时称为“V1”)。本指南仅关注当前版本 V2。

  • 在不使用全局表的情况下,DynamoDB 是一项区域性服务。它具有高可用性,对区域的基础设施故障 [包括整个可用区(AZ)的故障] 具有内在的弹性。单区域 DynamoDB 表具有 99.99% 的可用性 https://aws.amazon.com/dynamodb/sla/ 服务水平协议(SLA)。

  • 通过使用全局表,DynamoDB 允许表在两个或更多区域间复制其数据。多区域 DynamoDB 表具有 99.999% 的可用性 SLA。通过适当的规划,全局表可以帮助创建一个具有弹性并可抵御区域故障的架构。

  • 全局表采用主动-主动复制模型。从 DynamoDB 的角度来看,每个区域中的表在接受读取和写入请求方面具有同等地位。收到写入请求后,本地副本表将在后台将写入内容复制到其他参与区域。

  • 项目是单独复制的。在单个事务中更新的项目不能一起复制。

  • 源区域中的每个表分区都会与每个其他分区并行复制其写入内容。远程区域内的写入顺序可能与源区域内发生的写入顺序不匹配。有关表分区的更多信息,请参阅博客文章扩缩 DynamoDB:分区、热键和热拆分如何影响性能

  • 新写入的项目通常会在一秒内传播到所有副本表。附近区域的传播速度往往更快。

  • Amazon CloudWatch 为每个区域对提供一个 ReplicationLatency 指标。它的计算方法是查看到达的项目,将它们的到达时间与其初始写入时间进行比较并计算出平均值。时间存储在源区域的 CloudWatch 中。查看平均时间和最大时间有助于确定平均和最坏情况下的复制滞后。对于这种延迟,没有 SLA。

  • 如果大约在同一时间(在此 ReplicationLatency 时段内)在两个不同的区域更新同一项目,并且第二次写入发生在复制第一次写入之前,则可能会出现写入冲突。全局表根据写入的时间戳,使用以最后写入者为准机制来解决此类冲突。第一次写入“输给”第二次写入。这些冲突不会记录在 CloudWatch 或 AWS CloudTrail 中。

  • 每个项目都有最后一次写入时间戳,保留为一个私有系统属性。以最后写入者为准方法是通过使用条件写入来实现的,条件写入要求传入项目的时间戳大于现有项目的时间戳。

  • 全局表会将所有项目复制到所有参与区域。如果您想拥有不同的复制范围,可以创建不同的表,并为每个表分配不同的参与区域。

  • 即使副本区域处于离线状态或 ReplicationLatency 增长,也会接受对本地区域的写入。本地表继续尝试将项目复制到远程表,直到每个项目成功为止。

  • 在极少数情况下,如果某个区域完全离线,则当该区域稍后恢复在线时,将重试所有待处理的出站和入站复制。无需特殊操作即可使表恢复同步。以最后写入者为准机制可确保数据最终变得一致。

  • 您可以随时向 DynamoDB 表中添加新区域。DynamoDB 将处理初始同步和持续复制。如果删除某个区域,即使它是原始区域,也只会删除该区域的表。

  • DynamoDB 没有全局端点。所有请求都向区域端点发出,然后该端点访问该区域本地的全局表实例。

  • 对 DynamoDB 的调用不应跨区域进行。最佳实践是让一个区域中的计算层仅直接访问该区域的本地 DynamoDB 端点。如果在某个区域内检测到问题,无论这些问题出在 DynamoDB 层还是在周围的堆栈中,都应将终端用户流量路由到托管在不同区域中的不同计算层。得益于全局表复制,不同的区域将已经具有相同数据的本地副本供其在本地使用。在某些情况下,一个区域中的计算层可能会将请求传递到另一个区域的计算层进行处理,但这不应直接访问远程 DynamoDB 端点。有关该特定使用案例的更多信息,请参阅计算层请求路由

使用案例

全局表提供以下常见好处:

  • 读取延迟较低。您可以将数据副本放在离终端用户更近的位置,以减少读取过程中的网络延迟。缓存与 ReplicationLatency 值一样保持最新。

  • 写入延迟较低。您可以写入附近的区域以减少网络延迟和完成写入所需的时间。必须谨慎路由写入流量,以确保没有冲突。全局表的请求路由中详述了路由技术。

  • 改善了弹性和灾难恢复。如果某个区域的性能下降或出现全面中断,您可以撤离该区域(移离发送到该区域的部分或全部请求),恢复点目标(RPO)和恢复时间目标(RTO)以秒为单位衡量。使用全局表还可以将 DynamoDB SLA 从 99.99% 提高到 99.999%。

  • 无缝的区域迁移。您可以添加新区域,然后删除旧区域,以便将部署从一个区域迁移到另一个区域,所有操作都无需在数据层停机。例如,您可以将 DynamoDB 全局表用于订单管理系统,实现大规模可靠的低延迟处理,同时保持抵御可用区和区域故障的弹性。