如何归档SQL Server中存储的文档以控制Azure DB成本

核心思路是做冷热数据自动分层，不需要全量重构系统、不需要承担高额扩容成本、不需要运维自管磁盘，也不会出现离线备份调文档难的问题，完全匹配场景需求。

具体架构设计 #

按文档访问频率拆分三层存储，整体存储成本可降低90%以上，用户端访问无感知：

• 热数据层：近12个月新增、或近3个月有访问记录的文档，继续保留在现有Azure SQL DB中。按年新增5万份文档、单份文档平均8MB计算，热数据层常年稳定在40-60G区间，距离250G的成本跳涨阈值有充足余量，完全不会触发高价计费。
• 冷数据层：创建满12个月、且近6个月无访问记录的非合规高频调用文档，迁移至Azure Blob冷访问层，存储成本仅为Azure SQL DB的1/20左右，140G存量旧文档存满一年的成本不到百元。
• 归档层：创建满3年、无任何访问记录、仅需满足合规留存要求的文档，自动转储至Blob归档层，存储成本在冷层基础上再降80%，偶发调取时仅需数小时解冻即可访问。

落地步骤（零业务停机，改造量极小） #

1. 最小化代码改造，无需推翻现有逻辑
   仅需在原有文档元数据表新增3个字段即可：
   • storage_tier：tinyint类型，标记文档存储位置（0=SQL热层/1=Blob冷层/2=Blob归档层）
   • blob_uri：varchar类型，存储文档在Blob中的对应路径
   • last_access_at：datetime类型，记录文档最后一次被调取的时间
     原有文档上传、权限校验、版本管理、搜索逻辑全部不需要改动，仅在文档下载/预览的统一入口加一层判断：如果标记为SQL存储就走原有读库逻辑，如果标记为Blob存储就自动拉取对应Blob文件返回，前端用户完全感知不到存储位置的变化，单个开发1-2周即可完成全部改造。
2. 存量文档无停机迁移
   写一个后台常驻迁移任务，按文档创建时间从早到晚分批迁移：每次处理100份符合冷/归档层规则的文档，将SQL中存储的文件二进制流上传至对应Blob层，上传完成后校验MD5值和源文件一致，再清空SQL中对应行的二进制字段、更新存储标记字段即可。13万份存量文档后台跑2-3天即可全部迁完，全程不需要停服，也不会影响正常业务使用。迁移完成后直接执行SQL收缩命令，数据库大小会立刻从200G回落至50G左右，直接消除容量告警。
3. 配置自动规则，零后续运维
   直接在Blob存储侧配置生命周期规则：上传满12个月的文件自动转冷层、满36个月的文件自动转归档层；同时在业务侧加个简单逻辑：每次用户调取冷层/归档层文档后，自动将文件回拷到SQL热层、更新访问时间，后续30天内重复访问直接走SQL读取，兼顾访问速度和成本。整个存储体系自带3副本冗余，不需要额外做磁盘容灾、备份运维，比自管磁盘的稳定性高一个量级。

方案对比原有4个方向的优势 #

• 对比直接扩容承担成本：SQL库容量常年稳定在60G以内，永远不会触发250G以上的高阶计费，冷存储成本几乎可以忽略，整体存储开支下降90%以上。
• 对比转存自管磁盘：不需要采购硬件、不需要做磁盘阵列运维、不需要自己搭文件服务和容灾备份，Blob存储的可用性SLA远高于自运维磁盘，权限管控可以直接复用现有系统逻辑。
• 对比离线备份留存：冷层文档调取响应速度在百毫秒级，和原SQL存储体验几乎无差；归档层文档仅需提交解冻申请，等待1-5小时即可访问，完全满足偶发查阅需求，不需要翻找离线备份介质。
• 对比全量重构对接独立存储：仅修改文档读取入口的少量代码，不需要改动已经稳定运行多年的核心业务逻辑，上线风险极低，不会影响现有业务的稳定性。

可选补充优化 #

如果担心Blob存储的访问安全，可以给每个待访问的文件生成有效期15分钟的临时SAS令牌，不需要开放容器公共访问权限，权限管控粒度和原SQL存储完全一致，不会出现越权访问问题。如果有旧文档全文检索需求，可以配套配置Blob索引，检索旧文档的速度甚至快于原SQL存储方案。

内容的提问来源于stack exchange，提问作者Greg Gum