通过

将数据从 MongoDB 迁移到 Azure Cosmos DB for MongoDB 的迁移前步骤

  • 项目

适用对象： MongoDB

重要

在执行迁移前步骤之前，请完整阅读本指南。

本 MongoDB 迁移前指南是 MongoDB 迁移系列教程的一部分。 关键的 MongoDB 迁移步骤包括迁移前步骤、迁移步骤和迁移后步骤，如本指南所示。

从迁移前到迁移后的迁移步骤示意图。

迁移前步骤概述

在实际迁移任何数据之前，提前做出特定的迁移规划和决策至关重要。 此初始决策制定过程就是“迁移前”。

迁移前的目标是：

  1. 确保设置 Azure Cosmos DB 以满足应用程序的要求，以及
  2. 规划如何执行迁移。

按如下所述执行全面的迁移前步骤

  1. 发现现有的 MongoDB 资源并评估现有 MongoDB 资源的数据迁移准备情况
  2. 将现有的 MongoDB 资源映射到新的 Azure Cosmos DB 资源
  3. 在开始执行全规模的数据迁移之前规划迁移过程的端到端后勤工作

然后，根据迁移前计划执行迁移。

最后，执行关键的迁移后切换和优化步骤。

上述所有步骤对于确保迁移成功都至关重要。

规划迁移时，建议尽可能地在每个资源的级别进行规划。

迁移前的评估

迁移前的第一个步骤是发现现有的 MongoDB 资源，并评估资源的迁移准备情况。

发现过程涉及创建包含 MongoDB 数据资产中现有资源（数据库或集合）的综合列表。

评估涉及确定是否正在使用受支持的功能和语法。 它还包括确保遵循限制和配额。 此阶段的目的是创建不兼容问题和警告列表（如有）。 得出评估结果后，可以尝试在迁移规划的其余部分中处理结果。

有 3 种方法可以完成迁移前评估，我们建议使用 Azure Cosmos DB Migration for MongoDB 扩展。

Azure Cosmos DB Migration for MongoDB 扩展

Azure Data Studio 中的 Azure Cosmos DB Migration for MongoDB 扩展可帮助你评估 MongoDB 工作负载是否适合迁移到 Azure Cosmos DB for MongoDB。 可以使用此扩展对工作负载运行端到端评估，并找出在 Azure Cosmos DB 上无缝迁移工作负载可能需要执行的操作。 在评估 MongoDB 终结点期间，该扩展会报告发现的所有资源。

注意

我们建议你详细了解受支持的功能和语法以及 Azure Cosmos DB 限制和配额，并在实际迁移之前执行概念证明。

手动发现（旧式）

或者，你可以创建一个数据资产迁移电子表格。 此电子表格的目的是提高工作效率，帮助你规划端到端迁移，并在整个迁移过程中用作跟踪文档。

  • 此电子表格包含 MongoDB 数据资产中现有资源（数据库或集合）的综合列表。
  • 电子表格应采用列表形式的结构，其中记录数据资产资源。
  • 每行对应于一个资源（数据库或集合）。
  • 每列对应于资源的一个属性；至少以名称和数据大小 (GB) 作为列的开头。
  • 在完成本指南的过程中，需要将此电子表格构建为端到端迁移规划的跟踪文档，并根据需要添加列。

下面是可用于发现资源的一些工具：

请浏览该电子表格，根据受支持的功能和语法以及 Azure Cosmos DB 限制和配额中的详细说明验证每个集合。

数据库迁移助手实用工具（旧式）

注意

数据库迁移助手是一个旧式实用工具，旨在帮助你完成迁移前的步骤。 我们建议你使用 Azure Cosmos DB Migration for MongoDB 扩展来完成所有迁移前步骤。

你也可以使用数据库迁移助手 (DMA) 实用工具来帮助完成迁移前的步骤。

迁移前的映射

发现和评估步骤完成后，方程的 MongoDB 一端的准备工作现已完成。 现在可以规划方程的 Azure Cosmos DB 一端。 你计划如何设置和配置生产 Azure Cosmos DB 资源？ 在每个资源的级别进行规划 – 这意味着，应将以下各列添加到规划电子表格中：

  • Azure Cosmos DB 映射
  • 分片键
  • 数据模型
  • 使用专用吞吐量还是共享吞吐量

以下各部分提供了更多详细信息。

容量计划

正在尝试为迁移到 Azure Cosmos DB 进行容量计划？

使用 Azure Cosmos DB’s API for MongoDB 时的注意事项

在规划 Azure Cosmos DB 数据资产之前，请确保了解以下 Azure Cosmos DB 概念：

  • 容量模型：Azure Cosmos DB 上的数据库容量基于吞吐量模型。 此模型基于每秒请求单位数，此单位表示每秒可对集合执行的数据库操作次数。 可以在数据库或集合级别分配此容量，也可以在分配模型中进行预配，或者使用自动缩放预配的吞吐量。
  • 请求单位：在 Azure Cosmos DB 中，每个数据库操作都有关联的请求单位 (RU) 成本。 执行操作时，将从在给定的秒可用的请求单位级别中减去此请求单位。 如果请求所需的 RU 数超过了当前分配的每秒 RU 数，可以使用两个选项来解决此问题 - 增加 RU 数量，或等待下一秒开始，然后重试操作。
  • 弹性容量：给定集合或数据库的容量随时可以更改。 这种灵活性允许数据库弹性适应工作负荷的吞吐量要求。
  • 自动分片：Azure Cosmos DB 提供一个仅需要分片（或分区键）的自动分区系统。 自动分区机制在所有 Azure Cosmos DB API 之间共享，允许通过水平分配进行无缝的数据缩放和全面缩放。

规划 Azure Cosmos DB 数据资产

确定要创建的 Azure Cosmos DB 资源。 此过程要求执行数据资产迁移电子表格中的每个步骤，并将每个现有 MongoDB 资源映射到新的 Azure Cosmos DB 资源。

  • 预计每个 MongoDB 数据库都将成为 Azure Cosmos DB 数据库。
  • 预计每个 MongoDB 集合都将成为 Azure Cosmos DB 集合。
  • 选择 Azure Cosmos DB 资源的命名约定。 保留相同的资源名称通常是很好的做法，除非数据库和集合的结构发生了任何改变。
  • 确定你要在 Azure Cosmos DB 中使用分片集合还是未分片集合。 未分片集合的大小限制为 20 GB。 另一方面，分片有助于实现横向缩放，这对于许多工作负载的性能至关重要。
  • 如果使用分片集合，请不要假设 MongoDB 集合分片键会变为 Azure Cosmos DB 容器分区键。 不要假设现有的 MongoDB 数据模型文档结构应与你在 Azure Cosmos DB 上使用的模型相同。
    • 分片键是用于优化 Azure Cosmos DB 可伸缩性和性能的唯一最重要设置，数据建模是第二重要的设置。 这两个设置都是不可变的，且在设置后不可更改；因此，在规划阶段对其进行优化极其重要。 有关详细信息，请参阅不可变决策部分中的指导。
  • Azure Cosmos DB 无法识别某些 MongoDB 集合类型，例如有上限的集合。 对于这些资源，只需创建常规的 Azure Cosmos DB 集合即可。
  • Azure Cosmos DB 本身有两种集合类型 - 共享吞吐量和专用吞吐量。 使用共享吞吐量还是专用吞吐量是另一个关键的不可变决策，必须在规划阶段做出该决策。 有关详细信息，请参阅不可变决策部分中的指导。

不可变决策

创建 Azure Cosmos DB 资源后无法修改或撤消以下 Azure Cosmos DB 配置选择；因此，在开始执行任何迁移之前，在迁移前规划期间正确选择这些配置非常重要：

拥有成本

估算吞吐量

  • 在 Azure Cosmos DB 中，吞吐量是提前预配的，按每秒请求单位 (RU) 数计量。 不同于 VM 或本地服务器，RU 随时可以轻松纵向扩展和缩减。 可以即时更改预配的 RU 数。 有关详细信息，请参阅 Azure Cosmos DB 中的请求单位。

  • 可以使用 Azure Cosmos DB 容量计算器来确定应使用的请求单位数。 此数值基于你的数据库帐户配置、数据量、文档大小以及所需的每秒读写次数。

  • 下面是影响所需 RU 数的关键因素：

    • 文档大小：随着项目/文档大小的增大，读取或写入该项目/文档所要消耗的 RU 数也会增加。

    • 文档属性计数：创建或更新文档所消耗的 RU 数与该文档的属性数目、复杂性和长度相关。 可以通过限制已编制索引的属性数目，来减少写入操作的请求单位消耗量。

    • 查询模式：查询的复杂性会影响查询消耗的请求单位数。

  • 了解查询成本的最佳方式是使用 Azure Cosmos DB 中的示例数据，并在 MongoDB Shell 中使用 getLastRequestStastistics 命令运行示例查询以获取请求开销，此命令将输出消耗的 RU 数：

    db.runCommand({getLastRequestStatistics: 1})

    *此命令将输出类似于以下示例的 JSON 文档：

    {
  "_t": "GetRequestStatisticsResponse",
  "ok": 1,
  "CommandName": "find",
  "RequestCharge": 10.1,
  "RequestDurationInMilliSeconds": 7.2
}

  • 也可以使用诊断设置来了解针对 Azure Cosmos DB 执行的查询的频率和模式。 可将诊断日志中的结果发送到存储帐户、事件中心实例或 Azure Log Analytics。

迁移前的后勤规划

最后，在获得现有数据资产的视图和新 Azure Cosmos DB 数据资产的设计后，接下来可以规划如何端到端执行迁移过程。 同样，应在每个资源的级别进行规划，在电子表格中添加列以捕获本节中包含的逻辑维度。

执行后勤

  • 分配将每个现有资源从 MongoDB 迁移到 Azure Cosmos DB 的责任。 由你决定如何应用团队资源来引导迁移的完成。 对于小规模迁移，可以让一个团队开始整个迁移并监视其进度。 对于较大规模的迁移，可以按资源为团队成员分配迁移和监视该资源的责任。
  • 分配迁移资源的责任后，现在应选择适当的迁移工具进行迁移。 对于小规模迁移，你可以使用一种迁移工具（例如 MongoDB 本机工具或 Azure DMS）一次性迁移所有资源。 对于较大规模的迁移或具有特殊要求的迁移，可以按每个资源的粒度选择迁移工具。

    • 在规划要使用的迁移工具之前，建议熟悉可用的选项。 适用于 Azure Cosmos DB’s API for MongoDB 的 Azure 数据库迁移服务提供一个机制来简化数据迁移。该机制提供完全托管的主机平台、迁移监视选项和自动限制处理。 以下是完整的选项列表：

      迁移类型 解决方案 注意事项
      联机 Azure 数据库迁移服务 • 使用 Azure Cosmos DB 的批量执行工具库
      • 适合用于大型数据集，负责复制实时更改
      • 仅适用于其他 MongoDB 源
      Offline Azure 数据库迁移服务 • 使用 Azure Cosmos DB 的批量执行工具库
      • 适合用于大型数据集，负责复制实时更改
      • 仅适用于其他 MongoDB 源
      Offline Azure 数据工厂 • 使用 Azure Cosmos DB 的批量执行工具库
      • 适合用于大型数据集
      • 易于设置并支持多个源
      • 缺少检查点，这意味着，在迁移期间出现任何问题都需要重启整个迁移过程
      • 缺少死信队列，这意味着，几个文件有错误就可能会停止整个迁移过程
      • 需要编写自定义代码来增大某些数据源的读取吞吐量
      脱机 现有的 Mongo 工具（mongodump、mongorestore、Studio3T） • 易于设置和集成
      • 需要对限制进行自定义处理
      脱机/联机 Azure Databricks 和 Spark • 完全控制迁移速率和数据转换
      • 需要自定义编码

    • 如果资源能够容许脱机迁移，请使用此示意图选择适当的迁移工具：

      根据工具大小使用脱机迁移工具的示意图。

    • 如果资源要求联机迁移，请使用此示意图选择适当的迁移工具：

      基于统包解决方案或自定义解决方案的首选项使用联机迁移工具的示意图。

  • 为每个资源选择迁移工具后，下一步是确定要迁移的资源的优先级。 合理的优先级有助于使迁移保持符合计划。 一种很好的做法是优先迁移那些需要花费大部分时间来移动的资源；先迁移这些资源首先会带来最大的完成进度。 此外，由于这些耗时的迁移通常涉及更多的数据，运行迁移工具时它们消耗的资源更多，因此它们更有可能在迁移管道的早期阶段暴露出任何问题。 这种做法可以最大程度地减少由于迁移管道中出现的任何问题而导致计划改变的可能性。
  • 迁移开始后，规划如何监视迁移进度。 如果要在团队之间协调数据迁移工作，请同时规划一个定期团队同步操作，以便全面了解高优先级迁移的进展情况。

支持的迁移方案

最佳的 MongoDB 迁移工具取决于迁移方案。

迁移的类型

下面是每个迁移方案的兼容工具列表：

源 目标 过程建议
• MongoDB 本地群集
• IaaS VM 群集上的 MongoDB
• MongoDB Atlas 群集 - 脱机		 Azure Cosmos DB Mongo API • <10GB 数据：MongoDB 本机工具
• < 1-TB 数据：Azure DMS
• > 1 TB 数据：Spark
• MongoDB 本地群集
• IaaS VM 群集上的 MongoDB
• MongoDB Atlas 群集 - 联机		 Azure Cosmos DB Mongo API • < 1-TB 数据：Azure DMS
• > 1 TB 数据：Spark + Mongo Changestream
• 需要在迁移期间更改架构
需要比上述工具更灵活		 Azure Cosmos DB Mongo API • ADF 比 DMS 更灵活，在迁移期间支持架构修改，并支持大多数源/目标组合
• DMS 在缩放方面更好（例如更快的迁移）
• JSON 文件 Azure Cosmos DB Mongo API • MongoDB 本机工具，尤其是 mongoimport
• CSV 文件 Azure Cosmos DB Mongo API • MongoDB 本机工具，尤其是 mongoimport
• BSON 文件 Azure Cosmos DB Mongo API • MongoDB 本机工具，尤其是 mongorestore

各个 MongoDB 版本支持的工具

假设要从特定的 MongoDB 版本迁移，每个版本支持的工具都包含在此处：

MongoDB 源版本 Azure Cosmos DB for MongoDB 目标版本 支持的工具 不支持的工具
<2.x、>4.0 3.2、3.6、4.0 MongoDB 本机工具、Spark DMS、ADF
3.2、3.6、4.0 3.2、3.6、4.0 MongoDB 本机工具、DMS、ADF、Spark 无

迁移后

在迁移前阶段，请花些时间来规划在迁移后，要执行哪些步骤进行应用迁移和优化。

  • 在迁移后阶段，将执行应用程序的直接转换，以使用 Azure Cosmos DB 而不是现有的 MongoDB 数据资产。
  • 尽最大努力在每个资源级别规划索引、多区域分发、一致性和其他可变的 Azure Cosmos DB 属性。 但是，稍后可以修改这些 Azure Cosmos DB 配置设置，因此预计会对这些设置进行调整。 迁移后将应用这些可变配置。
  • 有关迁移后指南，请参阅使用 Azure Cosmos DB 的适用于 MongoDB 的 API 进行迁移后优化步骤。

后续步骤