【AWS征文】带你轻松迁移数据库到 AWS
如今，企业上云离不开数据库上云。然而，云上有很多数据库类型，企业该如何选择？将数据库迁移到云端，该有哪些步骤呢？不同的业务场景下，企业该如何选择？本文将介绍 AWS 各种常用数据库特性，以及如何满足客户不同业务需求，并列举数据库迁移案例为大家演示如何轻松便捷的把数据库迁移上云。
一、AWS 数据库概览
在这个互联网极其发达的时代，我们每个人会接收以及生产各式各样的信息，数据的重要性已经***到每个角落，成为每个行业发展和变革的必要元素。我们日常使用的手机应用，比如微信、支付宝、微博等，里面的数据都是需要数据库来进行存储，不同的应用会使用不同类别的数据库，甚至同一个应用可能同时使用多种数据库。
应用离开了数据库就像鱼儿离开了水，由此可见数据库在当今互联网的重要性。我们甚至可以说当今世界最宝贵的资源不再是石油，而是数据。随着业务的快速发展，全球化业务新兴需求增加，本地传统数据库已经无法为快速发展的业务提供支持，我们需要探索一种新的方式，把本地数据库迁移到云中，利用云中数据库的优势来解决本地数据库中遇到的瓶颈问题。
我对各家云厂商数据库种类做了一个比较，发现 AWS 为用户提供的数据库种类最为丰富，几乎把所有数据库相关的应用场景都捕捉到了。下面通过一个列表，来浏览一下 AWS 的数据库种类，其中关系型数据库最为丰富，也是目前应用使用最多的数据库。
以上这些数据库由 AWS 完全托管，用户不用去管理底层硬件系统升级维护等相关工作，这也是推荐使用全托管数据库而非自建数据库的原因。为了方便客户数据库迁移上云，AWS 还为客户提供了非常方便的迁移工具 DMS，帮助用户轻松经济高效的完成迁移任务。
那么面对这么多种类的数据库，尤其是一些新型数据库，我们从来没有使用过，我们该如何选择？我们需要从业务场景为出发点来分析使用哪种数据库，下面我对 AWS 数据库的使用场景做个简单的介绍，也让大家对 AWS 各种数据库的应用场景有一个大致了解。
| 数据库种类 | 应用场景 |
|---|---|
| 关系数据（RDS） | 传统应用程序、ERP、CRM 、电子商务 |
| 键值数据（DynamoDB） | 高流量 Web 应用、电子商务系统、游戏应用程序、微服务 |
| 宽列数据（Keyspaces） | 用于设备维护、队列管理和路线优化的大规模工业应用程序 |
| 文档数据（DocumentDB） | 内容管理、目录、用户配置文件、移动和 Web 应用程序 |
| 内存数据（ElasticCache） | 缓存、会话管理、游戏排行榜、地理空间应用程序 |
| 图数据（Neptune） | 欺诈检测、社交网络、推荐引擎、知识图谱 |
| 时序数据（Timestream） | IoT 应用、开发运营和工业遥测 |
| 分类账数据（QLDB） | 系统记录、供应链、注册、银行事务 |
初步了解 AWS 各项数据库的应用场景之后，我们详细介绍 AWS 各项数据库特性，以及 AWS 数据库如何满足用户在各种业务场景下面的需求。
数据库家族
关系型数据库
关系型数据库是起源非常早的数据库，也是目前各种应用使用最多的数据库。我们使用各种应用都需要注册用户，这些用户数据存放在关系型数据库里面；你在电商网站下了一个订单，订单也是存放在关系型数据库里面；我们访问的网站，其后台数据也是存放在关系型数据库里面。所以说关系型数据库无所不在。
说到 AWS 的关系型数据库，那不得不说一下 Amazon Aurora，Aurora 是 AWS 专为云而打造的云原生数据库，它兼容 MySQL 和 PostgreSQL，它可以支撑我们各种关系型数据库的应用场景，性能好、易扩展、安全、便于管理，Aurora 如此好用，也依托于它下面的一些特性：
- 性价比：吞吐量为标准 MySQL 的五倍，标准 PostgreSQL 的三倍，成本只有商业数据库的十分之一。
- 扩展性：基于共享存储，主从复制延迟很低，可跨三个可用区扩展至最多 15 个只读副本。
- 可用性与持久性：具有容错能力的自我修复存储；跨三个可用区建立六个数据副本；持续备份至 S3。
- 安全性：VPC 网络隔离、静态/传输数据加密、满足大多数地区合规性要求。
- 全球数据库：数据库跨越多个 AWS 地区同步复制，将数据库置于用户端，可以实现低延迟（典型延迟小于 1 秒）的本地读取和跨区域灾难恢复。
- 无服务器：可以根据工作负载自动扩容缩容，无需关心底层硬件扩展，适合业务波动的应用。
Aurora 具有很多传统数据库不具有的特性，这样让 Aurora 成为关系型数据库的首选。不过如果你不想更换数据库类型，把本地现有的数据库迁移到云中，AWS 还为用户提供 MySQL、MariaDB、PostgreSQL、SQL Server、Oracle 等关系型数据库，客户可选择相同的数据库引擎进行迁移。并且这些数据库依托于 AWS 强大的基础设施和管理，同样安全稳定。
如果 Aurora 非常吸引你，而你现在用的是 SQL Server 或者 Oracle，那该怎么办？不用担心，AWS 为客户提供了 Schema Conversion Tool、DMS 这两个服务，可以帮助客户评估并且转换数据库对象，非常便捷地将本地数据库迁移到 Aurora。
键值数据库
互联网发展到今天，数据表越来越大，有的应用要求写得快、读的快等需求。关系型数据库已经无法满足我们的需求，因此 NoSQL 数据库也就诞生了。我们把一些不需要关系查询，要求读写快的应用数据放置在 NoSQL 数据库里面来解决性能问题。
考虑到客户的需求，AWS 也为客户提供了自研的 NoSQL 数据库 Amazon DynamoDB，它支持键值存储，也支持文档存储，特别以键值存储为核心，面对海量数据，性能非常强悍。因其由 AWS 完全托管，所以也是无服务器架构中的重要一员。
-
扩展性：可自动纵向扩展和缩减表，以针对容量做出调整并保持性能，提供任意级别的请求流量。
- 高性能：对于一般的请求，DynamoDB 在个位数毫秒内可以完成，而且处理请求的速度不会随着数据量的增加而减慢。
- 分布式：无中心化架构，一个表上的数据可以分布到几百台机器上。
我也在 AWS 官方渠道了解到，汇量科技是一家广告公司，他们也大量使用了 AWS 的服务，尤其是对广告点击的数据，正是采用了 DynamoDB 数据存储，可以支撑 2019 年日均广告请求量 600 亿次，峰值高达 1000 亿次。如此巨大的请求量，放在关系型数据库将无法支撑，由此可见 DynamoDB 在这种应用场景性能多么强悍。
文档数据库
JSON 数据无数不在，它是一种非常灵活的格式，你可以很方便地修改一条数据的 Schema。它是一种轻量级的数据交换格式，目前使用最广泛的 API 标准 RESTfull API，它的输出标准也是 JSON。使用 JSON 进行数据建模最符合人类语言的逻辑。以上这些使用场景，我们都需要一种文档数据库来存储 JSON 数据，它既不是关系型数据库，也不是键值数据库。
哪些应用场景会用到文档数据库呢？因为 JSON 数据的灵活，文档数据已经***到各个领域，比如在游戏中，存储用户信息，装备积分等；在物流中，存储订单信息，订单状态；在社交中，存储用户信息以及用户发表的朋友圈信息；在视频直播中，存储用户信息和礼物信息等。
为了满足客户这些使用场景，AWS 为客户提供了 DocumentDB 数据库，见名知意，它是一个云原生的文档数据库，与 MongoDB 兼容，你可以把现有的 MongoDB 数据库通过 DMS 或 mongodump/mongorestore 等原生方式迁移上 AWS。
DocumentDB 扩展性很强，水平扩展在分钟级别，最多可以扩展到 15 个读副本；垂直扩展也在分钟级，最高扩展至 768 GiB 内存；存储可以自动扩展，最高支持 64TB。这些特性都是我们在自建数据库很难实现的。
内存数据库
如今的应用越做越大，很多都已经开始进行分布式或者微服务架构，这时候就需要一个存储库来储存用户的会话信息，不然用户可能处于频繁的登陆状态；还有应用要求提升数据查询速度，这就需要给数据库添加缓存层等。以上这些应用场景都会需要内存数据库。
那么 AWS 同样在云中为客户提供了完全托管的内存数据库 Amazon ElastiCache，客户可以把一些热数据、会话数据、消息数据、排行数据等存放在其中，以加速数据的存取速度。它支持两种存储引擎，Memcached 和 Redis。
- 极致性能：能够支持要求最严苛且需要亚毫秒级响应时间的应用程序。
- 轻松扩展：通过使用 AWS 管理控制台或者简单的 API，用户可以根据应用需要添加或删除缓存集群中的节点。
- 安全性：支持 Amazon VPC，可以进行网络隔离。通过安全组来管理集群的访问权限。
- 高可用：可将 2 到 6 个节点归入一个具有副本的集群，如果一个节点出于任何原因发生故障，您不会丢失所有数据。
图数据库
关系型数据库有了，键值和内存数据库也有了，已经基本满足大部分应用的日常需求，对于 AWS 来说，这还不够。用户还会面临性能和 schema 变更不易的问题，因此 AWS 推出了图数据库 Neptune。
使用图形数据库处理社交网络数据非常高效，Amazon Neptune 可以快速轻松地处理大量的用户配置文件和交互，从而构建社交网络应用程序。
时序数据库
顾名思义，时序数据库是和时间相关的数据库。因为很多对数据的查新都是以时间段为基础的， 适用于 IoT 和运营应用程序。因此 AWS 为用户提供了 Amazon Timestream，专门处理时序数据，目前还处于注册预览版。
分类账数据库
分类账数据库的使用场景也很好理解，最适合的场景是“记账本”。“账本”是不能被更改的，每一笔记录都不能被改动，被忠实的记录下来，以备查询。Amazon Quantum Ledger Database 就应运而生了。
这听起来和“区块链”有点关系，不过 QLDB 是有中心的，而“区块链”是去中心化的，那么你可能会问，AWS 有没有去中心化的数据库，回答是有的，那就是 Amazon Managed Blockchain。我们很难去想 AWS 到底不存在什么数据库，用户需要的它有，用户用不到的它也有，可以说达到了“应有尽有”的程度。
迁移工具
介绍了这么多的数据库，以及各种数据库的使用场景和特性，几乎满足日常应用的所有需求，那我们肯定是想知道如何使用这些数据库，以及如何把目前本地自建的数据库迁移到云中。下面我们将介绍 AWS 为客户提供的迁移神器 AWS Database Migration Service，以及 DMS 如何帮助客户便捷高效地把数据迁移到云中的数据库。
同样 DMS 也是完全托管的，这让我们把主要精力放在迁移任务上面来。DMS 支持多种数据库作为迁移的源，也支持多种数据库作为迁移的目标，从下面的表格可以详细了解支持哪些数据库：
| 数据迁移的源 | 数据迁移的目标 |
|---|---|
| Oracle、SQL Server、MySQL、MariaDB、PostgreSQL、SAP ASE、MongoDB、DB2 LUW、Azure SQL、Amazon RDS、S3 | Oracle、SQL Server、MySQL、MariaDB、PostgreSQL、SAP ASE、Amazon RDS、Amazon Redshift、Amazon S3、Amazon DynamoDB、Amazon Elasticsearch Service、Amazon Kinesis Data Streams、Amazon DocumentDB、Amazon Neptune、Apache Kafka |
我们可以从表格中看到各种数据库引擎，AWS DMS 支持同构数据库迁移，如 MySQL 迁移到 MySQL，也支持异构数据迁移，如 Oracle 到 MySQL，在进行异构数据库迁移的过程，AWS 还为用户提供一款工具 AWS Schema Conversion Tool，可以使用 AWS SCT 将源数据库架构和大部分对象自动转换为与目标数据库兼容的格式。
对 DMS 的总结，可以简单概括为下面几个小特性：
- 简单易用
- 最少停机时间
- 持续数据复制
- 多数据源支持
- 运行可靠
AWS DMS 可以成为复制和迁移数据库的最佳工具，它可以帮助用户将数据库工作负载迁移到 AWS 并更改数据库引擎，同时最大程度地减少停机时间。根据 AWS 的说明，使用 AWS DMS 已经进行了 20,000 个数据库到 AWS 云的迁移。由于使用该产品获得了如此广泛的成功，因此没有理由不将数据库迁移到 AWS，那么下面就开始我们的数据库迁移之旅吧。
迁移方式
所有的数据库都有自己的备份还原工具，使用这些工具我们可以方便的进行数据离线迁移，但是会造成较长的停机时间，主要看数据量的大小。如果需要最小的停机时间，那 DMS 是最佳选择。下面大致列举了各种迁移方式对业务的一个影响程度，可以根据自己的实际情况进行选择。
| 因素 | 离线（转储） | 混合 | 在线（DMS） |
|---|---|---|---|
| 复杂度 | 非常简单 | 复杂 | 中等 |
| 速度 | 快 | 中等 | 慢 |
| 停机时间 | 高 | 中 | 低 |
二、云上数据库迁移实践
迁移解决方案
我们在本地数据中心有各式各样的自建数据库，如果对数据库迁移上云，我们该如何选择云中的数据库呢，我下面简单整理了一个列表，针对不同的场景，我们可以选择对应的解决方案。
- 现有应用程序
- MySQL ---> Amazon Aurora for MySQL，RDS for MySQL
- PostgreSQL ---> Amazon Aurora for PostgreSQL，RDS for PostgreSQL
- MariaDB ---> Amazon Aurora for MySQL，RDS for MariaDB
- Oracle ---> 利用 AWS SCT 检测复杂性因素 ---> Amazon Aurora，RDS for Oracle
- SQL Server ---> 利用 AWS SCT 检测复杂性因素 ---> Amazon Aurora，RDS for SQL Server
- MongoDB ---> DocumentDB
- 新的应用程序
- 如果不需要关系类功能 ---> Amazon DynamoDB
- 如果需要关系类功能 ---> Amazon Aurora
-
内存存储/缓存
- Redis ---> Amazon ElasticCache
- Memcached ---> Amazon ElasticCache
- 时序数据
- Amazon Timestream（注册预览版）
- 跟踪各应用程序变更、加密可验证性，具备中央可信权威
- Amazon Quantum Ledger Database
迁移须知
数据库是任何应用程序的主要组件之一，因此我们必须谨慎地进行迁移。您需要知道数据库的大小，数据库内部表的大小以及数据库模式。
使用 AWS DMS 将数据迁移到 AWS 很简单。首先在 AWS 环境中创建复制实例，然后 AWS DMS 连接源数据库端点和目标数据库端点。迁移开始时，AWS DMS 会创建表，加载数据并同步数据库。整个复制任务都由复制实例承担，建议创建配置比较大的复制实例。
使用 AWS DMS 执行迁移的总体流程如下：
- 创建目标数据库。
- 复制架构。
- 创建 AWS DMS 复制实例。
- 定义源数据库和目标数据库的终端节点。
- 创建并执行迁移任务。
将 MySQL 数据迁移到 Aurora MySQL
这个案例是一个同构数据库迁移，相对来说比较简单，迁移的方案有三种，可以直接使用mysqldump导出数据，然后再导入到 Aurora，适合数据量不大的数据库，另外一种是直接把数据库的源文件复制到 S3 存储桶，可以使用 Xtrabackup 备份数据库然后传到 S3 中，然后用这些文件还原到 Aurora 数据库，适合比较大量的数据，不过这两种数据库都是离线传输，需要停机迁移。
针对实时在线迁移数据库，我们需要用到 AWS DMS，下面我将演示如何从一台 MySQL 数据库，实时迁移数据到 Aurora，对于源数据库，我们可以使用 AWS RDS，或者在 EC2 上面的自建数据库，或是其他云厂商的 MySQL 数据库，下面我选择使用在 EC2 上面自建的数据来进行演示，所以操作均在 AWS us-east-1 区域。
1、配置源数据库
源数据库我们已经有了，你可以创建一个只读权限的临时账户用于数据迁移，我们这里就直接用具有读写权限的账户演示。
2、创建 Aurora 数据库
首先我们在 AWS 控制台中创建一个 Aurora MySQL 数据库作为我们的目标数据库，因为不是主要介绍创建数据库，所以创建过程这里不再演示，创建完成之后，需要记录下数据库地址，账户密码，当然为了安全，你也可以单独创建一个用于迁移的临时账户。
3、创建复制实例
AWS DMS 复制实例执行源和目标之间的实际数据迁移。复制实例负责整个数据的迁移，对更改的数据进行缓存，所以说大一点的实例性能更好，缩短迁移时间。打开 AWS DMS 控制台，选择创建复制实例，注意网络方面的限制，需要复制实例可以连接到两个数据库。
4、创建 MySQL 终端节点
在 AWS DMS 控制台中，在导航窗格中选择 Endpoints (终端节点)。
5、创建 Aurora 终端节点
目标终端节点会更简单一写，因为是 AWS RDS，我们可以直接勾选。
6、创建迁移任务
迁移任务中的迁移类型我们选择复制现有数据以及持续复制变更的数据，记得源数据库开启 binlog 日志。
在表映射选项里面，选择告知 DMS 应该迁移哪些表，迁移过程中还可以对表名进行一些转换，我们这里就选择完全复制整个数据库。
7、监控迁移任务
再等待一段时间之后，我们可以在任务详情里面看到数据迁移完成，并且目标数据库数据检查没有问题。
我们可以看到，通过 DMS 仅仅需要简单几步就可以把数据库迁移到 AWS，并且源数据库变更数据会实时的更新到目标数据库中。
将 SQL Server 数据库迁移到 Aurora MySQL
这个案例是一个异构数据库迁移，我们会用到 AWS SCT 进行 Schema 转换，AWS DMS 支持从 RDS 迁移到 RDS，所以这次的源数据库 SQL Server 是 AWS RDS for SQL Server（Enterprise Edition）。
Schema 转换
1、在本地计算机安装 AWS SCT
需要在自己的电脑上面安装 AWS SCT 工具，以及连接 SQL Server 的 JDBC 驱动和 Aurora MySQL 的 JDBC 驱动。
然后启动 SCT，配置一下刚刚下载的 JDBC 驱动。
2、创建迁移项目
打开 AWS SCT，选择创建一个新项目，选择源和目标数据引擎。
分别连接 SQL Server 和 AWS Aurora 数据库。
勾选我们要迁移的数据库，右键选择 Create report。
查看报告，看看有没有问题，如果没有问题，我们就可以直接进行转换了。
我这边遇到一个存储过程 MySQL 不支持，我这边忽略掉，比较懂数据库的人员可以进行修正。
3、Schema 转换
问题处理掉之后，我们就可以进行 Schema 转换了，和前面一样，右键数据库，选择 Convert schema。
执行之后，很快我们在目标数据库看到了转换的 Schema。
数据迁移
对于 SQL Server 的数据迁移方式，我们选择一次性迁移，不进行持续复制，持续复制配置过程稍微复杂一些，需要对源数据库进行一些配置，需要持续复制的用户，可以参照 AWS 官方文档配置。
1、创建复制实例
打开 DMS 控制台，创建复制实例，同样注意网络情况，复制实例需要链接源和目标数据库。
2、创建 AWS DMS 源和目标终端节点
创建完终端节点之后，首先运行一下测试，可以连接成功即可。
3、创建迁移任务
可以按照我下面的表格选择来配置迁移任务。
| Parameter | Value |
|---|---|
| Task identifier | AuroraMigrationTask |
| Replication instance | replication-server |
| Source database endpoint | sqlserver |
| Target database endpoint | dst-mysql-instance-1 |
| Migration type | Migrate existing data |
| Start task on create | Checked |
| Target table preparation mode | Do nothing |
| Include LOB columns in replication | Limited LOB mode |
| Max LOB size (KB) | 32 |
| Enable validation | Unchecked |
| Enable CloudWatch logs | Checked |
在表映射方面，我们可以这样设定，就不进行表名的转换了，然后创建任务即可。
| Parameter | Value |
|---|---|
| Schema | Tecno |
| Table name | % |
| Action | Include |
4、检查目标库数据
可以看到，迁移任务完成，数据也都转移过来了。
至此我们完成了异构数据库迁移，整个过程会比同构数据库迁移麻烦一些，不过整体也是比较简单了。DMS 完全托管、按量付费、图形界面操作，是数据库上云的利器，推荐大家使用 DMS 对数据库迁移上云。
三、总结
AWS 数据库优势
在众多的云厂商中，我们为什么选择 AWS 数据库服务，AWS 还有哪些独特的优势呢？我主要总结以下几点：
成本优势
使用自建数据，企业首先需要支付一笔资金购买服务器，一些商业数据库的授权，需要再次支付一笔费用。如果迁移到 AWS 的自研数据库，客户不必再支付高昂的商业数据库授权，也不必再去花费大量资金去购买服务器，在云中，客户只需要按量付费，因此很多企业由于把数据库迁移到 AWS 而节省巨大费用支出。
从最近的 AWS 公告中，看到 AWS 帮助三星把数据从商业数据库 Oracle 迁移到了 Aurora，为三星每月的数据库成本降低了 44%，并让三星的数据库运行更加稳定。
完全托管
以上所说的几种数据库都是 AWS 完全托管的数据库，完全托管意味着零运维。首先客户不需要去维护硬件的生命周期、系统的补丁更新、高可用的部署、备份等。如果需要对数据库扩展，也只需点几下鼠标而已，非让方便，让 DBA 从复杂的数据库运维中解脱出来，专注于数据库性能调优。
全球优势
过去我们需要借助非常复杂的技术手段，花费大量的成本、甚至牺牲一定的可用性，才能实现快速、稳定、安全的跨区域的数据复制，现在只要在 AWS 云中轻轻点几下鼠标即可完成。
AWS 云现已在全球 24 个地理区域内运营着 77 个可用区，180个边缘站点等，为 AWS 相应全球数据库提供了基础保障。依托于 AWS 强大的基础设施，目前已经有三款数据库支持全球同步，延迟通常不超过 1 秒，可以满足目前大部分应用的需求。
对于关系型数据库的全球同步需求，Amazon Aurora Global Database 能够允许用户轻松实现跨区域的数据库部署，让用户轻松在区域之间复制数据和解决更新冲突，从而更加专注于应用程序的业务逻辑。
AWS 还提供了 Amazon DynamoDB Global Tables。它基于 DynamoDB 的全球覆盖范围构建，具有多区域、多主表的特性，可让全局分布式应用程序实现快速的本地读写性能，为用户提供一个完全托管的、多区域、多主的 Key-Value 类型数据库。
针对缓存数据库，在众多组织都在利用 Redis 为全球用户提供低延迟访问的背景下，AWS 为更好满足客户的需求，AWS 推出了 Amazon ElastiCache Global Datastore for Redis 全球缓存数据库，为用户提供数据跨区域复制，可以在一个区域写入数据，同时在其他区域读取数据，使缓存的数据更接近用户，减少网络延迟，并提高应用程序的响应能力。
心得与建议
当然，数据库迁移是一个庞大而复杂的工程，尤其将数据库迁移上公有云，除了数据库知识更需要了解公有云上网络，存储，虚拟化等一系列知识。但是，我们不应该仅仅将数据库上云看做一个复杂的任务，更应该把它当做一个优化我们数据库的契机，那么上云过程中有哪些注意事项和建议呢？
对于一些允许停机的应用，这部分数据我们推荐使用离线迁移，整个操作比较简单，速度快，不容易出问题。
如果业务需要在线迁移，那么推荐使用 DMS 进行迁移，需要注意的是，在数据库切换之前先停掉源数据库写入，带数据完全同步到目标数据库之后进行数据库切换。
如果迁移的数据量比较大，建议选择配置比较大的复制实例，这样可以加速我们的复制速度。
如果您想要转换数据库引擎，在使用 SCT 进行 Schema 转换的时候可能会遇到一些目标数据库不支持的地方，请先联系 DBA 人员，对这些地方进行更改，满足之后再进行转换。
