此前由 OceanBase 团队撰写的两篇论文被数据库领域国际顶级会议 VLDB 2026 正式录用。两篇论文分别介绍了 OceanBase 在“云原生共享存储架构”方向上的工程突破与创新实践以及在海量分区、动态负载均衡与跨分区分布式事务场景下的核心突破。目前这两项创新成果均在 OceanBase 生产体系中落地并取得显著成效。立即试用 OceanBase 企业版体验国产数据库能力180 天免费试用零门槛开通添加图片注释不超过 140 字可选添加图片注释不超过 140 字可选论文《OceanBase Bacchus: a High-Performance and Scalable Cloud-Native Shared Storage Architecture for Multi-Cloud》系统阐述了 OceanBase Bacchus 在“云原生共享存储架构”方向上的工程突破与创新实践。论文提出面向服务的 PALF 共享日志、共享块缓存服务、多层缓存与预热机制等核心技术创新为新一代云原生数据库的设计提供了完整参考。OceanBase Bacchus即 OceanBase 4.4.x是 OceanBase 自研的分布式云原生共享存储数据库系统在保留完整 ACID 事务能力的同时实现了存算分离、弹性扩缩容与多云原生部署已在公有云产品中完成规模化落地。在 SysBench、TPC-H、TPC-DS、ClickBench 等主流基准测试中OceanBase Bacchus 在 OLTP 场景下将存储成本降低 59%OLTP和 89%OLAP。100TB 数据量下Bacchus 与前代 OceanBase 存储成本对比OceanBase Bacchus 拥有三大核心技术。核心技术一基于 PALF 的共享日志服务化传统共享日志架构如Aurora、Socrates采用单写入者Single-Writer模式所有写入都通过主节点追加到共享日志存在明显的主节点瓶颈。Bacchus 通过引入PALF日志服务解决问题。设计核心分片日志流 多读写 Leader图1PALF共享日志示意图Bacchus 采用面向服务的日志架构基于 OceanBase 自研的 PALFPaxos-based Append-only Log Framework共识协议实现日志分片Log Stream Sharding数据被划分为多个日志流每个流对应一个逻辑分区。每个流有独立的 Leader 负责向 PALF 追加提交日志CLog单流单写入者避免了日志层的写入冲突。水平扩展多个 RW读写节点通过领导不同的日志流实现写入的水平扩展打破了经典共享日志的单写入者瓶颈。ACID 保障跨分区事务通过分布式 2PC两阶段提交协调多个流 Leader在实现分区级并行的同时保证全局事务一致性。RPO 0 的可靠性Bacchus 分离了两条持久化路径提交路径RPO0事务提交仅在 CLog 通过 PALF 复制并被多数派LogServer 持久化后才向客户端确认确保数据零丢失。归档路径PITR近实时归档异步将日志上传到对象存储用于时间点恢复和快照归档进度不影响事务提交。默认部署中每个 PALF 流在三可用区AZ的三台 LogServer 上复制2-of-3提交即使单 AZ 故障也能保证 RPO0。核心技术二共享块缓存服务对象存储的单次读取延迟高达50–100ms远超 OLTP 毫秒级响应要求。Bacchus 设计了三层缓存架构在对象存储与 OLTP 之间搭建高性能缓存层。图2三层缓存架构三级缓存层次结构内存缓存Memory Cache最热数据常驻内存微秒级访问用于存储最热的微块和索引数据。本地持久化缓存Local Persistent Cache本地云盘缓存跨重启保持数据缓解缓存雪崩和冷启动延迟同时作为写入缓存持久化元数据和最新变更日志。分布式共享缓存Distributed Shared Cache在各 AZ 内部署BlockServer 集群以宏块粒度缓存温数据供同 AZ 的 RW/RO 节点共享消除冗余副本。缓存预热机制OceanBase Bacchus 提供多种预热策略确保缓存命中率基线切换预热、主从预热、复制迁移预热、弹性扩缩容预热。生产环境实测显示OLTP 场景下私有宏块缓存命中率保持 100%共享宏块和整体命中率接近 100%对象存储读取被有效屏蔽。核心技术三LSM-Tree 对象存储的深度融合OceanBase充分利用 LSM-tree 与对象存储的天然契合——LSM-tree 的 SSTable 采用追加写模式与对象存储的追加特性完美匹配避免了原地更新和写入冲突。多级分离架构存储与计算分离无状态计算节点通过共享缓存和日志服务访问数据支持独立弹性扩缩容。日志与数据分离CLog 使用低延迟云盘老日志迁移到共享存储持久数据存于对象存储热数据缓存在本地。前台与后台分离压缩、DDL 等后台任务在独立进程中运行与前台流量隔离提升 CPU 利用率。冷热数据分层内存缓存最热数据本地缓存热数据对象存储冷数据实现成本与性能的最佳平衡。智能 Compaction 策略图3Bacchus的micro/mini/minor/major合并流程图4数据写入过程Micro Compaction在 Mini Compaction 之前进行micro compaction生成micro SSTables提前推进检查点降低弹性扩缩容成本加速故障恢复。Major Compaction主要在共享存储层独立运行计算节点无感知合并增量数据与基线数据。Compaction 卸载将计算密集的压缩任务卸载到空闲机器执行进一步分离存储与计算。多云原生支持OceanBase Bacchus 通过 S3 兼容接口支持多云对象存储AWS S3、阿里云 OSS、Azure Blob、MinIO 等避免厂商环境限制实现真正的灵活多云部署。最后总结一下基于这三项创新构建了一套生产级的多云原生共享存储架构实现了Stateless 计算节点支持计算、缓存、存储独立弹性扩缩容零数据丢失RPO0 的可靠性保障极致成本优化OLTP 存储成本降低 59%OLAP 降低 89%多云原生部署支持 AWS、阿里云、Azure 等多云平台避免厂商锁定卓越性能表现OLTP 与 HBase/Aurora 相当或更优OLAP 显著超越StarRocks基于实际部署经验团队总结出九大工程洞见对象存储需要 I/O 聚合与批量操作按集群/租户隔离存储桶实现 I/O 隔离与独立计费多种分离策略存算分离、读写分离、日志数据分离、前后台分离缺一不可日志服务是计算节点无状态化和高性能的关键本地微块 共享宏块缓存组合效果最佳多级缓存预热与热数据自动识别至关重要基于日志服务的分层元数据管理高效可靠统一多云架构可服务 OLTP/OLAP/KV 多种负载弹性缓存扩容与监控是控制尾延迟的关键未来OceanBase 团队将持续探索对象存储 I/O 模式优化、自适应缓存调度、跨云容灾增强、以及 Serverless 数据库形态等方向推动云原生共享存储架构从“可用”走向“极致高效”。添加图片注释不超过 140 字可选论文《A Tree-Structured Two-Phase Commit Framework for OceanBase: Optimizing Scalability and Consistency》系统性阐述了 OceanBase 在海量分区、动态负载均衡与跨分区分布式事务场景下的核心突破以日志流Log Stream 替代传统「一分区一参与者」的 2PC 模型提出树形两阶段提交Tree-Shaped 2PC 框架在保持 ACID 与线性一致性的同时将协调开销降低数个数量级并已在 OceanBase 4.x 生产体系中规模化落地。OceanBase 在 4.0 起采用以日志流Log Stream为核心的架构将共置在同一机器或资源单位上的分区 leader 映射到同一日志流共享单机日志与 Paxos 复制。这为「以日志流为协调单元」提供了天然基础。团队据此提出树形 2PC 框架同时攻克静态事务极致性能与动态迁移下的一致性。迁移过程中递归构建的日志流树核心技术一日志流作为合并参与者设计核心从「按分区 2PC」到「按日志流 2PC」在同一台机器上多个分区共享一条日志流。框架将整条日志流注册为一个 2PC 参与者而不是为每个分区单独注册。一笔触及 N 个共置分区的交易在提交阶段只与一个日志流参与者交互。效果当 N100 时协调参与者数量减少约 99%静态场景下事务延迟可逼近单机水平论文中典型约 1.2 ms显著降低 RPC 扇出、日志同步压力与参与者列表带来的网络带宽消耗。这与「数据面仍以分区做并发控制」并不矛盾分区仍是读写与锁的单元原子性边界上移到日志流从协调维度完成合并。图2按分区3.x与按日志流4.x的2PC 提交延迟对比核心技术二动态树形 2PC设计核心迁移中在线构造提交树无需显式更新参与者列表当分区在事务执行期间发生迁移时源日志流在上下文中记录目标日志流通过递归追踪形成一棵日志流树Log Stream Tree。定理保证该树满足 ACID 所需的最小参与者集合要求。在此基础上树形 2PC 将协调者与参与者组织成树内部节点对其子节点充当协调者对其父节点充当参与者Prepare/ Commit 消息沿树向下传播降低相对「扁平协调者直连所有叶子」的扇出与经典 R* 层次 2PC 不同节点是日志流而非静态站点边可在提交过程中因迁移而动态出现。迁移上下文作为叶子嵌入避免显式维护全局参与者列表、化解循环依赖并在拓扑变化下仍保证线性化提交。延迟优化协调者复用参与者日志、在收到全部 Prepare确认后即可应答客户端不必等待协调者 Commit 日志落盘在常见浅树和静态路径下将关键响应路径压缩为两轮 RPC 一次关键 I/O。图3树形 2PC 状态机图4分区迁移与树形 2PC 并发时的参与者维护核心技术三未知状态机制设计核心参与者丢上下文时「不说谎」层次 2PC 的经典隐患是参与者回收上下文后对重试请求可能返回错误的 Prepare 投票「说谎参与者」导致已提交事务被误中止。图5说谎参与者导致错误回滚OceanBase 引入prepare_unknown / trans_unknown在既无完整上下文、也无可恢复的终态决策时禁止伪造 Commit 或 Abort配合 TDTTransaction Data Table 保留终态决策服务重复与延迟请求。从而在上下文丢失、协调者重建等场景下既避免一致性破坏又将用户侧歧义控制在可预期范围内。图6unknown状态与终态决策恢复论文 Production Experience 一节与实验形成呼应某移动核心与公有云 SaaS 场景单库可达数十万至数百万分区生产抓包曾见单笔事务 4000 参与者某业务峰值 13 笔并发、每笔超 1.12 万分区级参与者参与者列表元数据一度占超 50% 网络带宽。3.x 压测100 参与者约 1.66 ms → 1000 参与者 240 ms → 1 万参与者 7.54 s → 2 万参与者超 1000 s。4.0 起迁移至日志流架构后同类海量分区压测提交延迟稳定在约 60 ms与实验结论一致。运维侧通过迁移前准入检查积压事务过多则暂缓、迁移并发控制与调度策略避免同一日志流短时反复迁移将提交树保持较浅抑制迁移与大量在途事务重叠时的尾延迟抖动内部分享曾出现单机上 5000 在途事务与迁移重叠导致数百毫秒级停顿的案例。总结一下OceanBase 树形 2PC 框架通过三项核心创新——「日志流合并参与者」「动态树形提交协议」「未知状态 终态决策恢复」——在统一系统内同时实现静态跨分区事务协调开销数量级下降性能逼近单机动态弹性扩缩容在线分区迁移下仍保持线性一致提交无需昂贵的参与者列表重校验。目前该工作已在 OceanBase 4.x 生产路径中验证支撑金融、互联网、公有云等场景下百万级分区、高频迁移的分布式 OLTP。未来团队将继续在热点日志流负载均衡、更深提交树下的尾延迟治理、以及与 PALF 高吞吐日志的协同优化等方向深化推动云原生数据库在“强一致”与“极致弹性”之间走得更远。立即试用 OceanBase 企业版体验国产数据库能力180 天免费试用零门槛开通