MongoDB存储大文本HTML数据是否应改用GridFS方案？

首先你当前的count操作慢，核心原因和HTML直接存BSON的方案本身没有直接关系，完全不需要迁移到GridFS。

慢查询根因 #

• 单条100-200KB的HTML文档远低于MongoDB单文档16MB的硬限制，本身属于BSON可高效承载的体积范围。30万条该类记录总数据量在30GB~60GB区间，是同记录量级轻量文档集合的数十倍。
• 如果你执行计数用的是countDocuments({})而非estimatedDocumentCount()，该操作会扫描集合索引、校验匹配文档，大文档带来的磁盘IO、内存换页开销会远高于轻量文档集合，才会出现15-20秒的耗时。estimatedDocumentCount()是直接读取集合元数据的统计值，和文档体积无关，正常情况下毫秒级即可返回结果，和轻量集合的计数速度一致。

为什么不推荐用GridFS #

GridFS的设计适用场景是存储超过16MB单文档大小限制的文件，或是需要对文件做分片传输、断点续传、读取文件部分片段的场景，你的需求完全不匹配：

• 100-200KB的文件存入GridFS会被拆分为1个255KB的chunk块+1条files元数据记录，每次按_id查询需要跨两个集合检索，反而比直接存单条BSON多一次查询开销，性能不升反降。
• GridFS没有针对小文件做存储优化，额外的元数据开销会进一步增加总存储体积。

适配你需求的优化建议 #

• 计数操作统一替换为estimatedDocumentCount()，不需要扫描实际文档数据，即可解决计数慢的问题。
• 现有直接存储HTML到BSON字段的方案完全匹配你「仅按_id检索完整HTML」的需求：WiredTiger存储引擎下_id是默认聚簇索引，按_id点查的性能本身很高，不需要做架构调整。
• 如果想进一步提升查询性能，可以将HTML内容做gzip压缩后以二进制类型存入字段，一般HTML文本压缩率可达30%_{20%，总存储体积可降到10GB}20GB区间，大幅提升内存缓存命中率、降低IO开销，业务端查询后做解压即可，计算成本极低。
• 只有当你后续需要将HTML作为静态资源对外提供访问、对接CDN缓存时，再考虑将HTML迁移到对象存储服务，数据库仅存储文件索引即可，当前阶段不需要做这类改造。

内容的提问来源于stack exchange，提问作者Jean DuPont