摘要

  • IBM Cold Vault 的最低计费对象大小为 256 KB，最低保存期为 90 天。一个假设的 4 KB 对象，容量计费基数因而是实际体积的 64 倍。总费用还取决于价格、时间、请求和读取。
  • 小对象是否分开保存，是一项会写进账单的产品设计。压缩、打包和选择储存类别，必须连同独立读取、删除及恢复的成本一起算。

先收房费，再谈折扣

把一个 4 KB 的小对象放进 IBM Cloud Object Storage 的 Cold Vault，账单上的房间会宽敞得多：256 KB 起租。内容只坐了一个角落，计费面积已经铺满整间套房。

这里的 4 KB 是用来算账的假设，256 KB 则来自 IBM 公布的最低计费对象大小。IBM 同时给 Cold Vault 规定了 90 天的最低保存期。Vault 的门槛较低：128 KB、30 天。Standard 和 Smart Tier 没有这两项最低限制，也不收读取费。请求、对公网传输等费用仍需另外看。储存类别说明

冷储存的名字很会让人放松警惕。文件不常读，放到听起来更安静的地方，价格应该更低。问题是，报价里的“每 GB”与企业电脑里统计的“总共多少 GB”，未必使用同一把尺子。对象大小的最低门槛，先改了被乘数，再轮到单价登场。

256 除以 4 等于 64。对这样一个对象，Cold Vault 的容量计费基数是内容大小的 64 倍。Vault 则是 32 倍。这个倍率只描述容量基数。把它直接印成“IBM 收贵了 64 倍”，等于用一句更响亮的话毁掉一道本来很有用的算术题。

更有用的问法是：如果全是一模一样的 4 KB 对象，而且保存时间已经满足最低期限，Cold Vault 的容量单价要低于 Standard 的六十四分之一，容量这一项才会更便宜。

实际报价是否跨过那条线，需要看适用地区和合同。读取、请求、传输与未满最低保存期的成本，还会继续改写总数。

财务看到一堆字节，系统看到一百万个边界

采购表通常喜欢一个总量：今年多少数据，明年增长多少。对象储存还有一个同样重要、却更容易被藏起来的量：这些数据被切成了多少份。

假设两套应用保存相同的内容。一套把许多小记录分别写成对象，另一套把它们装进较大的包。第一套会反复撞上每个对象的最低计费体积；第二套只在每个包上碰一次门槛。总内容相同，计费容量可以不同。供应商没有替客户制造更多内容，客户也确实买到了更多计费单位。

单看平均对象大小仍可能误判。几个很大的文件可以把平均数抬高，下面却藏着大量小对象。需要看的，是大小分布，以及各区间到底有多少个对象。

最朴素的容量计算，是逐个对象取实际大小与该类别最低大小中的较大值，再相加。把总字节数先加起来，再对整个桶应用一次最低值，会把这条规则算错。

IBM 的计费文件还把储存量、请求和对公网传输分开，并说明一个实例内同一储存类别的使用量会跨桶汇总。汇总发生在账务层，不能把每个小对象的门槛想象成一个能够靠大文件填满的公共零钱罐。计费说明

这也是压缩最容易遭遇的尴尬。一个已低于 256 KB 的对象，再压小一些，内容确实少了，Cold Vault 的最低计费体积却仍在那里。工程师交出一张漂亮的压缩率图，财务收到的容量账未必跟着瘦身。两边都可能没算错，只是优化了不同的量。

打包有收益，也有脾气

把小对象装成大包，看起来像一道简单的省钱题。省下来的最低计费单位，很快会引出另一道题：以后谁负责把东西取出来？

独立对象的好处非常具体。一个条目可以有自己的名字、读取边界和删除动作。

装进大包后，应用得知道它在包里的位置，维护索引，并决定如何处理单条更新、删除与恢复。某些设计能只读取所需片段，某些访问方式会搬动更多内容。差别要由应用与格式共同回答。

因此，打包的收益不能只写成“对象数下降”。若一条小记录经常被单独修改，原来清楚的更新边界可能变成一次包的重写。如果业务需要逐条删除，就得先设计删除如何真正落到储存内容上。把成本从容量列搬到请求、读取、工程工时或恢复操作列，财务不会凭空变富。

这不是要替小对象辩护。分散保存与打包保存，分别买了不同的操作自由。最低计费规则只是给这种自由标出了价格，让原本藏在架构里的选择走到了采购桌上。

类别也不是一个随时可拨的温度旋钮。IBM 的文档说明，储存类别在建桶时选定，现有桶不能原地改成另一类别。要换类别，需要把对象移到或复制到目标桶。类别配置 桶规则

于是，“以后换便宜的就好”还欠着一笔迁移工作。目标桶、对象复制、应用指向和核对都需要安排。选择留下或迁走都可以有道理，但只有把这笔工作算进去，便宜才是一个经营判断，而不是一个按钮的想象。

真正值得采购的那张表

这篇文章缺少某一家客户的对象大小分布、保存与读取模式，以及适用报价。有了这四项，才能算出具体节省额。

即便如此，采购的次序已经很清楚。先看对象群体，再比较单价。把大量低于最低体积的对象、经常提前删除的对象，以及需要频繁独立读取的对象分开看。一个“冷数据”标签，概括不了它们的经济行为。

IBM 把规则写在公开文件里，买方有机会在签字前算清楚。最昂贵的疏忽，是把储存类别名称当成商业结论，让架构团队决定对象粒度，却让采购团队只对每 GB 的折扣负责。两张表看似各尽其职，接缝处恰好足够放下一间 256 KB 的套房。

原始资料

本文依据 IBM 的储存类别、计费与桶文档。RIPE NCC 会员记录仅用于核对 International Business Machines Corporation 的名录身份。4 KB 算例为本文明确设定的假设。