数据库简史：共享存储集群架构的由来和华为参天引擎的机遇

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

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

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

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

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

【历史回眸】

单机的处理能力不足由来已久，而且在数据库发展的早期尤有甚之，那时候的小型机处理能力更加有限（我们不谈大型机，小型机那时候要革大型机的命），所以如何扩展数据库的能力是非常早期的挑战。

解决方案也毫不意外，就是两个方向，一个是分布式,一个是共享存储集群，一个是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在坚定的走向共享存储集群的路线，第三方集群件在数据库领域从此声名不显。

【上下求索】

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