MongoDB GridFS大文件压缩存储的实现方法

GridFS 本身不提供文件级压缩能力，如需压缩大文件，必须在应用层手动处理；而删除文件后磁盘空间不立即释放，则是 WiredTiger 存储引擎的设计特性所致。若想彻底回收空间，通常只能通过导出→清空→重建的方式完成。

GridFS 自身并不支持文件级自动压缩。很多人提到“压缩 MongoDB GridFS 大文件”，实际通常包含两个完全不同的问题：一是上传前如何缩小文件体积，也就是应用层压缩；二是删除文件后如何回收已经占用的磁盘空间，也就是存储层空间整理。这两件事本质不同，但在实际使用中经常被混淆。

上传前用 gzip / zlib 压缩原始文件再存入 GridFS

GridFS 不会自动压缩文件内容，它只是把输入流按块切分后原样写入 fs.chunks 集合。想减少 GridFS 存储占用，正确做法是在写入 MongoDB 之前由应用程序先完成压缩。

• 对文本类文件，例如日志、JSON、XML，压缩效果通常很明显；但对 JPEG、MP4、ZIP 这类本身已经压缩过的格式，基本没有效果，甚至可能让文件体积略有增加
• Python 示例：fs.put(gzip.compress(file_bytes), filename="report.json.gz", metadata={"original_name": "report.json"})
• Ja va 中可使用 ja va.util.zip.GZIPOutputStream 包装 InputStream，然后再传给 GridFSInputFile
• 建议务必在 metadata 或文件名里保留原始格式信息，否则文件读取出来后可能无法正确解压或还原

删除大量文件后，compact 命令无法释放磁盘空间

很多人在执行 db.runCommand({compact: "fs.chunks"}) 之后，会发现用 du -sh 查看磁盘占用几乎没有变化。这并不代表命令无效，而是因为 WiredTiger 的工作机制决定了它不会轻易把空间直接归还给文件系统。

• compact 的作用主要是整理内部数据页、合并空闲 slot，但不会直接触发文件系统层面的空间释放
• fs.chunks 中的文档通常较小（默认 256KB/chunk），大量删除后形成的往往是零散碎片，这也导致 compact 在该集合上的回收效果通常弱于普通业务集合
• 执行该命令时需要对集合加独占锁，在此期间相关读写都会被阻塞，因此生产环境或线上业务场景要谨慎使用

真正回收磁盘空间必须走导出→清空→重建流程

在 WiredTiger 引擎下，如果目标是实际缩小 .wt 文件的物理大小，最可靠的方法仍然是重建数据文件，而不是单纯依赖压缩或整理命令。

• 先导出仍然有效的数据：mongodump --gzip --db your_db --collection fs.files --collection fs.chunks -o /backup/
• 停止 mongod，手动删除数据目录中的所有 fs.*.wt 文件（⚠️仅适用于维护窗口，并确认没有其他进程正在访问）
• 重新启动 mongod，再执行 mongorestore --gzip /backup/ 完成导入——这样会生成全新的、无明显碎片的 .wt 文件
• 如果业务无法停机，也可以尝试 db.adminCommand({compactServer: true}) 配合文件系统级 fstrim（仅适用于 SSD + XFS/ext4，并且启用了 discard 挂载选项）

还有一个在 MongoDB GridFS 运维中非常容易被忽略的细节：文件删除后空间没有马上释放，通常并不是操作失误，也不一定是数据库异常，而是 WiredTiger 为了兼顾写入性能与崩溃恢复能力所做的设计权衡。日常排查时，建议重点关注 db.fs.chunks.stats().storageSize / db.fs.chunks.stats().size 这个比值；如果超过 2.0，通常就说明碎片问题已经比较严重，数据库重建和空间回收方案就应尽快纳入处理计划。