我正在嘗試比較 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}
我的配置有問題嗎？或者直到資料大小大大大于記憶體大小才開始壓縮？或者可用的存盤空間？我在這里缺少什么？
非常感謝您的幫助。
uj5u.com熱心網友回復：
壓縮演算法的作業原理是識別資料中的重復模式，并用明顯更小的識別符號替換這些模式。
除非亂數生成器非常糟糕，否則隨機資料沒有任何模式，因此不能很好地壓縮。
快速演示：
~% 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
uj5u.com熱心網友回復：
正如 Joe 已經解釋和展示的，你不能壓縮隨機資料，這是一個數學定律。
如果您想獲取真實資料，請訪問“開放資料”專案之一，例如 https://ourworldindata.org/或https://world.openfoodfacts.org/data（他們甚至提供MongoDB Dump）或只是Atlas Clusters 的可用樣本資料集
通常這些資料集也以 JSON 或 CSV 格式提供，因此您可以輕松匯入它們。
選擇 snappy 壓縮作為默認值是因為它在壓縮比和速度之間提供了一個很好的折衷——你不應該忽略壓縮和解壓縮也需要時間的事實。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/333521.html