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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于我國(guó)的數(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)的要求。只要代碼本身是安全的，并且符合我國(guó)的等保要求，比如支持SM3國(guó)密等，就可以了。

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