國產資料庫系列文章丨國產資料庫發展十策(二):資料庫難在研發還是難在生態?

資料和雲發表於2021-11-23

資料庫屬於基礎軟體,在資訊系統中的重要性不斷增強,今天最廣泛採用的 RDBMS 技術,也已經經歷了50年的發展演進歷程。然而在中國國產資料庫領域,仍然存在“卡脖子”的難題,那麼問題來了,資料庫的發展,究竟是難在研發,還是難在生態?

前文回顧 >  國產資料庫丨國產資料庫發展十策(一):開發一個資料庫到底需要多少人?_ITPUB部落格

更多資料庫行業變革,歡迎光臨   

2021dtcs.jpeg

    國產資料庫的起點

    在網際網路上,有一張珍貴的照片淵遠流傳,照片來自1977年在黃山召開第一屆資料庫學會會議,第二排左七是中國資料庫的泰斗薩師煊老師,這一年被認為是中國資料庫的起點,這一年中國剛剛恢復高考。同樣是1977年,一家名為“Software Development Laboratories (SDL)”的公司在美國矽谷註冊成立,後來它的另外一個名字更廣為人知 - Oracle。
    1.jpg

    傳聞Oracle的名字來源於Larry Ellison 為 CIA 執行的一個專案,這個傳聞是真的,在 CIA 的解密檔案上能夠看到這個專案:Project ORACLE.  下圖有彩蛋,歡迎火眼金睛,留言反饋
    image.png

    中國的學術界開始 研究資料庫,美國的工業界已經開始 研發關係型資料庫,差距就此拉開;而自90年代開始,Oracle、Sybase、DB2、Informix等產品紛紛進入中國,並且佔據了壟斷地位;在那之後的2000年左右,國產資料庫的產品才剛剛推出邁向市場;時至今日,國產資料庫才進入快速發展期,一大批創業企業、創新產品不斷湧向市場,2011年巨杉成立,2015年PingCAP成立,2020年雲和恩墨髮布MogDB資料庫產品…
    ES 20211119 at 13.52.41.png

    回顧歷史,今天我們更加知道, 資料庫產業要想實現發展超越,產學研用必須要要同步推進,才有可能消除短板、加速生長。

     已經獲得各位資料英雄的現場支援:
    阿里巴巴集團副總裁,阿里雲智慧資料庫事業部負責人 李飛飛 主旨演講:雲原生資料庫2.0:企業級一站式資料管理;
    華為雲資料庫服務總經理 蘇光牛 主旨演講:GaussDB企業級雲原生架構演進與開放生態
    螞蟻集團OceanBase CTO 楊傳輝 主旨演講:OceanBase一體化架構的原生分散式資料庫
    騰訊雲資料庫副總經理 王義成 主旨演講:DSQL在國產化領域的技術創新與實踐
    TiDB創始人 黃東旭 主旨演講:從核心到產品到平臺:TiDB 的 DBaaS 之路;
    中國移動資訊科技中心研發創新中心副總經理 張春:基於磐基PaaS平臺構建中國移動雲原生統一DBaaS
    雲和恩墨 MogDB 掌門人 張皖川 受邀發表主旨演講:MogDB-依託開源社群的技術創新

    IBM和Oracle的機遇

    RDBMS 資料庫的歷史機遇首先光顧了 IBM,今天幾乎已經是眾所周知,E.F.Codd 的論文改變了資料庫的歷史,但是 Oracle 比IBM更敏感的認識到了歷史機遇,Larry Ellison 背後還有一位天才的程式設計師 Bob Miner,他們結識於 AMPEX公司,這個公司的名字在 CIA 的解密檔案中隨處可見。

    照片中右二就是這位天才的程式設計師,在開始創業後的一年之內,Bob就成功的用編匯語言(Assembly Language)實現了RDBMS,此後,版本2,版本3的更新也幾乎都是他一個人完成的程式碼編寫工作。直到1992年Oracle版本7,Bob一直都是技術小組的領軍人物。

    現在 Oracle的程式碼中,還能找到  Bob Miner 的痕跡,在 catalog5.sql 檔案中,註釋中有 Miner 在1984年留下的註釋:Rewrite for new dictionary but it still looks much the same to users。
    Miner 上面那一行的註釋者就是前面我們提到的 Andy,他於1984年加入Oracle,工作至今,成為了Oracle資料庫新一代的研發掌門人。

    緊接著,有人在1992年,修正了 Bob 的一些 mistakes。
    image.png

    Bob Miner 為Oracle奠基的 Rollback Segment 技術,可以說是一筆不可估量的技術財富,指引 Oracle 資料庫發展演進,直至今日。

    達夢和金倉的差異化選擇

    在中國資料庫領域,最早期的研發者就包括馮玉才老師,他在1988年研發了資料庫系統 CRDS,這也成為了達夢資料庫的前身。達夢資料庫的版本 2.0 在1996年釋出。率先起步的先發優勢,讓達夢選擇了自主研發的道路,成為了今天國產資料庫領域為數不多的全自研產品。

    達夢公司創立於2000年,從這一年開始,達夢開始作為一家商業化資料庫公司,展開了馮老師的創業征程。
    image.png

    國產資料庫的另外一個先驅是來自人民大學的人大金倉,創立於1999年,早於達夢公司。金倉選擇的道路是在開源產品 PostgreSQL 上進行自研開發迭代,推出 KingBase 品牌。按照公開資訊,Kingbase ES V1.0 在1999年釋出。
    image.png

    達夢資料庫和人大金倉的選擇,也是今天眾多國產廠商的兩條路線:自主研發和開源演進。這兩個路線,只要持續投入,在程式碼上具備自主能力,在智慧財產權上沒有瑕疵,就都能夠走得遠。

    從國產資料庫的先驅者來看,在關係型資料庫領域,中國的軟體研發以及產品化比美國至少晚了20年。但是,正是因為有了這麼多前仆後繼的奉獻者和探索者,中國的資料庫演進脈絡並未中斷。

    人大金倉副總裁 金學東,受邀參加 已經受邀出席  ,並發表 打造雲上資料庫服務全生命週期管理方案,助力企業數字化轉型 主題演講。

    從Oracle和Sybase看先發者的挑戰

    在關係型資料庫領域,先發者面臨著技術路線的選擇、探索的挑戰,這其中往往就伴隨著挫折和失敗,所以在RDBMS 50年的技術長河中,很多名噪一時的品牌都漸漸消失的歷史的長河中,這其中就包括Informix,Sybase 等產品。

    在很多技術方向上,Oracle都是率先的探索者,當 1984年,Oracle 在版本4中實現了一致性讀,在Version 6 中實現了行級鎖,領先性就被確立下來:
    image.png

    在今天的資料庫世界裡,你可能很難想象資料庫的世界,曾經讀可以阻塞寫,鎖總是加在頁之上,直至今日,Oracle的官網上還有這樣的對比報告。以下是關於頁鎖的描述對比:
    image.png

    還有關於一致性讀的對比:
    image.png

    而大約25年前,Sybase 的專家是這樣辯駁的:

    I cannot think of any application in which a properly designed PLL solution would perform any worse than its RLL counter part (but, as has been pointed out, it may very well take more design effort to achieve these results). And, in fact, I think that for a very large sub-set of these applications, performance can actually improve using PLL.

    (在上面的論述中,PLL 指 Page Level Locking,RLL 指 Row Level Locking)。

    從openGauss和PolarDB看追趕者的優勢

    時至今日,RDBMS的理論和實現已經足夠成熟,開源資料庫也已經做出了完整的呈現,對於追趕者來說,站在前人的肩膀上,已經極大的降低了投入風險。

    在最近釋出的 openGauss 2.0 版本中,一個重要的特性被推出,這就是: 。原位更新這個詞聽起來很新鮮,但其實是源自對 PostgreSQL 原有的 Heap 儲存引擎的替代。PG 採用追加更新方式儲存資料,也就是當修改資料時,不是在原位置修改,而是寫入一個新記錄,這會導致空間膨脹,也就需要定期回收過期的資料空間。這一直是 PostgreSQL 的一個弱項。

    現在 openGauss徹底解決了這個問題,實現了 Undo 機制,也就可以在原位置更新資料。這帶來的好處就包括:

    • 高效能:對插入、更新、刪除等不同負載的業務,效能以及資源使用表現相對均衡,相比Append Update引擎效能提升10%
    • 執行平穩:效能執行平穩,8小時效能滾降值從13.8%降低至2.5%
    • 高效儲存:支援最大限度的原位更新, TPCC負載下平均節約空間15%~20%,UNDO空間統一分配,集中回收,複用效率更高,儲存空間使用更加高效、平穩

    image.png

    而現在的好處是,以開源的形式,我們可以隨時來檢視 openGauss 的 ,例如以下就是 Ustore 的資料塊儲存結構:
    image.png

    而在 Oracle 21c 中才出現的區塊連結串列,在 openGauss 2.0 中也已經被實現。關於 Oracle Database 21c vs openGauss 2.0 的特性對比,請參考:

    在今年的雲棲大會上,PolarDB 開源了  ,我們注意到阿里雲在這個版本中,同樣實現了和Oracle類似的一致性讀機制,同樣透過 SCN 來作為一致性讀的基準。那麼和Oracle同樣的工作機制就都出現了,類似的有,事務槽(Transaction Slot),延遲塊清除(Delayed Record Cleanout)等。
    image.png

    PolarDB-X 的分散式事務,是透過基於 Paxos 的2PC 原子提交實現的,如前所訴,還實現了基於 Read Version 的 MVCC 併發控制。
    螢幕快照 20211122 下午8.12.43.png

    Paxos 演算法是 Leslie Lamport 於 1990 年提出的共識演算法,因為一些波折 1998 年才公開發表,後來使其獲得2013年的圖靈獎。這篇論文以難懂著稱,Lamport 被問到忍無可忍,2001 年重新發表了一篇一個公式都沒有的論文 —— ,摘要僅有一句話:

    The Paxos algorithm, when presented in plain English, is very simple.

    站在前人的肩膀上,無疑讓我們走得更快,而我們應當保持同樣的開放和分享精神。 在國產資料庫領域,隨著 openGauss、PolarDB、OceanBase 的陸續開源,開源開放也已經成為行業共識。

    阿里巴巴集團副總裁,阿里雲智慧資料庫事業部和達摩院資料庫與儲存實驗室負責人 李飛飛 已經受邀出席  ,並發表:雲原生資料庫2.0:企業級一站式資料管理 主題演講

    為什麼SQL Server和DB2未形成規模化三方生態?

    Oracle 資料庫為什麼在市場競爭中獲勝?在眾多因素中,一定有生態這重要一環,生態讓產品生根發芽、茁壯成長,最後根深葉茂,影響深遠。

    在過去十年, 在資料庫服務領域,服務了超過1000家企業客戶,深刻的感受到了Oracle生態圈的覆蓋之廣、影響之深,同時我們也在思考,為什麼商業資料庫的第二、第三名(DB2、SQL Server)沒有形成類似 Oracle 的強大生態圈?

    眾所周知,在國內市場,有很多服務類廠商、生態工具廠商圍繞Oracle提供產品和解決方案,但是你可能沒有見到成規模的 DB2、SQL Server 三方廠商,何解?

    我有一個關於技術方向的答案,那就是: 開放性。

    經常有朋友問我,為什麼 Oracle 的DBA生態就這麼活躍?我曾經在《Oracle 效能最佳化與診斷案例》一書中表達過這樣一個觀點:

    “…我聽到一句話印象深刻,叫“隱藏的權利感”,我想把這句話應用到資料庫,表達一下我的觀點。

    Oracle資料庫,雖然是一個商用資料庫不開源,但是它又是非常開放的一個產品,Oracle幾乎所有的內部操作,不管是調優的過程還是資料庫的各種內部操作,都是可跟蹤解析的。比如Oracle資料庫的啟動和關閉過程,全程是可跟蹤的。它的啟動關閉會解析成多少個遞迴操作,我們全都可以跟蹤出來。

    所以我們做Oracle DBA的工作時,面對任何事情我們都會非常有信心。Oracle開放了各種介面,方法和手段給我們,只要我們去分析研究,就能夠把一個問題的Root Cause找出來,接近Root Cause就離解決問題不遠了。

    一個資料庫只有變得更加開放介面,更加開放DeBug功能的,才能讓我們在研究這個資料庫的時候也可以找到更多的樂趣。 我覺得這裡面找到的樂趣就是我講的,是隱藏的權利感。就是我不動聲色,但是我知道我在處理接觸這個資料庫的時候,我有非常強的把控力,我能撼動和解決幾乎所有的問題。我覺得這一點對於技術人員是非常重要的。

    Oracle 透過 開放性,培養起豐富的人才資源,而除了 Oracle之外,DB2、SQL Server 的技術棧是非常封閉的,至今很多稍微複雜的問題,就只能依賴原廠商的二線支援,而 Oracle資料庫,第三方力量幾乎可以應對各種異常(除了改程式碼修Bug)。

    當然,我們也可以認為,這個領域只有佔據了足夠的市場份額,才能夠培育起全面的生態市場。

    那麼我們同樣要面臨一個嚴峻的問題:如果說生態只屬於第一位的領先者,那麼後來者,如何去建設共享的資料庫生態,促進國產資料庫的成功,就顯得更加迫切和重要。

    在中信證券的報告: ,曾經這樣描述:

    合作伙伴生態是 Oracle 早期佔領中國市場的核心要素之一,也是國產資料庫廠商未來的戰略重點。資料庫管理系統是資料管理架構的底層產品,每個客戶核心系統架構都不同,意味著需要針對不同客戶做大量定製化的開發。整合商、二次開發商、IT諮詢公司都是資料庫廠商生態夥伴體系中的重要參與者。生態夥伴體系建設能夠幫助企業快速實現業務擴張,同時最大程度減少成本的增長,使資料庫廠商能將有限的人員和資金投入到資料庫技術和產品的開發上。早在 2009 年,Oracle 就推出合作伙伴網路計劃(OPN),在當時被認為是十年以來最重大的進展。2013 年 Oracle 大中華區 OPN 成員已達到 2412 家,超過 90%的收入是透過合作伙伴取得的。

    東方證券在一份報告中也曾指出: 。明確的指出了生態的關鍵作用。
    image.png

    為什麼雲資料庫成為潮流?

    既然生態是資料庫成功的關鍵因素(尤其是對於後來者),我們也就能夠理解為什麼雲資料庫成為潮流。

    雲資料庫可以藉助雲的基礎,在雲上生長,而無需從頭建立生態,從而可以避免生態短板、快速的邁向成功,這也是雲原生資料庫倍受關注的根本。在 Gartner 釋出的2011~2020全球資料庫市場格局中,微軟在2020年超越了 Oracle 位列第一,而第三名 AWS、第六名 Google、第七名 阿里雲、第十名 華為雲,無一不是憑藉雲的優勢,在資料庫領域爭鋒:
    image.png

    那麼是不是雲廠商成功了,獨立的資料庫廠商就不復存在了呢?

    我在今年的雲棲大會講過一段話,我認為, "雲資料庫"讓資料庫得以永生了。為什麼呢?
    如果雲上的資料庫只能由雲廠商提供,那麼未來獨立的資料庫廠商都將消亡,但是今天,新的先驅者驗證了一條道理,生存之道仍然存在,MongoDB、snowflake 的探索已經初見端倪。在上圖中,第11位的 MongoDB、第17位的 Snowflake 都為我們證明了這一點。

    在雲時代,只有和雲共舞、共生,才能在未來的世界生存下來。

    策二:資料庫生態建設是關鍵

    總結一下, 在資料庫技術發展的初級探索階段,技術是關鍵(一個錯誤的路線選擇可能就讓商業上所有的努力灰飛煙滅),而在當下的技術成熟階段,生態就成為最重要的一環。

    中國資料庫的發展需要全鏈條的、全方位的協作,從廠商到企業使用者到第三方生態,全流程的都要協同運轉起來,我曾經寫到,2019年是國產資料庫元年。這是因為,在那之前是資料庫廠商自己使力氣,非常艱難;只有當我們真正意識到這是一個“卡脖子”的問題時,當使用者真正做出選擇時,國產資料庫的春天才真正到來。

    我們建議:成立以資料庫為中心的生態聯盟,構建統一的生態社群平臺,透過統一的標準體系,建設具有廣泛適應性的認證相容機制,培養具備多樣化服務能力的從業人員,才能對整個行業帶來相容幷包的高效率的促進作用。

    插播:資料庫生態頂級會議:資料技術嘉年華 即將於2021.12.23~24 舉辦,歡迎報名參會。

    image.png

    同時, 當 160多個國產資料庫走向市場時,在行業裡更需要能夠統一提供服務、生態工具產品的企業,能夠作為國產資料庫的統一提供商、生態建設者,為使用者保駕護航,為廠商助力加油

    2019年參加華為的HC大會時,在一個資料庫閉門討論會,我印象深刻的記得,其中一位與會專家慨然批評國產資料庫不好用不能用。我當時的回答是,你如果問國產資料庫(僅指我熟悉的OLTP)和Oracle相比好不好用,肯定不好用。我在20年前接觸Oracle資料庫的時候,也遇到非常多的問題,時至今日,在墨天輪上提問的很多人也會說Oracle很多地方不好用,但是由於 Oracle 建設了非常良好的生態體系、培養了大量的專業工程師,使得使用者在遇到問題時,找得到支援,解決得了問題,從而保障了使用者的業務運轉。

    所以 國產資料庫的發展一定需要不同角色的廣泛參與,要有廠商基於國產資料庫開發應用軟體,要有第三方為國產資料庫提供服務,要有機構為國產資料庫培養輸送人才,要有投資方容忍國產資料庫試錯成長,唯有如此,國產資料庫才能少摔跤,跑得快!

    時至今日,國產資料庫的發展,一定要全軍為上,任何單方面的努力都是單薄無力的,我堅信這正是中國資料庫最好的發軔之機。

    參考文獻

    1. Oracle 和SQL Server,Sybase的對比

    2. Ustore在openGauss閃亮登場

    3. PolarDB-X分散式資料庫解決方案

    4. 中信證券:資料庫,企業數字化支撐,大資料時代基石

    5. 東方證券:國產基礎軟硬體,開源、遷移、上雲,關鍵在生態

    6. 金聲玉振-資料庫技術和生態變革創新的十年

    7. 2019,國產資料庫元年開啟新紀元

    來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31556440/viewspace-2843736/,如需轉載,請註明出處,否則將追究法律責任。

    相關文章