國產數據庫與開源代碼
?很多朋友覺得國產數據庫應該是完全自研的數據庫產品,不應該基于開源代碼去做開發。不過如果我換一個問題,一個只有三五年歷史的完全國產自研的數據庫產品與一個十分成熟的開源數據庫產品供他選擇,并且必須選擇其中之一,那么大概率情況下他會去選擇開源數據庫。這是一個十分現實的問題,數據庫是十分重要的IT基礎設施,其成熟度與穩定性是十分關鍵的。
在自研比例較高的國產數據庫廠商中,達夢是十分典型的一家,其數據庫產品已經有是超過20年歷史了。從達夢6開始在國家電網電力調度等核心系統中獲得了應用,也經受了磨練。從客戶用得戰戰兢兢到獲得了客戶的信任,這是花了至少五年時間的磨合的。從DM7開始,代碼進行了全面的重構,代碼自主率已經達到了較高的程度,目前的主流版本已經是DM8了,其穩定性已經經過了大量客戶的實際應用考驗。
國內像達夢一樣具有超過20年歷史的數據庫產品并不多,不過很多國產數據庫產品歷史雖然不是很長,但是都是基于相對比較成熟的開源項目的基礎上研發的。作為DBA或者用戶來說,我們對這些產品也是比較信任的,因為這些開源數據庫產品有社區里上百萬的用戶在使用。
而如果有人告訴我,他們的數據庫產品是一行行代碼自己開發出來的,沒有采用任何開源代碼,而這個產品的歷史不過三五年,那么恕我直言,我寧愿你是基于開源代碼開發的。三五年時間碼出的一個數據庫產品,沒有經過數萬個用戶去驗證過的,我是不敢完全信任它的。一個通用關系型數據庫產品是幾百萬行代碼起步的,哪怕只有兩百萬行代碼,那也是至少300-400個人年的全流程開發工作量。哪怕你的整個研發隊伍有100人,也需要3-4年的時間才能完成beta測試,交付給客戶試用。而這些產品必須能夠在企業核心業務場景中獲得使用的機會,才有可能從不夠成熟變得相對成熟。但是在目前的國產數據庫產品如此內卷的市場環境中,是很難找到當年達夢與電力調度這樣的磨練機會的。
國產數據庫產品真的不是必須是一行行代碼都是自己寫的,這樣會導致重復的去創造輪子,浪費有限的而研發費用與時間。實際上哪怕Oracle數據庫里也大量使用了開源代碼,用開源代碼沒有什么大不了的事情。我實際上是十分贊成在符合開源協議的基礎上,合理的使用開源代碼來開發國產數據庫產品的。
俄烏戰爭后,Oracle,IBM等都中斷了俄羅斯的業務,俄羅斯本土企業PostgresqlPro成為了Oracle的重要替代品。這家Postgresql開源社區下游的數據庫廠商,其核心完全使用PG開源代碼,整合進自己的原創代碼,發布了自主的企業版PG版本。美國的技術遏制并沒有對PostgresqlPro的數據庫業務造成影響,也證明了PG開源社區的安全性。使用開源代碼并不像某些領導想象的那樣,會不夠安全。
實際上,在通用關系型數據庫領域,最近幾年在技術上貢獻比較大的是亞馬遜,Aurora是近些年來數據庫領域最具影響力的創新技術。2022年谷歌推出的AlloyDB也是對Aurora的一種致敬。不管是Aurora還是AlloyDB都是完全基于開源數據庫基礎上的技術創新,其數據庫的最為核心的代碼都是開源代碼,隨著開源社區的發展,Aurora和AlloyDB都可以升級其數據庫核心代碼。從我個人的觀點來看,亞馬遜Aurora在數據庫技術上的創新和貢獻遠遠高于號稱代碼自主率超過90%的任何一家國產數據庫廠商。
使用開源代碼并不丟人,而是一種快速發展國產數據庫產業的有效模式。但是在數據庫產品中一定要有自己的原創,有自己的創新。PostgresqlPro讓人尊敬的原因也是如此,在PG社區還沒有解決XID64的時候,他們的企業版數據庫產品已經支持XID64了。日本的自主數據庫產業也是基于開源數據庫項目的,日本的PG數據庫應用規模十分龐大,并且也有大量的原創技術。從NTT的項目中孵化出了著名的PGXC/PGXL兩個開源項目,這兩個開源項目目前也被大量的國產數據庫廠商所使用。
令人欣慰的是國產數據庫基于開源項目的創新也已經起步。openGauss的起點是PG 9.2.4核心,不過整個代碼已經進行了重構,在開發語言上用C++替代了C語言,為了更好的適應NUMA架構,openGauss采用了單進程多線程架構替代了傳統PG的多進程架構。openGauss的核心代碼已經完全脫離PG社區,不過從openGauss 3.x的性能上來看,基本上是追上開源社區的最新版本了,在某些方面甚至還實現了對PG社區最新穩定版本的超越。雖然openGauss目前的SQL引擎的核心還在大量使用PG社區版的代碼,但是已經融入了大量的創新技術。特別是openGauss在USTOR替換ASTOR的方面進展十分迅速,我想4.0時openGauss會給我們更多的驚喜。目前已經有大量的國產數據庫廠商加入了openGauss開源生態,在中國廣大的用戶群體的磨練下,openGauss的前途十分光明。
瀚高旗下的ivorySQL走的是另外一條路線,其核心代碼完全兼容PG,并且能夠隨著PG版本升級,而ivorySQL的創新點集中在與Oracle的兼容性方面。我想完全兼容最新的PG核心和與Oracle高度兼容這個特性必然會滿足一部分準備把數據庫從Oracle遷移到開源或者國產數據庫的中小型用戶的需求,這個創新點雖然在技術上并不高大上,但是也十分有價值。
我十分贊同國產數據庫產品使用成熟的開源代碼,但是我們不能只做開源社區的吸血鬼,而應該為開源數據庫做出中國貢獻。前陣子我寫過一篇關于在PG數據庫中消除DOUBLE BUFFERING,引入AIO的文章,實際上對于一些開源數據庫中的老大難問題,我們的使用開源數據庫代碼的數據庫廠商完全是可以組織攻關的,把成果提交給開源社區或者在自己的企業版中自用都是沒有問題的。一旦創新進入深水區,那么解決核心問題也并不是不可能的事情。
實際上目前國產數據庫在自己的開源社區發展方面也十分成功,PINGCAP的TiDB,螞蟻的Oceanbase都已經發展成為有一定國際影響力的開源數據庫產品。阿里的Polardb-PG從架構上充分學習了Aurora的日志即數據庫的思想,充分利用開源數據庫PG的核心能力,打造出能夠支撐核心關鍵業務的自主數據庫產品,并把代碼保持開源。依托這些我國企業主導的開源數據庫產品,也必將能夠涌現出一批以這些開源項目為基礎的國產商用數據庫產品。
對于我國的數據庫產業而言,是否基于開源數據庫代碼構建商用數據庫產品并不重要,基于哪種開源社區代碼,PG還是MYSQL也不重要。只要企業能夠符合開源社區的版權要求,那么封裝商用數據庫產品都是合理的。我們的行業管理部門也不應該以是否使用了開源代碼來衡量是否符合信創的要求。只要代碼本身是安全的,并且符合我國的等保要求,比如支持SM3國密等,就可以了。
我們的行業監管部門應該把評測重點放在數據庫產品本身的能力上,其評測結果能夠給數據庫用戶提供更好的參考性,這樣的評測也才更有價值。比如我們可以基于某個國內企業使用較廣的ERP產品,財務軟件,MES系統,OA系統等,與我們的國產數據庫進行適配,形成適配兼容性報告與核心模塊性能報告。這些評測報告可能對于企業來說,比代碼自主率評測報告有價值的多。?