精通某项技术会让您如虎添翼。精通一门技术后，您就能正确驾驭它，尽享其带来的诸多优势。当大规模使用该技术时，您也能从容应对各种意外状况。
然而，再成熟的技术也总有被淘汰的时候。随着技术浪潮的翻涌更迭，您也要紧跟时代步伐，不断更新技术架构。云计算是近几十年 IT 领域最具革命性的技术浪潮，它掀起了一场自上而下、全方位的应用程序架构变革，也深刻影响了数据库的选型和使用。传统数据库普遍采用静态、本地部署的架构，适合服务少量用户，但在如今云时代大背景下，面对海量且遍布全球的用户群，这种架构已经力不从心。
现在是时候抛开传统数据库的束缚，迎接云原生数据库的崭新时代了。
点击以下选项卡，了解云原生数据库为何能更好地满足现代应用程序的需求。
-
节省许可和运维成本
-
云原生设计助力性能优化
-
提升开发效率
-
节省许可和运维成本
-
商业关系型数据库通常需要支付高昂的年度许可费用。不管实际使用情况如何，这些许可证费用通常是固定的。等到应用被某个商业数据库“套牢”后，厂商就会利用自己的垄断地位，施加种种霸王条款。
不仅如此，许可协议中的附加条款还可能限制您灵活扩缩容数据库的能力。弹性扩缩是云的核心优势之一，因为您可以按需调整计算和存储资源，在满足用户需求的同时，还能有效控制企业的 IT 支出。
而 Amazon Aurora、DynamoDB 等云原生数据库完全免除了高昂的年度许可费，用户只需为实际使用的容量和资源付费。这种模式可将前期大额资本支出转变为灵活的运营支出，让企业的投入产出比更加合理。
使用 Aurora 时，数据库存储容量可随着用量自动弹性扩展，不必再为应对流量突增而一次性采购过量存储。整个过程无需人工介入，存储会自动按需扩容，与应用程序始终保持同步。
DynamoDB 则实现了完全的按需付费，企业只需为应用程序实际消耗的资源付费。相比为 CPU 和内存付费，DynamoDB 采用了更灵活的读写单元定价。这免去了容量规划中不确定的因素和复杂的成本核算，让您只需专注于应用程序本身。
-
云原生设计助力性能优化
-
传统数据库的架构原本就是面向静态环境设计的。这种数据库假定企业只在每季度或每年进行一次容量评估，并按照评估结果采购配置。一旦真实流量不及预期，过剩的资源就会被浪费。如果流量超出预估，系统性能就要打折扣。
而诸如 Aurora、DynamoDB 这类云原生数据库，从一开始就是为云的动态弹性环境量身打造的。它们能够按需扩容，轻松应对流量突增。
Aurora 搭载专为云优化的存储引擎，可最大化发挥云的优势。Aurora 存储引擎横跨多个 AWS 可用区，实现了最大程度的可用性和持久性。每次对 Aurora 数据库的写入操作，都会被同步写入 6 个存储节点，形成六副本。这种基于 Redo 日志的创新架构，在提升性能的同时，大幅降低了 IOPS 成本。
DynamoDB 就是专为无限扩展而设计的。在全球范围内，DynamoDB 支撑起了一些体量最大的在线业务，包括 Lyft 出行、Airbnb 民宿以及 Capital One 网银等。DynamoDB 的设计理念源自 Amazon 工程师在构建和扩展 Amazon.com 全球零售平台过程中积累的宝贵经验。这些经验最终孕育出了一款全托管的、高可扩展以及高性能的 NoSQL 数据库，受到了众多初创公司和大型企业的追捧。
-
提升开发效率
-
在现代开发实践中，开发人员的敏捷性至关重要。面对日新月异的市场需求，您必须要能快速适应和持续迭代。
想要在团队壮大后继续保持敏捷，微服务架构是一种行之有效的做法。在微服务架构下，您可以将应用程序拆分成多个小组件，每个组件可单独部署和扩展。
在微服务架构中，服务之间往往需要通过异步的方式共享数据。像 Aurora、DynamoDB 这样的现代化数据库，提供了变更数据捕获 (CDC) 机制，大大简化了微服务之间的数据共享。Aurora 支持逻辑复制数据库中的数据变更。DynamoDB 用户则可以使用 DynamoDB Streams 捕获表级别的数据变更。这些功能可以让我们在微服务架构中更轻松地共享海量数据。
在从传统数据库迁移至云原生数据库的过程中，您应该仔细权衡各种选择，综合考虑各方因素。其中最关键的两点，一是要选择哪种云原生数据库，二是数据迁移的实施过程。
-
选择合适的云原生数据库类型
-
选择合适的迁移流程
-
选择合适的云原生数据库类型
-
选择云原生数据库时，首先需要考虑的因素就是数据库类型。
近年来，传统关系型数据库的主导地位正受到新兴 NoSQL 数据库的挑战。DynamoDB 等 NoSQL 数据库应运而生，它们致力于解决互联网时代和全球化浪潮带来的海量数据挑战。如今，应用程序服务的地域界限已经被彻底打破。现代应用程序动辄百万千万用户的体量需要全新的数据库架构来应对。
NoSQL 数据库为了追求极致的扩展性，通常会摒弃关系型数据库的某些特性，比如严格的模式 (Schema)、外键约束以及 JOIN 等 SQL 操作。事实上，这些功能在大规模应用程序中往往会成为性能瓶颈，使得开发者不是主动禁用，就是被迫弃用。相比之下，NoSQL 数据库提供了一系列独特的功能，它们在性能上也有不同的表现。比如，NoSQL 支持将数据切片、分片到无数的物理节点，从而实现无缝扩展。
如果您想把传统关系型数据库迁移至 DynamoDB 这样的 NoSQL 数据库，那就需要重新设计数据模型以及应用程序代码。关系型数据库和 NoSQL 数据库在数据建模原则上可谓大相径庭。对广大企业来说，NoSQL 在性能提升和弹性扩容方面的巨大优势，足以弥补迁移过程中投入的时间成本。
但您大可不必把原有的数据模型全盘推翻重来。Amazon Aurora 是一款兼容 MySQL 和 PostgreSQL 的云原生关系型数据库。即便您当前正在使用商业关系型数据库，通常也能轻松地将数据及触发器、视图等数据库对象平滑迁移至 Aurora。这样您既能享受专为云而生的关系型数据库的种种优势，又省去了重新设计数据模型的繁琐。
您可以在 AWS 平台灵活组合使用 Aurora 和 DynamoDB，定制出最适合自身的云原生数据库方案。
-
选择合适的迁移流程
-
将现有数据库从传统架构迁移至云原生架构，是一个需要精心筹划、步步为营的过程。尽管云原生数据库有诸多优势，但在迁移过程中，必须慎之又慎、措置有方，确保将对用户的影响降至最低。
为了确保迁移成功，AWS 提供了一系列工具供您选择。首选之一便是 AWS Database Migration Service (AWS DMS)，它支持将您自托管的数据库无缝迁移至 AWS 全托管数据库中。通过 AWS DMS，您不仅可以在相同数据库引擎之间迁移，比如将自托管的 MySQL 迁移至 Amazon Relational Database Service (Amazon RDS) 上的 MySQL，还能实现不同数据库引擎之间的迁移，比如将商业数据库 Oracle 迁移至云原生的 Aurora，甚至可以从关系数据库迁移至非关系数据库。AWS 还提供 AWS Schema Conversion Tool (AWS SCT)，用于在不同数据库引擎之间转换数据库模式。
此外，如果您在迁移途中遇到困难，AWS 还提供了多种形式的支持。对于符合条件的客户，Database Freedom 计划和 Amazon Database Migration Accelerator (DMA) 解决方案可提供专家咨询和迁移指导。利用数据库迁移专家的知识，帮助您实现无缝迁移。
最后，如果您需要迁移方面的实践指导，AWS Professional Services 团队可随时为您提供协助。AWS Professional Services 团队可以帮助您制定完善的迁移计划并付诸实施，确保万无一失。此外，AWS 在全球还有众多 Database Freedom 合作伙伴可为您提供迁移支持。
本教程接下来的内容将循序渐进地教您如何将传统关系型数据库迁移至 AWS 云原生数据库。