数据库简史：多主数据库架构的由来和华为参天引擎的机遇-CSDN博客

注本文发表后收到了很多后台反馈其中关于大型机的早期成就不容省略。微调重发本文纯属个人观点错谬之处仍然期待指正。

2023年10月13日在北京举办的“2023金融业数据库技术大会"上有一个非常重要的计划低调地发起了。这就是"北京金融信息化研究所"联合了华为、阿里巴巴、达梦、云和恩墨等企业共同启动的“金融多主数据库应用行动计划”。

“多主数据库”这么拗口的一个词粗暴的翻译过来就是Oracle RAC集群其典型特征是以多个计算节点、并发读写位于共享存储的集中式数据库。

这个计划隐秘地将集中式和分布式数据库之争再次提上议题。

这个问题还有争议吗是的还有。而且由来已久从未改变。

让我们简要的回顾一下数据库的历史。

【历史回眸】

话说天下大势分久必合合久必分分分合合本是常态。在计算机领域、数据库领域分分合合也自然而然。

大型机是合小型机是分集中式是合分布式是分。在早期的计算机市场上IBM的大型机mainframe占据主导地位自其20世纪60年代发明后凭借超强的计算和I/O处理能力以及在稳定性和安全性方面的卓越表现引领了计算机行业以及商业计算领域的发展。

由于大型机具备极高的可靠性和可用性、超强的计算能力早期的IT系统进入了集中式处理阶段。应用系统、中间件、数据库等资源往往集中在一台服务器上。

可是大型机的昂贵价格让大多数用户望而却步所以小型机和PC机开始次第出现。DEC是这一时期的明星企业它快速发展成为当时仅次于IBM的计算机制造商。

当小型机和微型机出现时单机的处理能力就显得不足起来如何扩展数据库的能力也就成为了非常早期的挑战。

解决方案也毫不意外就是两个方向一个是分布式,一个是共享存储集群一个是Scale-Out一个是Scale-Up和我们今天讨论的毫无二致。

1979年美国计算机公司就在DEC计算机上就实现了世界上第一个分布式数据库系统SDD-1。随后IBM在System R的基础上研制了分布式数据库R* 加州大学伯克利分校开发了“分布式Ingres”等。分布式数据库从来不是一个时髦的新词汇在数据库历史上的探索是非常早的。

但是分布式数据库的问题也非常突出这个我们后面再讲。

另外一个方向就是共享存储集群。在这个领域早期操作系统起了关键作用。DEC 最早在操作系统层提供了集群解决方案其在1983年发布的VAXcluster提供了卓越的系统级集群解决方案这一技术通过操作系统来解决并发锁竞争等分布式系统核心问题。后来DEC推出的Rdb在集群方面也具备极大的领先性当然后来DEC经营不善于1994年将Rdb卖给了Oracle公司。

VAXcluster 集群在当时要依赖DEC生产的硬件包括专用电缆和星形耦合器。下图是从历史文档中截取出来的集群中的每个节点和存储设备都通过一对或两对CI电缆连接到中央的Star Coupler。每对电缆的传输速率为70 Mb/s这在当时是很高的速度。VAXcluster是第一个取得商业成功的集群系统。当时对这套架构的一个负面声音是需要专用硬件架构复杂。

可是我们用今天的视角来看如果将其中的Star Coupler换成一个InfiniBand 交换机这不就是一套数据库一体机吗

当时DEC的RDB运行在VAXcluster上就是一套完美的架构组合和后来的Oracle RAC集群几乎一模一样。

其实在分布式这条路上图灵奖获得者 Jim Gray 是一个全程参与者他从IBM到天腾就曾经实现了非常著名的Non-Stop SQL分布式架构因其线性扩展能力而著称。那早在1987年。后来Jim Gray 去了DEC从DEC辗转到了微软参与了SQL Server的重构。

【Oracle的抉择】

好了问题开始摆在了Oracle创始人Larry Ellision的面前时间已经来到了1998年这时候Oracle 8i已经发布。并且在此之前Oracle已经探索了一项共享存储集群技术那时候称为并行服务器Oracle Parallel Server,OPS技术。这一架构能够在 DEC 的集群之上工作但是在OLTP场景下性能并不理想。

是坚持没有先例的共享存储集群技术还是跟随当时热门的Shared Nothing 分布式架构2b or not 2b这是一个问题。

事有不决问老板。Larry Ellision 开始拍脑袋。他认为虽然看起来分布式架构是一个安全的方向、热点、大家都在跟风但是事实证明除了数据仓库工作负载外无共享数据库集群从未在成熟的应用套件上成功运行过SAP R3 和Oracle EBS等应用都无法适应新的架构让用户从头来过无法被接受。埃里森拍板继续搞集群。这一版本在2001年Oracle版本9i中发布埃里森将其命名为 "真正应用集群"Real Application Cluster - RAC意思是众人皆假唯我独真。

当然这一决策也不是凭空拍脑袋当时Oracle的一个技术专家罗杰•班福德已经提出了一个突破性的设计方案- "高速缓存融合"Cache Fusion技术关于这些历史故事我在新书《数据库简史》中做了详细的介绍。最后的事实证明这一次开创性的冒险Oracle是赌对了。

同志们大家可以看一下20多年的问题和今天是否有差别我认为是没有的。让应用适应数据库还是数据库适应应用每个人心中自有答案。当然我们必须致敬华为Meta ERP 以一己之力、行业协同彻底解开自身在特定历史时期所面临的这一难题。

那么 Oracle 是怎么彻底解开这一 RAC 集群路线上的难题的

那就是将 VAXcluster 写到数据库里去。卧榻之侧岂容他人鼾睡。

大家都知道Oracle从 8 就开始做 DLM分布式锁管理器而这一技术的鼻祖是DEC。Distributed Lock Manager 最早就是 OpenVMS 集群软件中负责管理节点访问共享资源的组件。1982 年在 VAX/VMS V3.0 中就出现了第一个用于单机系统的锁管理器它为驻留在单个处理器上的多个进程提供同步服务并能消除死锁。分布式锁管理器由 Steve Beckhardt 设计于 1984 年随 VAX/VMS V4.0 一起发布。

Oracle RAC管理员非常熟悉的 Resource Manager、Lock Remastering 等都是 VAX 集群里首创的术语。以下这段VaxCluster手册中的描述放到今天的数据库手册中也毫无问题

锁管理器的实现是为了将锁管理的开销分散到整个集群中同时还能将执行锁服务所需的节点间流量最小化。因此内部数据库分为两部分资源锁描述和资源锁目录系统这两部分都是分布式的。

每个资源都有一个主节点负责授予该资源的锁主节点维护一个已授予锁的列表和一个该资源的等待请求队列。对一棵树的所有操作而言主节点就是对根节点提出锁请求的节点。当主节点维护其资源树的锁数据时任何对另一个节点掌握的资源持有锁的节点都会维护自己的资源和锁描述副本。

资源目录系统将资源名称映射为该资源的主节点名称。目录数据库分布在愿意分担这一开销的节点之间。给定一个资源名称节点就可以根据名称字符串和目录节点数量的函数轻松计算出所负责的目录。

当然除了 DEC 之外早期的 Veritas 也通过集群软件和 Oracle RAC 紧密连接而且售价相当可观几乎和数据库相当。

但是当Oracle将Cluster“写入数据库”之后这些软件和数据库的连接都被切断了也再未对数据库产生如早期般的深远影响。

由于在数据库领域几乎只有Oracle在坚定的走向共享存储集群的路线第三方集群件在数据库领域从此声名不显。

说完了Oracle和DEC的故事再来看看IBM。IBM是蓝色巨人在所有技术栈上几乎都有多套解决方案。在集群这一方向上IBM的大型机也形成了深厚的技术积累。

IBM 最早于1990年提出Systems Complex也即SysPlex)概念1994年提出Parallel Sysplex概念,并行系统耦合体是大型机最具代表性的集群技术。可以将一台或多台机器组成Sysplex用于跨系统的通信联络最多支持32个LPAR资源共享的读/写。同时提出的还有CF即Coupling Facility - 耦合装置CF是一种支持共享对象的技术。在DB2集群中CF提供了一个集中化设备来管理锁并且还充当脏页(dirty page)的全局共享缓冲池从而有助于实现可伸缩性和可恢复性操作。

C.Mohan 等人在1997年发表的论文中详细的介绍了IBM基于共享数据的集群设计以及Coupling Facility在其中所发挥的关键作用。

这些技术后来被下放到小型机中2009年DB2推出了基于小型机的pureScale集群但是没有取得像Oracle RAC那样的成功。

在pureScale的架构下因为CF被重新释意为Caching Facility的存在在集群成员节点故障时不需要进行资源目录的冻结这是优势但是CF存在单点也需要进行高可用保护客观上也增加了集群的复杂性。

【上下求索】

前面的数据库历程我们见证了系统软件的集群时代数据库一体化的时代最后Oracle RAC集群占据了主流并囊括了集群件的全部能力。

可是历史总在轮回数据库的问题不一定都要在数据库中解决。在中国数据库尤其是分布式蓬勃发展的过程中我们注意到在数据库外部有两大解决方案体系逐渐形成。

一者是在数据库上部通过数据库中间件解决分布式问题二者在数据库底层通过共享存储集群件提供数据库共享存储集群能力。

分布式中间件领域Sharding-Sphere 和 MyCat 都是不同时期典型的代表。例如 MogDB 结合 Sharding-Sphere也能打造数千万 tpmC的分布式架构。以下这个架构被称为 MogDB Clowder。

可是中国数据库行业呈现出的另外一个趋势是将“Sharding-Sphere"写到数据库里。历史再次重演了当分库分表、路由、中间件等能力被数据库一体化集成进去这些产品将在企业级应用消失了开源领域还会在但是商业价值的探索将更加困难。

我们再来看看多主数据库的核心 - 共享存储集群件。在这个领域中国此前没有探索者。一个是因为技术难度较大一个是因为数据库领域没有需求。中国数据库厂商将注意力聚焦在分布式架构上。

然而峰回路转涛声依旧。在“金融业数据库技术大会”上成立的“金融多主数据库应用行动计划”证明金融客户对多主集群仍然存在强烈的需求。

那么答案在哪里呢

华为公司近期开源了一个产品Cantian引擎。取义要扎根深远长成参天大树之意。

参天起到的作用就是将过去中国数据库领域缺少的一环补齐通过系统级的集群能力可以帮助以单机性能见长的数据库形成共享集群解决方案同时将可靠性和性能久经验证的企业级存储产品 OceanStor Dorado 引入作为共享存储。

可以一举解决金融行业数据库国产化替代难的症结。当前云和恩墨 MogDB 和 openGauss 都在加速适配参天存储引擎这次过程数据库厂商参与建立的同盟就是在这一方向上共识的体现。

参天引擎包含五大核心组件分别是 CMS负责集群管理服务维护集群一致性DRC分布式资源目录管理资源在集群中的分布DCS分布式缓存服务DLS分布式锁服务MES集群间通信服务。

通过有限的资料可以看到参天读写的Cache Fusion行为和Oracle基本保持一致。在下图展示的流程中(数据页位于内存中如果在双实例中实际上产生了一次 GC CR Block 2-way 的Cache Fusion读请求。

被数据库吞噬的还可以再独立出来。今天参天的尝试通过开源将成果行业共享这样能够实现社会价值最大化更能够助力中国数据库集体向前跃迁一大步。

参天引擎已经在 openEuler 社区开源从个人角度我期待看到更多的中国数据库和参天适配重新探索“共享存储集群”在中国数据库产业中应有的地位更好的支撑企业级用户对数据库的多样化架构需求。

云和恩墨已经投身其中也期待对此有兴趣的客户和我们一起探讨 MogDB 和 openGauss 的共享存储集群解决方案

---

云和恩墨大讲堂 | 一个分享交流的地方 | MogDB

长按识别二维码加入万人交流社群

请备注云和恩墨大讲堂

  点个“在看” 

你的喜欢会被看到❤