排查一个商城下载慢的故障时，我们发现商品说明书 PDF 全被编码塞进了 MongoDB。文件单个不大，但数量一多、并发一高，主库 CPU 和网络被拖得很惨。我是老李。这类问题不是第一次遇到。很多团队看到 MongoDB 支持 GridFS，就认为文件存储有了官方答案。今天把 GridFS 的原理、Spring Data 操作方式、以及“为什么生产图片视频还是应该放 OSS/S3”一次讲清。

## 01、痛点

典型业务里，商品说明书、合同扫描件、用户授权书等文件需要跟随单据走。早期常见做法有两种。

第一种是转 Base64 后塞进 MongoDB 文档。好处是查询方便，文件跟业务记录一体。但问题很明显：单文档有 16MB 限制，稍大一点的 PDF 或图片就会超限；即使不超限，读业务列表时也会把这些二进制字段带出来，序列化、内存、传输开销都很大；更新一个字段可能把整个大文档重写，写放大严重。

第二种是存服务器本地磁盘，数据库只存路径。单机部署还勉强能用，一旦多实例或容器化部署，文件可能落在不同节点，读取失败、备份漏掉、迁移困难。运维要额外维护共享存储，复杂度上升。

于是有人想到 GridFS：它是 MongoDB 自带的文件拆分存储规范，看起来既不用额外组件，又能突破 16MB 限制，还能把文件元数据查起来。但也正是这个“看起来”，让不少团队把大量图片视频也塞了进去，最后引发性能问题。

## 02、是什么

GridFS 不是独立服务，而是 MongoDB 的一种文件存储规范。它把大文件切分成固定大小的块，分别存到两个集合：fs.files 和 fs.chunks。

fs.files 是文件元数据集合，常见字段包括 _id、filename、length、chunkSize、uploadDate、metadata。其中 metadata 是业务自定义字段，比如商品 SKU、文件类型、上传人、状态等，查询时可以使用。

fs.chunks 是二进制分块集合，常见字段包括 _id、files_id、n、data。files_id 指向 fs.files._id，n 表示块序号，data 是该块二进制内容。下载时按照 files_id 和 n 升序把块拼起来，就是完整文件。

默认 chunkSize 是 255KB。一个 1MB 左右的 PDF，大约会被切成五块。这样拆分的好处是：读写不需要一次性把整个文件加载到内存；对单个块的读写可以并行；文件内容也比较容易分布在分片集群中。

Spring Data MongoDB 提供了 GridFsTemplate 和 ReactiveGridFsTemplate。前者用于阻塞式 Web 应用，后者配合 WebFlux 使用。它们封装了 GridFSBucket 的操作，将文件抽象成 GridFsResource。GridFsResource 实现了 Spring 的 Resource 接口，因此可以像操作普通资源一样拿到 InputStream、contentLength、描述信息等，这就是 Mongo Resource API 的价值：文件不再只是数据库里的二进制，而是一个可被 Spring 标准资源抽象管理的对象。

通俗说，GridFS 就像一个仓库：fs.files 是贴在箱子上的标签，fs.chunks 是箱子里按顺序编号的货物。只要标签在，按照编号重新拼接，就能完整取回原文件。

## 03、为什么

MongoDB 文档有单条 16MB 上限，BJSON 传输和内存管理也不适合频繁搬运大字段。GridFS 的设计目标很明确：用分块方式绕开单文档限制，让文件可以分片、可以并行读写，同时把文件元数据留在 MongoDB 里，方便查询。

GridFS 在一些场景下确实有优势。第一，小型受控附件。比如一个商品对应的几张说明页、合同副本、质检报告，数量级可控，单文件一般几百 KB 到几 MB。第二，需要和业务数据强绑定。MongoDB 里本来就有订单、商品、用户等文档，文件的 metadata 可以嵌入业务条件，一次查询拿到文件列表。第三，不想引入额外组件。团队规模小、系统相对单一，用同一套数据库备份和权限管理，开发成本低。

但它不是通用文件存储方案。为什么生产环境里的图片视频，很少默认放 GridFS，而更多选择 OSS/S3？

首先要看负载模型。图片视频是读多写少的大对象，一次写完后通常不再修改，但读取频率高、带宽消耗大。对象存储为这类场景做了优化：海量对象、高吞吐、低单价、跨区域冗余、生命周期分层、CDN 边缘分发。用户访问一个商品图，不需要经过业务数据库，CDN 直接回源对象存储，延迟低、成本低。

如果把这些图片视频放进 GridFS，问题会非常明显。chunks 集合会迅速膨胀，索引、内存、备份、恢复都跟着涨。数据库连接会被大量文件读写占用，影响核心交易查询。备份窗口变长，恢复时间更久。更关键的是，图片视频的访问路径通常不需要经过业务逻辑，用 CDN 就够了，经数据库反而增加一跳。

所以，GridFS 的“能存文件”，解决的是“文件与元数据同库、小规模、受控”的问题，不是“大规模静态媒体分发”的问题。

## 04、架构

在 Spring Boot 应用里，基于 GridFS 的典型访问链路如下。

上传链路：客户端把文件上传到应用服务，应用服务调用 GridFsTemplate.store，传入输入流、文件名、内容类型和 metadata。驱动会在 MongoDB 中先写分块数据，再维护 fs.files 元数据，最终返回文件 ID。应用服务可以把文件 ID 存入业务文档，例如商品表中的 manualFileId 字段。

下载链路：客户端请求下载，应用服务根据文件名或 metadata 查询 fs.files，得到 GridFSFile，再通过 GridFsTemplate.getResource 获取 GridFsResource，将 InputStream 写入 HTTP 响应。

集合索引设计上，fs.files 通常建议对 filename 和 uploadDate 建复合索引，对常用 metadata 字段建索引，比如 metadata.sku、metadata.bizType。fs.chunks 上则对 files_id 和 n 建唯一索引，保证块的顺序和完整性。具体语句可以用 MongoDB 驱动或工具创建。

对比方案 B，对象存储架构是：客户端先请求应用服务拿签名上传地址，然后直接把文件传到 OSS/S3，上传完成后回传对象 key。应用服务把 key、bucket、文件大小、hash、上传人、状态等元数据写入 MongoDB 或关系库。读取时，如果需要公开访问，直接返回 CDN 地址；如果需要私有访问，返回短时签名 URL。

两者差距不在“能不能存”，而在“存储后谁来读、读多少、怎么分发”。GridFS 适合文件量不大、读取路径经过业务系统、需要按业务字段检索的场景；对象存储适合文件量大、访问路径可绕过业务系统、需要 CDN 或跨区域分发的场景。

用一个简单表格对比：

| 维度 | GridFS | OSS/S3 |
| --- | --- | --- |
| 单文件上限 | 理论上可很大，但建议控制在几 MB 到几十 MB | 单对象可达数 TB |
| 海量文件 | 膨胀明显，成本高 | 更划算 |
| 元数据查询 | 直接使用 MongoDB 查询 | 需另存元数据 |
| 访问路径 | 必须经过应用服务 | 可 CDN/签名直连 |
| 备份恢复 | 随数据库整体恢复，数据量越大越痛苦 | 对象版本、生命周期、跨区域复制 |
| 运维复杂度 | 少一套服务，但数据库压力大 | 多一套对象存储，需管理权限与 bucket |

## 05、实战

下面用一个商品说明书 PDF 的保存、查询和下载例子，展示 Spring Data GridFsTemplate 的常用操作。

首先是依赖。Spring Boot 项目中引入 spring-boot-starter-data-mongodb 即可，不需要额外依赖。配置 MongoDB 连接：

```yaml
spring:
  data:
    mongodb:
      uri: mongodb://localhost:27017/shop
```

保存文件。注入 GridFsTemplate，使用 BasicDBObject 构造 metadata，把商品 SKU 和业务类型写进去：

```java
@Autowired
private GridFsTemplate gridFsTemplate;

public String saveManual(MultipartFile file, String sku) throws IOException {
    DBObject metadata = new BasicDBObject();
    metadata.put("sku", sku);
    metadata.put("bizType", "product-manual");
    return gridFsTemplate.store(
        file.getInputStream(),
        file.getOriginalFilename(),
        file.getContentType(),
        metadata
    ).toHexString();
}
```

这里返回的 ObjectId 就是 fs.files 的 _id，可以存到商品文档里。注意 store 方法会读取输入流，调用方负责关闭。metadata 必须可序列化为 BSON。

按文件名查询：

```java
GridFSFile file = gridFsTemplate.findOne(
    Query.query(Criteria.where("filename").is(fileName))
);
if (file == null) {
    throw new RuntimeException("file not found");
}
GridFsResource resource = gridFsTemplate.getResource(file);
InputStream in = resource.getInputStream();
```

按业务元数据查询，例如按 SKU 查找商品说明书：

```java
GridFSFile file = gridFsTemplate.findOne(
    Query.query(Criteria.where("metadata.sku").is(sku))
);
```

下载接口需要把流写入 HttpServletResponse，并设置响应头：

```java
response.setContentType(file.getContentType());
response.setHeader("Content-Disposition",
    "attachment; filename=" + file.getFilename());
StreamUtils.copy(in, response.getOutputStream());
```

如果使用 WebFlux，可以注入 ReactiveGridFsTemplate。保存时传入 Flux<DataBuffer> 和 metadata；下载时拿到 GridFsResource 后，把内容响应给客户端。ReactiveGridFsTemplate 的方法设计与 GridFsTemplate 对称，只是返回 Mono 或 Flux。

最后提醒一句：不要把超大文件或用户公开图片视频直接传到应用服务再写 GridFS。单文件超过 15MB、或者文件数量会快速增长时，优先走对象存储。如果只是少量受控附件，GridFS 确实可以少维护一套存储。

## 06、洞见

技术能力不等于架构默认项。MongoDB 能存文件，不代表你的系统就该用它存所有文件。

GridFS 把文件切块存进数据库，本质上是让文件“像数据一样被查询和管理”。它的强项是元数据索引和业务同库。你只有一个商品 SKU，想查这个 SKU 的所有说明书，GridFS 可以一条查询搞定，fileId 也能作为字段挂在商品文档上。这种场景下，GridFS 比对象存储加数据库元数据要少一层组装。

但图片、视频、音频等大规模静态媒体，特点完全不同。它们动辄几十 MB 到几十 GB，用户访问量巨大，而且大多数访问不需要业务逻辑介入。对象存储在存储成本、带宽成本、CDN 加速、生命周期管理、跨区域容灾方面，都比数据库有数量级优势。把媒体文件塞进 GridFS，短期看省了对象存储的接入，长期看会付出更大的数据库扩容、备份、性能代价。

所以判断依据不是“技术支不支持”，而是流量模型。受控附件是低频、强元数据、小文件、需权限；静态媒体是高频、弱元数据、大文件、重分发。两种流量的最优解不同。

打个比方：MongoDB 存文件就像皮卡能拉货，短途少量没问题；真要跑跨省冷链，还得上专业卡车。GridFS 和 OSS/S3 不是替代关系，而是分工关系。

## 07、行动

如果你正在设计文件存储，建议先分类，再选型。

小型受控附件，可以留在 GridFS。具体动作：限制单文件大小，比如不超过 10MB；限制文件类型，只允许 PDF、DOCX、图片等；把业务字段放进 metadata，并建索引；设置合理的 chunkSize，默认 255KB 通常够用；对 fs.files 和 fs.chunks 做定期归档或清理；把 MongoDB 的备份策略覆盖这两个集合。保存后把 ObjectId 写入相关业务文档，保证可追溯。

大规模静态媒体，放 OSS/S3。具体动作：数据库只存对象元数据，包括 bucket、objectKey、contentType、size、sha256、业务 ID、上传者、状态和时间；上传时优先走签名直传，减少应用服务中转；读取时使用 CDN 或签名 URL；对历史文件配置生命周期规则，比如 90 天转低频，180 天归档；开启对象版本或跨区域复制，满足容灾和合规。

还要做好迁移。如果已经有一批文件落在 GridFS，可以写迁移任务：扫描 fs.files，按批次读取流，上传到对象存储，把 objectKey 和 hash 写回业务表或 metadata，核对数量和大小后，再逐步删除 chunks 数据。迁移期间可以双写，新文件直接走对象存储，老文件保留只读。

最后给一个简单决策顺序：

1. 文件是否超过 15MB？是，走对象存储。
2. 是否海量图片、视频、音频？是，走对象存储。
3. 是否需要 CDN、跨区域高可用？是，走对象存储。
4. 文件是否小于 10MB、数量可控、需要按业务字段查询？是，可以考虑 GridFS。
5. 是否必须与业务文档同库事务？是且文件不多，再考虑 GridFS。

这五步基本能在大多数项目里帮你避开“会存但不该存”的坑。

## 08、小结

GridFS 是 MongoDB 解决大文件存储的一种规范，通过 fs.files 与 fs.chunks 两个集合把文件拆块存放。Spring Data 提供的 GridFsTemplate、ReactiveGridFsTemplate 和 GridFsResource，让存取文件像操作资源一样方便。它适合小型受控附件、文件与业务元数据强绑定、不想引入额外存储组件的场景。

但如果文件是海量图片视频，或者是需要高分发、低成本、生命周期管理的静态媒体，更合适的架构是对象存储加数据库元数据。能力存在，不等于默认选择。把小型受控附件和规模化静态媒体分开设计，才能避免“数据库存了所有文件，结果被文件拖垮”的被动局面。

## 09、链接与概念说明

- GridFS：MongoDB 文件存储规范，定义 fs.files 和 fs.chunks 两个集合。
- fs.files：文件元数据集合，保存文件名、大小、块大小、上传时间、业务 metadata。
- fs.chunks：文件分块集合，保存 files_id、块序号 n 和二进制 data。
- GridFsTemplate：Spring Data MongoDB 提供的模板类，封装 GridFS 的文件保存、查询、删除、下载。
- ReactiveGridFsTemplate：响应式版本，配合 WebFlux 使用。
- GridFsResource：Spring Resource 抽象，可将 GridFS 文件包装为资源。
- OSS/S3：对象存储服务，适合海量、高吞吐、低成本、带 CDN 的静态媒体存储。

参考资料方向：MongoDB 官方 GridFS 规范、Spring Data MongoDB 官方文档、AWS S3 开发指南、阿里云 OSS 开发指南。建议在选型前先做一次容量与流量估算，再决定文件落在数据库还是对象存储。

排查一个商城下载慢的故障时，我们发现商品说明书 PDF 全被编码塞进了 MongoDB。文件单个不大，但数量一多、并发一高，主库 CPU 和网络被拖得很惨。我是老李。这类问题不是第一次遇到。很多团队看到 MongoDB 支持 GridFS，就认为文件存储有了官方答案。今天把 GridFS 的原理、Spring Data 操作方式、以及“为什么生产图片视频还是应该放 OSS/S3”一次讲清。

《Spring Mongo实战》第18招 GridFS别当OSS用

从 Spring Data GridFsTemplate 保存商品说明书 PDF 说起，拆解 GridFS 原理与边界：小附件可控，图片视频等大规模静态媒体建议

架构师

数据库

后端

开发工具

GridFS与OSS/S3选型解析：MongoDB的GridFS分块存储适合小型受控附件，如商品说明书，可支持业务元数据查询。但海量图片视频等静态媒体应使用OSS/S3，避免chunks集合膨胀、数据库连接占用及备份压力。决策依据文件大小、数量及访问路径：大于15MB或高频分发走对象存储，否则可考虑GridFS。

CDN免费试用


2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring Mongo实战》第18招 GridFS别当OSS用-腾讯云开发者社区-腾讯云

《Spring Mongo实战》第18招 GridFS别当OSS用

《Spring Mongo实战》第18招 GridFS别当OSS用

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐