深色模式
存储成本优化
存储成本 = 容量 × 单价 + 请求数 × 单价 + 流量费。优化的核心思路是：让数据待在与其访问频率匹配的存储层。
适用环境
- 对象存储（S3/OSS/COS/GCS）或自建 MinIO/Ceph
- 了解各类数据的访问频率
- 有日志/备份的保留策略
bash
# 盘点当前存储用量
du -sh /data/* 2>/dev/null | sort -rh | head -20
df -h -x tmpfs -x devtmpfs1
2
3
2
3
操作步骤
1. 按访问频率给数据分类
bash
# 用文件 atime/mtime 粗略判断冷热（atime 需挂载时不带 noatime）
find /data -type f -printf '%A@ %s %p\n' 2>/dev/null \
| awk '{days=(systime()-$1)/86400; if(days>90) cold+= $2; else hot+=$2} END{printf "hot=%.1fGB cold=%.1fGB\n", hot/1024^3, cold/1024^3}'1
2
3
2
3
对象存储则用访问日志或生命周期分析功能：
text
热数据（日均访问 ≥ 1 次） → 标准存储
温数据（月均访问几次） → 低频/近线存储
冷数据（几乎不访问，合规） → 归档存储
冰数据（可删除） → 直接清理1
2
3
4
2
3
4
2. 配置生命周期规则（对象存储）
json
{
"Rules": [
{
"ID": "logs-tiering",
"Filter": { "Prefix": "logs/" },
"Status": "Enabled",
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 90, "StorageClass": "ARCHIVE" }
],
"Expiration": { "Days": 365 }
}
]
}1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
bash
# 应用规则（aws cli 示例，其它云命令类似）
aws s3api put-bucket-lifecycle-configuration \
--bucket my-logs --lifecycle-configuration file://lifecycle.json1
2
3
2
3
归档层有取回成本与延迟
归档/深度归档存储取回需要分钟到小时级，且通常有取回费用与最短保存期（如 90 天）。把可能频繁访问的数据放进归档，反而会更贵。
3. 压缩与格式优化
bash
# 日志压缩：文本日志 gzip 后通常可降到 10%~20%
gzip -9 app.log && ls -lh app.log.gz
# 列式存储替代 JSON（分析场景可省 5~10 倍空间）
python3 -c "
import pandas as pd
df = pd.read_json('events.json', lines=True)
df.to_parquet('events.parquet', compression='zstd')
"
ls -lh events.json events.parquet1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
4. 清理重复与过期数据
bash
# 找大文件（> 100MB 且 180 天未访问）
find /data -type f -size +100M -atime +180 -printf '%s %p\n' 2>/dev/null | sort -rn | head -20
# 找重复文件（按内容哈希）
find /data -type f -exec sha256sum {} + 2>/dev/null \
| sort | awk '{if($1==prev) print "DUP:"$2; prev=$1}' | head1
2
3
4
5
6
2
3
4
5
6
bash
# 数据库侧：清理无用历史表与 binlog
mysql -e "SELECT table_schema, table_name, ROUND((data_length+index_length)/1024/1024,1) MB
FROM information_schema.tables ORDER BY MB DESC LIMIT 20;"
mysql -e "PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);"1
2
3
4
2
3
4
5. 冗余与副本策略审视
text
成本 = 数据量 × 副本数 × 单价
审视三处副本：
- 对象存储的多 AZ 版本
- 数据库的多副本
- 应用层的备份（全量 vs 增量）1
2
3
4
5
6
2
3
4
5
6
非核心数据用单 AZ + 定期异地备份，核心数据才用多 AZ。
6. 快照与备份治理
bash
# 列出超过保留期的快照并按策略清理
# 增量备份 + 定期全量，比每日全量省一个数量级1
2
2
text
推荐保留策略：
日备保留 7 天，周备保留 4 周，月备保留 12 个月
全量每周 1 次，其余为增量1
2
3
2
3
7. 估算优化收益
text
设：总数据 10 TB
热数据 1 TB（标准层，单价 S）
温数据 3 TB（低频层，单价约 0.5S，但有取回费）
冷数据 6 TB（归档层，单价约 0.15S）
优化前：10 TB × S
优化后：1×S + 3×0.5S + 6×0.15S = 3.4 × S
节省约 66%（需扣低频层的请求/取回费用后再评估）1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
务必把请求次数费用算进去：低频层读一次的费用高于标准层，访问频繁的数据放低频会更贵。
验证
bash
# 1) 分层后核对账单的存储类分布
# 2) 确认应用读取归档数据时不会因为延迟而超时
# 3) 抽查恢复演练：归档数据能否在 RTO 内取回
aws s3 ls s3://my-logs/logs/ --recursive --summarize | tail -31
2
3
4
2
3
4
常见坑
无脑全量降冷
把访问频繁的数据降到低频/归档层，请求费和取回费会超过存储费的节省。降冷前必须统计真实访问频次。
生命周期规则误伤
Prefix 写错或 Days 设太小，可能把正在使用的对象删除或转储。规则上线前先在非生产桶验证，并对关键前缀设置 Expiration 例外。
忽略最小存储时长
低频与归档层通常有最短保存期（如 30/90 天），提前删除仍按最短时长计费。短期数据放冷层不划算。
只优化存储不优化备份
备份往往是存储成本的隐形大头，且增长最快。备份策略（全量/增量/保留期）未治理，优化成果很快被吃掉。