从 SQL Server 迁移到 Amazon DynamoDB：使用中转表进行数据转型

关键要点

成本效益和操作简化：迁移到 Amazon DynamoDB 可以降低运营成本、简化操作并提高性能。数据迁移步骤：通过创建中转表来映射 SQL Server 与 DynamoDB 的数据，使用 AWS 数据库迁移服务DMS进行数据迁移。操作模式设计：着重于写入操作的设计，以更好地适应 DynamoDB 的特性。监控与持续复制：设置 AWS DMS 监控任务以实现连续数据复制，确保数据的一致性和及时更新。

随着微服务架构的发展，越来越多的组织选择使用专用数据库。企业在选择合适的云服务和解决方案，以及迁移计划时，常常需要指导。在异构数据库迁移过程中，遇到的挑战之一是将自管理的 SQL Server 的传统表和列属性重构到 Amazon DynamoDB 的访问模式。

迁移到 DynamoDB 主要的动机是降低成本、简化操作并在规模上优化性能。DynamoDB 的无服务器架构可以通过按需付费、零扩展及无需前期成本等能力来节省资源，从而支持企业的增长与客户价值提升。在操作层面，摆脱了资源扩展、维护窗口和重大版本升级等问题，可以节省大量的运营时间，从而消除不必要的重复劳动。

每个应用程序都有特定的需求模式以满足业务用例。不论是 NoSQL、传统 SQL (RDBMS) 还是两者结合，应用程序在与数据库服务器交互时所承担的工作负载主要分为读取或写入。在本文中，我们将讨论更强调写入的访问模式，介绍如何将传统 SQL Server 表关系型成功迁移至 DynamoDB非关系型，适用于微服务应用，使用 AWS DMS 进行支持。

任何想要将小型或大型单体表迁移到 DynamoDB 的微服务应用都可以采用此方案。

解决方案概述

我们的解决方案包括在 Amazon Elastic Compute CloudAmazon EC2上创建的自管理 SQL Server 上使用的参照表。该参照表通过分析数据访问模式和在 DynamoDB 中执行属性映射而构建。确定设计模式后，我们为 DynamoDB 表提供合适的主键和排序键以映射参照表。然后使用 AWS DMS 从映射到 SQL Server 中此参照表的源端点迁移数据，并设置连续复制。

以下图表展示了系统架构。

解决方案工作流程包含以下步骤：

连接到您的自管理 SQL Server 实例，查看将迁移到 DynamoDB 表的关系源表。因为 SQL 源表符合传统 SQL 标准，且并不匹配 DynamoDB 属性，我们使用自定义脚本将源表转换为符合 DynamoDB 属性要求的中转表。在 SQL Server 中创建新的中转表，并使用自定义脚本来填充数据：一次性加载全加载：如果您只想从源表一次性传输数据，可以运行临时脚本来填充中转表。变更数据捕获CDC：当跟踪源表的实时更改时，在源表上生成 SQL 原生触发器INSERT以将更改插入中转表。本文只讨论源表上的 INSERT 操作。在其他用例中，如果需要处理 INSERT、UPDATE 或 DELETE 条件，应相应创建触发器。将中转表映射为 SQL Server 的源。在 DynamoDB 中创建具有对应于 SQL 中转表属性的分区键和排序键的表。使用 AWS DMS 将数据从源 SQL Server 迁移到目标 DynamoDB。为迁移数据，将 SQL Server 中转表作为源，DynamoDB 表作为目标。借助 SQL 原生触发器，我们在此场景中既使用全加载也使用 CDC，以获得来自 SQL Server 源中转表的实时数据。

我们使用 AWS Secrets Manager 存储 SQL 凭证在 AWS DMS 中，并利用 Amazon CloudWatch 监控 AWS DMS 任务。

实施解决方案的步骤如下：

配置 AWS 身份和访问管理 (IAM) 策略和角色。配置 DynamoDB 访问模式及全球二级索引 (GSI)。创建 DynamoDB 表。配置 SQL Server 表映射。使用 AWS DMS 迁移数据。验证在 DynamoDB 中迁移的数据。监控 AWS DMS 迁移任务。

前提条件

在跟随本文之前，您需要具备以下前提条件：

自管理的 SQL Server on Amazon EC2 或本地 RDBMS 服务器。有效的 IAM 角色 权限以便使用 DynamoDB。已设置 AWS DMS 和 复制实例。详细信息请参见 AWS 数据库迁移服务入门。AWS 命令行接口AWS CLI。要开始使用，请参考 配置 AWS CLI。

由于此文探讨了从 SQL Server (RDBMS) 到 DynamoDB (NoSQL) 的访问模式和属性映射，因此需要对 DynamoDB 核心概念 和设计模式有基础的了解。此外，还推荐了解 AWS DMS 相关的信息，例如：SQL Server 来源 和 DynamoDB 目标。

配置 IAM 策略和角色

完成以下步骤以配置 DynamoDB 的 IAM 策略和角色：

在 IAM 控制台的导航窗格中选择 策略。选择 创建策略。选择 JSON 并使用以下政策模板，替换 DynamoDB ARN 为正确的区域、账户号码和 DynamoDB 表名：

json { Version 20121017 Statement [ { Effect Allow Action [ dynamodbPutItem dynamodbCreateTable dynamodbDescribeTable dynamodbDeleteTable dynamodbDeleteItem dynamodbUpdateItem ] Resource [ arnawsdynamodbltregiongtltaccountnumbergttable/ltDDB Table namegt arnawsdynamodbltregiongtltaccountnumbergttable/awsdmsapplyexceptions arnawsdynamodbltregiongtltaccountnumbergttable/awsdmsfullloadexceptions ] } { Effect Allow Action dynamodbListTables Resource arnawsdynamodbltregiongtltaccountnumbergttable/ltDDB Table namegt } ] }

在导航窗格中选择 角色。选择 创建角色。选择 AWS DMS，然后选择 下一步：权限。选择您创建的策略。指定一个角色名称，然后选择 创建角色。

配置 DynamoDB 访问模式和 GSI

DynamoDB 表通常根据主键的唯一性创建，以满足业务或应用程序的访问模式。分区键和排序键组合形成一个主键。

访问模式

在当前使用场景中，我们使用 SQL 表tblStatusHistorylog作为源，将其迁移到 DynamoDB。由于我们强调写入INSERT工作负载，因此分区键应基于写入访问模式而不是读取模式。以下截图展示了源表列，使用 RowID 作为主键。

免费海外加速器推荐

我们必须建立能够满足微服务应用需求的模式，因为 RowID 不能在 DynamoDB 上提供唯一模式。分区键由列的组合UsrID accountid 和 siloid构成，以提供更有意义的访问模式，然而由于表tblStatusHistorylog可能有多个相同用户的 accountid 和 siloid 值，因此组合可能并不唯一。

为了使 DynamoDB 的主键唯一，最好将分区键与排序键结合使用。由于 RowID 在源表中已唯一，我们将其用作排序键。以下表格展示了如何扩展访问模式，以保留表的唯一性。

输入参数返回属性频率操作表UsrID AccountID SiloID所有属性更多插入/查询基础表UsrID AccountID SiloID StatusCode所有属性更多插入/查询基础表UsrID AccountID SiloID ReasonCode所有属性更多插入/查询基础表UsrID AccountID SiloID StatusDate所有属性更多插入/查询基础表UsrID SiloID StatusCode所有属性较少查询GSIUsrID SiloID ReasonCode所有属性较少查询GSIUsrID SiloID StatusDate所有属性较少查询GSI

以上表格总结了以下信息：

输入参数：应用程序如何向 DynamoDB 提供输入参数以进行查询的理想场景。返回属性：DynamoDB 表是否提供所有属性作为结果或特定列根据应用程序查询。频率：应用程序请求参数的出现频率。DynamoDB 操作：应用程序请求的最常见用例。表：表选项基础表或 GSI。

以下截图展示了组成主键的分区键和排序键的可视化表示。此外，其他属性 部分列出了所有来自原始源的列，这些列将包含在 DynamoDB 的结果输出中。

全球二级索引

为增强读取工作负载查询性能，基础表中添加了 GSIPK 属性，因为 GSI 索引可以跨所有分区的基础表中的所有数据。GSIPK 是由列UsrId 和 siloId组合而成，不包括 accountId。GSI 的另一个好处是您可以选择不在结果中包含所有预期属性。以下设计模型展示了 GSI 分区键、排序键及属性的示例。

创建 DynamoDB 表

使用以下代码通过 AWS CLI 创建 DynamoDB 表。我们将表命名为 DDBStatusHistoryLogs，并将 PK 和 SK 定义为分区键和排序键的属性名称。

bashAmazon DynamoDB createtable tablename DDBStatusHistoryLogs attributedefinitions AttributeName=PKAttributeType=S AttributeName=SKAttributeType=S keyschema AttributeName=PKKeyType=HASH AttributeName=SKKeyType=RANGE provisionedthroughput ReadCapacityUnits=25WriteCapacityUnits=25 tableclass STANDARD

运行命令后，等待表创建完成。您可以通过 AWS CLI 验证 DynamoDB 表是否已创建。

配置 SQL Server 表映射

在本节中，我们将走过配置 SQL Server 表映射的步骤。我们创建源和中转 SQL 表，为测试填充源表，创建一次性加载中转表的脚本，以及创建 SQL 表的 INSERT 触发器。

创建源和中转 SQL 表

为了我们的参考示例，我们有两个 SQL Server 表来执行迁移。以下代码创建一个新的数据库 dmsload。我们创建源表 tblStatusHistorylog，作为 AWS DMS 加载的基础数据，并创建中转表 DDBStatusHistoryDMSLoad，作为 AWS DMS 映射 DynamoDB 中定义的关键属性的参照表。

sqlcreate database dmsloadgo

USE dmsloadGOCREATE TABLE [dbo]tblStatusHistorylog ON [PRIMARY]GO

CREATE TABLE [dbo]DDBStatusHistoryDMSLoad ON [PRIMARY]GO

因为中转表作为 DynamoDB 的数据源，正常属性从基础表复制到中转表。PK、SK 和 GSIPK 是在 DynamoDB 上形成大量访问模式的关键列。以下脚本演示了中转表的数据加载。

为测试填充源表

使用以下代码来填充源表 (tblStatusHistorylog) 的测试数据：

sqluse dmsloadgoInsert into dbo[tblStatusHistorylog](UsrIDaccountidsiloidstatuscodestatusdescstatusdatereasoncodereasondescreasondateupdatedateusername)values (1011233214562001claim initiatedgetdate()1RC200claim from the stockbackloggetdate()1getdate()KJ)(1011233214563001claim processedgetdate()1RC300claim initiated