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

关键要点

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

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

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

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

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

解决方案概述

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

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

删除)

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

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

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

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

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

前提条件

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

• 自管理的 或本地 RDBMS 服务器。
• 有效的 权限以便使用 DynamoDB。
• 已设置 AWS DMS 和 。详细信息请参见 。
• （AWS CLI）。要开始使用，请参考 。

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

配置 IAM 策略和角色

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

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

`json { "Version": "2012-10-17", "Statement": 创建 DynamoDB 表。我们将表命名为 DDB_StatusHistory_Logs，并将 PK 和 SK定义为分区键和排序键的属性名称。

bash Amazon DynamoDB create-table \ --table-name DDB_StatusHistory_Logs \ --attribute-definitions \ AttributeName=PK,AttributeType=S \ AttributeName=SK,AttributeType=S \ --key-schema \ AttributeName=PK,KeyType=HASH \ AttributeName=SK,KeyType=RANGE \ --provisioned-throughput \ ReadCapacityUnits=25,WriteCapacityUnits=25 \ --table-class STANDARD

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

删除)

配置 SQL Server 表映射

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

创建源和中转 SQL 表

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

USE dmsload GO CREATE TABLE  NOT NULL,  
    \[Usr_ID\] \[int\] NOT NULL,    
    \[account_id\] \[varchar\]\(40\) NOT NULL,
    \[silo_id\] \[int\] NOT NULL,
    \[status_code\] \[varchar\]\(12\) NOT NULL,
    \[status_desc\] \[varchar\]\(250\) NOT NULL,
    \[status_date\] \[datetime\] NOT NULL,
    \[reason_code\] \[varchar\]\(12\) NULL,
    \[reason_desc\] \[varchar\]\(250\) NULL,
    \[reason_date\] \[datetime\] NULL,
    \[update_date\] \[datetime\] NOT NULL,
    \[username\] \[varchar\]\(15\) NOT NULL   
 CONSTRAINT \[PK_tbl_StatusHistory_log\] PRIMARY KEY CLUSTERED

\(

    \[RowID\] ASC
\)WITH \(PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY =
OFF\) ON \ NOTNULL,

    \[SK\] \[varchar\]\(50\) NOT NULL,
    \[GSI-PK\] \[varchar\]\(50\) NOT NULL,
    \[SRC\] \[varchar\]\(5\) NOT NULL,
    \[account_id\] \[varchar\]\(40\) NOT NULL,
    \[status_code\] \[varchar\]\(12\) NOT NULL,
    \[status-desc\] \[varchar\]\(250\) NOT NULL,
    \[status-date\] \[datetime\] NOT NULL,
    \[reason-note\] \[varchar\]\(12\) NULL,
    \[reason-desc\] \[varchar\]\(250\) NULL,
    \[reason-date\] \[datetime\] NULL,
    \[update-date\] \[datetime\] NOT NULL,
    \[username\] \[varchar\]\(15\) NOT NULL   
 CONSTRAINT \[PK_DDB_StatusHistory_DMSLoad\] PRIMARY KEY CLUSTERED

\(

    \[PK\] ASC,
    \[SK\] ASC
\)WITH \(PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY =
OFF\) ON \[PRIMARY\]) ON [PRIMARY] GO ```

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

### 为测试填充源表

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

```sql use dmsload go Insert into dbo.[tbl_StatusHistory_log]
(Usr_ID,account_id,silo_id,status_code,status_desc,status_date,reason_code,reason_desc,reason_date,update_date,username)
values (101,'123321456','200',1,'claim initiated',getdate()-1,'RC200','claimfrom the stockbacklog',getdate()-1,getdate(),'KJ')
,(101,'123321456','300',1,'claim processed',getdate()-1,'RC300','claiminitiated