存储成本模型：云存储计费模式与分层策略

聊 Schema 变更对账单的影响，得先搞清楚云存储到底怎么收费的。我见过不少团队，上来就改表结构，改完发现账单翻倍了，才回头查存储成本模型。说白了，你不懂计费规则，就控制不住成本。

这一章，我把云存储的计费模式、存储分层、数据压缩这三个核心维度拆开讲。每个点我都踩过坑，你跟着走一遍，心里就有底了。

按量付费 vs 预留空间：两种计费模式的博弈

云厂商的存储计费，本质上就两种玩法：按量付费和预留空间。我习惯把它们比作出租车和月票——短途用出租车划算，天天通勤肯定买月票。

我在一家电商公司遇到过这种情况：他们给订单表加了 5 个冗余字段用于报表加速，用的是按量付费。一个月后账单涨了 40%。后来我建议切到预留空间，把基线容量包住，超出的波动部分走按量。嗯，账单直接降了 25%。

存储分层：热、温、冷数据的成本密码

云存储不是一价制。数据访问频率不同，存储单价天差地别。我见过最夸张的案例——有人把 3 年前的日志放在热存储层，每年多花十几万。

存储分层一般分三层：

• 热数据层：频繁读写，延迟低，单价最高。适合在线交易、实时报表。
• 温数据层：偶尔访问，读写频率下降，单价中等。适合近 30 天的历史数据。
• 冷数据层：极少访问，读写延迟高，单价最低。适合归档、合规保留。

具体价格差异有多大？我拿某主流云厂商的公开定价举个例子：

存储层	存储单价（元/GB/月）	读取单价（元/GB）	写入单价（元/GB）	数据最短保留期
热数据	0.12	0.01	0.01	无
温数据	0.06	0.03	0.02	30 天
冷数据	0.02	0.08	0.05	90 天

看到没？冷数据的存储单价只有热数据的 1/6，但读取单价是 8 倍。所以分层不是无脑扔冷层——你得算清楚访问模式。

Schema 变更对分层的影响也很直接。比如你给热数据表加了一个 JSON 列，存储量涨了，热层单价高，账单立竿见影。反过来，如果你把冷数据表的 Schema 简化（比如去掉无用索引），存储量降了，省的钱却不多——因为冷层单价本来就低。所以，成本优化的优先级永远是：热数据 > 温数据 > 冷数据。

数据压缩与编码：被忽视的省钱利器

很多人只盯着存储量，却忽略了压缩率。我习惯说一句话：「同样的数据，不同的编码方式，存储成本能差 3~5 倍。」

云存储一般支持几种压缩/编码方式：

• 行式存储 + 通用压缩（gzip/snappy）：压缩比 2:1~3:1，适合 OLTP 场景。
• 列式存储 + 专用编码（字典/游程/RLE）：压缩比 5:1~10:1，适合 OLAP 场景。
• 混合编码（ZSTD + 列式）：压缩比 4:1~8:1，兼顾读写性能。

举个例子。我做过一个日志分析系统，原始数据 100GB，用行式存储 + gzip 压缩到 35GB。后来改成列式存储 + 字典编码，直接压到 12GB。存储成本从 12 元/月降到 4 元/月——只是改了个编码方式。

Schema 变更对压缩率的影响，很多人没意识到。你加一个高基数字段（比如 UUID），字典编码直接失效，压缩率暴跌。我遇到过有人给表加了 3 个 UUID 列，压缩率从 8:1 掉到 2:1，存储成本翻了 4 倍。所以，设计 Schema 时就要考虑编码兼容性——低基数、重复度高的字段，才能享受高压缩率。

一张图看懂存储成本模型

下面这张图，把计费模式、存储分层、压缩编码三者的关系串起来了。你盯着看 30 秒，就能理解 Schema 变更到底在哪个环节影响账单。

你看，Schema 变更不是直接改账单，而是通过「存储量」「访问模式」「压缩率」三条路径，最终传导到计费模式、存储分层和编码方式上。每条路径都有优化空间，也都有坑。

我个人习惯，每次做 Schema 变更前，先画一张类似的图，把变更后的数据量、访问频率、压缩率预估填进去，再算一遍账单。花 10 分钟做这件事，能省下后面几个月的对账时间。