迁移到亚马逊 DynamoDB 的动机

Amazon DynamoDB 是一个完全托管的、无服务器的键值型 NoSQL 数据库，在任何规模下都能实现个位数毫秒级的性能。DynamoDB 提供内置安全性、持续备份、自动多区域复制、99.999% 的可用性 SLA 以及数据导入和导出工具。

DynamoDB 是根据外部客户的需求和亚马逊内部的需求建立的，目的是克服关系数据库的规模和运营缺陷，摆脱惩罚性且昂贵的旧式关系数据库许可证。DynamoDB 专为需要在任何规模下保持稳定性能的运营工作负载而构建和优化。这意味着，例如，对于拥有 10 个用户的购物车用例，DynamoDB 提供的稳定的个位数毫秒性能与为 1 亿用户提供的性能相同。这就是为什么 DynamoDB 可以在疫情期间为 Zoom 提供支持，因为他们从每日 1000 万用户扩展到每日 3 亿用户。对于像 Zoom 这样的客户来说 ，这是 30 倍的规模，无需重新架构或过度配置硬件。

在首次推出十一年后，DynamoDB 仍在帮助客户摆脱关系数据库的束缚，同时降低成本并大规模提高性能。DynamoDB 拥有成千上万的客户，继续以惊人的速度增长，并且几乎为各种规模、行业和地域的客户提供服务。

尽管自2012年以来向DynamoDB的关系和NoSQL迁移一直保持稳定，但当前的经济趋势加速了此类迁移。迁移到 DynamoDB 的关键动机是降低成本，同时简化操作并大规模提高性能。DynamoDB 使您能够腾出资源，为客户增加收入和价值做出贡献。DynamoDB 的无服务器架构使您能够通过按请求付费、扩展到零等功能来节省成本，而且无需预付费用。在运营方面，无需处理资源扩展、维护窗口或主要版本升级，可以节省大量的运营时间，并消除无差别的繁重工作。总体而言，DynamoDB 提供了一种成本优化的方法来构建创新和颠覆性解决方案，提供差异化的客户体验。

在这篇文章中，我们将讨论向 DynamoDB 的常见迁移类型、向 DynamoDB 的迁移如何帮助客户节省时间和金钱、DynamoDB 如何帮助降低成本和运营，以及迁移到 DynamoDB 的方法。

向亚马逊 DynamoDB 迁移的常见类型

多年来，许多客户已将其任务关键型传统应用程序迁移到 DynamoDB。迁移到 DynamoDB 的常见来源包括：

  • 传统关系数据库 -从关系数据库迁移到 DynamoDB 的动机通常是需要比关系数据库管理系统 (RDBS) 所能提供的更稳定的大规模性能。此外，您可以摆脱传统数据库的束缚，从而节省许可证、超额配置的资源和运营成本。
  • NoSQL 数据库 — 从其他 NoSQL 数据库迁移到 DynamoDB 的动机是希望利用其云原生功能，例如其完全托管的无服务器架构、全局表、自动扩展、无影响备份以及与其他 亚马逊云科技 服务的集成。我们还看到，客户超额配置了他们自行管理的 NoSQL 数据库，以应对应用程序增长和数据紧缩。DynamoDB 基于使用量的定价和扩展到零的功能使这些客户能够降低总拥有成本。
  • 本地数据库 -从本地数据库（关系数据库或 NoSQL）迁移到 DynamoDB 的动机是希望迁移到基于云的无服务器架构，以提高灵活性、可扩展性和成本效益。您可以利用 DynamoDB 的完全托管功能，无需本地硬件和基础架构，从而降低成本。

以下是迁移到 DynamoDB 的其他好处：

  • 提高了性能和可扩展性 — DynamoDB 以稳定的低延迟处理大量数据和高流量负载，使其成为需要快速、可靠地访问数据的应用程序的绝佳选择。
  • 降低成本 — 作为一项完全托管的服务，DynamoDB 使您无需管理自己的硬件和基础架构，从而降低成本并简化管理。
  • 提高灵活性 — 通过迁移到 DynamoDB，您可以利用 亚马逊云科技 云的可扩展性和灵活性，使您能够快速轻松地适应不断变化的业务需求。例如，像 Branch 这样的客户能够在几分钟内 扩展到以前容量的 40 倍 ，而无需重新设计应用程序。使用 DynamoDB，您无需花时间确定实例类型、实例大小、维护时段或数据库版本。

移民工作需要仔细的规划和实施，以确保取得成功的结果。迁移到 DynamoDB 包括评估现有的数据模型、了解访问模式、设计针对性能进行了优化的适当架构以及确定规模和成本要求。解决方案设计还应考虑数据安全性、合规性和监管要求，并应使用 DynamoDB 的原生功能来缩短上市时间。

有关向 DynamoDB 迁移的客户案例

多年来，有多个客户通过迁移到 DynamoDB 来降低成本的例子。我们在本节中介绍几个。

SmugMug

SmugMug 从传统的 MySQL 数据库迁移到 DynamoDB，以提高其照片共享平台的可扩展性和性能。SmugMug 最初将其 MySQL 数据库重新设计为键值存储，但很难实现大规模的可预测响应时间。SmugMug 正在经历显著增长，需要更具可扩展性的解决方案来处理不断增长的数据量和流量负载。

迁移到 DynamoDB 后，无论存储量如何，SmugMug 的性能和可预测的查询响应时间都得到了显著改善。DynamoDB 的灵活性允许 SmugMug 在 1 年内将 Flickr（由 SmugMug 收购）从雅虎数据中心迁移到 亚马逊云科技 云端。SmugMug 将 Flickr 的数百 PB 数据、数百亿张照片和超过 1 亿用户迁移到了 DynamoDB 和其他 亚马逊云科技 服务。如果您在 Flickr 上查看照片，则表示您正在与 DynamoDB 进行互动。要了解完整故事，请参阅 亚马逊 DynamoD B 的十年创新 。

益百利

益百利采用云优先的方法，从微软 SQL Server 迁移到 DynamoDB，以构建微服务驱动的架构，以实现可扩展性、灵活性和安全性。益百利扩展了其客户服务平台，以支持每年增长 50-75% 的数据量，在没有显著开销或延迟的情况下处理数 TB 的存储。

此外，凭借其灵活的成本模型，DynamoDB 帮助益百利节省了在硬件、软件、网络和存储方面的大量资本投资。使用 DynamoDB 进行开发的简单性使益百利能够将其部署时间从几天缩短到几小时。 阅读完整案例研究 以了解更多信息。

三星云

三星云从 Cassandra 迁移到 DynamoDB，以提高运营效率并降低支持三星 Galaxy 智能手机备份和恢复功能的三星云服务的成本。三星云正在经历与管理其Cassandra集群相关的巨大运营开销和成本，因此需要更高效、更具成本效益的解决方案。

迁移到 DynamoDB 后，三星云显著提高了运营效率，降低了成本和复杂性。他们还体验到了可扩展性的提高、每天数千万次操作的稳定性能以及节省 40% 的成本。要了解更多信息，请参阅 将 Galaxy 迁 移到云端：三星关于迁移到亚马逊 DynamoD B 的最佳实践 。

保管箱

Dropbox 将其四分之一的元数据存储从使用分片 MySQL 集群构建的本地分布式数据库 Edgestore 迁移到了 DynamoDB 和亚马逊 Simple Storage S ervice (Amazon S3) 上的生产就绪型云元数据 存储 区Alki。 元数据的快速增长需要一个高度可扩展但经济实惠的解决方案，Dropbox 可以在两年内实施该解决方案，并且仅需两种资源。

他们将热门元数据迁移到 DynamoDB，支持每张表每秒最多提取 6,000 次写入，每天最多存储 80 GB 的数据。DynamoDB 的可扩展性允许 Dropbox 在迁移期间以每秒 600,000 次查询的速度摄取数据，从而在不到 2 周的时间内完成 300 TB 数据的迁移。通过迁移到 DynamoDB，Dropbox 每年将每千兆字节的成本降低了 5.5 倍，此外还节省了数百万美元的本地数据中心的扩展成本。 阅读完整的案例研究 以了解更多信息。

神奇宝贝公司

神奇宝贝公司从第三方 NoSQL 文档存储迁移到了 DynamoDB 和亚马逊 Aurora 。 由于用户在 2 年内超过 3 亿，他们现有的 NoSQL 数据库需要 300 多台服务器，并面临操作和可靠性方面的挑战。为了消除无差别的繁重负担，神奇宝贝迁移到了 亚马逊云科技 完全托管的服务。

他们将全局配置和生存时间 (TTL) 数据迁移到 DynamoDB，以大规模实现个位数毫秒的性能。内置的 TTL 设置允许 PokémonCompany 跟踪超过最大登录尝试次数的用户并拒绝其进入，从而将机器人登录尝试次数减少了 90%，从而为合法用户腾出系统资源，无需过度扩展。 阅读完整案例研究 以了解更多信息。

分支

Branch 在第三方 NoSQL 键值存储方面面临挑战，即将其基础设施扩展到 60 个大型 亚马逊弹性计算云 (Amazon EC2) 实例以外，以应对 100 倍的流量增长。为了满足扩展需求并最大限度地降低基础架构的成本，Branch 将其托管 400 亿条记录的关键任务链接系统迁移到 DynamoDB。他们的主要要求是扩展存储和吞吐量，提高可靠性和耐久性，减少开支，并建立可预测的成本模型。

迁移到 DynamoDB 将可用性提高了 33%，在几分钟内将吞吐量提高了 40 倍，使他们能够预测增长 10 倍的成本，同时将成本降低 66%。要详细了解他们的迁移历程，请参阅 从零到 400 亿个链接：我们迁移到 DynamoD B 的旅程 。

信任飞行员

Trustpilot 是一个拥有超过 1 亿条评论的在线评论平台，它从 MongoDB 迁移到 DynamoDB，以适应具有高可扩展性要求的访问模式。Trustpilot 的迁移是使用 亚马逊云科技 专用数据库的典型示例。随着时间的推移，DynamoDB 成为他们的首选数据库，超过 144 个生产表支持各种访问模式。

通过使用适当的数据建模技术，Trustpilot 可以实现高可扩展性、提高性能和降低成本。要了解更多信息，请参阅 亚马逊 DynamoDB：无服务器世界中数据库的不为人知的故事 。

Snapcha

Snapchat 将其关键存储用例从谷歌云平台迁移到了 DynamoDB。该团队的目标是降低成本，并战略性地扩展到GCP以外的云提供商以实现可扩展性。故事收件箱是故事帖子的集合，是 Snapchat 从 GCP 迁移到 DynamoDB 的关键但具有挑战性的功能之一，该功能旨在支持每秒数百万次写入，同时通过弹性架构节省大量成本。

Snapchat 将 100% 的用户迁移到 DynamoDB，该服务提供的可扩展性使他们能够支持除夕夜的高峰流量，无需运营商干预。通过此次迁移，Snapchat 消除了 GCP 产生的大部分存储和吞吐量成本，每年节省数百万美元。要了解更多信息，请参阅 亚马逊 DynamoDB 上的 Snapchat 故事 。

亚马逊

亚马逊将 Wallet（一项允许客户存储和支付订单的服务）从 Oracle 迁移到 DynamoDB。亚马逊每天的交易量达到50亿笔，需要简化扩展和存储管理，同时控制成本和持续保持较高的性能。为了支持其扩展需求，亚马逊纵向和横向扩展了其甲骨文数据库，但是在不停机的情况下实现这种规模非常耗时，而且每年需要熟练的工程师和数据库管理员团队工作6个月。

亚马逊通过使用 DynamoDB 的完全托管功能减少了对熟练 DBA 的需求。钱包团队在没有停机的情况下将 100 亿条记录从八个 Oracle 表迁移到六个 DynamoDB 表。这种迁移将平均延迟减少了50％，吞吐量提高了40％，并显著降低了基础设施成本。钱包团队还节省了他们之前在扩展和管理 Oracle 实例上投资的 90% 的时间。 阅读完整案例研究 以了解更多信息。

McAfee

McAfee 通过从传统的本地商业数据库迁移到 DynamoDB，实现了活动管理系统的现代化。活动管理系统通过个性化内容自动发送消息，每月有数亿次曝光量，并且已达到扩展其传统商业数据库的极限。

通过迁移到 DynamoDB，McAfee 扩展到每月处理 80 亿次读取操作和每月处理 20 亿次写入操作，并且它们继续支持当前数百万用户的订阅量同比两位数增长。此外，McAfee 每月在基础设施成本方面节省了 40% 的成本，同时减少了延迟，提高了可扩展性和可靠性。McAfee 的工程师现在花时间开发和推出新产品，使用完全托管的服务来消除无差别的繁重工作。 阅读完整案例研究 以了解更多信息。

以下是一些公开的例子；我们听说每天都有更多客户从 DynamoDB 的简单性中受益。

DynamoDB 如何帮助降低成本

在本节中，我们将讨论 DynamoDB 中一些使您能够降低成本的内置功能。

按请求付费

DynamoDB 按请求付费的定价模型允许您仅为实际向表发出的读写请求付费。使用这种定价模式，您不必担心闲置容量，因为您只需为实际使用的容量付费。

按请求付费定价有利于工作负载高峰期的应用程序，在这些应用程序中，传统的定价模式要求您为高峰使用量预置容量，从而导致在使用率较低的时期出现未使用的容量。对于具有稳定状态工作负载的客户，带有 Auto Scaling 的预置容量提供了进一步优化成本的选项。DynamoDB 中的 自动扩展 功能允许您自动向上或向下扩展容量以满足应用程序的实时需求。自动扩展使您无需干预，因为您不必手动管理和调整容量，这可能既耗时又昂贵。

按 GB 付费的存储空间

使用按GB计费的存储定价，您只需为实际使用的存储空间付费，无需过度配置存储空间。您从少量的存储空间开始，然后随着数据的增长而向上扩展。自动扩展存储空间可帮助您避免为不需要的存储付费，这可以节省大量成本。

DynamoDB 的每 GB 定价模式提供较低的存储成本，特别是对于大量数据，使您能够在保持应用程序性能和可靠性的同时降低总体存储成本。DynamoDB 会自动管理存储并根据需要进行扩展，从而帮助您节省管理和配置存储所需的时间和资源。凭借其生存时间 (TTL) 功能，DynamoDB 允许客户免费删除超过所需保留期的数据。DynamoDB 的每 GB 定价模式是一种灵活、经济实惠的数据库解决方案，适合希望降低存储成本和优化数据库成本的客户。

读取、写入和存储分离

DynamoDB 独立扩展读取吞吐量、写入吞吐量和存储。您可以控制读取和写入容量，以便根据访问模式预置和优化工作负载。DynamoDB 客户通常会在高使用率期间增加容量，然后在低使用率时将其缩减以优化成本。分离存储成本可以帮助您优化具有大量数据、可能不需要频繁读写的应用程序的成本。DynamoDB 推出了 标准不频繁访问 (IA) 等功能， 以帮助您节省此类工作负载的成本。

缩放到零

作为真正的无服务器数据库，DynamoDB 可以扩展到零。这意味着，如果没有使用按需容量模式对 DynamoDB 表发出请求，则您无需为吞吐量付费。扩展到零对于具有周期性和高峰工作负载的工作负载很有用，因为它允许您在使用率低的时期降低成本。当应用程序的流量增加时，DynamoDB 会自动调整容量以满足需求，确保应用程序响应请求。DynamoDB 能够扩展到零容量，可确保您为消耗的资源付费，同时仍提供处理不同流量水平所需的可扩展性和响应能力，从而帮助您降低成本。

更高的利用率

DynamoDB 允许您实现更高的容量利用率，从而节省成本。2023 年初，我们帮助客户从可扩展到峰值负载的自配置缓存集群转为 DynamoDB 按需定价，从而节省了 99% 的数据库成本。

由于 DynamoDB 可以实时扩展以适应负载，并在不再访问表时扩展到零，因此您可以降低总体成本。它的按需容量允许您仅为消耗的读取和写入容量付费，而不必预先为峰值容量进行预配置。此功能有助于显著降低访问模式不可预测的工作负载的成本，因为您只需为使用的容量付费，从而提高利用率和降低成本。通过使用高效的数据建模技术，Trustpilot 等客户通过设计针对访问模式进行优化的表来最大限度地减少读取和写入操作的数量，从而实现更高的利用率。

优化成本的功能

DynamoDB 提供了多种成本优化选项，例如为稳定的预置容量工作负载预留容量以获得高达 77% 的额外节省，标准不频繁访问可将包含不经常访问数据的表的成本降低多达 60%，以及无需预置备份容量即可创建备份的按需备份和恢复。TTL 通过自动删除不再需要的数据来降低存储成本，而无需为区域内删除支付额外费用。自动扩展和 预置容量 等功能旨在通过可预测的访问模式优化工作负载的成本，而 按需容量 模式则专为高峰工作负载而设计。通过允许您在这些模式之间无缝切换，DynamoDB 使您能够最大限度地节省任何工作负载的成本。

DynamoDB 如何帮助减少操作

我们的客户通常选择 DynamoDB 来提高开发人员的敏捷性，从而缩短上市时间。减少花在日常操作上的时间是这些客户的共同要求。以下是一些可帮助您减少运营和总体拥有成本 (TCO) 的内置功能：

  • 没有实例 — DynamoDB 的无服务器架构使您无需管理实例。您可以简单地创建表并开始使用它们，而不必预置实例。您不必担心管理底层基础架构、操作系统或软件堆栈，这样可以节省大量时间和金钱。要了解如何在不到 10 分钟的时间内创建和查询 DynamoDB，请参阅使用亚马逊 Dy namoDB 创建和查询 NoSQL 表 。
  • 没有维护窗口- 传统数据库需要维护窗口才能执行诸如软件更新、硬件升级和数据库维护之类的任务，这通常会导致停机和运营开销。DynamoDB 可自动应用更新，包括操作系统和数据库软件，无需停机或维护窗口。这不仅减少了软件更新的操作开销，还确保了数据库始终是最新和安全的。
  • 无需进行版本升级- 使用传统数据库进行 版本升级非常耗时，需要进行大量的测试和验证，然后才能投入生产。作为一项完全托管的服务，DynamoDB 无需您进行任何版本升级。DynamoDB 管理版本升级并处理无需您手动干预的数据库软件升级。DynamoDB 进行持续的维护和监控，以确保数据库的平稳高效运行并降低停机风险。
  • 没有查询处理器 — 与许多数据库不同，DynamoDB 没有复杂的查询处理器，也不会创建查询计划。这简化了服务使用并提高了性能，因为 DynamoDB 不会像其他数据库在规划和优化阶段那样花费处理时间。在调试期间，开发人员通常会花费大量时间来了解所选（或未选择）的查询计划，并确定查询性能大规模下降的原因。DynamoDB 为开发人员和 DBA 移除了这项任务，从而为您节省时间和成本。
  • 自动扩展 -自动扩展可自动调整预置容量以响应不断变化的应用程序流量模式，从而减少了手动容量规划和扩展的需求，这通常非常耗时且容易出错。由于 DynamoDB 会根据应用程序的峰值和下降情况动态调整容量，因此您可以保持应用程序的稳定性能，同时减少手动干预或调整的需求。您可以根据目标利用率定义扩展策略，在几秒钟内设置自动扩展，DynamoDB 会根据这些策略自动调整容量。

通过减少运营时间，您可以专注于开发应用程序和为客户创造价值，而不必担心管理底层基础架构。

迁移到 DynamoDB

确定要迁移到 DynamoDB 的工作负载后，了解迁移所涉及的阶段至关重要。迁移到 DynamoDB 涉及五个阶段。

第 1 阶段：开发心理模型

DynamoDB 是一个 NoSQL 数据库，专为在任何规模上提供稳定的性能而构建。从其他关系或非关系数据库迁移时，了解 DynamoDB 的工作原理并开发在 DynamoDB 上实现现有工作负载所需的思维模型至关重要。例如，将所有表从具有一对一映射的关系数据库迁移到 DynamoDB 表是一种反模式。迁移到 DynamoDB 时，务必考虑现有的访问模式并找出优化这些模式的机会。为了帮助关系开发者了解如何使用 DynamoDB 进行开发，请在《 揭穿亚马逊 DynamoDB 神话》上的 亚马逊云科技 Twitch 节目。

第 2 阶段：设计数据模型

使用 DynamoDB 进行数据建模是客户在迁移过程中花费大部分时间的领域（没错！）。高效的数据建模可帮助您以低成本实现最佳性能。读写访问模式、访问模式频率、数据基数、分区和排序键设计以及评估对全局二级索引 (GSI) 的需求是数据建模期间需要理解的一些常见主题。要了解有关使用 DynamoDB 进行数据建模的更多信息，请查看使用 Dyn amoDB 进行 数据建模研讨会 。 您还可以在 GitHub 上找到一些示例数据模型和源代码以开始使用 。

阶段 3：迁移数据

设计架构后，是时候确定将数据从源数据库迁移到 DynamoDB 的方法了。了解停机要求对于定义数据迁移解决方案非常重要：

  • 如果迁移不能容忍停机，并且源数据库中的多个表需要迁移到 DynamoDB 中的类似表中，那么 亚马逊云科技 数据库迁移服务 (亚马逊云科技 DMS) 是一个不错的选择。有关更多信息，请参阅 使用亚马逊 DynamoDB 数据库作为 亚马逊云科技 数据库迁移服务的目标 。
  • 如果迁移不能容忍停机，并且源数据库中的多个表需要迁移到单个或一组非规范化的 DynamoDB 表，则常见的设计方法是在切换之前将数据同时写入源数据库和 DynamoDB，这与亚马逊使用电子钱包的方法类似。
  • 如果停机时间是可以接受的，则可以在源数据库上构建 SQL 视图以合并表，使用 JOIN 将实体非规范化为单个结果集，并使用 亚马逊云科技 DMS 将视图的内容移至 DynamoDB 表。

阶段 4：迁移应用程序

不涉及真正的应用程序迁移，因为客户通常会开发新的应用程序来与 DynamoDB 交互。大部分应用程序现代化工作都利用此阶段作为机会，使用 AW S Lambda 开发微服务，并使用 Step Functions 协调这些 微服务 ，从而使您的整个软件堆栈无服务器。在此阶段，您可以使用 DynamoDB 开发工具包与 DynamoDB 表进行交互。此阶段相对简单，涉及使用从应用程序层到数据库的 CRUD 操作。 使用我们的 动手教程，使用软件开发工具包开始使用 DynamoDB。

阶段 5：操作工作负载

此阶段的目标是使您能够大规模操作 DynamoDB。了解要 监控 的 Amazon CloudWatch 指标 、确定 定价 、估算 预留容量需求 以及确定 成本 优化 方法 是此阶段的任务示例。

在设计数据模型和开发应用程序时，最佳做法是确保您的工作负载按照 亚马逊云科技 Well Architected Framework 进行架构。 DynamoDB 架构完善的镜头 可以帮助您审查工作负载并发现改进机会。

摘要

在这篇文章中，我们讨论了向 DynamoDB 的常见迁移类型，以及从关系和非关系数据库迁移到 DynamoDB 如何帮助您节省成本和减少操作，如一些客户示例所示。我们还讨论了迁移方法，并提供了资源来帮助您开始迁移到 DynamoDB。

您是否准备好升级应用程序以实现稳定的大规模性能，同时显著降低成本？ 现在就开始吧 。

作者简介

HeadShot Karthik Vijayraghavan Karthik Vijayraghavan 是 亚马逊云科技 DynamoDB 专业解决方案架构师的高级经理。他一直在使用 NoSQL 数据库帮助客户实现应用程序现代化。他热衷于解决客户问题，并热衷于提供具有成本效益、可大规模运行的解决方案。Karthik 的职业生涯始于开发 Web 和 REST 服务的开发人员，他非常注重与关系数据库的集成，可以与正在迁移到 NoSQL 的客户建立联系。

约瑟夫·伊齐奥雷克目前 是亚马逊网络服务的产品管理总监。Joseph 在关系和非关系数据库服务领域拥有十多年的工作经验，并拥有爱荷华州立大学的计算机工程博士学位。在 亚马逊云科技，Joseph 领导 DynamoDB 和 Keyspaces 的产品管理，此前曾领导亚马逊 DocumentDB 以及许多其他专门构建的数据库计划。