MongoDB在Linux上的数据压缩

MongoDB 在 Linux 上的数据压缩实践

一 存储引擎与压缩总览

• 在 Linux 上，MongoDB 默认使用 WiredTiger 存储引擎，支持对集合与索引进行压缩，以降低磁盘占用并减少 I/O。集合支持 none/snappy/zlib/zstd（MongoDB 3.0+ 起支持 zstd），索引默认启用 前缀压缩（prefix compression），WiredTiger 的 Journal 也支持压缩。压缩在写入磁盘时完成，WiredTiger 缓存中保留未压缩数据以保证访问速度，因此压缩主要影响写性能与磁盘占用。WiredTiger 自 MongoDB 3.2 起成为默认存储引擎。

二 配置集合与索引压缩

• 配置文件方式（推荐）：在 /etc/mongod.conf 中设置

  storage:
    engine: wiredTiger
    wiredTiger:
      collectionConfig:
        blockCompressor: snappy   # 可选：none/snappy/zlib/zstd
      indexConfig:
        prefixCompression: true   # 默认 true，建议保持开启
  

  修改后需重启 mongod 生效。

• 运行时单库/单集合覆盖：创建集合时指定

  db.createCollection("email", {  storageEngine: {    wiredTiger: { configString: "block_compressor=zlib" }  }})

• 版本提示：若实例版本低于 4.2，通常不支持 zstd；如需 zstd，请先升级版本。

三 压缩算法选择与影响

• 选择原则：在“CPU 换磁盘”的权衡下，结合读写比例、数据类型与 CPU 余量选择算法。
• 常见算法对比（示例压缩率与开销为经验值，实际取决于数据特征）：
  

  算法	压缩率	CPU 开销	适用场景
  none	无	极低	已加密/已压缩数据（如图片、视频）
  snappy	中等（约2:1）	低	写入密集、对时延敏感
  zlib	较高（约3:1）	中	读取低频、存储敏感
  zstd	最高（约4:1）	中低	读取密集、存储紧张

• 实践建议：写入密集优先 snappy；读取密集且存储紧张优先 zstd；不可压缩数据用 none。

四 网络传输压缩

• 配置项：net.compression.compressors，可选 snappy/zlib/zstd。MongoDB 4.2+ 默认启用 snappy,zstd,zlib（按优先级协商），两端需至少共享一种算法才可生效。
• 建议：云环境/跨机房优先 zstd 节省带宽；低延迟内网可用 snappy 降低 CPU 开销。

  net:
    compression:
      compressors: snappy,zstd,zlib
  

• 兼容性：确保客户端（应用、备份工具、shell）支持所选算法，避免连接失败。

五 监控、空间回收与备份压缩

• 监控与评估
  • 查看内存使用：db.serverStatus().mem（关注 resident/virtual）。
  • 评估压缩收益：比较 db.stats().dataSize + db.stats().indexSize 在压缩前后变化（单位字节）。
• 空间回收
  • 删除文档/集合后，WiredTiger 会在数据文件中维护 Empty Records 列表并复用空间，但可能产生碎片。
  • 使用 compact 整理碎片并释放未使用空间：db.runCommand({ compact: "<collection>" })（注意：执行期间会占用额外磁盘空间与 I/O）。
• 备份压缩
  • 使用 mongodump/mongorestore 的 --gzip 在导出/导入时直接压缩，减少备份体积与磁盘占用（MongoDB 3.2+ 支持）。

    mongodump --host <host> --port <port> --gzip --out /backup/path
    mongorestore --host <host> --port <port> --gzip /backup/path
    

• 配置生效与注意事项
  • 部分存储配置（如 directoryForIndexes）在实例初始化后修改，往往需迁移数据才能生效；变更配置前务必在测试环境验证并安排维护窗口。