基于湖库一体架构,统一管理结构化、半结构化与非结构化等多模态数据,一个系统承载事务处理、实时分析与 AI 工作负载。
What's New
更新时间:2025-11-13 11:51:58
OceanBase 数据库重磅推出 V4.4.0 Beta 版本,同时支持 Shared-Nothing 与 Shared-Storage 两种部署形态,是 OceanBase 面向多云、AI 时代的重大架构升级。Shared-Storage 形态下,计算节点和数据存储完全分离,存储可按需购买,计算节点可灵活扩缩容,从而实现极致的资源弹性与成本优化,并支持 AP、TP、KV 全产品形态。
基于存算分离架构,OceanBase 开创性地实现了独立的日志服务 LogService,不仅数据共享日志也能共享,OBServer 变成真正意义上的无状态的计算引擎,可独立快速扩缩容,也解决了单副本跨 AZ 容灾的难题。
本篇文章主要为您介绍 OceanBase V4.4.0 beta 的一些关键功能特性以及主要的性能提升。
关键特性说明
架构升级

共享存储架构
相较于 Shared-Nothing 形态的云盘存储,Shared-Storage 形态使用了独立且成本更低的存储介质。全量数据位于对象存储中,低成本轻松存储海量数据。OBServer 挂载小规格云盘,基于访问频率或业务规则识别并缓存热数据,保证命中云盘缓存场景的计算性能相对 Shared-Nothing 形态不回退。相同的性能下,对 TP 负载,保持事务强一致性的同时,存储成本可降至 1/2;对 AP 负载,支持大规模分析场景的同时,存储成本可降至 1/10。
作为多云原生数据库,共享存储支持 Amazon S3、阿里云 OSS 等主流对象存储,并支持所有主流云平台;支持 TP、AP、KV 等产品形态,满足不同业务负载;在 SQL 协议上,共享存储继承了 OceanBase 原生的 MySQL、Oracle 兼容能力,业务可平滑迁入。
共享存储架构具有低成本、高性能、极致弹性、按需收费等显著优势,适合对少量延迟抖动不敏感且有较明显冷热数据分离特征的大数据量场景。
独立日志服务 LogService
基于数据共享的 Shared-Storage 架构,相对 Shared-Nothing 架构有效降低了存储成本、优化了扩缩容性能, 但日志计算绑定的设计可能面临云盘抖动引起的性能波动、单副本容灾能力不足的挑战。因此, OceanBase 在 V4.4.0 版本,基于共享存储架构,对日志模块做了升级改造,推出了支撑日志计算分离的独立日志服务 LogService。
日志计算分离架构中,日志服务拥有单独的 oblogservice 进程,和 observer 进程部署在不同的节点中。OBServer 作为计算层,提供 SQL 和事务能力;日志服务作为日志存储层,提供日志的高效写入和读取能力,并通过日志多副本 Paxos 协议保证日志的高可用。
独立日志服务 LogService,是面向多云架构设计的分布式日志存储系统,为多云原生的 OceanBase 数据库带来突破性的业务价值:
- 支持跨 AZ 容灾。将日志副本数与计算副本数解耦,保证计算节点单副本也具备跨 AZ 容灾的能力,使得单副本下也能实现 RPO=0。
- 增强弹性能力。计算资源水平扩缩容时无需物理迁移数据,单 ZONE 内可快速增、删计算节点。
- 降低存储和计算成本。根据业务对计算节点高可用的需求,计算节点可以使用单副本或两副本,与现有的3F方案相比,计算成本降低 66% 或 33%;作为独立的分布式系统,LogService 可以服务单个或多个集群,通过共享日志服务,日志的存储成本从数据库资源总成本的 7%,降低到 1% 以内,效果显著。
- 提升性能。日志服务独立,避免同数据盘 IO 争抢、云盘带宽限制,低延时、高吞吐、更稳定,毫秒级的读写延迟,满足 TP/实时 AP/AI 业务的性能需求。
单副本形态
依托独立日志服务提供的跨 AZ 容灾能力,V4.4.0版本推出了单副本部署的 TP、AP、KV 产品形态。单副本架构下,日志服务和 OceanBase 集群是 1:1 关系部署。在计算层,普通租户单副本部署,SYS 租户为了实现单副本故障自动容灾,需要部署为三副本的高可用形态;日志存储层,日志服务三副本部署。

单副本架构下,数据库能够提供机房级容灾:单 AZ 故障时,无损自动容灾,保证 RPO=0,RTO 分钟级。
内核增强
locality 变更支持 2F 到 1F
OceanBase 4.x 作为单机分布式一体化数据库,能够支持单机部署扩展成分布式部署,但是低版本未支持分布式部署变更为单机部署。V4.4.0 放开限制, 允许通过
ALTER TENANT语句将 locality 从 2F 缩减到 1F,从而支持租户的单副本模式。全文搜索支持短语匹配
全文搜索目前已经支持
NATURAL LANGUAGE MODE、BOOLEAN MODE两种查询模式,分别用于模糊匹配、不分词复杂逻辑匹配的场景。V4.4.0 版本,针对需要进行短语精确匹配场景,新增MATCH PHRASE MODE查询模式,可使用MATCH ('<colum name>') AGAINST ('some words' IN MATCH PHRASE MODE)语法精确查询包含 "some words" 短语的文档信息。支持 ODPS Storage API
基于 Tunnel API 的 ODPS 外表,执行阶段对每个分区的扫描,都需要开启独立的 session 来处理,而打开 session 需要秒级延迟,这导致一些本身耗时非常小的查询,会花费时间在 session 准备阶段。除 Tunnel API 外,ODPS 还提供了一种开放的 Storage API,支持直接访问 ODPS 的底层存储,提供了更多的优化策略和更好的读取性能,因此 OceanBase V4.4.0 适配支持了 ODPS Storage API,进一步提升外表访问性能。
MySQL 模式 JAVA UDF
为了进一步提升 PL 的灵活性和可扩展性,更好地支撑业务需求,V4.4.0 版本在 MySQL 模式下新增 JAVA UDF 功能。创建 JAVA UDF 时,支持指定 jar 包的 URL 路径,执行时动态加载;也支持通过
DBMS_JAVA.LOADJAVA先上传 jar 包到数据库内,UDF 执行时直接引用 。目前支持 ODPS 风格,仅需少量改动即可复用已有的 ODPS JAVA UDF jar 包。
性能提升
UDF 性能优化
为了提升 UDF 在 SQL 中的执行性能,新版本针对标记
RESULT_CACHE或DETERMINISTIC子句的 UDF 支持了结果缓存功能,不能进行结果缓存的场景也对执行路径做了针对性优化。另外,新版本 UDF 适配了向量化框架,大部分场景可由单行执行优化为向量化执行。PS Cursor 性能优化
OceanBase PS Cursor 目前为单线程非流式执行,性能不优。V4.4.0 版本开始,将 PS Cursor 从单线程非流式执行优化为双线程非流式执行,充分利用 client-server 之间交互的时间差,提升 PS Cursor 性能。在大查询 Fetch 前 N 行和 Fetch 所有行的场景,分别有 77% 和 90% 左右的性能提升。
外表查询性能优化
OceanBase V4.4.0 针对外表查询场景,新增外表缓存、prebuffer 预取、IO 合并、一致性 Hash Location 等优化;针对 Parquet、ORC 文件外表,还支持了 file、rowgroup 级别的 Filter 下压。性能有较明显提升。
相关文档
本篇文章主要向您介绍了重点的新增功能、关键特性等,如果想要了解更多版本详情以及其他各版本信息,请关注我们的版本发布记录: