基于湖库一体架构,统一管理结构化、半结构化与非结构化等多模态数据,一个系统承载事务处理、实时分析与 AI 工作负载。
系统架构
更新时间:2026-08-23 11:23:02
OceanBase Database AI 采用存算分离的共享存储架构,将传统数据库的计算、日志、存储三大能力解耦为独立的三层架构。各层职责明确、独立演进,协同为用户提供高性能、高可用、低成本且弹性可扩展的数据库服务。
计算层(OBServer):
计算层由 OBServer 计算节点组成,是数据库的业务入口,提供完整的 SQL 引擎与事务处理能力。
计算节点通过本地磁盘缓存热数据,加速数据读取;同时节点实现无状态化设计,不依赖本地日志盘,支持高效弹性扩缩容,可支持单副本部署,显著降低计算成本。
日志层(LogService):
日志层是一个独立的分布式日志存储系统,专门承担数据库日志的持久化、高可用保障与高效读写职责。
日志层默认采用 Paxos 三副本部署,副本自动分布在不同的可用区,任一可用区发生故障时数据不丢失、服务不中断。日志写入直接落盘至本地高性能存储,延迟极低。
存储层(对象存储):
存储层是系统的数据底座,基于对象存储提供海量、持久化的数据存储与共享访问能力。
存储层统一保存日志文件、基线数据和转储数据,支持兼容 S3 协议的对象存储。同一日志流的多份副本共享底层同一份数据文件,避免重复存储,将存储成本降至最低。对象存储天然具备跨可用区容灾能力,为数据的长期可靠保存提供保障。
概念介绍
可用区(Zone):OceanBase Database AI 集群由若干节点组成,节点分属于一个或多个可用区。每个节点仅归属于一个可用区,同一可用区内可包含多个节点。可用区是集群高可用与容灾的基本单元,支持跨可用区部署以实现故障隔离。
租户(Tenant):OceanBase Database AI 支持在单个集群内创建多个相互隔离的数据库实例,即租户。每个租户拥有独立的资源配额、权限体系和数据空间,互不干扰。集群支持创建 MySQL 兼容模式的租户,应用连接后可像使用独立 MySQL 数据库一样,在租户内创建用户、Database 及各类数据库对象,使用体验与原生 MySQL 完全一致。
分区(Partition):OceanBase Database AI 支持将一张表的数据按照用户指定的划分规则进行水平拆分,每个数据分片称为一个表分区(Partition)。每一行数据有且仅属于一个分区。支持的分区类型包括 Hash、Range、List 等。一张表的多个分区可分布在同一可用区内的多个节点上,实现数据的分布式存储与并行处理。
分片(Tablet):Tablet 是 OceanBase Database AI 中数据存储的基本物理单元。每个表分区对应一个 Tablet,用于存储该分区的有序数据记录。Tablet 是数据读写、迁移和副本管理的最小粒度。
日志流(Log Stream,LS):日志流是 OceanBase Database AI 中保障数据持久化与一致性的核心逻辑单元。当对 Tablet 中的数据进行修改时,系统会将 Redo 日志写入该 Tablet 所属的日志流。每个日志流可同时服务其所在节点上的多个 Tablet,实现日志的高效聚合与管理。
主副本(Leader):主副本是日志流的写入方,承担该日志流的主要读写职责。主副本负责处理事务写入、强一致性读取。每个日志流在同一时刻有且仅有一个主副本。
从副本(Follower):从副本提供只读能力,支持弱一致性读取。从副本不处理写入请求,而是从日志服务远程拉取日志并进行回放,以保持与主副本的数据同步。从副本可在故障发生时被提升为新的主副本,保障服务的高可用。
日志服务副本(Log Service Replica):日志服务副本是日志服务层中日志流的存储副本。每个日志服务副本与计算层的日志流通过
<cluster_id, tenant_id, ls_id>三元组唯一绑定,两者基于 Paxos 协议协同工作,共同实现日志的高性能写入、强一致性保障和跨可用区容灾。ODP(OceanBase Database Proxy):ODP 是 OceanBase Database AI 的数据库代理组件,部署于应用与 OBServer 集群之间,提供 SQL 路由转发、连接池管理、读写分离、负载均衡、故障自动切换及协议兼容等能力。ODP 将应用连接透明分发至后端多个 OBServer 节点,使应用无需感知集群拓扑变化,实现高效、可靠的数据库访问。
单副本架构

- 计算层(OBServer):单副本,单可用区,多节点
- 日志层(LogService):三副本,保障日志高可用
- 存储层:标准对象存储
优点
- 计算成本极低:相比传统三副本架构,计算成本降低 66%
- 资源占用最少:仅需一个副本的计算节点,资源消耗最小
- 运维简单:部署和管理复杂度最低
- 跨 AZ 容灾能力:依托独立日志服务的三副本部署,单副本计算节点也能实现跨 AZ 容灾
- RPO=0:无损自动容灾,保证数据零丢失
- 快速弹性:扩缩容无需数据迁移
缺点
- 可用性风险:多计算节点的集群,单节点故障会导致该节点缓存失效,部分 SQL RT 会在一段时间变长;单计算节点的集群,节点故障后会导致服务不可用,需等待新的计算节点拉起
- 故障恢复时间:虽然 RPO=0,但 RTO 是分钟级
- 性能瓶颈:所有读写请求都集中在一个副本上
适用场景
- 成本敏感型业务:对成本有极致要求
- 非核心业务系统:可接受一定时间的性能波动或服务中断
- 备份库/历史库:主要用于数据归档和查询
- 测试/开发环境:资源有限的环境
- 弹性要求高的业务:需要快速扩缩容
两副本架构

- 计算层:两副本
- 日志层:三副本,保障日志高可用
- 存储层:标准对象存储
优点
- 高可用性:两个副本互为备份,提高服务可用性
- 负载均衡:可分散读写压力
- 故障切换:主副本故障时能快速切换到备副本,RTO < 8s
- 计算成本适中:相比传统三副本架构,计算成本降低 33%
- 性能更优:可分担负载,避免单节点瓶颈
- 容错能力:可容忍机房级故障
缺点
- 资源占用较高:比单副本多一倍的算力资源
- 成本较高:相比单副本,成本增加 100%
- 部署复杂度:需要维护两个副本的状态同步
- 故障检测:需要更复杂的故障检测和切换机制
适用场景
- 核心业务系统:对可用性要求较高
- 7×24 小时服务:不能容忍长时间服务中断
- 性能要求高:需要负载均衡分担压力