解读

在国内公有云面试中，面试官把 CouchDB 与 Glacier Deep Archive 放在一起问，并不是想听你背 AWS 文档，而是考察两点：

1. 你是否理解 “冷数据—热数据”分层模型 对 NoSQL 归档场景的成本影响；
2. 你是否能把 CouchDB 的复制、压缩、附件机制 与取回策略结合起来，给出可落地的省钱方案。
   一句话：让 Glacier 只做“深度冷冻”，不让它频繁“解冻”，同时把 CouchDB 的存储格式、同步节奏、业务 SLA 全部对齐到“最小化取回”这个目标上。

知识点

• Glacier Deep Archive 国内对标产品：阿里云归档型 OSS、腾讯云深度归档 COS，单价 0.015 元/GB·月左右，取回费用是存储费的 20～50 倍，且按“取回量+早期删除”双重计费。
• CouchDB 附件（attachment） 默认以 MIME 方式内联，每份附件都会生成独立 revision，导致同一份冷数据反复上传，取回时全部计费。
• CouchDB 复制过滤函数 可在源端就屏蔽冷数据，避免把归档库拉回线上节点。
• 压缩+打包：CouchDB 的 JSON 文档本身不可压缩，但把 N 份冷文档合并成 tar.zst 后再作为单附件写入，可将取回对象数从 N→1，费用下降 1～2 个数量级。
• 国内云厂商“批量取回”策略：阿里云归档 OSS 支持“批量回热 1 TB 以内免费”，腾讯云 COS 支持“回热按天计费，24 h 内重复读取不再收费”，合理利用窗口期可进一步摊薄成本。

答案

1. 数据分层：把 CouchDB 集群按“热/温/冷”拆成三个库

   • 热库：SSD，保留 30 天内的活跃文档；
   • 温库：标准 OSS，保留 30～365 天；
   • 冷库：Deep Archive，仅保留 365 天以上且法律要求留存的文档。
     通过 filtered replication 把冷数据从热库剔除，确保线上节点永不触发取回。

2. 写入前打包：在业务层定时（如每周）把待归档的 JSON 文档按 500 MB 一个逻辑分片打包成 tar.zst，以单附件形式写入冷库专用设计文档（_id 前缀固定为 archive/）。这样一次取回无论多少原始文档，都只算 1 个对象+1 次回热费用。

3. 取回策略：

   • 采用 “批量取回+本地缓存 7 天” 模式，利用国内云厂商“首 TB 免费回热”额度，把一周内的所有审计请求集中在一个批量任务完成；
   • 取回后写入 只读 CouchDB 节点（couchdb@readonly），前端查询走该节点，避免二次取回；
   • 若业务必须实时，提前 12 h 提交 “标准取回” 任务，利用国内云厂商“回热按天计费”规则，把 SLA 从 12 h 对齐到 24 h，费用最低。

4. 生命周期兜底：设置 365 天早期删除保护，防止业务误删导致“不足 365 天”罚金；同时关闭 CouchDB 的 attachment compression，因为压缩后大小变化会打乱容量预估，反而增加取回量。

5. 监控与告警：在 CouchDB 端监控 /_active_tasks 中 replication 状态，一旦发现源端有 archive/ 前缀的文档被拉回线上，立即触发告警，防止人为误操作把冷库拉回热库。

按以上五步，取回费用可控制在存储费用的 5 % 以内，且完全满足国内审计合规要求。

拓展思考

• 如果未来业务要求 “秒级回热”，可考虑把冷库再拆两层：Deep Archive 存 3 年，低频访问型 OSS 存 3～6 个月，通过 CouchDB 的 “多源复制” 把低频库作为中间缓冲，实现“冷热双缓冲”架构，取回费用再降一半。
• 对于 跨省容灾 场景，国内云厂商的 Deep Archive 支持“跨地域复制免出流量费”，可以把打包后的 tar.zst 直接复制到异地，CouchDB 端只记录 异地副本的 etag 与版本号，实现“元数据在线、数据离线”的极致低成本容灾。