对象存储真能扛住TP数据库的“重活”？OceanBase交出了一个新方案

摘要：以前你要说：“对象存储可以直接用于TP数据库的生产环境”，估计不少人会觉得——不靠谱。但现在，OceanBase推出了“共享存储”产品，正在尝试把这件听上去“不靠谱”的事，变成现实。

数据库发展几十年，说到底是一场“存储形态”不断演进的故事。

从早年的机械硬盘，到现在的SSD、大内存、甚至NVM；从单机部署，到分布式架构，再到如今的多云原生数据库。这背后，其实是一场围绕性能、成本、弹性和可靠性之间的“拉锯战”。

而现在，一个新的问题被摆上了桌面：对象存储，能不能扛起TP数据库的主力存储大旗？

5月17日，在广州召开的第三届OceanBase开发者大会上，“对象存储”被正式请上了TP数据库的“C位”。

OceanBase发布的“共享存储”产品，不仅把对象存储接进来了，而且还进行了深度定制和改造，目标就是：让它扛得住TP业务的高并发和高频访问压力。

这背后的信号挺值得琢磨：数据库架构的变化，已经不只是“兼容新硬件”，而是进入到了一个围绕多云原生基础设施“重构”的新阶段。

TP场景到底难在哪？对象存储为啥一直打不上主力？

TP数据库是什么？说白了就是企业最核心的系统：

• 银行的账户操作、转账记录；

  
  

• 电商的下单、支付、订单流转；

  
  

• 物流平台的调度、签收、路由跟踪……

这类场景有几个共同点：低延迟、高并发、强一致性。要求严苛，一点都不“佛系”。

而对象存储从出生起，走的就不是这条路：

• 它更适合处理非结构化、冷数据，比如日志、音视频、历史归档；

  
  

• 它的访问延迟高，随机IO能力弱；

  
  

• 它的写放大问题，在高频更新场景下很容易“掉链子”；

  
  

• 它的一致性模型弱，很多对象存储是最终一致性……

一句话总结：之前大家不敢把对象存储用于TP主战场，不是没想过，而是真的顶不住。

OceanBase的解法:不是“拼接”,而是“重构”

这次OceanBase干了一件别人不敢干或者说很难做的事——这次推出的“共享存储”产品，并不是简单地加个“对象存储接口”，而是做了底层的全面改造，包括存储引擎、日志系统、调度机制和缓存策略的联动设计。

换句话说，它不是"把大象塞进冰箱"，而是重新造了个“更适合大象住的冰箱”。

根据现场发布的信息，以及老鱼后来采访OceanBase产品总经理杨志丰时了解到的内容，可以看出一些门道：

1、多级缓存架构：用三层设计"绕过"对象存储的慢

为了弥补对象存储在延迟上的短板，OceanBase构建了一套多层缓存体系，目标很明确：让绝大多数请求在前两层就搞定，只有极少数才下沉到对象存储。

• 内存缓存层：承载最热点数据，确保关键事务毫秒响应；

  
  

• 本地持久化缓存层：提升访问效率，解决对象存储随机读慢的问题；

  
  

• 底层对象存储层：用于存储低频访问的大容量数据；

通过“冷热分层+命中率最大化”的设计，OceanBase把对象存储的影响控制在最低限度。

2、自研LSM-Tree引擎：适配对象存储

OceanBase自研的LSM-Tree存储引擎是一种以追加写为主的存储结构，天生适合对象存储的"顺序友好"特性。

OceanBase 在这里做了几个关键动作：

• 规避随机小I/O：对象存储不擅长这个，LSM-Tree擅长顺序读写；

  
  

• 聚合小I/O、异步刷盘、并发控制：降低写放大，提升稳定性；

  
  

• 节流机制+异步提交：应对对象存储IOPS被限流的问题，确保高并发下不被打爆；

3、缓存也能“弹性扩容”，应对业务波动

TP业务一个明显特征是：波动特别大。高峰期冲得猛，低谷期又很“佛”。这对缓存设计提出了更高要求。

OceanBase的本地缓存系统，支持根据业务负载自动扩缩容，这在当前主流数据库中还不多见。热数据多了就自动扩容，业务平稳了又能回收资源，既确保性能，又降低成本。

4、日志架构重构：独立服务化，提升可靠性和资源效率

共享存储版本下，OceanBase也同步改造了日志系统。在传统share-nothing三副本架构中，日志服务分布在每个副本内部。而在新的架构下，日志被抽象成了一个独立服务。

这有什么用？首先可以把日志I/O打包优化，提升吞吐和稳定性；其次，日志可以在集群间复用，带来更好的资源复用率和更低的成本。更重要的是，也为未来更弹性的跨集群部署打下基础。

5、支持Serverless弹性：异步化设计提升计算性价比

为了让数据库更贴近多云原生的使用模型，OceanBase也在探索Serverless方向。例如，通过拆解Compaction、DDL、备份恢复等重I/O任务为异步后台任务，再配合Spot节点调度，在实现存算分离的同时大幅降低计算成本。

同时，本地无状态设计也使得数据库节点可以根据负载自动扩缩、跨集群调度，进一步提升资源弹性和整体利用率。

6、全链路调优：从链路设计到副本同步压低波动

最后，为了保障TP负载对稳定性极度敏感的需求，OceanBase还对整条访问链路进行了调优。包括I/O调度策略、缓存命中策略、预取机制，以及跨可用区的副本同步方式，目标是尽可能压缩波动区间，保证即使遇到抖动也不会影响事务稳定性。

正是这些技术难点的逐一突破、这些工程能力的系统构建，使OceanBase成为目前业内唯一能够在TP场景下稳定运行对象存储的多云原生数据库。

从架构变革看行业趋势：这件事的意义在哪？

如果说Snowflake和Databricks重新定义了数据分析的"存算分离"范式，那么OceanBase这次的"共享存储"方案，则是在TP数据库领域打开了一扇新的门。

传统TP架构大多采用shared-nothing模式，数据与计算节点强绑定。性能强，但带来的问题也不少：扩缩容困难、资源利用率低、跨云迁移复杂。

而OceanBase这次祭出的"共享存储"方案，本质上是给TP数据库装上了多云原生引擎：计算和存储分开，多云环境随便跑。

换句话说——TP系统终于不用再被本地磁盘绑架了，相当于直接撬动了TP系统的最大成本壁垒。

官方数据说，在TP场景下可节省约50%的存储成本；在AP场景，AI、数据湖等混合负载下，整体成本甚至可以降到传统架构的1/10。

据了解，OceanBase共享存储产品尤其适合海量数据、冷热数据特征明显、对成本敏感的业务场景。比如典型TP、历史库及备份库，时序类业务、HBase兼容类业务、流水型业务系统、OLAP业务等。

对象存储是否真的能扛起TP系统的重任？目前还没有定论。但OceanBase用行动证明：路是人走出来的。虽然现在还没到大规模商用阶段，但至少证明了：这条路，是能走通的。

从更宏观的角度看，这背后也透露出几个行业趋势：

• 存算分离走向更深融合：对象存储的引入，是存储进一步云化、解耦化的一个体现；

  
  

• 数据库开始更重视"成本-性能"的平衡：不再一味追求极致性能，而是要考虑弹性、成本、可维护性；

  
  

• TP/HTAP/AP的边界越来越模糊：在 AI、IoT 等新型场景下，TP 和 AP 的边界越来越模糊，一套体系同时支撑多种负载，才是真正的“现代数据库”。

写在最后：为什么是OceanBase？

值得一提的是，OceanBase作为一家纯自研的国产数据库厂商，其在存储引擎、分布式架构、一致性协议等关键技术上始终坚持"底层自控"，这为其推动"对象存储进入TP核心"提供了足够的工程主动权。

在过去十余年里，OceanBase已在大规模分布式事务、高可用架构、SQL引擎等核心能力上积累深厚技术储备。这一次面向多云原生的"共享存储"产品发布，是其将工程能力向未来存储体系延展的一次尝试。

未来对象存储是否能真正成为TP数据库的“长期搭子”？目前尚需时间验证。但可以肯定的是，对象存储+TP数据库的组合模式，已经不再是"不可想象"的未来设想，而是一个可被工程化落地的方向。

在AI与大数据驱动的新业务浪潮下，数据库行业需要更低成本、更高灵活性的新型架构。"共享存储"产品的推出，是OceanBase迈出的重要一步，也可能为行业提供新的启发。