?很多朋友覺得國產(chǎn)數(shù)據(jù)庫應(yīng)該是完全自研的數(shù)據(jù)庫產(chǎn)品，不應(yīng)該基于開源代碼去做開發(fā)。不過如果我換一個問題，一個只有三五年歷史的完全國產(chǎn)自研的數(shù)據(jù)庫產(chǎn)品與一個十分成熟的開源數(shù)據(jù)庫產(chǎn)品供他選擇，并且必須選擇其中之一，那么大概率情況下他會去選擇開源數(shù)據(jù)庫。這是一個十分現(xiàn)實的問題，數(shù)據(jù)庫是十分重要的IT基礎(chǔ)設(shè)施，其成熟度與穩(wěn)定性是十分關(guān)鍵的。

在自研比例較高的國產(chǎn)數(shù)據(jù)庫廠商中，達夢是十分典型的一家，其數(shù)據(jù)庫產(chǎn)品已經(jīng)有是超過20年歷史了。從達夢6開始在國家電網(wǎng)電力調(diào)度等核心系統(tǒng)中獲得了應(yīng)用，也經(jīng)受了磨練。從客戶用得戰(zhàn)戰(zhàn)兢兢到獲得了客戶的信任，這是花了至少五年時間的磨合的。從DM7開始，代碼進行了全面的重構(gòu)，代碼自主率已經(jīng)達到了較高的程度，目前的主流版本已經(jīng)是DM8了，其穩(wěn)定性已經(jīng)經(jīng)過了大量客戶的實際應(yīng)用考驗。

國內(nèi)像達夢一樣具有超過20年歷史的數(shù)據(jù)庫產(chǎn)品并不多，不過很多國產(chǎn)數(shù)據(jù)庫產(chǎn)品歷史雖然不是很長，但是都是基于相對比較成熟的開源項目的基礎(chǔ)上研發(fā)的。作為DBA或者用戶來說，我們對這些產(chǎn)品也是比較信任的，因為這些開源數(shù)據(jù)庫產(chǎn)品有社區(qū)里上百萬的用戶在使用。

而如果有人告訴我，他們的數(shù)據(jù)庫產(chǎn)品是一行行代碼自己開發(fā)出來的，沒有采用任何開源代碼，而這個產(chǎn)品的歷史不過三五年，那么恕我直言，我寧愿你是基于開源代碼開發(fā)的。三五年時間碼出的一個數(shù)據(jù)庫產(chǎn)品，沒有經(jīng)過數(shù)萬個用戶去驗證過的，我是不敢完全信任它的。一個通用關(guān)系型數(shù)據(jù)庫產(chǎn)品是幾百萬行代碼起步的，哪怕只有兩百萬行代碼，那也是至少300-400個人年的全流程開發(fā)工作量。哪怕你的整個研發(fā)隊伍有100人，也需要3-4年的時間才能完成beta測試，交付給客戶試用。而這些產(chǎn)品必須能夠在企業(yè)核心業(yè)務(wù)場景中獲得使用的機會，才有可能從不夠成熟變得相對成熟。但是在目前的國產(chǎn)數(shù)據(jù)庫產(chǎn)品如此內(nèi)卷的市場環(huán)境中，是很難找到當(dāng)年達夢與電力調(diào)度這樣的磨練機會的。

國產(chǎn)數(shù)據(jù)庫產(chǎn)品真的不是必須是一行行代碼都是自己寫的，這樣會導(dǎo)致重復(fù)的去創(chuàng)造輪子，浪費有限的而研發(fā)費用與時間。實際上哪怕Oracle數(shù)據(jù)庫里也大量使用了開源代碼，用開源代碼沒有什么大不了的事情。我實際上是十分贊成在符合開源協(xié)議的基礎(chǔ)上，合理的使用開源代碼來開發(fā)國產(chǎn)數(shù)據(jù)庫產(chǎn)品的。

俄烏戰(zhàn)爭后，Oracle，IBM等都中斷了俄羅斯的業(yè)務(wù)，俄羅斯本土企業(yè)PostgresqlPro成為了Oracle的重要替代品。這家Postgresql開源社區(qū)下游的數(shù)據(jù)庫廠商，其核心完全使用PG開源代碼，整合進自己的原創(chuàng)代碼，發(fā)布了自主的企業(yè)版PG版本。美國的技術(shù)遏制并沒有對PostgresqlPro的數(shù)據(jù)庫業(yè)務(wù)造成影響，也證明了PG開源社區(qū)的安全性。使用開源代碼并不像某些領(lǐng)導(dǎo)想象的那樣，會不夠安全。

實際上，在通用關(guān)系型數(shù)據(jù)庫領(lǐng)域，最近幾年在技術(shù)上貢獻比較大的是亞馬遜，Aurora是近些年來數(shù)據(jù)庫領(lǐng)域最具影響力的創(chuàng)新技術(shù)。2022年谷歌推出的AlloyDB也是對Aurora的一種致敬。不管是Aurora還是AlloyDB都是完全基于開源數(shù)據(jù)庫基礎(chǔ)上的技術(shù)創(chuàng)新，其數(shù)據(jù)庫的最為核心的代碼都是開源代碼，隨著開源社區(qū)的發(fā)展，Aurora和AlloyDB都可以升級其數(shù)據(jù)庫核心代碼。從我個人的觀點來看，亞馬遜Aurora在數(shù)據(jù)庫技術(shù)上的創(chuàng)新和貢獻遠遠高于號稱代碼自主率超過90%的任何一家國產(chǎn)數(shù)據(jù)庫廠商。

使用開源代碼并不丟人，而是一種快速發(fā)展國產(chǎn)數(shù)據(jù)庫產(chǎn)業(yè)的有效模式。但是在數(shù)據(jù)庫產(chǎn)品中一定要有自己的原創(chuàng)，有自己的創(chuàng)新。PostgresqlPro讓人尊敬的原因也是如此，在PG社區(qū)還沒有解決XID64的時候，他們的企業(yè)版數(shù)據(jù)庫產(chǎn)品已經(jīng)支持XID64了。日本的自主數(shù)據(jù)庫產(chǎn)業(yè)也是基于開源數(shù)據(jù)庫項目的，日本的PG數(shù)據(jù)庫應(yīng)用規(guī)模十分龐大，并且也有大量的原創(chuàng)技術(shù)。從NTT的項目中孵化出了著名的PGXC/PGXL兩個開源項目，這兩個開源項目目前也被大量的國產(chǎn)數(shù)據(jù)庫廠商所使用。

令人欣慰的是國產(chǎn)數(shù)據(jù)庫基于開源項目的創(chuàng)新也已經(jīng)起步。openGauss的起點是PG 9.2.4核心，不過整個代碼已經(jīng)進行了重構(gòu)，在開發(fā)語言上用C++替代了C語言，為了更好的適應(yīng)NUMA架構(gòu)，openGauss采用了單進程多線程架構(gòu)替代了傳統(tǒng)PG的多進程架構(gòu)。openGauss的核心代碼已經(jīng)完全脫離PG社區(qū)，不過從openGauss 3.x的性能上來看，基本上是追上開源社區(qū)的最新版本了，在某些方面甚至還實現(xiàn)了對PG社區(qū)最新穩(wěn)定版本的超越。雖然openGauss目前的SQL引擎的核心還在大量使用PG社區(qū)版的代碼，但是已經(jīng)融入了大量的創(chuàng)新技術(shù)。特別是openGauss在USTOR替換ASTOR的方面進展十分迅速，我想4.0時openGauss會給我們更多的驚喜。目前已經(jīng)有大量的國產(chǎn)數(shù)據(jù)庫廠商加入了openGauss開源生態(tài)，在中國廣大的用戶群體的磨練下，openGauss的前途十分光明。

瀚高旗下的ivorySQL走的是另外一條路線，其核心代碼完全兼容PG，并且能夠隨著PG版本升級，而ivorySQL的創(chuàng)新點集中在與Oracle的兼容性方面。我想完全兼容最新的PG核心和與Oracle高度兼容這個特性必然會滿足一部分準(zhǔn)備把數(shù)據(jù)庫從Oracle遷移到開源或者國產(chǎn)數(shù)據(jù)庫的中小型用戶的需求，這個創(chuàng)新點雖然在技術(shù)上并不高大上，但是也十分有價值。

我十分贊同國產(chǎn)數(shù)據(jù)庫產(chǎn)品使用成熟的開源代碼，但是我們不能只做開源社區(qū)的吸血鬼，而應(yīng)該為開源數(shù)據(jù)庫做出中國貢獻。前陣子我寫過一篇關(guān)于在PG數(shù)據(jù)庫中消除DOUBLE BUFFERING，引入AIO的文章，實際上對于一些開源數(shù)據(jù)庫中的老大難問題，我們的使用開源數(shù)據(jù)庫代碼的數(shù)據(jù)庫廠商完全是可以組織攻關(guān)的，把成果提交給開源社區(qū)或者在自己的企業(yè)版中自用都是沒有問題的。一旦創(chuàng)新進入深水區(qū)，那么解決核心問題也并不是不可能的事情。

實際上目前國產(chǎn)數(shù)據(jù)庫在自己的開源社區(qū)發(fā)展方面也十分成功，PINGCAP的TiDB，螞蟻的Oceanbase都已經(jīng)發(fā)展成為有一定國際影響力的開源數(shù)據(jù)庫產(chǎn)品。阿里的Polardb-PG從架構(gòu)上充分學(xué)習(xí)了Aurora的日志即數(shù)據(jù)庫的思想，充分利用開源數(shù)據(jù)庫PG的核心能力，打造出能夠支撐核心關(guān)鍵業(yè)務(wù)的自主數(shù)據(jù)庫產(chǎn)品，并把代碼保持開源。依托這些我國企業(yè)主導(dǎo)的開源數(shù)據(jù)庫產(chǎn)品，也必將能夠涌現(xiàn)出一批以這些開源項目為基礎(chǔ)的國產(chǎn)商用數(shù)據(jù)庫產(chǎn)品。

對于我國的數(shù)據(jù)庫產(chǎn)業(yè)而言，是否基于開源數(shù)據(jù)庫代碼構(gòu)建商用數(shù)據(jù)庫產(chǎn)品并不重要，基于哪種開源社區(qū)代碼，PG還是MYSQL也不重要。只要企業(yè)能夠符合開源社區(qū)的版權(quán)要求，那么封裝商用數(shù)據(jù)庫產(chǎn)品都是合理的。我們的行業(yè)管理部門也不應(yīng)該以是否使用了開源代碼來衡量是否符合信創(chuàng)的要求。只要代碼本身是安全的，并且符合我國的等保要求，比如支持SM3國密等，就可以了。

我們的行業(yè)監(jiān)管部門應(yīng)該把評測重點放在數(shù)據(jù)庫產(chǎn)品本身的能力上，其評測結(jié)果能夠給數(shù)據(jù)庫用戶提供更好的參考性，這樣的評測也才更有價值。比如我們可以基于某個國內(nèi)企業(yè)使用較廣的ERP產(chǎn)品，財務(wù)軟件，MES系統(tǒng)，OA系統(tǒng)等，與我們的國產(chǎn)數(shù)據(jù)庫進行適配，形成適配兼容性報告與核心模塊性能報告。這些評測報告可能對于企業(yè)來說，比代碼自主率評測報告有價值的多。?