由RDBMS 到Amazon DynamoDB 迁移最佳实践指南 · PDF fileAmazon Web Services – 由RDBMS 到Amazon DynamoDB：迁移最佳实践指南 2014 年4 月 3 RDBMS 是一项成熟且稳定的技术方案。

Amazon Web Services – 由 RDBMS 到 Amazon DynamoDB：迁移最佳实践指南 2014 年 4 月

1

由 RDBMS 到 Amazon DynamoDB：迁移最佳实践指南

利用 NoSQL 的强大功能承载对应工作负载

Nathaniel Slater

2015 年 3 月


2

目录

目录 2

摘要 2

简介 2

Amazon DynamoDB 概述 4

合适的工作负载 6

不适用的工作负载 7

键概念 8

由 RDBMS 迁移至 DynamoDB 13

规划阶段 13

数据分析阶段 15

数据建模阶段 17

测试阶段 21

数据迁移阶段 22

总结 23

附录 23

扩展阅 23

摘要

时至今日，软件架构师与开发人员都需要在数据存储与持久性层面做出一系列选择。其中的具体选项除了

传统关系型数据库管理系统（简称 RDBMS）之外，还包括多种 NoSQL 数据库，例如 Amazon DynamoDB。

特定工作负载能够在 NoSQL 解决方案之上拥有更为出色的规模化扩展及执行效率表现。本份白皮书将着重

探讨将工作负载由 RDBMS 迁移至 DynamoDB 过程当中的各项最佳实践。我们将讨论 DynamoDB 等

NoSQL 数据库与传统 RDBMS 之间的差异，同时提出一套用于指导由 RDBMS 向 DynamoDB 进行分析、

数据建模与数据迁移的执行框架。

简介

数十年以来，RDBMS 一直是数据存储与持久保留的最佳选项。任何一款数据驱动型应用程序，无论是电子

商务网站还是费用报告系统，都几乎必然利用关系型数据库对应用程序所需要的数据进行检索与存储。

RDBMS 之所以广受欢迎，主要源自以下几项理由：


3

RDBMS 是一项成熟且稳定的技术方案。

其查询语言 SQL 功能丰富且相当灵活。

运行 RDBMS 引擎的服务器在 IT 基础设施当中往往属于最为稳定且强大的构成元素。

各类主流编程语言都包含相关支持驱动程序，用于实现同 RDBMS 之间的通信，另外亦有大量工具用于

简化数据库驱动型应用程序的开发流程。

正是由于以上乃至其它众多原因，RDBMS 才能够在多年以来一直成为数据处理的不朽丰碑。对于架构师及

软件开发人员而言，他们根本没有理由放弃这样一套强大的数据存储与保留方案——然而，如今情况发生

了变化。

“互联网规模”Web 应用程序的崛起已经成为客观事实，其中包括电子商务以及社交媒体等等。另外，智

能手机与平板设备极大扩展了联网设备的种类，而大数据的出现亦带来了传统关系型数据库难以应对的新

型工作负载。由于系统设计目标单纯着眼于事务处理，因此各类 RDBMS 必须能够支持所谓 ACID 原则定

义，即原子性、一致性、隔离性与持久性。其中原子性代表着“全有或者全无”，即某项事务完全执行或者

完全不执行。一致性是指事务的执行会引发一种有效状态的转换。一旦事务被提交，则结果数据的状态必

须符合数据库模式对其施加的约束。隔离性要求各并发事务之间彼此独立执行。这一隔离属性保证如果并

发事务以顺序方式执行，则数据的最终状态仍将保持相同。持久性则要求数据状态在事务执行后即得到保

存。这意味着即使出现电力或者系统故障，数据库亦能够恢复至上一已知状态。

这些 ACID原则当然非常重要，但对其加以全部支持则对架构做出了诸多限制，这意味着相关成果在处理当

前数据密集型工作负载时面临着严峻挑战。举例来说，一致性要求数据库模式经过良好定义，而存储在数

据库内的全部数据都应符合该模式。这样的设计适用于临时性查询以及读取密集型工作负载。但对于那些

持续进行写入的工作负载，例如在游戏应用中保存玩家的当前状态，那么这类模式就会给存储及计算资源

带来巨大压力。游戏开发者们需要投入大量精力将这些数据转化为行与表的形式，并将其通过良好定义的

键集合进行彼此关联。


4

一致性则需要对数据中的某些部分进行锁定，直到事务修复操作完成并令变更结果立即可见。对于银行交

易而言，即由某一账户借记并向另一账户贷记的操作，这样的要求非常必要。此类事务亦被称为“强一致

性”。然而在另一方面，社交媒体应用则并不需要全部用户都能够在更新数据馈送后精确地立足同一时间点

查看到最新结果。在后一类情况下，该事务应保持“最终一致性”。对于社交媒体应用而言，以规模化方式

处理数百万并发用户的操作显然更为重要，而保证这些用户在同一时间查看到数据更改则会带来不必要的

资源浪费。对 RDBMS 进行规模扩展以实现这一级别的一致性，同时保持更新内容的实时传递将耗费厂商

难以承受的成本。这种“向上扩展”或者“垂直扩展”思路通常不具备可行的成本水平。因此我们必须找

到更具成本效益的数据库规模化方式，从而立足于商用硬件添加更多服务器实例以支持基础一致性。这种

作法被称为“向外扩展”或者“横向扩展”，其在成本效益方面要远优于垂直扩展。

以 Amazon DynamoDB 为代表的各类 NoSQL 数据库能够解决 RDBMS 面临的各类规模化与性能挑战。所

谓“NoSQL”的说法，代表的正是该数据库并不遵循关系型模型提出的各项原则。这一概念最初由 E.F Codd

于 1970 年发表的《面向大规模共享数据存储的关系型数据模型》1所提出，其也成为现代 RDBMS 的实现

基础。作为结果，NoSQL 数据库在功能与我层面与传统 RDBMS 存在着巨大差异。其中不存在像 SQL 这

样通用的查询语言，而查询灵活性在很大程度上被替代为高 I/O 性能及横向可扩展能力。NoSQL 数据库并

不像 RDBMS 那样强制执行某种模式。其中某些数据库能够存储半结构化数据，例如 JSON。另一些则负

责将相关值以列集合的形式存储。再有，部分 NoSQL 数据库亦直接存储键/值对。

由此带来的结果是，NoSQL 数据库能够实现部分查询功能与 RDBMS 中的 ACID 属性，但具体途径为建立

更为灵活且能够横向扩展的数据模型。这些特性使得 NoSQL 数据库在承载非关系型工作负载时成为

RDBMS 的理想替代方案（例如之前提到的游戏状态存储场景），其能够同时解决性能瓶颈、运营复杂性以

及成本过高等难题。DynamoDB 提供的解决方案能够顺利应对这些问题，同时亦是一套出色的 RDBMS 工

作负载迁移目标平台。

Amazon DynamoDB 概述

Amazon DynamoDB 是一项运行在 AWS 云之上的全面托管 NoSQL 数据库服务。运行高可扩展性、分布式

NoSQL 数据库所带来的种种复杂性因素都将由该服务自身解决，从而保证软件开发人员将精力集中在构建

应用程序而非管理基础设施方面。NoSQL 数据库的设计目标在于实现规模扩展，但其架构本身往往相当复

杂，而且运行大规模 NoSQL 集群会带来高昂的运营成本。相较于雇用经验丰富的专家处理分布式计算中的

艰深概念，开发人员能够只需要掌握 DynamoDB 的直接 API，并使用所熟悉编程语言对应的 SDK 即可。

1 http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf


5

除了易于使用之外，DynamoDB 还极具成本效益优势。利用 DynamoDB，大家只需要为自己实际使用的存

储资源以及配置的 IO 吞吐容量付费。另外，其在设计中还充分考虑到规模化弹性需求。当某一应用程序的

存储与吞吐容量需求降低时，则 DynamoDB 服务内只会配置一小部分容量作为供应。而随着该应用的用户

数量不断提升，必要的 IO 吞吐能力也需要随之增长，这时服务会实时为其添加更多资源。这种机制使得应

用程序能够以无缝化方式完成规模扩展，甚至能够应对每秒高达数百万用户发来的无数数据库并发请求。

表属于 DynamoDB 当中整理并存储数据的基本结构。每份表中包含多个条目，而每个条目由一个惟一主键

作为标识，外加作为属性存在的键/值对。尽管这里的条目概念与 RDBMS 表中的行非常相似，但同一

DynamoDB 表中的各条目并不需要像关系型表内各行进行列共享那样共享同一组属性。图一所示为一套

DynamoDB 以及其中包含的各条目结构。DynamoDB 表当中不存在列的概念，表中的每个条目皆可表示为

一个包含任意数量元素的元组，其最大元素数量可达 40 万。这种数据模型非常适合为对象序列及消息收发

场景下的分布式系统提供数据存储支持。正如我们将在下一章节中所提到，涉及此类数据的工作负载适合

被迁移至 DynamoDB 当中。

图一：DynamoDB 表结构


6

我们可以通过 DynamoDB API 对表与条目进行创建、更新与删除。NoSQL 当中并不存在如关系型数据库

那样的标准 DML 语言。在 DynamoDB 当中，数据的操作以面向对象型代码方式编程实现。我们可以在

DynamoDB 表中进行数据查询，但其同样通过该 API 以编程形式完成。由于不存在 SQL 这样的通用型查

询语言，因此大家必须充分理解自己的应用程序所使用的数据访问模式，从而高效运用 DynamoDB。

适合的工作负载

DynamoDB 是一套 NoSQL 数据库，这意味着其比较适合处理那些非关系型数据。非有关系型工作负载中

的常见用例包括：

广告技术

o 获取浏览器 cookie 状态

移动应用

o 存储应用数据与会话状态

游戏应用

o 存储用户偏好与应用状态

o 存储玩家的游戏状态

消费者“投票”应用

o 真人秀节目、超级碗广告

大型网站

o 会话状态

o 用于实现个性化的用户数据

o 访问控制

应用程序监控

o 存储应用日志与事件数据

o JSON 数据

物联网

o 传感器数据与日志数据提取


7

以上各类用例都能够从 NoSQL 数据库的强大功能当中受益。广告技术应用通常要求具备极低延迟水平的性

能表现，因此非常适合 DynamoDB 的低个位数毫秒读取及写入性能。移动应用与消费者投票应用通常需要

面向数百万位用户，且每秒需要处理成千上万条请求。DynamoDB 能够通过横向扩展应对此类负载。最后，

应用监控解决方案通常每分钟需要从数十万个数据点处提取信息，而 DynamoDB 的无模式数据模型、高 IO

性能以及对原生 JSON 数据类型的支持能力都非常适用承载此类应用程序。

另一项需要考虑的重要特性在于，在审查某种工作负载是否适合以 DynamoDB 为代表的各类 NoSQL 数据

库时，我们还应当了解其是否需要进行横向规模。移动应用可能面对数百万名用户，但每一安装完成的应

用将只面向单一用户进行会话数据的读取与写入。这意味着 DynamoDB 表中的用户会话数据可在多个存储

分区之间进行分布。某一特定用户的数据读取或者写入可归属于单一分区。如此一来，DynamoDB 表就能

够实现横向扩展——随着更多用户加入进来，我们可随之创建更多分区。只要针对此数据的读取与写入请

求还能够被均匀分布至各个分区，DynamoDB 就可以以理想的性能水平处理大规模并发数据访问。此类横

向扩展对于 RDBMS 来说，如果不利用“分片”机制将很难实现，但此种机制亦会将数据库拆分成多个实

例而显著提升复杂性。这意味着我们既需要保留一份包含各实例的索引，同时保留各实例中的数据。为了

进行数据读取与写入，客户端应用需要了解哪个分片当中保存有需要读取或者写入的数据范围。另外，分

片机制还会给管理工作带来额外的运营负担——相较于单一数据库实例，现在大家需要负责维持全部数据

库服务的上线与运行。

另外在考虑某种工作负载是否适合于DynamoDB时，对其数据一致性要求进行评估同样非常重要。实际上，

DynamoDB 当中支持两类一致性模型：强一致性与最终一致性，前者对于 IO 的配置要求远高于后者。这

种灵活性允许开发人员在充分发挥数据库潜在性能的同时，继续支持应用程序的实际一致性要求。如果应

用程序并不要求“强一致性”读取，意味着由单一客户端进行的内容更新并不需要立即为他人所见，那么

使用具备强一致性的 RDBMS 会带来巨大但对应用本身并无益处的资源负担。这是因为强一致性通常需要

锁定数据中的某些部分，而性能瓶颈正是因此而出现。

不适合的工作负载


8

并非所有工作负载都适合由 DynamoDB 等 NoSQL 数据库承载。尽管在理论层面上，我们完全可以利用

DynamoDB 表与条目实现一套经典的关系型模型，但这其实际使用过程会变得非常麻烦。事务型系统要求

各实体之间拥有良好的关系定义，而这类工作负载仍然最好是由 RDBMS 负责实现。另外一些不适合交由

NoSQL 数据库打理的工作负载还包括：

即时查询

OLAP

BLOB 存储

由于 DynamoDB 并不支持 SQL 这类标准查询语言，而且由于其中不存在表加入的概念，因此其在进行即

时查询时往往不像 RDBMS 那样高效。虽然我们可以利用 DynamoDB 运行此类查询，但需要同时配合

Amazon EMR 以及 Hive。同样的，OLAP 应用也很难在 NoSQL 数据库中实现，这是因为用于分析处理的

维度数据模型需要将实际表加入维度表。最后，由于 DynamoDB 对单一条目设定的大小限制，存储 BLOB

往往不具备实际可行性。DynamoDB 确实支持十进制数据类型，但其并不适用于存储大型二进制对象——

例如图像或者文档。然而，在 DynamoDB 表中存储指向实际保存在 Amazon S3 中的大型 BLOB 的指针能

够很好地解决这一问题。

键概念

正如之前章节中所提到，DynamoDB 会将数据整合为由条目构成的表。DynamoDB 表中的每项条目都能够

定义一组任意属性，但该表中的全部条目都必须定义一个用于标识该条目的主键。此键必须包含一条所谓

“hash key”属性，同时可选择额外包含另一“range key”属性。图二所示为一套 DynamoDB 表定义 hash

与 range 键的结构。


9

图二：DynamoDB 表与 Has 及 Range 键

如果某一条目可由单一属性值进行惟一标识，那么此属性则可作为 hash 键发挥作用。在其它情况下，某一

条目需要由两项值方可被惟一识别。在这种情况下，其主键将由 has 键与 range 键共同构成。图三所示即

为这一概念。一套 RDBMS 表将媒体文件与用于对其进行转码的编解码器加以关联，并利用由 has 与 range

键构成的主键将其作为单一表于 DynamoDB 内建模。需要注意的是 DynamoDB 表中的数据经过了去标准

化。这是在将数据由RDBMS迁移至NoSQL数据库时的常见作法，我们将在后文当中对此进行进一步说明。


10

图三：Has 与 Range 键示例

理想的 hash 键应包含大量均匀分布在表内各条目间的不同值。用户 ID 就是一种典型的属性示例，其在表

内各条目间进行均匀分布。在 RDBMS 当中，这些属性往往会被建模为查找值或者枚举，但此类作法会导

致 hash 键不正确——原因在于某些特定值的发生频率远高于其它值。具体概念如图四所示。需要注意的是，

user_id 的数量是统一的，但 status_code 则非如此。如果 status_code 在 DynamoDB 表中被用作 hash 键，

那么那些发生频率更高的值最终会被保存在同一分区当中，这意味着单一分区面对的读取与写入操作会大

幅增加。这就是所谓“热区”，且会对性能造成负面影响。

根据 user_id从 user_preferences 组当中选定 user_id, count(*)作为总值

user_id total

8a9642f7-5155-4138-bb63-870cd45d7e19 1

31667c72-86c5-4afb-82a1-a988bfe34d49 1

693f8265-b0d2-40f1-add0-bbe2e8650c08 1


11

从 status_code sc, log l中选定 status_code, count(*) 作为总值，其

中 l.status_code_id = sc.status_code_id

各条目可利用主键从表中获取。一般来讲，我们可以使用不同的值组而非 hash 与 range 键完成条目获取。

DynamoDB 支持经由本地与全局次级索引实现的此类操作。本地次级索引使用与表定义相同的 hash 键，但

却使用另一属性作为 range 键。图五所示为如何在表中定义一套本地次级索引。全局次级索引则可利用任何

标定属性作为 hash 或者 range 键。利用次级索引获取条目需要配合定义在 DynamoDB API 当中的查询接口。

图五：本地次级索引

由于每套表内的现存本地与全局次级索引的数量是有限的，因此最重要的就是了解各利用 DynamoDB 作为持

久存储的应用的具体数据访问要求。另外，全局次级索引还要求将该属性值投射至索引当中。这意味着当索引

创建时，我们需要在父表内为其选定一个属性子集并将其纳入此索引。当某条目经由全局次级索引被查询时，

只有那些被投射至索引内的属性会被填充进返回结果当中。图六所示即为此概念。需要注意的是，其中初始

hash 与 range 键属性会自动在全局次级索引内进行传播。针对全局次级索引的读取始终保持最终一致性，而

本地次级索引则同时支持最终或者强一致性。最后，本地与全局次级索引都利用配置 IO（将在后文中进行详

述）实现针对该索引的读取与写入。这意味着每当有条目被插入主表或者进行更新时，任何次级索引都将消耗

IO 进行索引更新。

status_code total

400 125000

403 250

500 10000

505 2

图四：潜在键值的均匀与非均匀分布


12

图六：在表中创建一套全局次级索引

无论何时，当某一条目自 DynamoDB 表或索引进行读取或者写入时，执行该读取或者写入操作所必需的数

据会被表示为“读取单元”或者“写入单元”。读取单元由 4K 数据构成，而写入单元则为 1K。这意味着获

取一个 8K 大小的条目需要占用 2 个数据读取单元，而插入该条目则需要 8 个数据写入单元。每秒读取与写

入单元的数量由表的“配置 IO”决定。如果大家的应用程序要求每秒写入 1000 个 4K 条目，则需要至少

在写入容量配置时提供每秒 4000 个写入单元。而当表的现有读取或者写入单元数量不足时，DynamoDB

服务能够“催动”读取及写入操作。在这种情况下，我们可能遭遇性能下降甚至在某些应用客户端中发生

错误。有鉴于此，我们必须要在设计表时充分考虑应用程序的 IO 需求。然而，现有表内的读取与写入能力

可以随时进行修改，意味着如果某个应用程序在使用中突出面对流量峰值，则其 IO 供应量可以同步提升以

承载额外工作负载。同样的，如果由于某种原因而负载强度下降，为其供应的 IO 也将同步削减。这种动态

改变表 IO 能力的特性正是 DynamoDB 与传统 RDBMS 之间的一大关键性区别，后者的 IO 吞吐能力会根据

底层硬件以及运行所在的数据库引擎被固定下来。


13

由 RDBMS 迁移至 DynamoDB 在上一章节当中，我们探讨了 DynamoDB 的几项关键特性以及 DynamoDB 与传统 RDBMS 之间的几项核

心区别。在本章节中，我们将立足于这些关键特性与差异，探索出一项由 RDBMS 迁移至 DynamoDB 的可

行策略。由于数据库迁移往往非常复杂且极具风险，因此我们采取的是分阶段迭代式方案。虽然采用其它

新型技术同样值得肯定，但这里我们不妨先从最简单的用例入手。另外需要强调的是，在本章节中我们的

DynamoDB 迁移工作并不一定属于“全是或者全非”流程。对于特定迁移工作，大家可能需要将工作负载

同时运行在 DynamoDB 以及 RDBMS 当中，这里我们只讨论将负载成功迁移至 DynamoDB 并保证应用程

序正常运行的办法。

以下状态示意图展示了我们提出的迁移策略：

图七：各迁移阶段

需要强调的是，此流程以迭代方式完成。特定状态可能返回至上一状态。另外，数据分析与数据建模阶段

内的问题将在测试时进行考虑。在大多数情况下，我们需要在达成最终数据迁移状态之前，在各个阶段进

行数次迭代。每个阶段都将在接下来的各个章节中进行具体讨论。

规划阶段

规划阶段的第一步是确定数据迁移的目标。其中通常包含（但不限于）：

提升应用程序性能

降低成本

降低单一 RDBMS 上的负载强度

在多数情况下，迁移的目标源自以上几点。在目标确定之后，我们可以根据这些要求指导将 RDMBS 表迁移

至 DynamoDB。正如之前所提到，涉及非关系型数据的工作负载表非常适合迁移至 DynamoDB。将此类表迁

移至 DynamoDB 能够显著提升应用程序性能，同时降低成本以及 RDBMS 之上的负载强度。部分合适的迁移

负载类型包括：


14

实体-属性-值表

应用程序会话状态表

用户偏好表

日志记录表

在表确定之后，源表中任何可能导致迁移难点的特性都会被记录在案。这部分信息非常重要，我们需要利用其

建立起健全的迁移策略。下面我们一同了解比较常见的影响迁移策略的难点：

难点对迁移策略的影响

在迁移之前或者期间，指向 RDBMS 源很难将目标 DynamoDB 表内的数据与数

表的写入操作无法正常进行。据源进行同步。考虑在迁移策略中将数据

并发写入至源与目标表。

源表当中的数据量可能超过现有网络传输带宽的传输能力考虑将源表中的数据导出至便携式磁盘，

同时利用 AWS Import/Export 服务将数

据导入至 S3 存储桶。而后将将数据由

S3 直接导入至 DynamoDB 数据库。

另外，降低需要迁移的数据问题，包括

只导出那些在特定时间点之后的记录。

全部早于这一时间点的数据将继续保留

在 RDBMS 的原有表内。

源表中的数据需要在导入 DynamoDB 之前进行转换。将源表中的数据导出至 S3.考虑利用 EMR

执行整个数据传输过程，而后将传输完成


15

难点对迁移策略的影响

的数据导入至 DynamoDB 数据库。

源表的主键结构无法被移植至 DynamoDB。标记各适用于已导入条目的 has 与 range

键的列。另外，考虑向源表中添加一条

代理键（例如 UUID），其将作为合适

的 hash 键使用。

源表中的数据经过了加密。如果加密机制由 RDBMS 负责管理，那么该数

据需要在导出前进行解密，而后在导入时利用

应用程序（而非底层数据库引擎）的加密模

式进行重新加密。各加密键随后需要在

DynamoDB 之外进行管理。

表一：影响迁移策略的各项难点

最后，也可能是最重要的一点，备份与恢复流程同样应当在规划阶段内进行定义与文档记录。如果迁移策略需

要完整的自 RDBMS 到 DynamoDB 交接，则定义恢复功能以避免在 RDBMS 迁移过程中遭遇数据丢失显然是

必不可少的。为了降低风险，大家可以考虑同时在 RDBMS 与 DynamoDB 之上并发运行工作负载。在这种场

景下，基于 RDBMS 的传统应用程序只会在利用 DynamoDB 立足生产环境完成测试之后才会被最终禁用。

数据分析阶段

数据分析阶段的目标在于理解源数据组合，而后确定应用程序所使用的数据访问模式。这部分信息需要作为数据建模阶段中的输入结果。另外，我们还需要了解运行在 DynamoDB 之上的工作负载的成本与性能。对源数据的分析应当包含：


16

需要导入至 DynamoDB 当中的条目数量。

条目分布的整体规模。

可用作 hash 或者 range 键的值多重性。

DynamoDB 的计费机制包含两大主要组成部分——存储与配置 IO。通过估算需要导入至 DynamoDB 表内

的条目数量，以及各个条目的具体规模，我们可以计算出该表的存储与配置 IO 要求。常见的 SQL 数据类

型将映射 DynamoDB 中三种标量类型中的一种：字符串、数字与二进制。各数字数据类型的长度是可变的，

而字符串则采用二进制 UTF-8 编码。在做主条目大小时，这里的重点应该放在具备最大值的属性身上，并

据此以1K为增量单位配置 IOPS——DynamoDB当中不存在分数 IO的概念。如果某一条目估算大小为3.3K，

那么其需要 4 个 1K 写入 IO 单元与 1 个 4K 读取 IO 单元，用于实现单一条目的写入与读取。由于会被直接

舍入至最近的千字节，因此数值类型的确切大小并不重要。在大多数情况下，即使存在大量高精度数据，

我们还是可以利用少量字节完成数据存储。由于表中的每个条目可能包含多条属性，因此其可用于计算条

目大小分布并利用百分比值代表条目大小。举例来说，大家可以利用第 95 百分位代表某一条目大小，并利

用其估算存储与配置 IO 成本。倘若源表当中存在大量需要逐一检查的行，则从源数据中提取样本并利用其

计算条目大小分布。

至少，一套表应当配置有充裕的读取与写入单元，用于处理每秒单一条目的读取与写入操作。举例来说，

如果我们需要利用 4 个写入单元进行对应大小或者低于第 95 百分位的条目的写入操作，则该表应当至少采

用每秒 4 个写入单元作为配置 IO。任何低于这一水平的单一条目写入操作都会导致限制及性能降低。在实

践当中，配置的读取与写入单元数量将远高于必要的最低水平。利用 DynamoDB 作为数据存储的应用程序

通常需要并发进行读取与写入操作。

正确估计配置 IO 非常关键也非常必要，其将成为保障应用程序性能与了解成本水平的前提。了解各可作为

hash 或者 range 键的 RDBMS 列值则能够保证我们的体系具备最高性能。包含非均匀分布的值（即某些出

现频率高于其它的值）的各列往往不适合作为 hash 或者 range 键，因为访问频率高的各键所对应的条目会

存在于同一 DynamoDB 分区当中，这会给应用程序性能造成负面影响。

数据分析阶段的第二个目标在于对应用程序的数据访问模式进行分类。由于 DynamoDB 并不支持 SQL 这

类常规查询语言，所以必须利用文档记录各数据立足表进行写入与读取的方式。这部分信息在数据建模阶

段非常重要，其中各表、键结构以及索引都将进行定义。目前常用的数据访问模式包括：


17

纯写入——各条目被写入至表，且永远不会接受应用程序的读取。

由不同值获取——各条目由表内惟一标记的一个值进行获取。

跨越值范围查询——常见于时间数据当中。

如下一章节当中所见，应用程序的数据访问模式记录文档会使用各种类别进行划分，而其将成为数据建模

的决策依据。

数据建模阶段

在这一阶段当中，各表、hash 与 range 键以及次级索引都将进行定义。此阶段中确定的数据模型必须支持

在数据分析阶段内描述的数据访问模式。数据建模的第一步是为目标表确定 hash 与 range 键。该主键——

无论是单纯由 hash 键构成，还是同时包含 hash 与 range 键——都必须区别于表内的其它条目。在立足于

RDBMS 进行数据迁移时，我们一般可以利用源表的主键作为 hash 键。不过在实际操作当中，该键对于应

用程序并不具备任何语义层面的含义。举例来说，RDBMS 当中的 User 表可能定义一个数字主键，但负责

对用户进行日志记录的应用程序需要的则是电子邮箱地址，而非数字用户 ID。在这种情况下，电子邮箱地

址为“天然键”，其更适合作为 DynamoDB 表中的 hash 键，这是因为各条目能够轻松为其 hash 键值所提

取。以这种方式进行 hash 键建模非常适合由不同值获取条目的数据访问模式。而对于其它数据访问模式，

例如“纯写入”模式，则可利用一条随机生成的数字 ID 作为 hash 键。在这种场景下，应用程序永远不会

从表内获取各条目，因此该键只需要用于对各条目进行惟一标记，而非数据获取的手段。

RDBMS 包含有惟一双键值索引的RDBMS表适合同时利用hash键与 range键定义主键。用于定义RDBMS

当中多对多关系的交集表通常利用由关系双方键值对的惟一索引进行建模。由于从多对多关系内获取数据

要求进行一系列表加入，因此将这样一套表迁移至 DynamoDB 还将涉及数据的非标准化操作（将在下文中

进行详细讨论）。另外，日期值也常作为 range 键使用。包含 URL 访问日期与次数的表能够将该 URL 定义

为 hash 键，而日期则作为 range 键。由于主键仅由单一 hash 键构成，因此利用一条复合主键进行条目获

取则要求由应用程序同时指定 hash 与 range 键值。我们需要在评估时考虑使用代理键或者天然键来作为

hash 以及/或者 range 键。


18

由于非键属性可被任意添加至任何条目当中，因此惟二需要在 DynamoDB 表定义中进行指定的只有 hash

键与（可选）range 键。然而，如果次级索引需要根据任意非键属性进行定义，则其必须被包含在表定义当

中。非键属性向表定义中的引入并不需要对表内的全部条目进行任何形式的构建。除了主键，表中的每个

条目都能够具备任意属性列表。

RDBMS 对 SQL 的支持能力意味着各记录可利用表内的任意列值进行获取。这些查询可能并非永远有效—

—如果列中不存在可用于获取数据的索引，那么可能需要进行全表扫描以定位匹配的行。DynamoDB API

提供的查询接口并不支持以这种方式从表中获取条目。我们可以进行全表扫描，但这一操作效率很低且在

表规模较大时会消耗大量读取单元。相反，各条目应利用表的主键从 DynamoDB 表当中获取，或者使用定

义于表内的本地或全局次级索引键。由于以 RDBMS 表中非键列为基础的索引代表着该应用通常会利用值

进行数据查询，因此这些属性比较适合在 DynamoDB 表之内作为本地或者全局次级索引。DynamoDB 表 2

所允许的次级索引数量是有限的，因此利用应用程序在获取数据时使用频率最高的属性值为这些索引选择

定义键。

DynamoDB 并不支持表加入概念，因此从 RDBMS 表内进行数据迁移往往需要对数据加以非标准化处理。

在配合 RDBMS 时，其在概念层面存在些许冲突。由于自 RDBMS 迁移至 DynamoDB 的合适工作负载往往

涉及非关系型数据，因此非标准化处理并不存在太多难点。举例来说，如果某套关系型数据库包含一套 User

与一套 UserAddress 表，二者通过 UserID 进行关联，那么我们可以将 User 属性与 Address 属性合并为单

一 DynamoDB 表。在关系型数据库内，我们可以对 UserAddress 信息进行标准化，从而将多条地址指定至

单一给定用户。这类要求常见于联系人管理或者 CRM 系统。不过在 DynamoDB 之内，User 表的作用可能

有所不同——例如追踪某款移动应用程序的注册用户。在此类用例中，User 到 Address 的多样性在重要性

层面低于用户记录的可扩展性与快速检索能力。

http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html


19

数据建模示例

下面我们将通过一项示例，结合本文各章节内提到的概念。本示例将展示如何利用次级索引完成高效数据

访问，以及如何为一套 DynamoDB 表估算条目大小与配置 IO 水平。图八所示为一套 ER 示意图，其中的

模式用于通过电子商务门户在处理在线订单时追踪各事件。其中将同时演示RDBMS与DynamoDB表结构。

图八：用于追踪事件的 RDBMS 与 DynamoDB 模式

需要迁移的行数约为 10！，因此这里我们不再以迭代方式计算条目大小的第 95 百分位。相反，我们将对 101

行进行简单的随机抽样，这将提供具备充足精度的项目大小估算结果。要做到这一点，我们构建起一套 SQL

视图，其中包含将被插入至 DynamoDB 表内的各字段。我们首先进行抽样，而后随机从此视图中选择 10！

行，最终计算代表第 95 百分位的大小。

统计抽样字段中的第 95 百分位大小为 6.6 KB，其中大部分由“Data”数据所消费（其最大可为 6 KB）。因

此写入单一条目的最低写入单元数量应该为：

(6.6 1 ) = 7


20

根据同样的算法，读取单一条目的最低读取单元数量要求为：

(6.6 4 ) = 2

对于那些写入强度较高的特定工作负载，我们需要配置充分的 IO 为每天 500 份订单的 1000 次写入事件提

供支持。其计算方式如下：

500 × 1000 = 5 ×10!

5 × 10! × 86400 = 5.78

5.78 × 7 = 41

每小时只需要对该表进行一次读取，而上个小时的数据被导入至 Amazon Elastic MapReduce 集群进行ETL。

这项操作利用一条查询从给定的数据范围选取条目（正因为如此，EventDate 属性既属于 range 键亦属于

全局次级索引）。检索查询结果所必需的读取单元的数量（其将在此全局次级索引当中进行配置）基于该查

询返回的结果大小：

5.78 × 3600 ℎ = 20808 ℎ

20808 ℎ × 6.6

1024 = 134. 11 ℎ

单一查询操作返回的最大数据量为1 MB，因此必须对其进行分页。每小时读取查询将需要读取135页数据。

对于强一致性读取，我们需要利用 256 个读取单元以一次性读取一个完整页面（这一数字相当于最终一致

性读取次数的一半）。从实际情况来看，写入单元很可能以偶数表达，例如 48。我们现在已经拥有了评估此

工作负载 DynamoDB 成本所必需的全部数据：

1. 条目数量(10!)

2. 条目大小(7 KB)

3. 写入单元(48)

4. 读取单元(256)

这些数据可经由 Amazon Simple Monthly Calculator3加以运行，从而完成成本评估。

http://calculator.s3.amazonaws.com/index.html


21

测试阶段

测试阶段属于迁移策略当中最重要的组成部分。在此阶段当中，我们需要对整个迁移流程进行端到端测试。

一套全面的测试规划应当至少包含以下内容：

测试类别目标

基本验收测试这些测试应当在数据迁移流程内以自动化方式

执行。其主要目标在于验证整个数据迁移是否

成功。这些测试中的部分常见输出结果包括：

处理的整体条目数量

导入的整体条目数量

跳过的整体条目数量

整体警告数量

整体错误数量

如果由测试报告的总和与预期值不符，则意

味着迁移无法成功，我们需要首先解决问题

而后再进行下一步骤或者下一轮测试。

功能测试这些测试会检验利用 DynamoDB 作为数据

存储机制的应用程序的功能性。其中将同时

包含自动与手动测试。功能测试的主要目标

在于发现应用程序当中由 RDBMS 数据迁移

至 DynamoDB 所引发的问题。在此轮测试当中

，经常能够发现数据模型之间的对接空缺。

非功能测试这些测试将评估应用程序的各类非功能特性，

例如多种负载水平下的性能以及应用程序堆栈

中任意部分的故障弹性。


22

测试类别目标

这些测试中还可包含可能性较低但会给应用程

序造成负面影响的边界与边缘（例如大量客

户在同一时间内对同一记录进行更新）。规划

阶段当中定义的备份与恢复流程也应当被纳

入非功能测试当中。

用户验收测试这些测试应当在最终数据迁移完成之后，由

应用程序的最终用户负责执行。这些测试的

目标为由最终用户决定应用程序的可用性是

否符合相关机构内的主要功能。

表二：数据迁移测试规划

由于迁移策略具备迭代特性，因此这些测试将进行多次执行。为了最大程度提升效率，考虑利用生产数据

（如果需要迁移的数据规模过大）中的样本进行数据迁移测试。测试阶段的成果通常要求对此前完成的各

个阶段进行审查。总体迁移策略能够在流程中的各次迭代内得到进一步细化，而且一旦全部测试且成功完

成，我们将能够以此为基础迈入最终阶段——数据迁移。

数据迁移阶段

在数据迁移阶段，来自源 RDBMS 表的全部生产数据集合都将被迁移至 DynamoDB 当中。到了这一阶段，

所有端到端数据迁移流程都应该已经测试并核实完成。该流程的各个步骤也皆进行了完备记录，因此将其

在生产数据集内进行运行将与执行其它既定规程完全一致。作为最终阶段的准备工作，我们应当向应用程

序的各位用户发送通知，提醒他们此应用将进行维护且可能带来停机时间。

一旦数据迁移工作完成，上一阶段当中定义的用户验收测试即应开始执行，负责确保应用程序处于可用状

态。一旦迁移工作由于某种故障而未能成功，则备份与恢复规程开始执行——其亦同样应当预先经过测试

与核实。当该系统重新恢复至稳定状态，则对故障的根本原因进行分析，并在将问题解决之后重新执行数

据迁移。如果一切顺利，则该应用程序应当在未来几天内接受密切监控，直到有足够的数据表明应用程序

已经开始正常运作。


23

总结

利用 DynamoDB 处理合适的工作负载能够带来更低的运营成本、降低日常维护开销，同时带来比传统

RDBMS 更为出色的性能、可用性与可靠性。在本份白皮书当中，我们提出了一项策略以确定哪些工作适合

由 RDBMS 迁移至 DynamoDB。在实施这项重复地，我们需要仔细规划并执行设计工作，同时对将其迁移

至 NoSQL 解决方案保持信心，从而真正将 DynamoDB 迁移所必需的前期费用转化为可观的投资回报。

附录

以下“附录”内容总结了此份白皮书当中涉及的各项关键性概念，同时列出了与该概念相关的具体章节：

概念章节

确定合适的工作负载合适的工作负载

选择正确的键结构键概念

表索引数据建模阶段

配置读取与写入配置数据建模示例

选择一项迁移策略规划阶段

扩展阅读

为了获取更多帮助，请大家参阅以下资料：


24

DynamoDB 开发者指南 4

DynamoDB 网站 5

4 http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedDynamoDB.html 5 http://aws.amazon.com/dynamodb

Documents

由RDBMS 到Amazon DynamoDB 迁移最佳实践指南 · PDF fileAmazon Web Services – 由RDBMS 到Amazon DynamoDB：迁移最佳实践指南 2014 年4 月 3 RDBMS 是一项成熟且稳定的技术方案。