.NET Web应用日均增长9GB扫描文档存储优化方案咨询

1. 数据库选型建议 #

该场景不推荐直接在数据库中存储二进制文件本体，如果仅在SQL Server、MongoDB两个选项中选择：

• 若已有成熟的SQL Server运维栈，不需要额外切换到MongoDB，切换技术栈带来的学习、迁移成本远高于收益
• 最优选型是专用对象存储（如自建MinIO），专门适配大文件、低频访问、高写入的场景，比通用数据库的适配性高30%以上

2. 存储优化技术选择 #

三类技术不互斥，可结合场景分层使用：

• 优先做二进制与元数据分离，把文件本体迁移到文件系统/对象存储，数据库仅存储业务关联ID、文件路径、上传时间等元数据，从根源降低数据库存储压力
• 暂时无法剥离数据库存储的情况下，优先按上传时间做表分区，降低单表容量，提升运维效率
• 同步搭配冷热归档技术，超过访问周期的冷数据直接归档到低成本存储层，不占用在线高性能存储资源

3. 超大图片数据库管理最佳实践 #

• 避免在关系型数据库行内存储大容量二进制文件，SQL Server场景可使用自带的FILESTREAM特性存储二进制文件，不要使用普通varbinary(max)行内存储
• 严格执行元数据与文件本体分离的架构，元数据用SQL Server存储，满足业务关联查询需求，文件本体存放到对象存储/文件系统
• 提前定义文件生命周期规则，明确不同时效文件的存储层级、保留期限，到期自动执行清理或归档操作
• 所有扫描文件上传后先做格式压缩，转成高压缩率的PDF/A、WebP等格式后再落盘，避免无压缩位图直接存储
• 定期做存储容量巡检，提前至少1个月准备扩容预案，避免存储占满导致业务故障

4. 容量上限控制与压缩技术使用 #

压缩技术必须使用，扫描类文件无损压缩率普遍可达30%~50%，可直接降低一半的容量增长速度，可选择的压缩手段包括：

• 业务层上传时压缩文件格式，无需依赖存储层能力
• 开启SQL Server页级/归档压缩，或者对象存储的服务端自动压缩，无需修改业务代码
  控制容量上限的核心手段：
• 明确文件最长保留期限，超过期限的文件自动清理或归档到离线存储
• 限制单文件上传大小，比如单份扫描件最大不超过20MB，避免无效大文件占用空间
• 存储层配置容量告警阈值，达到阈值后自动触发归档动作

5. 写多读低频场景适配方案 #

该场景天然适配冷热分层存储架构：

• 热数据（通常为最近3个月内的文件，访问概率较高）存放在高性能SSD在线存储，保证访问效率
• 冷数据（超过3个月的文件，访问概率通常低于1%）直接归档到低成本HDD存储或离线磁带库，冷数据访问走专门的取回流程即可，可降低70%以上的存储成本

6. 存储优化落地方案 #

短期优化（无核心架构改动，1~2周可落地） #

• 将现有varbinary(max)列迁移到SQL Server FILESTREAM存储，利用文件系统IO能力降低数据库负载
• 开启SQL Server冷数据分区的归档压缩，热分区开启页压缩
• 按上传时间做表分区，运维操作仅需处理活跃热分区，大幅降低运维难度

长期优化（架构升级，1~2个月可落地） #

• 全量迁移二进制文件到对象存储，数据库仅保留KB级元数据，数据库容量增长降到可忽略水平，日均9GB的存储增长全部转移到对象存储，运维成本大幅降低
• 配置自动生命周期管理规则，自动完成冷热分层、过期清理、归档操作，无需人工干预

内容的提问来源于stack exchange，提问作者noor arshad