0

我正在尝试比较 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}

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

非常感谢你的帮助。

4

2 回答 2

2

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

除非随机数生成器非常糟糕，否则随机数据没有任何模式，因此不能很好地压缩。

快速演示：

~% 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 ://stackoverflow.com/a/2443944/2282634

于 2021-10-23T01:29:35.677 回答
1

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

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

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

snappy 压缩被选为默认值，因为它在压缩率和速度之间提供了一个很好的折衷 - 你不应该忽略压缩和解压缩也需要时间的事实。

于 2021-10-23T07:26:14.997 回答