从关系数据库迁移到 DynamoDB

将关系数据库迁移到 DynamoDB 需要仔细规划，以确保取得成功。本指南将协助您了解此过程的工作原理，您有哪些可用的工具，以及如何评估潜在的迁移策略，并选择符合您要求的迁移策略。

迁移到 DynamoDB 的理由

迁移到 Amazon DynamoDB 可为企业和组织带来一系列引人注目的好处。以下是让 DynamoDB 成为数据库迁移极具吸引力的选择的一些关键优势：

• 可扩展性：DynamoDB 旨在处理海量工作负载并实现无缝扩展，以适应不断增长的数据量和流量。借助 DynamoDB，您可以根据需求轻松地纵向或横向扩展数据库，从而确保您的应用程序能够在不影响性能的情况下，应对突然的流量激增。

• 出色的性能：DynamoDB 提供低延迟的数据访问，使应用程序能够以超乎寻常的速度检索和处理数据。其分布式架构可确保读取和写入操作分布在多个节点上，即使在请求速率很高的情况下，也能提供稳定的个位数毫秒响应时间。

• 完全托管：DynamoDB 是由 AWS 提供的一项完全托管的服务。这意味着 AWS 可以处理数据库管理的操作方面，包括预置、配置、修补、备份和扩展。这使您可以将更多的精力放在开发应用程序方面，同时减少您的数据库管理任务。

• 无服务器架构：DynamoDB 支持名为 DynamoDB 按需的无服务器模式，在这种模式下，您只需为应用程序的实际读取和写入请求付费，无需预先支付容量费用。这种按请求付费的模式极具成本效益且最大限度减少运营开销，因为您只需为消耗的资源付费，无需预置和监控容量。

• NoSQL 灵活性：与传统的关系数据库不同，DynamoDB 采用 NoSQL 数据模型，为架构设计提供了灵活性。借助 DynamoDB，您可以存储结构化、半结构化和非结构化数据，使其非常适合处理各种不断变化的数据类型。这种灵活性可以缩短开发周期，更容易适应不断变化的业务需求。

• 高可用性和耐久性：DynamoDB 在一个区域内的多个可用区之间复制数据，从而确保高可用性和数据耐久性。它可以自动处理复制、失效转移和恢复，从而最大限度地降低数据丢失或服务中断的风险。DynamoDB 提供的可用性服务水平协议（SLA）高达 99.999%。

• 安全性与合规性：DynamoDB 与 AWS Identity and Access Management 集成，可实现精细的访问控制。它可提供静态和传输中加密，确保数据安全。此外，DynamoDB 还遵守各种合规标准，包括 HIPAA、PCI DSS 和 GDPR，让您能够满足监管要求。

• 与 AWS 生态系统集成：作为 AWS 生态系统的一部分，DynamoDB 与其它 AWS 服务（例如 AWS Lambda、AWS CloudFormation 和 AWS AppSync）无缝集成。这种集成使您能够构建无服务器架构，利用基础设施即代码，并创建实时数据驱动型应用程序。

将关系数据库迁移到 DynamoDB 时的注意事项

关系数据库系统和 NoSQL 数据库各有优劣：这些区别使得这两个系统的数据库设计不同：

任务类型	关系数据库	NoSQL 数据库
查询数据库	在关系数据库中，可以灵活查询数据，但查询成本相对较高，不能很好地扩展适应高流量情况（参见在 DynamoDB 中为关系数据建模的初始步骤）。关系数据库应用程序可以在存储过程、SQL 子查询、批量更新查询和聚合查询中实现业务逻辑。	在 NoSQL 数据库（如 DynamoDB）中，高效查询数据的方式有限，此外查询成本高且速度慢。向 DynamoDB 执行写入是单例的。必须将以前在存储过程中运行的应用程序业务逻辑重构为，通过运行于 Amazon EC2 或 AWS Lambda 等主机的自定义代码形式，在 DynamoDB 之外运行。
设计数据库	针对灵活性设计，不必担心实现细节或性能。查询优化通常不会影响架构设计，但标准化很重要。	对架构进行专门设计，以尽可能地加快最常见和最重要的查询的速度并尽可能降低其成本。根据业务使用案例的具体要求定制数据结构。

为 NoSQL 数据库设计需要不同于设计关系数据库管理系统（RDBMS）的思维方式。对于 RDBMS，可以创建规范化数据模型，不考虑访问模式。以后出现新问题和查询要求后进行扩展。可以将每种类型的数据整理到各自的表中。

借助 NoSQL 设计，当您了解 DynamoDB 需要回答的问题时，就可以为 DynamoDB 设计架构。事先了解业务问题和应用程序读写模式十分重要。还应在 DynamoDB 应用程序中保留尽可能少的表。使用较少的表可以提高事物的可扩展性，减少权限管理需求，并降低 DynamoDB 应用程序的开销。此外还可以帮助降低总体备份成本。

DynamoDB 的关系数据建模和构建前端应用程序新版本的任务是一个单独的主题。本指南假设您有专为使用 DynamoDB 而构建的新版应用程序，但您仍需要确定在割接期间如何出色地迁移和同步历史数据。

大小注意事项

存储在 DynamoDB 表中的每个项目（行）的最大限制为 400 KB。有关更多信息，请参阅 Amazon DynamoDB 中的服务、账户和表限额。项目大小由项目中所有属性名称和属性值的总大小决定。有关更多信息，请参阅 DynamoDB 项目大小和格式。

如果应用程序需要存储的项目数据超出 DynamoDB 大小限制允许的范围，可以将项目拆分为项目集、压缩项目数据，或者将项目作为对象存储在 Amazon Simple Storage Service（Amazon S3）中，同时将 Amazon S3 对象标识符存储在 DynamoDB 项目中。请参阅 在 DynamoDB 中存储大型项目和属性的最佳实践。更新项目的费用取决于项目的整个大小。对于需要频繁更新现有项目的工作负载，相比于较大的项目，拥有 1 KB 或 2 KB 的小项目，更新成本更低。有关项目集的更多信息，请参见 项目集合 - 如何在 DynamoDB 中对一对多关系建模。

在选择分区和排序键属性、其它表设置、项目大小和结构以及是否创建二级索引时，请务必查看 DynamoDB 建模文档以及关于优化 DynamoDB 表的成本的指南。请务必测试您的迁移计划，确保您的 DynamoDB 解决方案具有成本效益，并且符合 DynamoDB 的特征和限制。

了解迁移到 DynamoDB 的工作原理

在查看可供我们使用的迁移工具之前，请考虑 DynamoDB 是如何处理写入操作的。

默认且最常见的写入操作是单个 PutItem API 操作。您可以循环执行 PutItem 操作来处理数据集。DynamoDB 支持几乎无限的并发连接，因此，假设您可以配置和运行大规模多线程加载例程，例如 MapReduce 或 Spark，写入速度仅受目标表容量（通常也是无限的）的限制。

在 DynamoDB 中加载数据时，务必了解加载程序的写入速度。如果您加载的项目（行）大小为 1 KB 或更少，则此速度就是每秒的项目数。然后，可以为目标表预置足够的 WCU（写入容量单位）来应付此速率。如果您的加载程序在任何一秒钟内超过了预置的容量，则额外的请求可能会被节流或完全被拒绝。您可以在 DynamoDB 控制台监控选项卡的 CloudWatch 图表中检查节流情况。

可以执行的第二个操作是使用名为 BatchWriteItem 的相关 API。BatchWriteItem 允许您将最多 25 个写入请求合并到一个 API 调用中。这些请求由服务接收，并作为对表的单独 PutItem 请求进行处理。目前，如果您选择 BatchWriteItem，则当使用 PutItem 进行单例调用时，将无法获得 AWS SDK 中所含的自动重试的优势。因此，如果有任何错误（例如节流异常），则必须在对 BatchWriteItem 的响应调用中查找所有失败写入的列表。有关在 CloudWatch 节流图表中检测到节流警告时如何处理节流警告的更多信息，请参阅DynamoDB 节流问题。

借助从 S3 导入 DynamoDB 特征，可以进行第三种类型的数据导入。此特征允许您在 Amazon S3 中暂存大型数据集，并让 DynamoDB 自动将数据导入到新表中。导入不是即时的，需要的时间与数据集大小成正比。但是，导入很方便，因为它不需要 ETL 平台或自定义 DynamoDB 代码。DynamoDB 将数据加载到通过导入创建的新表中。目前，它不支持您将数据加载到现有表中。DynamoDB 按原样导入数据，不进行任何转换。与 PutItem 相似，它需要一个上游进程，并将数据以您选择的格式写入 Amazon S3 存储桶。

有助于迁移到 DynamoDB 的工具

您可以使用几种常用的迁移和 ETL 工具将数据迁移到 DynamoDB 中。

Amazon 提供了许多可在迁移中使用的数据工具，包括 AWS Database Migration Service（DMS）、AWS Glue、Amazon EMR 和 Amazon Managed Streaming for Apache Kafka。所有这些工具都可用于执行停机迁移，并且可以利用关系数据库更改数据捕获（CDC）功能来支持在线迁移。在选择工具时，考虑贵组织针对每种工具所具备的技能组合和经验，以及每种工具的功能、性能和成本，将会很有帮助。

许多客户选择编写自己的迁移脚本和任务，以便为迁移过程构建自定义数据转换。如果您计划使用存在大量写入流量的高容量 DynamoDB 表或定期执行大量批量加载任务，则可能需要自行编写迁移工具，以便更熟悉 DynamoDB 在高写入流量下的行为。在项目早期执行实践迁移时，可能会遇到诸如节流处理和高效表预置之类的情况。

选择合适的策略迁移到 DynamoDB

大型关系数据库应用程序可能跨一百个或更多表，并支持多种不同的应用程序功能。在进行大规模迁移时，可以考虑将应用程序拆分为较小的组件或微服务，然后一次迁移一小组表。然后，您可以分批将其它组件迁移到 DynamoDB。

在选择迁移策略时，不同的因素可能会引导您选择这样或那样的解决方案。我们会根据相关的要求和可用资源，在决策树中提供这些选项，以简化可用选项。这里简要提到了这些概念（但稍后将在本指南中更深入地介绍）：

• 离线迁移：如果应用程序在迁移过程中能够容忍一些停机时间，它将简化迁移过程。

• 混合迁移：这种方法在迁移期间支持部分操作正常运行，例如支持读取但不支持写入，或者支持读取和插入但不支持更新和删除。

• 在线迁移：要求在迁移期间零停机的应用程序不太容易迁移，可能需要进行大量的规划和自定义开发工作。一个关键决策是估算和权衡构建自定义迁移流程的成本与割接期间的停机时段给业务带来的成本。

如果	并且	那么
您可以在维护时段内将应用程序停机一段时间来执行数据迁移。这就是离线迁移。		使用 AWS DMS，通过完全加载任务执行离线迁移。如果需要，可以使用 SQL VIEW 预先设置源数据的形状。
可以在迁移期间以只读模式运行应用程序。这就是混合迁移。		禁用应用程序或源数据库内的写入操作。使用 AWS DMS，通过完全加载任务执行离线迁移。
在迁移过程中，您可以通过读取和插入新记录来运行应用程序，但不能执行更新或删除操作。这就是混合迁移。	您具备应用程序开发技能，可以更新现有关系应用程序来为所有新记录执行双重写入（包括向 DynamoDB）	使用 AWS DMS，通过完全加载任务执行离线迁移。同时，部署允许读取和执行双重写入的现有应用程序版本。
您需要尽可能以较短的停机时间来完成迁移。这就是在线迁移。	您可以将源表 1:1 迁移到 DynamoDB 中，无需进行重大架构更改。	使用 AWS DMS 执行在线数据迁移。先执行批量加载任务，然后执行 CDC 同步任务。
您需要尽可能以较短的停机时间来完成迁移。这就是在线迁移。	您可以遵循堆叠架构或单表原则，将源表合并成更少的 DynamoDB 表。 您具备后端数据库开发技能且 SQL 主机上有备用容量。	在 SQL 数据库中创建支持 NoSQL 的表。使用 JOIN、UNION、VIEW、触发器、存储过程对其进行填充和同步。
您需要尽可能以较短的停机时间来完成迁移。这就是在线迁移。	您可以遵循单表原则，将源表合并成更少的 DynamoDB 表。例如： 您不具备后端数据库开发技能且 SQL 主机上没有备用容量。	可以考虑混合或离线迁移方法。
您需要尽可能以较短的停机时间来完成迁移。这就是在线迁移。	您可以跳过迁移历史交易数据，也可以将其存档在 Amazon S3 中不进行迁移。您只需要迁移几个小型静态表。	编写脚本或使用任何 ETL 工具迁移表。如果需要，可以使用 SQL VIEW 预先设置源数据的形状。

离线迁移到 DynamoDB

离线迁移适用于能够容忍停机一段时间来执行迁移的情况。关系数据库通常每月至少需要一些停机时间进行维护和修补，或者可能需要更长的停机时间来进行硬件升级或主要版本升级。

在迁移过程中，Amazon S3 可用作暂存区。以 CSV（逗号分隔值）或 DynamoDB JSON 格式存储的数据可以使用从 S3 导入到 DynamoDB 特征，自动导入到新的 DynamoDB 表中。

您可能想要合并表以利用独特的 NoSQL 访问规律（例如，将四个旧表转换为单个 DynamoDB 表）。与执行多表联接的 SQL 数据库相比，单个键值文档请求或对预分组项目集的查询返回结果的延迟通常更低。但是，这会让迁移任务变得更加困难。SQL 视图可以在源数据库中执行工作来准备一个数据集，将全部四个表整合到一个集合中。

此视图可能会 JOIN 表，将其转换为非规范化形式，或者可能会使用 SQL UNION 使实体保持规范化并堆叠表。本视频介绍了关于重塑关系数据的关键决策。对于离线迁移，使用视图合并表是将数据调整成 DynamoDB 单表架构的好方法。

规划

使用 Amazon S3 执行离线迁移

工具

• 一个 ETL 任务，提取和转换 SQL 数据并将其存储在 S3 存储桶中，例如：

  • AWS Database Migration Service，该服务可以批量加载历史数据，还可以处理更改数据捕获（CDC）记录来同步源表和目标表。

  • AWS Glue

  • Amazon EMR

  • 您自己的自定义代码

• 从 S3 导入 DynamoDB 特征

离线迁移步骤：

1. 构建一个可以查询 SQL 数据库的 ETL 任务，将表数据转换为 DynamoDB JSON 或 CSV 格式，然后将其保存到 S3 存储桶中。

   

2. 调用从 S3 导入 DynamoDB 特征来创建新表并自动从您的 S3 存储桶加载数据。

完全脱机迁移既简单又直接，但它可能不受应用程序所有者和用户的欢迎。如果应用程序能够在迁移期间提供一定级别的服务，而不是根本不提供服务，那么将会对用户有好处。

您可以添加功能来在离线迁移期间禁用写入操作，同时允许读取照常进行。在迁移关系数据期间，应用程序用户仍然可以安全地浏览和查询现有数据。如果这是您希望了解的内容，请继续深入阅读来了解混合迁移。

混合迁移到 DynamoDB

虽然所有数据库应用程序都执行读取和写入操作，但在规划混合或在线迁移时，应考虑所执行的写入操作的类型。数据库写入可分类为为三个存储桶：插入、更新和删除。某些应用程序可能不要求立即处理删除操作。例如，这些应用程序可以将删除操作推迟到月底的批量清理过程。这些类型的应用程序可以更轻松地迁移，同时允许部分操作正常运行。

规划

结合应用程序双重写入执行在线/离线混合迁移

工具

• 一个 ETL 任务，提取和转换 SQL 数据并将其存储在 S3 存储桶中，例如：

  • AWS DMS

  • AWS Glue

  • Amazon EMR

  • 您自己的自定义代码

混合迁移步骤：

1. 创建目标 DynamoDB 表。此表将同时接收历史批量数据和新的实时数据

2. 创建禁用删除和更新的旧版应用程序，同时以双向写入 SQL 数据库和 DynamoDB 的方式执行所有插入

3. 开始 ETL 任务或 AWS DMS 任务来回填现有数据，同时部署新的应用程序版本

4. 回填任务完成后，DynamoDB 将拥有所有现有记录和新记录，并准备好进行应用程序割接

注意

回填任务直接从 SQL 写入到 DynamoDB。我们无法像在离线迁移示例中那样使用 S3 导入功能，因为该功能会创建一个新表，而该表在 DynamoDB 加载数据之前不会生效。

通过 1:1 迁移每个表来在线迁移到 DynamoDB

许多关系数据库都有一项名为更改数据捕获（CDC）的特征，该特征允许用户请求表在特定时间点之前或之后进行的更改的列表。CDC 使用内部日志来启用此功能，并且不要求表中具有任何时间戳列即可正常运行。

将 SQL 表架构迁移到 NoSQL 数据库时，您可能需要将数据合并并重塑为更少的表。这样做可以让您在一个地方收集数据，而不必通过多步读取操作手动联接相关数据。但是，单表数据形状设置并非总是必需的，有时您会将表一比一迁移到 DynamoDB 中。这些一对一的表迁移不那么复杂，因为您可以利用源数据库 CDC 特征，使用支持此类迁移的常用 ETL 工具。每行数据仍可转换为新格式，但每个表的范围保持不变。

考虑将 SQL 表一对一迁移到 DynamoDB，但需要注意的是，DynamoDB 不支持服务器端联接。您需要向应用程序添加逻辑，来合并来自多个表的数据。

规划

使用 AWS DMS 将每个表在线迁移到 DynamoDB

工具

• AWS DMS（DMS）

在线迁移步骤：

1. 确定源架构中将要迁移的表

2. 在 DynamoDB 中使用与源中相同的键结构创建相同数量的表

3. 在 AWS DMS 中创建复制服务器，然后配置源端点和目标端点

4. 定义所需的任何按行转换（例如串联列或将日期转换为 ISO-8601 字符串格式）

5. 针对完全加载和更改数据捕获为每个表创建迁移任务

6. 监控这些任务，直到开始持续复制

7. 此时，您可以执行任何验证审计，然后将用户切换到向 DynamoDB 执行读取和写入的应用程序

使用自定义暂存表在线迁移到 DynamoDB

与上述离线迁移场景一样，您可能选择合并表来利用独特的 NoSQL 访问规律（例如，将四个旧表转换为一个 DynamoDB 表）。SQL VIEW 可以在源数据库中执行工作来准备一个数据集，将全部四个表整合到一个集合中。

但是，对于包含实时、不断变化的数据的在线迁移，您无法利用 CDC 功能，因为 VIEW 不支持这些功能。如果您的表包含上次更新的时间戳列，并且这些列已合并到 VIEW 中，则可以构建一个自定义 ETL 任务，使用这些列实现同步批量加载。

应对这一挑战的一种新方法是，使用视图、存储过程和触发器等标准 SQL 功能，来创建采用最终所需的 DynamoDB NoSQL 格式的新 SQL 表。

如果数据库服务器有备用容量，则可以在迁移开始之前创建这一单个暂存表。这可以通过编写一个存储过程来实现，该存储过程将从现有表中读取数据，根据需要转换数据，然后写入新的暂存表。可以添加一组触发器，来将表中的更改实时复制到暂存表中。如果根据公司政策不允许使用触发器，则更改存储过程一样可以达到相同的效果。您可以向任何写入数据的过程添加几行代码，以便额外将相同的更改写入暂存表。

有了这个与传统应用程序表完全同步的暂存表，可以为实时迁移提供一个很好的起点。使用数据库 CDC 完成实时迁移的工具（例如 AWS DMS）现在可以用于此表。这种方法的一个优点是，它使用了关系数据库引擎中提供的众所周知的 SQL 技能和特征。

规划

使用 AWS DMS 在线迁移 SQL 暂存表

工具

• 自定义 SQL 存储过程或触发器

• AWS DMS

在线迁移步骤：

1. 在源关系数据库引擎中，确保有一些额外的磁盘空间和处理容量。

2. 在 SQL 数据库中创建新的暂存表，启用时间戳或 CDC 特征

3. 编写并运行存储过程，来将现有关系表数据复制到暂存表中

4. 部署触发器或修改现有过程来双向写入新的暂存表，同时对现有表执行正常写入

5. 运行 AWS DMS，将此源表迁移并同步到目标 DynamoDB 表

本指南介绍了将关系数据库数据迁移到 DynamoDB 的几个注意事项和方法，重点是最大限度地减少停机时间和使用常用的数据库工具和技巧。有关更多信息，请参阅下列内容：

• AWS DMS 用户指南

• AWS Glue 用户指南

• 从 RDBMS 迁移至 DynamoDB 的最佳实践