将数据从 MongoDB 迁移到 Azure Cosmos DB for MongoDB 的迁移前步骤
适用于: MongoDB
重要
在执行迁移前步骤之前,请完整阅读本指南。
本 MongoDB 迁移前指南是 MongoDB 迁移系列教程的一部分。 关键的 MongoDB 迁移步骤包括迁移前步骤、迁移步骤和迁移后步骤,如本指南所示。
迁移前步骤概述
在实际迁移任何数据之前,提前做出特定的迁移规划和决策至关重要。 此初始决策制定过程就是“迁移前”。
迁移前的目标是:
- 确保设置 Azure Cosmos DB 以满足应用程序的要求,以及
- 规划如何执行迁移。
按如下所述执行全面的迁移前步骤
- 发现现有的 MongoDB 资源并创建一个数据资产电子表格来跟踪这些资源
- 评估现有的 MongoDB 资源是否已做好数据迁移的准备
- 将现有的 MongoDB 资源映射到新的 Azure Cosmos DB 资源
- 在开始执行全规模的数据迁移之前规划迁移过程的端到端后勤工作
然后,根据迁移前计划执行迁移。
最后,执行关键的迁移后切换和优化步骤。
上述所有步骤对于确保迁移成功都至关重要。
规划迁移时,建议尽可能地在每个资源的级别进行规划。
数据库迁移助手(DMA) 可帮助你完成规划中的发现和评估阶段。
迁移前的发现
第一个迁移前步骤是资源发现。 在此步骤中,需要创建一个数据资产迁移电子表格。
- 此电子表格包含 MongoDB 数据资产中现有资源(数据库或集合)的综合列表。
- 此电子表格旨在提高工作效率,并帮助你端到端规划迁移。
- 建议扩展此文档,并在整个迁移过程中将其用作跟踪文档。
使用数据库迁移助手以编程方式发现
可以使用数据库迁移助手 (DMA) 来帮助你以编程方式完成发现阶段并创建数据资产迁移表。
可通过 Azure Data Studio 客户端轻松设置和运行 DMA。 可以从连接到源 MongoDB 环境的任何计算机中运行。
可将以下任一 DMA 输出文件用作数据资产迁移电子表格:
workload_database_details.csv
- 提供源工作负载的数据库级视图。 文件中的列包括:数据库名称、集合计数、文档计数、平均文档大小、数据大小、索引计数和索引大小。workload_collection_details.csv
- 提供源工作负载的集合级别视图。 文件中的列包括:数据库名称、集合名称、文档计数、平均文档大小、数据大小、索引计数、索引大小和索引定义。
下面是由 DMA 创建的数据库级迁移电子表格示例:
DB 名称 | 集合计数 | 文档计数 | 平均文档大小 | 数据大小 | 索引计数 | 索引大小 |
---|---|---|---|---|---|---|
bookstoretest |
2 | 192200 | 4144 | 796572532 | 7 | 260636672 |
cosmosbookstore |
1 | 96604 | 4145 | 400497620 | 1 | 1814528 |
geo |
2 | 25554 | 252 | 6446542 | 2 | 266240 |
kagglemeta |
2 | 87934912 | 190 | 16725184704 | 2 | 891363328 |
pe_orig |
2 | 57703820 | 668 | 38561434711 | 2 | 861605888 |
portugeseelection |
2 | 30230038 | 687 | 20782985862 | 1 | 450932736 |
sample_mflix |
5 | 75583 | 691 | 52300763 | 5 | 798720 |
test |
1 | 22 | 545 | 12003 | 0 | 0 |
testcol |
26 | 46 | 88 | 4082 | 32 | 589824 |
testhav |
3 | 2 | 528 | 1057 | 3 | 36864 |
总计: | 46 | 176258781 | 72.01 GB | 2.3 GB |
手动发现
或者,可以参考本指南中的示例电子表格并自行创建类似的文档。
- 电子表格应采用列表形式的结构,其中记录数据资产资源。
- 每行对应于一个资源(数据库或集合)。
- 每列对应于资源的一个属性;至少以名称和数据大小 (GB) 作为列的开头。
- 在完成本指南的过程中,需要将此电子表格构建为端到端迁移规划的跟踪文档,并根据需要添加列。
下面是可用于发现资源的一些工具:
迁移前的评估
其次,作为规划迁移的准备工作,请评估数据资产中的资源的迁移就绪性。
评估涉及确定是否正在使用受支持的功能和语法。 它还包括确保遵循限制和配额。 此阶段的目的是创建不兼容问题和警告列表(如有)。 得出评估结果后,可以尝试在迁移规划的其余部分中处理结果。
使用数据库迁移助手以编程方式评估
数据库迁移助手 (DMA) 还可帮助你完成迁移前规划的评估阶段。
请参阅使用数据库迁移助手以编程方式发现部分,了解如何设置和运行 DMA。
DMA 笔记本针对从源 MongoDB 收集的资源列表运行一些评估规则。 评估结果列出了继续执行迁移所需的必需更改和建议的更改。
结果在 DMA 笔记本中作为输出打印并保存到 CSV 文件 - assessment_result.csv
。
注意
数据库迁移助手是一个初步实用工具,旨在帮助你完成迁移前步骤。 它不执行端到端评估。 除了运行 DMA 外,还建议你详细了解受支持的功能和语法以及Azure Cosmos DB 限制和配额,并在实际迁移之前执行概念证明。
迁移前的映射
发现和评估步骤完成后,方程的 MongoDB 一端的准备工作现已完成。 现在可以规划方程的 Azure Cosmos DB 一端。 你计划如何设置和配置生产 Azure Cosmos DB 资源? 按照每个资源级别进行规划 - 这意味着应将以下列添加到计划电子表格中:
- Azure Cosmos DB 映射
- 分片键
- 数据模型
- 使用专用吞吐量还是共享吞吐量
以下各部分提供了更多详细信息。
容量计划
正在尝试为迁移到 Azure Cosmos DB 进行容量计划?
- 如果你只知道现有数据库群集中的 vCore 和服务器数量,请阅读根据 vCore 或 vCPU 数量估算请求单位数
- 若知道当前数据库工作负载的典型请求速率,请阅读使用 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 中的分区和横向缩放以选择最佳分片键。 分区(也称为分片)是迁移数据之前要考虑的一个要点。 Azure Cosmos DB 使用完全托管的分区来提高数据库中的容量,以满足存储和吞吐量要求。 此功能不需要托管或配置路由服务器。
- 分区功能以类似方式自动增加容量,并相应地重新均衡数据。 有关为数据选择正确分区键的详细信息,请参阅选择分区键。
- 按照 Azure Cosmos DB 中的数据建模指南选择数据模型。
- 按照在 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 源脱机 Azure 数据工厂 • 使用 Azure Cosmos DB 的批量执行工具库
• 适合用于大型数据集
• 易于设置并支持多个源
• 缺少检查点,这意味着,在迁移期间出现任何问题都需要重启整个迁移过程
• 缺少死信队列,这意味着,出现几个有错误的文件就可能会停止整个迁移过程
• 需要编写自定义代码来增大某些数据源的读取吞吐量脱机 现有的 Mongo 工具(mongodump、mongorestore、Studio3T) • 易于设置和集成
• 需要对限制进行自定义处理脱机/联机 Azure Databricks 和 Spark • 完全控制迁移速率和数据转换
• 需要自定义编码如果资源能够容许脱机迁移,请使用此示意图选择适当的迁移工具:
如果资源要求联机迁移,请使用此示意图选择适当的迁移工具:
观看迁移解决方案的概述和演示视频。
- 为每个资源选择迁移工具后,下一步是确定要迁移的资源的优先级。 合理的优先级有助于使迁移保持符合计划。 一种很好的做法是优先迁移那些需要花费大部分时间来移动的资源;先迁移这些资源首先会带来最大的完成进度。 此外,由于这些耗时的迁移通常涉及更多的数据,运行迁移工具时它们消耗的资源更多,因此它们更有可能在迁移管道的早期阶段暴露出任何问题。 这种做法可以最大程度地减少由于迁移管道中出现的任何问题而导致计划改变的可能性。
- 迁移开始后,规划如何监视迁移进度。 如果要在团队之间协调数据迁移工作,请同时规划一个定期团队同步操作,以便全面了解高优先级迁移的进展情况。
支持的迁移方案
最佳的 MongoDB 迁移工具取决于迁移方案。
迁移的类型
下面是每个迁移方案的兼容工具列表:
源 | 目标 | 过程建议 |
---|---|---|
• MongoDB 本地群集 • IaaS VM 群集上的 MongoDB • MongoDB Atlas 群集 - 脱机 |
Azure Cosmos DB Mongo API | • < 10 GB 数据: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 进行迁移后优化步骤。
后续步骤
- 迁移到 Azure Cosmos DB API for MongoDB