暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

openGauss开源oGRAC:国产RAC,终于有了开源选项

老鱼笔记 2026-01-06
244

摘要:当分布式、云原生被反复写进技术路线图,甚至快成数据库“政治正确”时,一批中国数据库厂商却选择回头补RAC这门硬功夫。


这不是逆潮流,而是行业开始从概念驱动,转向场景驱动的一个信号。


会上公开oGRAC代码仓


最近,openGauss社区正式开源了oGRAC,支持多节点同时读写。如果你在数据库圈待得够久,听到“多写多读”这四个字,脑子里大概率只会冒出一个名字:Oracle RAC。


这不是惯性反应,而是行业现实。


过去二十多年里,Oracle RAC几乎就是企业级多写高可用方案的事实标准。它足够成熟、足够稳定,在金融、电信、能源等关键行业反复经受过真实业务的考验。


很多核心系统至今仍运行在Oracle RAC上,并不是“不敢换”,而是因为它确实啃下了最难啃的那组问题:高可用、强一致、复杂事务,以及多节点并发写。这四个条件,单拎出来都不算难,但放在一起就是地狱级难度。


RAC被称为“数据库领域的珠穆朗玛峰”,并不夸张。Oracle用了20多年,把这套能力做成了一个几乎无法撼动的护城河。


所以,当openGauss宣布把oGRAC直接开源时,很多人的第一反应不是兴奋,而是怀疑:


“真的假的?这玩意儿能跑吗?”


openGauss社区理事长熊伟


比PPT更有说服力的,其实是那句 “一小时编译成功”。


oGRAC代码仓库刚一开放,openGauss社区理事长熊伟就在朋友圈提到:


不到一小时,就已经有人反馈代码成功编译并跑了起来。


这个细节很关键。


因为对数据库这种底层基础设施来说,真正能说明问题的,从来不是PPT上漂亮的tpmC数字,而是——别人能不能拿到代码,自己跑一遍,亲手验证它是不是靠谱。


oGRAC是什么?有何突破?


不绕弯子,直接说能力边界。


oGRAC是一种RAC类多写高可用数据库架构,目标很清晰,让多个数据库节点同时读写,并且保证:


  • RPO = 0(数据不丢)

  • RTO < 10 秒(切换够快)

  • 性能不崩(双节点约350万tpmC,扩展比0.82)


单看这些指标,并不“炸裂”,但结合“开源”这个前提,就变得有意思了。


比如,oGRAC通过页面级MVCC结合全局唯一SCN来统一事务可见性判断,利用分布式缓存融合机制减少跨节点对数据页的重复访问,并通过与页面事务槽协同的行级并发控制设计来降低多节点并发写入的协调开销。


这些设计所应对的核心挑战,本质上都是多节点共享存储环境下的数据一致性、缓存协同与高并发控制问题。如果你熟悉Oracle RAC,会发现其Cache Fusion、全局资源管理等机制,解决的正是同一类问题——只是实现路径并不相同。


更关键的是,oGRAC是开源的。这意味着你可以看代码、改代码、测代码,而不是对着一个黑盒反复猜:


“它到底靠不靠谱?”


正如前文提到的,随后代码仓库向全球开发者一开放,很快就有合作伙伴向熊伟反馈:“已经跑起来了。”


这就是开源的价值:


不是听你怎么说,而是我自己怎么验证。


分布式这么火,为什么中国还要坚持搞RAC?


这个问题绕不开。


答案也很简单:不是所有系统,都需要分布式。


互联网公司要扛大促流量,数据量动辄PB级,分布式是自然选择。但银行的核心交易系统、电力调度平台、政府关键业务,往往更看重“确定性”——确定的响应时间、确定的一致性、确定的故障恢复行为。这类系统并发量未必极高,但每一笔操作都不能出错,也不能停。这种“固定并发+高可靠”的场景,RAC反而是更合适的解法。


Oracle RAC能长期站住脚,靠的不是市场惯性,而是它真的好用、可靠。 oGRAC的出现,提供了一个开放、可审计、可定制的国产替代路径。


还有一个现实问题:历史包袱。大量现有系统是基于Oracle RAC构建的,存储过程、触发器、复杂SQL深度耦合。推倒重来?成本太高,风险太大。如果国产RAC能在语法、行为上保持较高兼容度,替换风险会直接下降一个量级。


再叠加监管因素,《数据安全法》《关键信息基础设施安全保护条例》都在强调“安全可控”。 集中式架构在审计、权限、加密策略上,路径更清晰、验证更直接。


所以,在中国,RAC不是“逆潮流”,而是贴地飞行。


oGRAC的真正意义,不在“首个”,而在“开源”


必须说清楚一点:oGRAC目前还在早期阶段。社区自己也很坦承:“完成了从0到1,但离大规模商用还有距离。”


工具链、运维体验、极端场景下的稳定性,都需要时间和真实业务去慢慢打磨。


所以,纠结“是不是全球首个开源RAC”,意义并不大。”真正重要的是:它做对了一件事:


它把RAC这种高门槛能力,从封闭体系里拉了出来。


Oracle RAC的成功,值得尊重。但技术世界不能只有一种选择。但基础设施层,不能永远只有一种选择。多样性,本身就是系统韧性的一部分。


最后说一句


oGRAC不是万能药,RAC的存在,也不是技术倒退。


中国数据库的发展,不该陷入“分布式 vs 集中式”的二元对立,而应该坚持一件事:


场景驱动,多元共存


如果你正在做国产化替代,或者评估高可用方案,oGRAC至少值得你亲手跑一跑、测一测。


毕竟,好的技术,不靠口号,只靠经不经得起验证。


附:代码仓传送门

https://gitcode.com/opengauss/oGRAC



- END -

延伸阅读


Redis分叉之后,谁在真正把Valkey往前推?

首款国产AI原生数据库开源

国产数据库九死一生,达梦凭啥笑到最后?

国产数据库的“生态突围”才刚刚开始

国产数据库真实战报:2025年Q3

从国外数据库到国产:一场没有退路的迁徙

国产数据库要平替,先啃下这块硬骨头

Oracle,怎么悄悄成了AI背后的大哥?

深圳地铁为什么选择这家国产数据库?

当竞争对手“满嘴跑火车”,该怎么办?

对象存储真能扛住TP数据库的“重活”?

5家国产数据库公司2024营收PK!

全球40+数据库公司2023年营收真相
国产数据库生死线:工程师愿用,老板敢买
国产数据库破局:分布式扛把子入局单机市场
国产数据库市场部生存指南
国产数据库最凶悍的破局者
国产数据库技术路线生死局
国产数据库,那些被误解的真相
国产数据库谁能胜出?
国产数据库是笑话吗?

Db2,一把好牌打得稀烂!

六大行真核心在用哪些国产数据库?

从0到1:Teradata在中国创业记

银行数据库选型需求,你真的清楚吗?

一个真实的案例,一些真实存在的选型误区

开源数据库虽香,但需警惕风险勿沦为“韭菜“



欢迎订阅老鱼笔记

✬如果你喜欢这篇文章,欢迎分享到朋友圈✬

原创不易,且行且珍惜

文章转载自老鱼笔记,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论