按访问频率分层
分层存储的基本假设是数据价值随时间衰减：刚产生的数据被频繁读取，之后访问越来越少但必须保留。于是把容量分成若干层，热层性能好但单位成本高，冷层与归档层便宜但取回需要等待。分层策略把「什么时候该搬」写进自动化规则，让容量成本跟着访问模式走，而不是一刀切地全部放在高性能层。
基本信息
| 分层依据 | 最后访问时间、对象创建时间、标签与业务归属 |
|---|---|
| 执行方式 | 生命周期规则自动转移，或由业务主动指定层 |
| 取回代价 | 可能有解冻等待时间与额外请求开销 |
| 容量约束 | 冷层与归档层常有最短存储期 |
典型使用场景
- 日志与监控数据：热存数周用于排查，之后转冷长期留存
- 备份档案：按恢复时间目标把不同批次放到不同层
- 影像与素材库：成品留在热层，原始素材归档
- 合规留存：期限内必须可查但极少访问的数据
- 成本治理：把历史数据从高成本层迁出释放预算
分层流程示意
分层流程示意
# 1) 分析访问模式：取对象访问日志，统计各前缀的读取频率分布
# 2) 定边界：日读 -> 热层；月读 -> 温层；季读 -> 冷层；基本不读 -> 归档
# 3) 配规则：按前缀与天数自动转移，注意最短存储期限制
# 4) 保退路：对可能被重新访问的数据保留快速回温通道
# 5) 常校验：按日志抽样确认对象确实落在预期层层与访问期望
| 层级 | 访问频率 | 取回特点 |
|---|---|---|
| 热层 | 频繁读取，要求低延迟 | 可即时读取 |
| 温层 | 偶尔读取 | 可即时读取，单位成本下降 |
| 冷层 | 很少读取 | 成本更低，取回可能有请求开销 |
| 归档层 | 基本不读，仅作留存 | 需要解冻等待，最短存储期较长 |
设计要点
- 先用访问日志量化频率，再定分层边界，不要按感觉划分
- 转移与过期天数要衔接，避免刚转冷就被清理
- 为可能重新变热的数据准备回温流程，包含等待时间与人工审批
- 多副本与版本会影响分层效果，非当前版本需单独规划
- 分层后定期抽样验证，防止规则写错导致数据落错层
归档不是备份：把数据放进归档层并不会自动多一份副本，容灾能力仍取决于集群自身的冗余与站点规划。
各实现对层的命名、最短存储期与解冻机制差异明显，做成本与恢复时间测算时以目标存储的官方文档为准。