mongodb 的 bson 与 gzip 转储

Question

我有一个数据库

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

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

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

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

转储是从 8 核、40 GB 内存的机器（机器 B）到 12 核、48GB 内存的机器（机器 A）获取的。并从机器 A 恢复到 12 核、48 GB 机器（机器 C），以确保 mongo、mongorestore 和 mongodump 进程之间不存在资源争用。蒙戈版本4.2.0

我有几个问题，比如

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

---

更新：2.bson转储可以被压缩以使其压缩吗？

是的

% ./mongodump -d=test                                                                     
2022-11-16T21:02:24.100+0530    writing test.test to dump/test/test.bson
2022-11-16T21:02:24.119+0530    done dumping test.test (10000 documents)
% gzip dump/test/test.bson                                         
% ./mongorestore   --db=test8 --gzip dump/test/test.bson.gz
2022-11-16T21:02:51.076+0530    The --db and --collection flags are deprecated for this use-case; please use --nsInclude instead, i.e. with --nsInclude=${DATABASE}.${COLLECTION}
2022-11-16T21:02:51.077+0530    checking for collection data in dump/test/test.bson.gz
2022-11-16T21:02:51.184+0530    restoring test8.test from dump/test/test.bson.gz
2022-11-16T21:02:51.337+0530    finished restoring test8.test (10000 documents, 0 failures)
2022-11-16T21:02:51.337+0530    10000 document(s) restored successfully. 0 document(s) failed to restore.

Answer 1

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

1. 2 个转储之间的功能差异是什么？

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

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

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

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

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

  编辑：

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

  gzipPerformed bymongodump只是gzip在 mongodump 端执行。它实际上与我们手动压缩原始 BSON 文件相同。

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

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

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

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

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

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

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

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

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

解决方案取决于...

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

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

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

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

在我的公司，我们通常对几周前的生产备份进行 P-1 和 gzip 压缩的非压缩备份和恢复，并进一步手动压缩几个月前的备份。

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

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

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

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

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

希望这可以帮助您解答您的问题。如果您有的话请告诉我：

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