注：本文發(fā)表后，收到了很多后臺(tái)反饋，其中關(guān)于大型機(jī)的早期成就不容省略。微調(diào)重發(fā)本文，純屬個(gè)人觀點(diǎn)，錯(cuò)謬之處，仍然期待指正。

2023年10月13日，在北京舉辦的“2023金融業(yè)數(shù)據(jù)庫技術(shù)大會(huì)"上，有一個(gè)非常重要的計(jì)劃低調(diào)地發(fā)起了。這就是"北京金融信息化研究所"聯(lián)合了華為、阿里巴巴、達(dá)夢(mèng)、云和恩墨等企業(yè)共同啟動(dòng)的“金融多主數(shù)據(jù)庫應(yīng)用行動(dòng)計(jì)劃”。

“多主數(shù)據(jù)庫”這么拗口的一個(gè)詞，粗暴的翻譯過來就是Oracle RAC集群，其典型特征是以多個(gè)計(jì)算節(jié)點(diǎn)、并發(fā)讀寫位于共享存儲(chǔ)的集中式數(shù)據(jù)庫。

這個(gè)計(jì)劃，隱秘地將集中式和分布式數(shù)據(jù)庫之爭(zhēng)再次提上議題。

這個(gè)問題還有爭(zhēng)議嗎？是的，還有。而且由來已久，從未改變。

讓我們簡(jiǎn)要的回顧一下數(shù)據(jù)庫的歷史。

【歷史回眸】

話說天下大勢(shì)，分久必合，合久必分，分分合合本是常態(tài)。在計(jì)算機(jī)領(lǐng)域、數(shù)據(jù)庫領(lǐng)域，分分合合也自然而然。

大型機(jī)是合，小型機(jī)是分，集中式是合，分布式是分。在早期的計(jì)算機(jī)市場(chǎng)上，IBM的大型機(jī)（mainframe）占據(jù)主導(dǎo)地位，自其20世紀(jì)60年代發(fā)明后，憑借超強(qiáng)的計(jì)算和I/O處理能力，以及在穩(wěn)定性和安全性方面的卓越表現(xiàn)，引領(lǐng)了計(jì)算機(jī)行業(yè)以及商業(yè)計(jì)算領(lǐng)域的發(fā)展。

由于大型機(jī)具備極高的可靠性和可用性、超強(qiáng)的計(jì)算能力，早期的IT系統(tǒng)進(jìn)入了集中式處理階段。應(yīng)用系統(tǒng)、中間件、數(shù)據(jù)庫等資源往往集中在一臺(tái)服務(wù)器上。

可是大型機(jī)的昂貴價(jià)格讓大多數(shù)用戶望而卻步，所以小型機(jī)和PC機(jī)開始次第出現(xiàn)。DEC是這一時(shí)期的明星企業(yè)，它快速發(fā)展成為當(dāng)時(shí)僅次于IBM的計(jì)算機(jī)制造商。

當(dāng)小型機(jī)和微型機(jī)出現(xiàn)時(shí)，單機(jī)的處理能力就顯得不足起來，如何擴(kuò)展數(shù)據(jù)庫的能力也就成為了非常早期的挑戰(zhàn)。

解決方案也毫不意外，就是兩個(gè)方向，一個(gè)是分布式,一個(gè)是共享存儲(chǔ)集群，一個(gè)是Scale-Out，一個(gè)是Scale-Up，和我們今天討論的毫無二致。

1979年，美國(guó)計(jì)算機(jī)公司就在DEC計(jì)算機(jī)上就實(shí)現(xiàn)了世界上第一個(gè)分布式數(shù)據(jù)庫系統(tǒng)SDD-1。隨后，IBM在System R的基礎(chǔ)上研制了分布式數(shù)據(jù)庫R* ，加州大學(xué)伯克利分校開發(fā)了“分布式Ingres”等。分布式數(shù)據(jù)庫從來不是一個(gè)時(shí)髦的新詞匯，在數(shù)據(jù)庫歷史上的探索是非常早的。

但是分布式數(shù)據(jù)庫的問題也非常突出，這個(gè)我們后面再講。

另外一個(gè)方向，就是共享存儲(chǔ)集群。在這個(gè)領(lǐng)域，早期操作系統(tǒng)起了關(guān)鍵作用。DEC 最早在操作系統(tǒng)層提供了集群解決方案，其在1983年發(fā)布的VAXcluster提供了卓越的系統(tǒng)級(jí)集群解決方案，這一技術(shù)通過操作系統(tǒng)來解決并發(fā)鎖競(jìng)爭(zhēng)等分布式系統(tǒng)核心問題。后來DEC推出的Rdb在集群方面也具備極大的領(lǐng)先性，當(dāng)然后來DEC經(jīng)營(yíng)不善，于1994年將Rdb賣給了Oracle公司。

VAXcluster 集群在當(dāng)時(shí)要依賴DEC生產(chǎn)的硬件，包括專用電纜和星形耦合器。下圖是從歷史文檔中截取出來的，集群中的每個(gè)節(jié)點(diǎn)和存儲(chǔ)設(shè)備都通過一對(duì)或兩對(duì)CI電纜連接到中央的Star Coupler。每對(duì)電纜的傳輸速率為70 Mb/s，這在當(dāng)時(shí)是很高的速度。VAXcluster是第一個(gè)取得商業(yè)成功的集群系統(tǒng)。當(dāng)時(shí)對(duì)這套架構(gòu)的一個(gè)負(fù)面聲音是，需要專用硬件，架構(gòu)復(fù)雜。

可是我們用今天的視角來看，如果將其中的Star Coupler換成一個(gè)InfiniBand 交換機(jī)，這不就是一套數(shù)據(jù)庫一體機(jī)嗎？

當(dāng)時(shí)DEC的RDB運(yùn)行在VAXcluster上，就是一套完美的架構(gòu)組合，和后來的Oracle RAC集群幾乎一模一樣。

其實(shí)，在分布式這條路上，圖靈獎(jiǎng)獲得者 Jim Gray 是一個(gè)全程參與者，他從IBM到天騰，就曾經(jīng)實(shí)現(xiàn)了非常著名的Non-Stop SQL分布式架構(gòu)，因其線性擴(kuò)展能力而著稱。那早在1987年。后來，Jim Gray 去了DEC，從DEC輾轉(zhuǎn)到了微軟，參與了SQL Server的重構(gòu)。

【Oracle的抉擇】

好了，問題開始擺在了Oracle創(chuàng)始人Larry Ellision的面前，時(shí)間已經(jīng)來到了1998年，這時(shí)候Oracle 8i已經(jīng)發(fā)布。并且在此之前，Oracle已經(jīng)探索了一項(xiàng)共享存儲(chǔ)集群技術(shù)，那時(shí)候稱為并行服務(wù)器（Oracle Parallel Server,OPS）技術(shù)。這一架構(gòu)能夠在 DEC 的集群之上工作，但是在OLTP場(chǎng)景下性能并不理想。

是堅(jiān)持沒有先例的共享存儲(chǔ)集群技術(shù)，還是跟隨當(dāng)時(shí)熱門的Shared Nothing 分布式架構(gòu)，2b or not 2b，這是一個(gè)問題。

事有不決問老板。Larry Ellision 開始拍腦袋。他認(rèn)為，雖然看起來分布式架構(gòu)是一個(gè)安全的方向、熱點(diǎn)、大家都在跟風(fēng)，但是事實(shí)證明，除了數(shù)據(jù)倉(cāng)庫工作負(fù)載外，無共享數(shù)據(jù)庫集群從未在成熟的應(yīng)用套件上成功運(yùn)行過，SAP R3 和Oracle EBS等應(yīng)用都無法適應(yīng)新的架構(gòu)，讓用戶從頭來過無法被接受。埃里森拍板繼續(xù)搞集群。這一版本在2001年Oracle版本9i中發(fā)布，埃里森將其命名為 "真正應(yīng)用集群"（Real Application Cluster - RAC），意思是眾人皆假，唯我獨(dú)真。

當(dāng)然，這一決策也不是憑空拍腦袋，當(dāng)時(shí)Oracle的一個(gè)技術(shù)專家羅杰?班福德已經(jīng)提出了一個(gè)突破性的設(shè)計(jì)方案- "高速緩存融合"（Cache Fusion）技術(shù)（關(guān)于這些歷史故事，我在新書《數(shù)據(jù)庫簡(jiǎn)史》中做了詳細(xì)的介紹）。最后的事實(shí)證明，這一次開創(chuàng)性的冒險(xiǎn)，Oracle是賭對(duì)了。

同志們，大家可以看一下，20多年的問題和今天是否有差別？我認(rèn)為是沒有的。讓應(yīng)用適應(yīng)數(shù)據(jù)庫，還是數(shù)據(jù)庫適應(yīng)應(yīng)用？每個(gè)人心中自有答案。當(dāng)然我們必須致敬華為，Meta ERP?以一己之力、行業(yè)協(xié)同，徹底解開自身在特定歷史時(shí)期所面臨的這一難題。

那么 Oracle 是怎么徹底解開這一 RAC 集群路線上的難題的？

那就是將?VAXcluster 寫到數(shù)據(jù)庫里去。臥榻之側(cè)，豈容他人鼾睡。

大家都知道，Oracle從 8 就開始做 DLM（分布式鎖管理器），而這一技術(shù)的鼻祖是DEC。Distributed Lock Manager 最早就是?OpenVMS 集群軟件中負(fù)責(zé)管理節(jié)點(diǎn)訪問共享資源的組件。1982 年，在 VAX/VMS V3.0 中就出現(xiàn)了第一個(gè)用于單機(jī)系統(tǒng)的鎖管理器，它為駐留在單個(gè)處理器上的多個(gè)進(jìn)程提供同步服務(wù)，并能消除死鎖。分布式鎖管理器由 Steve Beckhardt 設(shè)計(jì)，于 1984 年隨 VAX/VMS V4.0 一起發(fā)布。

Oracle RAC管理員非常熟悉的?Resource Manager、Lock Remastering 等都是 VAX 集群里首創(chuàng)的術(shù)語。以下這段VaxCluster手冊(cè)中的描述放到今天的數(shù)據(jù)庫手冊(cè)中也毫無問題：

鎖管理器的實(shí)現(xiàn)是為了將鎖管理的開銷分散到整個(gè)集群中，同時(shí)還能將執(zhí)行鎖服務(wù)所需的節(jié)點(diǎn)間流量最小化。因此，內(nèi)部數(shù)據(jù)庫分為兩部分：資源鎖描述和資源鎖目錄系統(tǒng)，這兩部分都是分布式的。

每個(gè)資源都有一個(gè)主節(jié)點(diǎn)，負(fù)責(zé)授予該資源的鎖；主節(jié)點(diǎn)維護(hù)一個(gè)已授予鎖的列表和一個(gè)該資源的等待請(qǐng)求隊(duì)列。對(duì)一棵樹的所有操作而言，主節(jié)點(diǎn)就是對(duì)根節(jié)點(diǎn)提出鎖請(qǐng)求的節(jié)點(diǎn)。當(dāng)主節(jié)點(diǎn)維護(hù)其資源樹的鎖數(shù)據(jù)時(shí)，任何對(duì)另一個(gè)節(jié)點(diǎn)掌握的資源持有鎖的節(jié)點(diǎn)都會(huì)維護(hù)自己的資源和鎖描述副本。

資源目錄系統(tǒng)將資源名稱映射為該資源的主節(jié)點(diǎn)名稱。目錄數(shù)據(jù)庫分布在愿意分擔(dān)這一開銷的節(jié)點(diǎn)之間。給定一個(gè)資源名稱，節(jié)點(diǎn)就可以根據(jù)名稱字符串和目錄節(jié)點(diǎn)數(shù)量的函數(shù)，輕松計(jì)算出所負(fù)責(zé)的目錄。

當(dāng)然除了 DEC 之外，早期的 Veritas 也通過集群軟件和 Oracle RAC 緊密連接，而且售價(jià)相當(dāng)可觀，幾乎和數(shù)據(jù)庫相當(dāng)。

但是，當(dāng)Oracle將Cluster“寫入數(shù)據(jù)庫”之后，這些軟件和數(shù)據(jù)庫的連接都被切斷了，也再未對(duì)數(shù)據(jù)庫產(chǎn)生如早期般的深遠(yuǎn)影響。

由于在數(shù)據(jù)庫領(lǐng)域，幾乎只有Oracle在堅(jiān)定的走向共享存儲(chǔ)集群的路線，第三方集群件在數(shù)據(jù)庫領(lǐng)域從此聲名不顯。

說完了Oracle和DEC的故事，再來看看IBM。IBM是藍(lán)色巨人，在所有技術(shù)棧上幾乎都有多套解決方案。在集群這一方向上，IBM的大型機(jī)也形成了深厚的技術(shù)積累。

IBM 最早于1990年提出Systems Complex（也即SysPlex)概念，1994年提出Parallel Sysplex概念,并行系統(tǒng)耦合體是大型機(jī)最具代表性的集群技術(shù)?？梢詫⒁慌_(tái)或多臺(tái)機(jī)器組成Sysplex，用于跨系統(tǒng)的通信聯(lián)絡(luò)，最多支持32個(gè)LPAR資源共享的讀/寫。同時(shí)提出的還有CF，即Coupling Facility - 耦合裝置，CF是一種支持共享對(duì)象的技術(shù)。在DB2集群中，CF提供了一個(gè)集中化設(shè)備來管理鎖，并且還充當(dāng)臟頁(dirty page)的全局共享緩沖池，從而有助于實(shí)現(xiàn)可伸縮性和可恢復(fù)性操作。

C.Mohan 等人在1997年發(fā)表的論文中，詳細(xì)的介紹了IBM基于共享數(shù)據(jù)的集群設(shè)計(jì)，以及Coupling Facility在其中所發(fā)揮的關(guān)鍵作用。

這些技術(shù)后來被下放到小型機(jī)中，2009年，DB2推出了基于小型機(jī)的pureScale集群，但是沒有取得像Oracle RAC那樣的成功。

在pureScale的架構(gòu)下，因?yàn)镃F（被重新釋意為Caching Facility）的存在，在集群成員節(jié)點(diǎn)故障時(shí)，不需要進(jìn)行資源目錄的凍結(jié)，這是優(yōu)勢(shì)；但是CF存在單點(diǎn)，也需要進(jìn)行高可用保護(hù)，客觀上也增加了集群的復(fù)雜性。

【上下求索】

前面的數(shù)據(jù)庫歷程，我們見證了系統(tǒng)軟件的集群時(shí)代，數(shù)據(jù)庫一體化的時(shí)代，最后，Oracle RAC集群占據(jù)了主流，并囊括了集群件的全部能力。

可是歷史總在輪回，數(shù)據(jù)庫的問題，不一定都要在數(shù)據(jù)庫中解決。在中國(guó)數(shù)據(jù)庫，尤其是分布式蓬勃發(fā)展的過程中，我們注意到，在數(shù)據(jù)庫外部，有兩大解決方案體系逐漸形成。

一者，是在數(shù)據(jù)庫上部，通過數(shù)據(jù)庫中間件解決分布式問題，二者，在數(shù)據(jù)庫底層，通過共享存儲(chǔ)集群件，提供數(shù)據(jù)庫共享存儲(chǔ)集群能力。

分布式中間件領(lǐng)域，Sharding-Sphere 和 MyCat?都是不同時(shí)期典型的代表。例如 MogDB 結(jié)合 Sharding-Sphere也能打造數(shù)千萬 tpmC的分布式架構(gòu)。以下這個(gè)架構(gòu)被稱為 MogDB Clowder。

可是中國(guó)數(shù)據(jù)庫行業(yè)呈現(xiàn)出的另外一個(gè)趨勢(shì)是：將“Sharding-Sphere"寫到數(shù)據(jù)庫里。歷史再次重演了，當(dāng)分庫分表、路由、中間件等能力，被數(shù)據(jù)庫一體化集成進(jìn)去，這些產(chǎn)品將在企業(yè)級(jí)應(yīng)用消失了，開源領(lǐng)域還會(huì)在，但是商業(yè)價(jià)值的探索將更加困難。

我們?cè)賮砜纯?strong>多主數(shù)據(jù)庫的核心 -?共享存儲(chǔ)集群件。在這個(gè)領(lǐng)域，中國(guó)此前沒有探索者。一個(gè)是因?yàn)榧夹g(shù)難度較大，一個(gè)是因?yàn)閿?shù)據(jù)庫領(lǐng)域沒有需求。中國(guó)數(shù)據(jù)庫廠商將注意力聚焦在分布式架構(gòu)上。

然而峰回路轉(zhuǎn)，濤聲依舊。在“金融業(yè)數(shù)據(jù)庫技術(shù)大會(huì)”上成立的“金融多主數(shù)據(jù)庫應(yīng)用行動(dòng)計(jì)劃”證明，金融客戶對(duì)多主集群仍然存在強(qiáng)烈的需求。

那么答案在哪里呢？

華為公司近期開源了一個(gè)產(chǎn)品：Cantian引擎。取義要扎根深遠(yuǎn)，長(zhǎng)成參天大樹之意。

參天起到的作用就是將過去中國(guó)數(shù)據(jù)庫領(lǐng)域缺少的一環(huán)補(bǔ)齊，通過系統(tǒng)級(jí)的集群能力，可以幫助以單機(jī)性能見長(zhǎng)的數(shù)據(jù)庫，形成共享集群解決方案，同時(shí)將可靠性和性能久經(jīng)驗(yàn)證的企業(yè)級(jí)存儲(chǔ)產(chǎn)品 OceanStor Dorado 引入作為共享存儲(chǔ)。

可以一舉解決金融行業(yè)數(shù)據(jù)庫國(guó)產(chǎn)化替代難的癥結(jié)。當(dāng)前，云和恩墨 MogDB 和 openGauss 都在加速適配參天存儲(chǔ)引擎，這次過程數(shù)據(jù)庫廠商參與建立的同盟，就是在這一方向上共識(shí)的體現(xiàn)。

參天引擎包含五大核心組件，分別是 CMS，負(fù)責(zé)集群管理服務(wù)，維護(hù)集群一致性；DRC，分布式資源目錄，管理資源在集群中的分布；DCS，分布式緩存服務(wù)；DLS，分布式鎖服務(wù)；MES，集群間通信服務(wù)。

通過有限的資料，可以看到，參天讀寫的Cache Fusion行為和Oracle基本保持一致。在下圖展示的流程中(數(shù)據(jù)頁位于內(nèi)存中），如果在雙實(shí)例中，實(shí)際上產(chǎn)生了一次 GC CR Block 2-way 的Cache Fusion讀請(qǐng)求。

被數(shù)據(jù)庫吞噬的，還可以再獨(dú)立出來。今天參天的嘗試，通過開源，將成果行業(yè)共享，這樣能夠?qū)崿F(xiàn)社會(huì)價(jià)值最大化，更能夠助力中國(guó)數(shù)據(jù)庫集體向前躍遷一大步。

參天引擎已經(jīng)在 openEuler 社區(qū)開源，從個(gè)人角度，我期待看到更多的中國(guó)數(shù)據(jù)庫和參天適配，重新探索“共享存儲(chǔ)集群”在中國(guó)數(shù)據(jù)庫產(chǎn)業(yè)中應(yīng)有的地位，更好的支撐企業(yè)級(jí)用戶對(duì)數(shù)據(jù)庫的多樣化架構(gòu)需求。

云和恩墨已經(jīng)投身其中，也期待對(duì)此有興趣的客戶，和我們一起探討 MogDB 和 openGauss 的共享存儲(chǔ)集群解決方案！

---

云和恩墨大講堂?|?一個(gè)分享交流的地方?|?MogDB

長(zhǎng)按，識(shí)別二維碼，加入萬人交流社群

請(qǐng)備注：云和恩墨大講堂

??點(diǎn)個(gè)“在看”?

你的喜歡會(huì)被看到?文章來源地址http://www.zghlxwxcb.cn/news/detail-713235.html