國產資料庫與開原始碼

很多朋友覺得國產資料庫應該是完全自研的資料庫產品，不應該基於開原始碼去做開發。不過如果我換一個問題，一個只有三五年曆史的完全國產自研的資料庫產品與一個十分成熟的開源資料庫產品供他選擇，並且必須選擇其中之一，那麼大機率情況下他會去選擇開源資料庫。這是一個十分現實的問題，資料庫是十分重要的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系統等，與我們的國產資料庫進行適配，形成適配相容性報告與核心模組效能報告。這些評測報告可能對於企業來說，比程式碼自主率評測報告有價值的多。