mongodb 的 bson 与 gzip 转储

编程问答 2022-04-23

问题描述

我有一个数据库

关于磁盘大小 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 转储可以压缩以使其成为 zip 文件吗？
  3. 索引数量如何影响 mongodump 和恢复过程。 （如果我们删除一些唯一索引然后重新创建它，它会加快总转储和恢复时间吗？考虑在执行插入 mongodb 时不必考虑唯一性部分）
  4. 有没有办法加快整个过程。从这些结果中，我看到我们必须在转储和恢复速度之间选择 1。
  5. 拥有一个更大的机器（RAM）来读取转储并恢复它是否会加快整个过程？
  6. 较小的转储会在总体上有所帮助吗？

解决方法

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

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

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

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

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

  1. bson 转储可以压缩以使其成为 zip 文件吗？

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

    编辑：

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

    gzip 执行的

    mongodump 只是在 mongodump 端执行的 gzip。从字面上看，这和我们这边手动压缩原始 BSON 文件是一样的。

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

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

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

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

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

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

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

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

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

解决方案取决于...

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

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

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

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

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

  • 您还有一个选择，我不推荐这种方法。您可以直接移动您的MongoDB实例指向的data路径，并更改迁移机器的MongoDB实例中的DB路径。同样，我不推荐这种方法，因为有很多事情可能会出错，尽管我对这种方法没有任何问题。但我不能保证你也一样。如果您决定这样做，风险自负。
  1. 拥有一个更大的机器（RAM）来读取转储并恢复它是否会加快整个过程？
  • 我不这么认为。我不确定这一点，但我有 16 GB RAM，我将 40GB mongodump 的备份恢复到我的本地并且没有遇到任何由于 RAM 导致的瓶颈，但我可能是错误的，因为我不确定。如果您自己知道答案，请告诉我。
  1. 较小的转储会在总体上有所帮助吗？
  • 如果使用 smaller dump，您的意思是使用 --query 标志限制要转储的数据，因为要备份和恢复的数据非常少，所以肯定会。请记住 No. of Indexes * No. of Documents 规则。

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

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