?寫(xiě)這篇文章的周末，我很多時(shí)候都是在思考一個(gè)數(shù)據(jù)庫(kù)國(guó)產(chǎn)化替代的建設(shè)方案，翻閱了大量的資料。今年正好是我參加工作后的第31個(gè)年頭，工作的最初十年，我寫(xiě)了十年代碼，從匯編、COBOL到C語(yǔ)言，寫(xiě)了幾十萬(wàn)行代碼；隨后的十幾年，我一直在幫助用戶用好數(shù)據(jù)庫(kù)，也在幫助Oracle推廣RAC技術(shù)；2015年開(kāi)始，我一邊繼續(xù)從事數(shù)據(jù)庫(kù)優(yōu)化的工作，一邊在幫助客戶如何從Oracle遷移到成本更低的數(shù)據(jù)庫(kù)系統(tǒng)上。所以對(duì)國(guó)產(chǎn)數(shù)據(jù)庫(kù)我一直有一種十分特殊的情感，這是一種愛(ài)恨交織的情感。所以今天最后用“亂象”這個(gè)題目的時(shí)候，還是有些猶豫的，在國(guó)產(chǎn)數(shù)據(jù)庫(kù)發(fā)展如火如荼的時(shí)候，潑這盆冷水合適不合適。

亂象

1.國(guó)產(chǎn)關(guān)系型數(shù)據(jù)庫(kù)廠商數(shù)量多，碎片化嚴(yán)重

根據(jù)工信部數(shù)據(jù)庫(kù)發(fā)展白皮書(shū)2021的描述，截止2021年6月底，光是國(guó)產(chǎn)關(guān)系型數(shù)據(jù)庫(kù)廠商就已經(jīng)高達(dá)81家，估計(jì)馬上要發(fā)布的2022版里突破100家甚至150家都是很有可能的。相對(duì)于十多年前的寥寥數(shù)家，這些年國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)業(yè)的發(fā)展確實(shí)是十分迅猛，用野蠻生長(zhǎng)來(lái)描述也不為過(guò)。這些新興的國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商里，也不乏具有相當(dāng)強(qiáng)大基因，投資巨大，真正認(rèn)真在做數(shù)據(jù)庫(kù)產(chǎn)業(yè)的企業(yè)，不過(guò)大洪水下肯定也會(huì)泥沙俱下。原本就起步較晚，人才儲(chǔ)備、資金投入都不太足夠的國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)業(yè)，再被割裂為這么多的細(xì)小單位，每個(gè)獨(dú)立個(gè)體的真實(shí)能力就很值得懷疑了。無(wú)論是CPU，服務(wù)器，操作系統(tǒng)，中間件這些IT基礎(chǔ)設(shè)施，投身于IT基礎(chǔ)設(shè)施中的王冠的企業(yè)沒(méi)想到有這么多，這不知道是中國(guó)數(shù)據(jù)庫(kù)之幸還是中國(guó)數(shù)據(jù)庫(kù)的災(zāi)難。

上周五我在一個(gè)沙龍上分享了一些關(guān)于基于業(yè)務(wù)場(chǎng)景的國(guó)產(chǎn)數(shù)據(jù)庫(kù)選型的演講，并不是開(kāi)門(mén)見(jiàn)山的去討論業(yè)務(wù)場(chǎng)景和數(shù)據(jù)庫(kù)選型，而是從對(duì)國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商的分析開(kāi)始的。這些分析都是基于工信部的產(chǎn)業(yè)發(fā)展白皮書(shū)的內(nèi)容。

從成立年限上看，我們的國(guó)產(chǎn)數(shù)據(jù)庫(kù)企業(yè)還很年輕，不過(guò)成立20年以上的企業(yè)還是有十四家，只不過(guò)這些企業(yè)的這20年并不好過(guò)，以數(shù)據(jù)庫(kù)產(chǎn)品銷(xiāo)售為主業(yè)根本生存不下去。因此雖然有20年的歷史，實(shí)際上真正的歷史恐怕要打些折扣的。

只看歷史可能還無(wú)法直接感受到差距，而從從業(yè)人數(shù)上看，就可以看到國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)業(yè)碎片化的惡果了。超過(guò)60%的數(shù)據(jù)庫(kù)廠商不足100人，而超過(guò)500人的企業(yè)不足10%。對(duì)于想摘取IT基礎(chǔ)設(shè)施王冠的中國(guó)數(shù)據(jù)庫(kù)企業(yè)，最大的企業(yè)的規(guī)模可能還不如某個(gè)哪怕二三流的國(guó)外數(shù)據(jù)庫(kù)廠商的一個(gè)小研發(fā)部門(mén)的規(guī)模。如果把人員再細(xì)化為管理、研發(fā)、產(chǎn)品、市場(chǎng)、銷(xiāo)售、后勤等部門(mén)，恐怕研發(fā)人員就更是少得可憐了。據(jù)說(shuō)目前國(guó)內(nèi)最大的數(shù)據(jù)庫(kù)廠商的研發(fā)人員不足500人，這就是中國(guó)數(shù)據(jù)庫(kù)企業(yè)的現(xiàn)狀。

2.技術(shù)基礎(chǔ)薄弱，人才匱乏，大多數(shù)技術(shù)來(lái)源于開(kāi)源項(xiàng)目

如果我們?cè)賮?lái)看看技術(shù)層面的東西，從專(zhuān)利數(shù)量上看，90%的數(shù)據(jù)庫(kù)企業(yè)的數(shù)據(jù)庫(kù)領(lǐng)域的專(zhuān)利數(shù)少于100件，所有的關(guān)系型數(shù)據(jù)庫(kù)廠商的專(zhuān)利數(shù)加在一起不足4000件，而截止2020年，Oracle公司一家企業(yè)的專(zhuān)利數(shù)就超過(guò)1萬(wàn)4千件。

在技術(shù)基礎(chǔ)薄弱，人才匱乏的情況下，為什么一下子能涌現(xiàn)出如此多的數(shù)據(jù)庫(kù)企業(yè)和產(chǎn)品呢？從國(guó)產(chǎn)數(shù)據(jù)庫(kù)的技術(shù)來(lái)源分析上我們就可以看出一些端倪了。

上面這個(gè)圖表是我們根據(jù)收集到的資料自己做的，不一定十分準(zhǔn)確，不過(guò)可以大體反映出國(guó)產(chǎn)數(shù)據(jù)庫(kù)的技術(shù)來(lái)源。大多數(shù)是來(lái)自于開(kāi)源項(xiàng)目，因此才會(huì)出現(xiàn)大量的規(guī)模較小的數(shù)據(jù)庫(kù)企業(yè)。使用開(kāi)源技術(shù)來(lái)發(fā)展自己的數(shù)據(jù)庫(kù)產(chǎn)業(yè)并不是一件壞事，實(shí)際上我還是比較贊成的。充分利用開(kāi)源技術(shù)能夠加速國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)業(yè)的發(fā)展，縮短與國(guó)外頭部企業(yè)的差距。不過(guò)利用開(kāi)源技術(shù)不等于完全依靠開(kāi)源技術(shù)，而是應(yīng)該在開(kāi)源技術(shù)基礎(chǔ)上進(jìn)行大量的自主創(chuàng)新，加入自己的技術(shù)。比如國(guó)內(nèi)有很多利用PG開(kāi)源代碼的數(shù)據(jù)庫(kù)產(chǎn)品，有哪家公司對(duì)PG的源碼的理解程度，對(duì)PG社區(qū)的貢獻(xiàn)能夠達(dá)到俄羅斯POSTGRESQLPRO的水平呢？可喜的是，在這種亂象后面我們已經(jīng)看到了一些數(shù)據(jù)庫(kù)廠商開(kāi)始了自主化的創(chuàng)新，在開(kāi)源代碼的基礎(chǔ)上已經(jīng)走得很遠(yuǎn)了，我想再有幾年的積累，一定會(huì)突破開(kāi)源技術(shù)上的某些瓶頸，走出自己的自主化道路。

3.國(guó)產(chǎn)數(shù)據(jù)庫(kù)的代碼自主化率是個(gè)迷

如果看工信部的代碼自主化測(cè)試報(bào)告，那么絕大多數(shù)號(hào)稱(chēng)國(guó)產(chǎn)自研的數(shù)據(jù)庫(kù)產(chǎn)品都能夠拿出很高自主化率的報(bào)告來(lái)，而且動(dòng)不動(dòng)都是95%以上的。我曾經(jīng)測(cè)試過(guò)一個(gè)號(hào)稱(chēng)代碼自主化率超過(guò)95%的數(shù)據(jù)庫(kù)產(chǎn)品，其SQL引擎是完全“兼容”MYSQL的，存儲(chǔ)引擎用的不是INNODB。有一次一不小心我把一個(gè)不太常用的MYSQL原生態(tài)的參數(shù)調(diào)整了一下，沒(méi)想到，SQL引擎的工作模式居然按照參數(shù)的要求調(diào)整了。如果僅僅為了保持MYSQL語(yǔ)法的兼容性的自主化代碼，連這種細(xì)微之處都模仿得如此完美，那也太牛了吧。

4.時(shí)常聲稱(chēng)吊打Oracle，實(shí)際上與Oracle差距甚大

雖然國(guó)產(chǎn)數(shù)據(jù)庫(kù)的專(zhuān)利很少，不過(guò)這不影響國(guó)產(chǎn)數(shù)據(jù)庫(kù)彎道超車(chē)，如果不能把Oracle拉出來(lái)吊打一番都不好意思說(shuō)自己是國(guó)產(chǎn)數(shù)據(jù)庫(kù)。而真實(shí)的應(yīng)用場(chǎng)景下卻反映出來(lái)我們的國(guó)產(chǎn)數(shù)據(jù)庫(kù)在CBO和SQL引擎方面與Oracle差距甚大。我也曾經(jīng)和一些數(shù)據(jù)庫(kù)研發(fā)人員做過(guò)深度交流，他們也承認(rèn)，要在數(shù)據(jù)庫(kù)上縮短與Oracle的差距是十分困難的。無(wú)論在人才積累、資金投入和實(shí)際應(yīng)用案例的反饋等方面都存在巨大的差距。特別是第三點(diǎn)，導(dǎo)致Oracle可以不斷從生產(chǎn)環(huán)境中發(fā)現(xiàn)優(yōu)化器的問(wèn)題加以改進(jìn)，而我們甚至都不知道優(yōu)化器改進(jìn)的目標(biāo)，更不要談從架構(gòu)上去規(guī)劃優(yōu)化器的發(fā)展路線了。

5.HTAP成為國(guó)產(chǎn)數(shù)據(jù)庫(kù)的標(biāo)配功能

雖然我們的國(guó)產(chǎn)數(shù)據(jù)庫(kù)還無(wú)法解決用戶迫切需要的SQL引擎和優(yōu)化器的提升，不過(guò)并不妨礙我們?cè)谄渌恍╊I(lǐng)域上進(jìn)行創(chuàng)新。在各種宣傳資料上，HTAP已經(jīng)成為了國(guó)產(chǎn)數(shù)據(jù)庫(kù)的標(biāo)配功能，不過(guò)我想一些國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商自己都沒(méi)幾個(gè)人真正地懂得什么是HTAP。他們號(hào)稱(chēng)的所謂HTAP大多數(shù)只是一個(gè)OLTP數(shù)據(jù)庫(kù)上具有一定的批處理能力而已。OLAP的計(jì)算場(chǎng)景和OLTP是完全不同的，OLTP要求資源均衡分配，每次執(zhí)行的延時(shí)穩(wěn)定并且盡可能段。而OLAP要求的是小并發(fā)下的大型甚至巨型計(jì)算，利用并行執(zhí)行充分利用服務(wù)器的資源，盡可能把CPU/內(nèi)存/IO的能力都充分壓榨出來(lái)，完成復(fù)雜的計(jì)算，大吞吐量的數(shù)據(jù)輸入和輸出。一個(gè)連資源隔離都做不好的數(shù)據(jù)庫(kù)產(chǎn)品，如何支持HTAP中兩種會(huì)互相傷害的計(jì)算場(chǎng)景呢？我見(jiàn)識(shí)過(guò)的大多數(shù)號(hào)稱(chēng)完美解決HTAP問(wèn)題的數(shù)據(jù)庫(kù)產(chǎn)品，實(shí)際上都不真正具備可實(shí)用的混合負(fù)載能力。僅僅是在某些測(cè)試環(huán)境可以表現(xiàn)出一些能力而已。

雖然如此，也并不能阻止HTAP成為很多企業(yè)招標(biāo)中的參數(shù)指標(biāo)，我不知道是采購(gòu)單位是真正需要這種計(jì)算能力，還是僅僅以此來(lái)黨同伐異的噱頭呢？

6.評(píng)價(jià)體系的亂象

每年都會(huì)出臺(tái)各種所謂的國(guó)產(chǎn)數(shù)據(jù)庫(kù)排行榜，不過(guò)這種排行榜似乎有點(diǎn)排排坐吃果果的感覺(jué)，第一名和第二十名的評(píng)分不超過(guò)5分，前幾天我看到一個(gè)榜單，第一名和第十名的分差只有1分多。如果我是一個(gè)企業(yè)的IT主管，會(huì)有一個(gè)感覺(jué)，這個(gè)榜上的產(chǎn)品，隨便選都不會(huì)有多大的差別吧。

結(jié)語(yǔ)

國(guó)產(chǎn)數(shù)據(jù)庫(kù)現(xiàn)在迎來(lái)了最好的發(fā)展機(jī)遇，我們已經(jīng)看到了芯片，服務(wù)器、安全等領(lǐng)域都在這個(gè)機(jī)遇到來(lái)時(shí)顯現(xiàn)出了勃勃生機(jī)。而在我相對(duì)熟悉的數(shù)據(jù)庫(kù)領(lǐng)域，我看到的只是一種表面的繁榮，并沒(méi)有看到一種良性的發(fā)展趨勢(shì)，希望這種局面很快會(huì)有所改觀，希望國(guó)產(chǎn)數(shù)據(jù)庫(kù)產(chǎn)業(yè)能夠異軍突起。?