如何压缩MongoDB GridFS存储的大文件？

GridFS不提供文件级压缩，需应用层手动压缩；删除后空间不释放是WiredTiger设计所致，唯一彻底回收方式是导出→清空→重建。

GridFS 本身不提供文件级压缩功能，所谓“压缩大文件”，实际是指两件事：一是减少上传前的文件体积（应用层压缩），二是回收删除后残留的磁盘空间（存储层空间回收）。两者完全无关，但常被混为一谈。

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

GridFS 不会对内容自动压缩，它只是把输入流原样切块存进 fs.chunks。想减小存储体积，必须在写入前手动压缩。

1. 对文本类文件（日志、JSON、XML）效果显著；对已压缩格式（JPEG、MP4、ZIP）几乎无效，甚至可能略微增大体积
2. Python 示例：fs.put(gzip.compress(file_bytes), filename="report.json.gz", metadata={"original_name": "report.json"})
3. Java 中可用 java.util.zip.GZIPOutputStream 包裹 InputStream 后传给 GridFSInputFile
4. 务必在 metadata 或文件名中记录原始格式，否则读取时无法正确解压

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

执行 db.runCommand({compact: "fs.chunks"}) 后 du -sh 显示的磁盘占用几乎不变——这不是命令没生效，而是 WiredTiger 的设计使然。

1. compact 只重排内部页、合并空闲 slot，不触发文件系统级空间归还
2. fs.chunks 文档极小（默认 256KB/chunk），大量删除后留下的是细碎空洞，compact 效率远低于业务集合
3. 该命令要求集合独占锁，期间所有读写阻塞，线上环境慎用

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

WiredTiger 引擎下，唯一能降低 .wt 文件物理大小的方式是彻底重建数据文件。

1. 导出存活数据：mongodump --gzip --db your_db --collection fs.files --collection fs.chunks -o /backup/
2. 停 mongod，手动删除数据目录下所有 fs.*.wt 文件（⚠️仅限维护窗口，确认无其他进程访问）
3. 重启 mongod，再用 mongorestore --gzip /backup/ 导入——此时生成全新、无碎片的 .wt 文件
4. 若无法停服，可尝试 db.adminCommand({compactServer: true}) + 文件系统级 fstrim（仅限 SSD + XFS/ext4 启用 discard 挂载选项）

最易被忽略的一点：GridFS 删除后空间不释放，不是运维疏忽，而是 WiredTiger 为保障写入吞吐和崩溃恢复能力做的主动取舍。日常应盯住 db.fs.chunks.stats().storageSize / db.fs.chunks.stats().size 比值，一旦超过 2.0，说明碎片已严重，该安排重建了。