mongodb - mongodb的bson vs gzip转储

Question

我有一个数据库

关于磁盘大小19.032GB（使用show dbs命令）

数据大小56 GB（使用db.collectionName.stats(1024*1024*1024).size命令）

使用命令mongodump获取 mongodump 时，我们可以设置参数 --gzip。这些是我有和没有这个标志的观察结果。

命令	转储时间	转储大小	恢复时间	观察
用 gzip	30分钟	7.5 GB	20 分钟	在 mongostat 中，插入速率范围从 30K 到 80k par sec
没有 gzip	10 分钟	57 GB	50 分钟	在 mongostat 中，插入率非常不稳定，范围从 8k 到 20k par sec

转储从 8 核、40 GB ram 的机器（机器 B）到 12 核、48GB ram 的机器（机器 A）。并从机器 A 恢复到 12 核、48 GB 机器（机器 C），以确保 mongo、mongorestore 和 mongodump 进程之间没有资源争用。Mongo 版本 4.2.0

我有几个问题，比如

1. 2 个转储之间的功能区别是什么？
2. 可以压缩 bson 转储以使其压缩吗？
3. 索引数量如何影响 mongodump 和恢复过程。（如果我们删除一些唯一索引然后重新创建它，它会加快总转储和恢复时间吗？考虑在执行插入 mongodb 时不必处理唯一性部分）
4. 有没有办法让整个过程更快。从这些结果我看到我们必须在转储和恢复速度之间选择 1。
5. 拥有一台更大的机器（RAM）来读取转储并恢复它会加快整个过程吗？
6. 较小的转储对整体时间有帮助吗？

标签： mongodbmongodumpmongorestore

Answer 1

我不是 MongoDB 专家，但我在 MongoDB 备份和恢复活动方面拥有丰富的经验，并且会尽我所能回答。

1. 2 个转储之间的功能区别是什么？

• mongodump不使用该--gzip选项的命令会将每个文档以bson格式保存到文件中。

  这将显着减少备份和恢复操作所花费的时间，因为它只是读取 bson 文件并插入文档，妥协是.bson转储文件的大小

• 但是，当我们传递该--gzip选项时，bson 数据被压缩并被转储到文件中。这将显着增加 和 所花费的时间mongodump，mongorestore但由于压缩，备份文件的大小会非常小。

2. 可以压缩 bson 转储以使其压缩吗？

• 是的，它可以进一步压缩。但是，您将花费额外的时间，因为您必须在恢复操作之前压缩已经压缩的文件并再次提取它，从而增加了总时间。如果压缩文件的大小与 gzip 相比非常小，请执行此操作。

  编辑：

  正如@best wish所指出的，我完全误解了这个问题。

  gzip执行者mongodump只是gzip在 mongodump 端执行的。从字面上看，这与从我们端手动压缩原始 BSON 文件相同。

  例如，如果您.gzip.bson使用任何压缩应用程序提取文件，您将获得实际的 BSON 备份文件。

  请注意，zip和gzip并不相同（就压缩而言），因为它们都使用不同的压缩算法，即使它们都压缩文件。因此，在比较文件的 mongodump gzip 和手动 zip 时，您会在文件大小方面得到不同的结果。

3. 索引数量如何影响 mongodump 和还原过程。（如果我们删除一些唯一索引然后重新创建它，它会加快总转储和恢复时间吗？考虑在执行插入 mongodb 时不必处理唯一性部分）

• 每当您进行转储时，mongodump工具都会创建一个<Collection-Name.metadata.json>文件。这基本上包含所有索引，后跟集合名称、、uuid等。colmoddbUsersAndRoles

• 集合中索引的数量和类型在操作过程中不会产生影响mongodump。但是，使用命令恢复数据后mongorestore，它会遍历元数据文件中的所有索引，并尝试重新创建索引。

• 此操作所花费的时间取决于索引的数量和集合中的文档数量。简而言之（索引数量 * 文档数量）。索引的类型（即使它是唯一的）对性能没有重大影响。如果使用该background: true选项在原始集合中应用索引，则在恢复时重建索引将花费更多时间。

• mongorestore您可以通过在命令行中传递--noIndexRestore选项来避免操作过程中的索引操作。您可以稍后在需要时编制索引。

在我公司的生产备份环境中，键的索引比数据的恢复需要更多的时间。

4. 有没有办法让整个过程更快。从这些结果我看到我们必须在转储和恢复速度之间选择 1

解决方案取决于...

• 如果网络带宽不是问题（例如：在云中运行的两个实例之间移动数据），请不要使用和压缩，因为它会节省您的时间。

• 如果新移动的实例中的数据不会立即被访问，则使用该--noIndexRestore标志执行恢复过程。

• 如果备份用于冷存储或保存数据以备后用，请应用gzip压缩或手动zip压缩，或两者兼而有之（以最适合您的方式）

选择最适合您的方案，但您必须首先在决定是否应用索引时在时间和空间之间找到适当的平衡。

在我的公司中，我们通常对 P-1 进行非压缩备份和恢复，对数周前的 prod 备份进行 gzip 压缩，然后对数月前的备份进一步手动压缩。

• 你还有一个选择，我不推荐这种方法。您可以直接移动data您的MongoDB实例指向的路径，并更改迁移机器的MongoDB实例中的DB路径。同样，我不推荐这种方法，因为有很多事情可能会出错，尽管我对这种方法没有任何问题。但我不能保证你也一样。如果您决定这样做，请自行承担风险。

5. 拥有一台更大的机器（RAM）来读取转储并恢复它会加快整个过程吗？

• 我不这么认为。我对此不确定，但我有 16 GB RAM，我将 40GB mongodump 的备份恢复到我的本地，并且由于 RAM 没有遇到任何瓶颈，但我可能是错的，因为我不确定。如果您自己知道答案，请告诉我。

6. 较小的转储对整体时间有帮助吗？

• 如果通过smaller dump，您的意思是使用标志限制要转储的--query数据，因为要备份和恢复的数据非常少，所以肯定会。记住No. of Indexes * No. of Documents规则。

希望这可以帮助您回答您的问题。让我知道你是否有：

• 任何进一步的问题
• 如果我犯了任何错误
• 找到了更好的解决方案
• 你最终决定了什么