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

适用于:Azure Cosmos DB API for MongoDB

重要

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

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

Diagram of migration steps.

迁移前步骤概述

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

迁移前的目标是:

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

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

  1. 发现现有的 MongoDB 资源并创建一个数据资产电子表格来跟踪这些资源
  2. 评估现有的 MongoDB 资源是否已做好数据迁移的准备
  3. 将现有的 MongoDB 资源映射到新的 Azure Cosmos DB 资源
  4. 在开始执行全规模的数据迁移之前规划迁移过程的端到端后勤工作

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

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

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

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

数据库迁移助手(DMA) 可帮助你完成规划中的发现评估阶段。

迁移前的发现

第一个迁移前步骤是资源发现。 在此步骤中,需要创建一个数据资产迁移电子表格。

  • 此电子表格包含 MongoDB 数据资产中现有资源(数据库或集合)的综合列表。
  • 此电子表格旨在提高工作效率,并帮助你端到端规划迁移。
  • 建议扩展此文档,并在整个迁移过程中将其用作跟踪文档。

使用数据库迁移助手以编程方式发现

可以使用数据库迁移助手 (DMA) 来帮助你以编程方式完成发现阶段并创建数据资产迁移表。

可通过 Azure Data Studio 客户端轻松设置和运行 DMA。 可以从连接到源 MongoDB 环境的任何计算机中运行。

可将以下任一 DMA 输出文件用作数据资产迁移电子表格:

  • workload_database_details.csv - 提供源工作负载的数据库级视图。 文件中的列包括:数据库名称、集合计数、文档计数、平均文档大小、数据大小、索引计数和索引大小。
  • workload_collection_details.csv - 提供源工作负载的集合级别视图。 文件中的列包括:数据库名称、集合名称、文档计数、平均文档大小、数据大小、索引计数、索引大小和索引定义。

下面是由 DMA 创建的数据库级迁移电子表格示例:Data estate spreadsheet example

手动发现

或者,可以参考上面的示例电子表格并自行创建类似的文档。

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

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

迁移前的评估

其次,作为规划迁移的准备工作,请评估数据资产中的资源的迁移就绪性。

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

使用数据库迁移助手以编程方式评估

数据库迁移助手 (DMA) 还可帮助你完成迁移前规划的评估阶段。

请参阅使用数据库迁移助手以编程方式发现部分,了解如何设置和运行 DMA。

DMA 笔记本针对从源 MongoDB 收集的资源列表运行一些评估规则。 评估结果列出了继续执行迁移所需的必需更改和建议的更改。

结果在 DMA 笔记本中作为输出打印并保存到 CSV 文件 - assessment_result.csv

注意

数据库迁移助手是一个初步实用工具,旨在帮助你完成迁移前步骤。 它不执行端到端评估。 除了运行 DMA 外,还建议你详细了解受支持的功能和语法Cosmos DB 限制和配额,并在实际迁移之前执行概念证明。

迁移前的映射

发现和评估步骤完成后,方程的 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 资源的命名约定。 阻止对数据库和集合的结构进行任何更改并保留相同的资源名称通常是很好的做法。
  • 确定你要在 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 • 完全控制迁移速率和数据转换
      • 需要自定义编码
    • 如果资源能够容许脱机迁移,请使用下图选择适当的迁移工具:

      Offline migration tools.

    • 如果资源要求联机迁移,请使用下图选择适当的迁移工具:

      Online migration tools.

  • 为每个资源选择迁移工具后,下一步是确定要迁移的资源的优先级。 合理的优先级有助于使迁移保持符合计划。 良好的做法是优先迁移那些需要花费大部分时间来移动的资源;先迁移这些资源可以最好地保持完成进度。 此外,由于这些耗时的迁移通常涉及更多的数据,运行迁移工具时它们消耗的资源更多,因此它们更有可能在迁移管道的早期阶段暴露出任何问题。 这可以最大程度地减少由于迁移管道中出现的任何问题而导致计划改变的可能性。

  • 迁移开始后,规划如何监视迁移进度。 如果要在团队之间协调数据迁移工作,请同时规划一个定期团队同步操作,以便全面了解高优先级迁移的进展情况。

支持的迁移方案

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

迁移的类型

下面显示了每种迁移方案的兼容工具:

Supported migration scenarios.

各个 MongoDB 版本支持的工具

假设你要从特定的 MongoDB 版本迁移,支持的工具如下:

MongoDB versions supported by migration tools.

迁移后

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

  • 在迁移后阶段,需要对应用程序执行直接转换,以使用 Azure Cosmos DB 而不是现有的 MongoDB 数据资产。
  • 请尽量在每个资源级别规划索引、多区域分布、一致性和其他可变 Azure Cosmos DB 属性,但是,可以稍后对这些 Azure Cosmos DB 配置设置进行修改,以便可以在未来对这些设置进行调整 。 不要让这些方面成为分析瘫痪的原因。 迁移后将应用这些可变配置。
  • 有关迁移后指南,请参阅使用 Azure Cosmos DB 的适用于 MongoDB 的 API 进行迁移后优化步骤

后续步骤