Grab换数据库，省了一半的钱

出行平台的每一秒，都是数据库的压测现场。

据InfoQ报道，Grab完成了其高流量Counter Service的存储层重构：从一套宽列数据库整体迁移到Aerospike。结果很朴素，但分量不轻——生产环境p99读延迟下降约50%，磁盘占用从3TB降到1TB，单节点成本下降45%到50%。

在一个日均请求量以十亿计的服务里，这三个数字同时成立，说明这不是一次调参式的优化，而是一次彻底的架构判断。

📈 Counter Service为什么撑不住了

先说场景。Counter Service是Grab内部典型的高频计数服务——订单量、司机在线数、活动参与人数这类"数字一直在涨"的业务，都要靠它扛住洪峰。这类服务的技术画像非常明确：读多写多、单键热点集中、延迟要求苛刻，p99一旦抖动，用户端看到的加载圈就多转一圈。

原本的方案是宽列数据库。这在行业里是标准答案，Cassandra式的存储天生适合大规模写入。但标准答案不等于最优解。宽列模型为了通用性付出的代价，在这类单一模式、单键聚合的场景里会持续放大：存储膨胀、compaction开销、以及在高并发读场景下并不突出的p99表现。

据多位接近该类架构演进的一线工程师反映，宽列数据库在计数类服务上的"存储放大"是长期痛点——数据逻辑上很小，落盘后却带着各类索引、墓碑、副本结构，1TB的逻辑数据写成3TB的物理占用并不罕见。Grab这次公开的"3TB降到1TB"，本质上就是把这笔隐性的存储税一次性退了回去。

产业逻辑很清楚：当业务模式足够确定时，通用数据库的灵活性就是成本。 计数服务不需要宽列的schema自由度，它需要的是极小的单条记录、极高的读吞吐、可预测的p99。

🔋 换引擎不难，换引擎不出事才难

真正的看点不在"换成了Aerospike"，而在"怎么换的"。

任何一家有规模的公司都明白，在线核心服务的存储迁移，风险不在目标系统性能不够，而在迁移过程中出一秒的错。Grab的迁移方案是一套教科书式的组合拳，值得拆开看：

第一步是存储抽象。在业务代码和底层存储之间先建一层抽象，让上层不直接依赖宽列数据库的API。这一步本身不产生性能收益，却是后面所有步骤的前提——没有抽象，"可替换"三个字无从谈起。

第二步是数据模型重构。Grab把原来分散的"时间桶"合并成基于map结构的单条记录。原来一个计数器按时间切片拆成多条记录，现在收敛为一条记录内的map字段。这直接减少了记录数量、降低了读放大，也解释了磁盘占用从3TB到1TB的跃迁来源之一。

第三步是影子流量。让真实生产流量同时打到新旧两套存储上，新系统只读不服务，用来在真实负载下观测性能与正确性。这比任何压测环境都真实——流量的热点分布、突发形态，只有线上才有。

第四步是数据一致性校验。逐条比对新旧系统的数据，确认没有一条对不上。

第五步才是渐进切流。流量按比例逐步导向新存储，每一步都留有回退空间。

这套流程没有一步是"聪明"的，全都是笨功夫。但据业内私下流传的说法，很多公司的存储迁移最后出事，恰恰是因为跳过了其中某一步——通常是为了赶时间跳过影子流量或数据校验。

💡 专用数据库的反击：NoSQL大一统叙事正在瓦解

Aerospike在这个故事里的角色值得单独说。

它不是新面孔。这家公司做了十几年TPM（每秒事务数）级别的实时数据平台，长期活跃在广告技术、风控、实时反欺诈这类"延迟就是钱"的场景。它的定位从来不是"什么都能做"，而是"特定负载下做到极致"：内存级索引加SSD级存储的混合架构，让它在p99这个指标上有硬实力。

但过去几年，云厂商托管的通用数据库——DynamoDB、Bigtable式的一站式方案——几乎成了默认选择。理由很充分：不用运维、弹性扩缩、生态成熟。专用数据库在这样的叙事下节节败退。

Grab这次迁移是一次信号：当规模大到一定程度，通用方案的成本曲线会陡然上翘，专用引擎的经济性重新占优。 单节点成本下降45%到50%，在一个数千节点的集群上，是一年数百万美元量级的差距。这不是架构师的审美问题，是CFO看得懂的报表问题。

更广的产业背景是，近年来多个大规模团队都在重新评估"一套数据库打天下"的路线。多语言持久化（Polyglot Persistence）这个老词正在回来——但这次的版本更务实：不是每种业务选一个数据库，而是在成本与可靠性压力足够大的时候，允许专项负载用专项引擎。

很多技术团队看完这条新闻的直觉是："我们也换Aerospike？"

先泼冷水。Grab的收益来自三件事的叠加：负载特征极端（计数类、单键热点）、规模足够大（成本摊得开）、迁移方法论足够克制（五步走，一步不省）。缺任何一条，结果都不会复现。

如果你的计数服务只有几十个节点，宽列数据库运维成熟、团队熟悉，迁移的工程成本很可能吃掉全部性能收益。数据库选型的第一原则从来是负载特征，不是榜单和风口。

但反过来，这个故事里真正值得所有团队抄的，是那五步迁移法。存储抽象、影子流量、数据校验、渐进切流——这套流程和具体换哪个引擎无关，它是所有在线存储演进的安全边界。据业内普遍经验，能把影子流量和数据一致性校验做成基础设施能力的团队，后续每一次存储迭代都会快得多。

🚀 从中台叙事到成本叙事：存储选型回归工程本质

把镜头拉远一点。几年前，大型互联网公司流行"统一数据中台""统一存储层"的叙事——一套基础设施服务所有业务，减少重复建设。这个方向在数据治理维度依然成立，但在存储引擎维度，正在被现实修正。

现实是：负载的异构性是客观存在的。计数服务、图关系、时序数据、全文检索，各自的最优引擎不同。强求统一，等于让所有业务为最不方便的那个场景付存储税。

Grab这次公开的技术细节，本质上是在说一件事：存储选型的决策权正在从"架构统一性"回到"单位成本与p99"这两个可以被度量的指标上。 当经济周期让所有公司重新审视基础设施账单时，这种务实主义的权重只会更高。

对国内的同类团队，这条新闻的参考价值不在Aerospike这个具体产品，而在三件事：给核心服务建存储抽象层、把影子流量变成常规能力、用真实数据说服自己而不是用benchmark说服老板。

数据库没有银弹，只有算得过来的账。

下一步值得观察的是：随着更多公司公布这类迁移的真实成本数据，"通用托管数据库是默认答案"的假设，会不会在超大规模场景里被系统地重写。