华为云 OBS 对象存储：海量数据存储与管理实战

第 0 天起      → 标准
第 30 天起     → 低频
第 180 天起    → 归档
第 365 天起    → 删除（或再降一档）
```

三个必须注意的点：

1. **前缀/标签要能真的区分数据。** 如果所有对象都堆在同一个前缀下，"分阶段"就无从谈起——**生命周期规则的设计，实际上是在要求你设计 key 的命名结构**。
2. **删之前要确认没有依赖。** 备份目录被删掉一周后才发现，这类事故的根源是"没人知道这个桶里有什么"。
3. **最短存储期与转档时间要互相兼容。** 转入归档后立即删除，可能付出比"多存一个月"更高的成本。

## 四、上规则之前，先看访问分布

这是我最想强调的一条实践：**在写生命周期规则之前，先确认访问模式真的符合你的假设。**

原因很实在——**规则一旦生效，它就开始改变数据的位置；而"冷档"的数据要重新变热，是需要代价的。** 如果假设错了，你要做的是反向搬运，成本比当初省下的高得多。

可用的判断材料通常是这几样：

- **访问日志**（开了服务端日志的话）：谁在什么时候读了哪些前缀。
- **监控指标**：请求次数与流量按前缀/类别的分布。
- **应用侧的知识**：哪些数据是"冷备但必须能立刻取出"（比如合规留存、事故取证）——**这类数据不该进归档档**，因为它的要求是"随时可取"，与"便宜"是直接冲突的。

最后这一类数据常被误放进归档，然后在下一次审计来临时集中取回，账单出现一个尖峰。**"合规要求保留"不等于"可以放最冷的档"**——要看的是"被取出时的时限要求"。

## 五、请求费被放大的三种情形

小文件场景下，请求费往往比存储费更值得关注。它主要在三种情形下被放大：

1. **海量小对象**：同样 1TB 数据，1KB 一个对象和 10MB 一个对象，请求次数差四个数量级。**聚合小文件**（打包成归档格式）几乎总是划算的。
2. **列表操作**：`list` 类操作按次计价，遍历超大前缀很贵。**目录式的穷举查询在大桶上是反模式**——需要索引就自己维护一份，别指望用列举代替数据库。
3. **重复取回**：没有客户端缓存的读取会把同一次请求重复付很多遍。加一层 CDN 或本地缓存，往往比换存储档位省得更多。

第 2 条还有一个非成本的理由：**超大前缀的列举会变慢**，而且慢得不稳定。这在删除整个目录这类操作上会变成运维体验问题。

## 六、对象存储没有"目录"，这个事实会漏进应用设计

对象存储的 key 是平坦的，`a/b/c.txt` 里的斜杠只是字符。这个事实会以几种方式漏进应用：

| 你的直觉 | 实际的语义 | 后果 |
| --- | --- | --- |
| "删除这个目录" | 逐个删除匹配前缀的对象 | 大前缀上耗时且可能部分失败 |
| "重命名目录" | 复制 + 删除 | 大目录上是 O(n) 的数据搬运 |
| "文件已被覆盖" | 版本控制开启时旧版本仍在计费 | 容量增长但没人知道原因 |
| "读到的就是最新的" | 有版本控制/多段上传时语义更复杂 | 读到中间状态 |

第三行特别值得留意：**版本控制是好功能，但它的成本效应是"删除不等于释放容量"。** 如果开了版本控制又配了生命周期删除，规则里通常需要同时处理"当前版本"和"历史版本"——只删当前版本的规则，在这个桶上几乎不省空间。

## 七、这篇没写什么

- **没写具体价格与档位名称。** 这些变动频繁，请以官方价格页为准；这篇讲的是结构，不是数字。
- **没写 SDK 用法与签名机制。** 那是接入层的内容，且各语言 SDK 差异不小。
- **没写跨区域复制与灾难恢复。** 这是一个独立课题（RPO/RTO、复制费用、删除的传播语义），塞进来会两边都讲不透。
- **没给生命周期参数推荐值。** 30/180/365 只是结构示例。**真正该由访问日志决定**——没有日志就定规则的，是在赌。

一句话收束：对象存储的省钱办法，从来不是"选更便宜的档"，而是**先回答"这份数据多久会被读一次、被读时要多快拿到"**。这两个问题回答不了，再便宜的价格表也用不对。