概述
更新时间:2025-06-08
存放在 BOS 中的文件通常会发生归档下沉、删除等涉及到文件生命周期的操作。一般情况下,文件在新建后的短期内会被频繁读取访问,随着时间的推移,该文件的读取次数将变少,进而变成"冷文件",即不再被频繁的访问。到最后,该文件将会被最终删除。用户如果手工维护数据的生命周期,则费时费力;但如果不去维护,则数据始终存放在标准存储里会产生不菲的费用。因此,BOS 提供生命周期管理功能,以帮助用户自动化地完成数据的生命周期管理,实现数据从创建到归档到删除的自动管理流程,从而节约人力和存储费用。
文件生命周期管理方式
- 为了使数据管理更加便捷与智能,我们在保持【基础生命周期管理】(原生命周期管理)的基础上,又支持了【智能分层】,智能分层不仅可根据文件访问频次进行自动沉降,也可根据文件的访问情况进行智能冷热转化,自动升级至标准或低频存储,该功能提供了数据存储的成本与读写性能最优解决方案。
- 在基础生命周期中在基础基于前缀进行细化管理的能力上,又扩展支持设置对象标签功能(Tag)、目录排除(Not)、文件大小过滤(Filesize)、对象多版本的生命周期管理功能,可细化生命周期操作粒度。
智能分层与基础生命周期管理区别
方式 | 规则配置 | 适合场景 | 转化模式 | 转化存储类型 |
---|---|---|---|---|
智能分层 | 一键开启 | 访问模式不固定或者无法预估访问模式的数据 | 支持数据降冷,也可按需回暖 | 不支持归档与多az存储类型,其余均支持 |
基础生命周期管理 | 需自定义管理规则 | 1.可预估访问模式 2.需要精细管理 |
单向降冷 | 全部支持(多版本暂不支持归档) |
功能说明
存储桶仅支持配置【生命周期管理】或【智能分层】,二者不可同时设置。
智能分层
- 存储桶开启智能分层,系统将周期性地监测数据访问次数,在持续一段时间没有数据访问时,将数据转移至存储成本更低的访问层。如果数据重新被访问,则会被重新转移到高频访问层上,保障数据读取性能。
- 支持文件从标准存储-〉低频存储-〉冷存储 或冷存储-〉低频存储-〉标准存储;
- 可配置删除文件与碎片(分片上传任务中,未完成的文件碎片)定期清除,支持按照指定固定天数后执行删除操作, 规则中计算起始时间以 Object 的创建时间为准,删除优先级高于转化,到期会执行删除;
- 配置规则后您可通过控制台存储桶数据分析查看单个存储桶沉降与回暖数据量。
智能分层注意事项
- 不支持转化为归档存储,标准存储-多AZ,低频存储-多AZ;
- 存储桶仅可配置一条规则。
基础生命周期
基础生命周期管理支持如下功能
- 自定义时间换存储类型,从标准存储转低频存储、转冷存储、转归档存储;或从标准存储-多 AZ 到低频存储-多 AZ;
- 定时删除不再需要的数据;
- 清除过期的三步上传数据。
从场景上划分,基础生命周期管理支持两种模式
- 数据达到一定寿命后自动归档:如定义所有创建时间超过30天的数据自动转为存储费用更为低廉的低频存储;
- 数据达到一定寿命后自动删除:如定义所有创建时间超过30天的数据自动删除。
从规则配置上划分,基础生命周期管理支持简单与复杂模式
- 简单模式:定义规则中仅还有指定生效文件范围设置仅配置前缀或存储桶全部文件(不包含多版本对象);
- 复杂模式:定义规则中包含指定生效文件范围设置包含对象标签、排除某些文件、指定文件大小、对象历史版本中的任意一种配置。
复杂生命周期规则管理支持功能
- 支持设置对象标签,支持指定标签沉降删除Object。
- 支持设置目录排除,排除目录外的Object以及指定对象标签。
- 支持设置文件大小,支持对指定文件大小范围内的object进行沉降删除。
- 设置多版本生命周期, 支持对历史版本进行删除。
特别提示
存储桶生命周期管理规则复杂和简单模式,表现在对文件的转化与删除的执行规则的区别。
- 简单模式:对冲突的多条简单规则会按照“精细化执行”的逻辑,例如:规则 1:当设置 a/b/ 目录下文件创建满 180 天删除;规则 2: a/b/c 目录下文件创建满365 天删除,执行结果为a/b/c/1.txt 文件会在创建满365 后执行删除,而a/b/2.txt 则会在创建满180 后执行删除。
- 复杂模式:对冲突的多条复杂规则会按照“全局最优执行”的逻辑,且删除优先。例如规则 1:当设置 a/b/ 目录下文件(未配置历史版本)创建满 180 天删除;规则 2: a/b/ 目录下文件配置 365 天删除,并且排除 a/b/test目录,执行结果为a/b/c/1.txt 文件会在创建满180 天后执行删除,a/b/test/2.txt 也会在 180 天后删除。
- 存储桶中若创建一条复杂规则,则存储桶生命周期管理整体应用复杂规则执行
基础生命周期注意事项
通用注意事项
- 每个 Bucket 可以有至多 1000 条规则;
- BOS 生命周期规则设置后会在一天内生效;
- 规则生效后,BOS 会对符合条件的 Object 进行相应的处理,但处理需要一定的时间,不一定能马上看到效果。一般情况下,沉降或删除的时间为几小时,但若沉降数据量较大,则可能会在几天甚至更长的时间完成下沉或者删除;
- 规则中计算的时间(即 Object 的“年龄”)以 Object 的创建时间为准,而不是生命周期规则的创建/修改时间;
- BOS 只保存文件的最后修改时间,即 last-modified 时间;如果您不更新 meta 或者覆盖文件,那么 last-modified 就是创建时间。所以生命周期中的“创建时间”其实是 last-modified 时间。
- 基于文件访问时间记录的生效策略,目前仅北京和苏州区域支持。
- 低频存储、冷存储和归档存储的最低存储时间分别为 30 天,60 天和 180 天。您配置的生命周期沉降/删除规则需要满足最低存储时间的要求。若您配置的时间小于最低存储时间时间,控制台将会产生提示,请您根据提示中的要求进行配置。
- 单 AZ 类型文件仅能沉降到单 AZ 类型文件,无法沉降到多 AZ 类型文件;标准存储-多AZ 类型文件只能沉降到低频存储-多 AZ 类型文件。
- 发生生命周期沉降时,原类型若需要取回,则会产生取回费用。同时,沉降完成后,原类型文件会被删除,也会产生请求费用。比如,一个低频存储类型文件沉降到冷存储,那么 BOS 需要先获取原低频存储文件,该操作产生取回费用;当文件成功沉降为冷存储文件后,原低频存储文件会被删除,该操作产生 Delete 请求费用,该请求费用包含在写请求费用中。
- 生命周期暂不支持对通过追加上传所生成的 Appendable Object 进行层级转换。
复杂生命周期规则注意事项
- tag的规则设置: 每个规则最多有10个对象标签,每个key长度小于等于128, value长度小于等于256。
- 每个rule下只有1个排除目录, 开启Not选项时,前缀和标签必须至少存在一项,即同时设置前缀和标签或者只设置前缀或标签,Not中的前缀或标签只有一个;排除前缀必须位于设置前缀之下,并和前缀的结构形式一样,例如前缀是 bucket/prefix , not prefix可以是bucket/prefix1
- 指定最小文件指定生命周期规则作用的最小文件大小,最小文件大小要求大于等于0字节,小于5TB。
- 指定最大文件指定生命周期规则作用的最大文件大小,最大文件大小要求大于0字节,小于等于5TB。
基础生命周期简单与复杂生命周期规则在执行层面的区别:
- 简单生命周期语义: 按照的是最长前缀的原则, 如果命中最长前缀,那么就不会去寻找其他规则。
- 复杂生命周期语义会寻找全局最优规则, 寻找符合prefix、 not、 filesize、 tag的规则下最早执行的规则。
- 了解更多功能细节,请参考开发者指南-基础生命周期管理。
配置方式
1.控制台操作
- 基础生命周期,参考配置基础生命周期管理;
- 智能分层,参考配置基础智能分层。
2.相关API操作
- PutBucketLifecycle 接口:使用 PutBucketLifecycle API 接口创建生命周期管理规则。
- GetBucketLifecycle 接口:使用 GetBucketLifecycle API 接口获取定义的生命周期管理规则详细信息。
- DeleteBucketLifecycle 接口:使用 DeleteBucketLifecycle API 接口删除定义的生命周期管理规则。