mongodb snappy 压缩数据大小与存储大小

Posted 2023-03-06

【中文标题】mongodb snappy 压缩数据大小与存储大小

【英文标题】：mongodb snappy compression Data Size vs Storage Size

【发布时间】：2021-10-22 21:14:05

【问题描述】：

我正在尝试比较 snappy、zstd 等的 mongodb（最新来自 git repo）的压缩率。这是来自我的 /etc/mongod.conf 的相关片段

storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
  wiredTiger:
    engineConfig:
      journalCompressor: snappy
    collectionConfig:
      blockCompressor: snappy
    indexConfig:
      prefixCompression: true

我的测试用例将条目插入到集合中。每个 db 条目都有一个 _id 和 1MB 的二进制文件。二进制文件是使用 faker 随机生成的。我输入了 5GB/7GB 的数据，但存储大小似乎没有被压缩。托管 monodb 的 AWS 实例有 15GB 的内存和 100GB 的磁盘空间。以下是我看到的从 dbstat 收集的示例数据：

5GB 数据：

'Data Size': 5243170000.0,
 'Index Size': 495616.0,
 'Storage size': 5265686528.0,
 'Total Size': 5266182144.0

7GB 数据：

'Data Size': 7340438000.0,
 'Index Size': 692224.0,
 'Storage size': 7294259200.0,
 'Total Size': 7294951424.0

我的配置有问题吗？或者直到数据大小大大大于内存大小才开始压缩？或者可用的存储大小？我在这里错过了什么？

非常感谢您的帮助。

【参考方案1】：

压缩算法的工作原理是识别数据中的重复模式，并用明显更小的标识符替换这些模式。

除非随机数生成器非常糟糕，否则随机数据没有任何模式，因此压缩效果不佳。

快速演示：

~% dd if=/dev/urandom bs=1024 count=1024 of=rand.dat
1024+0 records in
1024+0 records out
1048576 bytes transferred in 0.011312 secs (92695833 bytes/sec)

~% ls -l rand.dat
-rw-r--r--  1 user  group  1048576 Oct 22 18:22 rand.dat

~% gzip -9 rand.dat

~% ls -l rand.dat.gz
-rw-r--r--  1 user  group  1048923 Oct 22 18:22 rand.dat.gz

这表明即使使用最佳/最慢压缩设置的 gzip 也会生成一个实际上比原始文件更大的“压缩”文件。

您可以尝试使用随机对象生成器来创建文档，例如：https://***.com/a/2443944/2282634

【讨论】：

非常感谢您发现我的错误！我什至没有考虑过真正的随机数据（二进制）会受到严重的压缩。我切换到使用句子而不是二进制，我得到了大约 45% 的 snappy 压缩率。

【参考方案2】：

正如 Joe 已经解释和展示的那样，您不能压缩随机数据，这是一个数学定律。

如果您想获取真实数据，请访问“开放数据”项目之一，例如 https://ourworldindata.org/ 或 https://world.openfoodfacts.org/data（他们甚至提供 MongoDB Dump）或只是 Available Sample Datasets for Atlas Clusters

这些数据集通常也以 JSON 或 CSV 格式提供，因此您可以轻松导入它们。

默认选择 snappy 压缩是因为它在压缩率和速度之间提供了很好的折衷 - 您不应忽视压缩和解压缩也需要时间这一事实。