Venmo 迁移到亚马逊 DocumentDB 的流程（兼容 MongoDB）

这是一篇客座文章，由PayPal Inc.的技术人员2成员、数据库工程师库沙尔·沙阿和Venmo的高级软件工程师Puneeth Melavoy撰写。这篇文章中的内容和观点是第三方作者的内容和观点。

Venmo 创立的原则 是打破围绕金融交易的令人生畏的壁垒，使其变得直观、友好甚至有趣。它奏效了：人们喜欢用Venmo汇款，而且我们正在突飞猛进地发展！

有关更多详细信息，请参阅 Venmo 统计与事实 。

但是我们才刚刚开始。我们想利用使用Venmo汇款的魔力，将其扩展到人们使用金钱的每个地方。这意味着尽可能以最直观、最有趣的方式将人们与他们的钱联系起来，然后将人们彼此联系起来。

Venmo在2021年的总支付量同比增长了44％。流量增长和新产品功能带来了许多可扩展性挑战，包括我们的数据存储面临的挑战。其中一个数据存储是 MongoDB，它在我们的应用程序堆栈中起着关键作用，因为它用于面向客户的用例，例如支付交易风险分析，以及客户支持门户等内部工具。

随着增长和新功能的部署，我们必须不时地横向和纵向扩展我们现有的文档数据库集群。为了为进一步增长做好准备并为我们的用户提供最佳性能，我们开始研究大规模解决方案。我们考虑的一些选项是：

  • 在 MongoDB 上为我们一些最大的集合实现分片并横向扩展
  • 将集合迁移到另一个键值存储

这两个选项都需要进行一些改造，在考虑了所有因素之后，我们决定将 35 个馆藏迁移到 亚马逊 DocumentDB（兼容 MongoDB） 。 在我们的迁移计划中，我们涵盖了从一个数据存储迁移到另一个数据存储的四个重要方面：

  • 应用程序和功能兼容性
  • 数据迁移策略
  • 切换计划
  • 回滚策略

在这篇文章中，我们将详细讨论我们在几乎为零的停机时间内将 35 个馆藏从源文档数据库迁移到 Amazon DocumentDB 的方法。在这篇文章中，我们分享了我们的迁移策略、我们面临的挑战和经验教训。

应用程序和功能兼容性

对于从一个数据存储到另一个数据存储的任何迁移，研究和验证应用程序要求和逻辑以确定任何功能是否需要更新或变通办法非常重要。由于亚马逊 DocumentDB 与 Apache 2.0 开源 MongoDB 3.6、 4.0 或 5.0 API 兼容，因此应用程序方面所需的更改极其有限。该过程的一部分是审查 支持的 MongoDB API、操作和数据类型 ， 以及 M ongoDB 和 DocumentDB 之间的 功能差异 。

就我们的使用而言，我们唯一需要做的更新是稀疏索引。Amazon DocumentDB 支持稀疏索引，但要求在索引涵盖的字段上使用 $ex ists 子句。如果您省略 $exists ，则 亚马逊文档数据库不会使用稀疏索引。因此，我们要么修改了应用程序代码以在查询中使用 $exists 子句，要么更新了索引类型。

数据迁移策略

在开始数据迁移之前，我们在 Amazon DocumentDB 中创建了新的集合，并使用索引 迁移 工具创建了预先创建的 索引。 我们将数据迁移视为一个由两部分组成的过程。我们首先将所有当前数据从源数据迁移到 Amazon DocumentDB，然后实施了一种机制，使数据从源头同步到 Amazon DocumentDB。考虑到收集规模和吞吐量，我们要么使用 在线方法，要么使用混合方法 进行数据迁移。

对于大多数馆藏来说，在线迁移方法对我们来说效果很好。在这种方法中，我们使用了 亚马逊云科技 Database Migration Servic e (亚马逊云科技 DMS) 来执行完整数据加载并使用 亚马逊云科技 DMS 更改数据捕获 (CDC) 模式保持数据同步。下图说明了在线迁移方法及其工作流程。

Online Migration Approach

在线迁移方法

下图说明了混合迁移迁移方法及其工作流程。

Hybrid Migration Approach

混合迁移方法

切换计划

Amazon DocumentDB 使用的底层实现与其他文档数据库不同，可以表现出不同的性能特征。我们证实，我们没有使用任何特别指出的 Amazon DocumentDB 不支持的案例，但我们仍然希望防止迁移过程中的性能下降。尽管我们针对读取和写入场景对 Amazon DocumentDB 进行了性能测试，但性能测试环境并没有 100% 覆盖我们的功能。存在读取回归的可能性，因此为了防范这种情况，我们提前单独提高了读取量。

由于我们决定先提高读取率，因此我们需要了解任何先写后读的用例，以及由于源和 Amazon DocumentDB 之间的数据延迟而对这些用例的影响。根据读取用例的要求，我们将集合分为两种不同的场景：

  • 没有写后读用例的集合
  • 具有 “先写后读” 用例的集合

根据馆藏所处的情况，我们使用了不同的切换策略。此外，我们不是一次迁移所有集合，而是逐步迁移集合，一次以 3-5 个集合为一组。

没有写后读用例的集合

66% 的馆藏属于这种情况，即集合要么没有先写后读的用例，要么通过 亚马逊云科技 DMS 管道在源和 Amazon DocumentDB 之间的数据延迟在相应馆藏所需的 SLA（服务等级协议）之内。

对于这些集合，在将写入流量切换到亚马逊文档数据库之前，我们首先将所有读取流量迁移到亚马逊 DocumentDB，以验证 Amazon DocumentDB 上的任何性能下降。为了验证读取性能，我们依赖于读取延迟、平均查询运行时间等指标。验证读取性能后，我们切断了 Amazon DocumentDB 的写入流量。下图说明了这个过程。

Scenario 1

场景 1

具有 “先写后读” 用例的集合

34% 的馆藏属于这种情况，即集合要么有先写后读的用例，要么源和 Amazon DocumentDB 之间通过 亚马逊云科技 DMS 管道的复制延迟略高于相应集合所需的 SLA。

对于这些馆藏，我们首先只将 1% 的读取流量迁移到了亚马逊 DocumentDB。这样做会带来写入后读取不一致的可能性，但为了获得完整的读取性能回归覆盖率，我们接受了这一点。验证读取性能后，由于存在先写后读限制，我们同时切断了 Amazon DocumentDB 的剩余读取和写入流量。下图说明了这个过程。

Scenario 2

场景 2

对于其中两个集合，我们必须避免将Amazon DocumentDB的读取流量增加1％，因为我们在测试期间观察到的错误数量相对较多。对于这两个集合，我们进行了大量测试以验证非生产环境中的读取性能，同时将 100% 的读取和写入流量迁移到了 Amazon DocumentDB。

通过将馆藏拆分为不同的转换场景，我们得以切断所有到 Amazon DocumentDB 的馆藏流量，而不会对面向客户的应用程序造成任何明显影响。此外，我们没有发现依赖这些集合的内部工具受到任何影响。

回滚策略

对于任何数据存储迁移，针对任何不可预见的情况制定回滚策略尤为重要。例如，在将操作手册从源数据库切换到 Amazon DocumentDB 时，您还应该有一本经过全面测试和验证的操作手册，以便从 Amazon DocumentDB 回滚到源数据库。

我们使用 亚马逊云科技 DMS 将数据从源代码复制到 Amazon DocumentDB，但是没有这样的第三方工具可以帮助将数据从 Amazon DocumentDB 复制到我们的源数据库。如果出现任何不可预见的功能或性能问题，如果我们必须将任何集合回滚到源数据库，则需要将所有数据从 Amazon DocumentDB 复制到源数据库。

由于缺少第三方工具，我们编写了一个内部脚本来从 Amazon DocumentDB 变更流中读取数据，并将最近的更改写回源代码。我们使用此脚本在写入流量切换后的至少 48 小时内保持数据从 Amazon DocumentDB 到源的同步。

摘要

通过本文中讨论的迁移方法，我们成功地将所有 35 个集合从源数据库迁移到 Amazon DocumentDB，停机时间几乎为零。通过将此工作负载迁移到亚马逊 DocumentDB，Venmo 得以将总体成本降低50％。

如果您有任何评论或反馈，请将其留在评论部分。

作者简介

Puneeth Melavoy 是 Venmo 的高级软件工程师。他是核心平台团队的一员，负责在 Kubernetes 云基础架构上开发和管理应用程序。他热衷于构建高度可扩展和弹性的云原生解决方案。

Kushal Shah 是 PayPal Inc. 的技术人员 2、数据库工程师。他热衷于构建和管理高度可用和可扩展的关系存储以及 NoSQL 数据存储。在加入PayPal之前，库沙尔曾在Auction.com和雅虎公司担任数据库工程师。

Jigar Mand li 是亚马逊网络服务的高级技术账户经理。作为 亚马逊云科技 企业支持团队的一员，他帮助客户使用最佳实践规划和构建解决方案，并保持其环境的健康运营。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。