大家都已經(jīng)很熟悉openGauss了，昨天我的文章中說陜西電力的用采系統(tǒng)用Gaussdb替代了Oracle，就有朋友問我這個(gè)Gaussdb是不是就是openGauss。這個(gè)問題還真的有點(diǎn)不好回答，Gaussdb和openGauss淵源很近，但是還不是一碼事。華為在數(shù)據(jù)庫產(chǎn)品這方面還是挺復(fù)雜的。這個(gè)Gaussdb實(shí)際上指的是Gaussdb企業(yè)版，在早期的華為云上，叫做Gaussdb for openGauss。這個(gè)企業(yè)版的Gaussdb分為分布式和主備兩種形態(tài)，陜西用采用的是其中的分布式版本。而openGauss是Gaussdb產(chǎn)品的開源版本，是基于Gaussdb代碼基礎(chǔ)上分離出來的一個(gè)獨(dú)立的數(shù)據(jù)庫產(chǎn)品，也就是其主備版本，其中的分布式特性是完全剝離的。

這是一個(gè)Gaussdb的分布式形態(tài)的架構(gòu)圖。從這張圖上，我們可以看出Gaussdb分為CN/DN/GTM三種節(jié)點(diǎn)。CN是計(jì)算節(jié)點(diǎn)，DN是存儲(chǔ)節(jié)點(diǎn)，GTM是分布式事務(wù)管理器。實(shí)際上還有一些其他的組件，比如集群管理CM，管理配置信息的ETCD等，這里就不一一羅列了。

CN是Coordinator Node的簡稱，負(fù)責(zé)數(shù)據(jù)庫系統(tǒng)元數(shù)據(jù)存儲(chǔ)、查詢?nèi)蝿?wù)的分解和部分執(zhí)行，以及將DN中查詢結(jié)果匯聚在一起。DN是數(shù)據(jù)存儲(chǔ)節(jié)點(diǎn)，負(fù)責(zé)存儲(chǔ)本地?cái)?shù)據(jù)，并且負(fù)責(zé)分布式執(zhí)行計(jì)劃的本地算子執(zhí)行。

可能有些朋友看到上面的架構(gòu)會(huì)想起POSTGRES-XC這個(gè)開源項(xiàng)目，確實(shí)是的，早期的GAUSSDB是基于POSTGRES-XC開源項(xiàng)目的，因此雖然經(jīng)過多年迭代，還是保留了一定的PGXC的痕跡。有興趣的朋友可以去做個(gè)對(duì)比，實(shí)際上目前的Gaussdb與PGXC已經(jīng)是完全不同的數(shù)據(jù)庫了。

從這張圖上，我們可以看出Gaussdb執(zhí)行SQL的邏輯?？蛻舳送ㄟ^CN的監(jiān)聽端口連接到數(shù)據(jù)庫上，在CN上發(fā)起一個(gè)SQL查詢。CN進(jìn)行SQL解析，生成分布式執(zhí)行計(jì)劃，并將查詢計(jì)劃下推到多個(gè)DN，DN啟動(dòng)執(zhí)行線程完成查詢，將結(jié)果返回CN，CN匯總執(zhí)行結(jié)果，對(duì)客戶端返回結(jié)果。

針對(duì)網(wǎng)上對(duì)Gaussdb的質(zhì)疑，認(rèn)為Gaussdb僅僅是PG套殼，實(shí)際上也是不夠嚴(yán)肅的。實(shí)際上在Gaussdb的官方文檔中也沒有遮遮掩掩，直接表明了Gaussdb與PG以及PG-XC的關(guān)系。Gaussdb與PG的主要區(qū)別在于進(jìn)程模型與線程池模型的差異，以及Gaussdb在PG的ASTORE基礎(chǔ)上自研了內(nèi)存引擎，列存和USTORE。目前在openGauss中USTORE還是處于BETA版本，而在商用的Guassdb上，USTORE已經(jīng)正式商用了。

另外在GTM上，Gaussdb改寫了PGXC的GTM，打破了PGXC在高并發(fā)環(huán)境下的GTM性能瓶頸。開源的PGXC因?yàn)镚TM過重，并且GTM無法橫向擴(kuò)展而導(dǎo)致高并發(fā)的負(fù)載下，GTM會(huì)成為一個(gè)十分明顯的瓶頸點(diǎn)。

作為信創(chuàng)替代工作的潛在數(shù)據(jù)庫產(chǎn)品，大家可能很關(guān)心Gaussdb的Oracle兼容性問題，從openGauss上我們看到的和Oracle兼容的特性并不很多，因此很多朋友可能很關(guān)心Gaussdb是不是也像openGauss一樣。如果簡單分析一下Gaussdb，我們還是可以看出研發(fā)團(tuán)隊(duì)還是在兼容性上做了一定的工作的。首先PL/SQL存儲(chǔ)過程的兼容性還是不錯(cuò)的，大多數(shù)Oracle的存儲(chǔ)過程是可以簡單的遷移過去的，當(dāng)然PL/SQL上不大可能100%兼容，大多數(shù)國產(chǎn)數(shù)據(jù)庫，哪怕是和Oracle兼容性做得很好的達(dá)夢(mèng)數(shù)據(jù)庫都只能做到90+%的存儲(chǔ)過程語法兼容，不過這些兼容對(duì)于大多數(shù)應(yīng)用遷移來說就完全夠用了，Oracle PL/SQL的一些特殊語法，可能大多數(shù)開發(fā)人員都沒聽說過。

在語法上，Gaussdb支持(+)外連接，“||”拼接字符串等Oracle數(shù)據(jù)庫的操作，還是做了一定的友好性兼容的，NVL,DECODE等函數(shù)也實(shí)現(xiàn)了和Oracle語法的兼容，也設(shè)計(jì)了rowid位列。不過Gaussdb并沒有引入Oracle的dual表，因此雖然sequence的語法做了與Oracle兼容，不過只能使用select  seq.nextvel 語法來替代select  seq.nextvel from dual;。遇到這種Oracle數(shù)據(jù)庫使用的比較頻繁的語句還是要修改應(yīng)用的。另外rownum位列的缺失也會(huì)讓分頁查詢的語法與Oracle的一些傳統(tǒng)寫法不同。另外在時(shí)間函數(shù)上，Gaussdb引入了sysdate，并且支持對(duì)sysdate進(jìn)行類似Oracle的加減法操作。不過我并沒有找到systimestamp，如果要使用timestamp就只能使用pg_systimestamp了。

在統(tǒng)計(jì)和窗口函數(shù)上，Gaussdb提供的內(nèi)容要比Oracle還豐富一些，這對(duì)于分布式數(shù)據(jù)庫來說是十分重要的。這方面實(shí)際上是分布式數(shù)據(jù)庫的一個(gè)短板，能夠提供豐富的統(tǒng)計(jì)與窗口函數(shù)，說明Gaussdb在復(fù)雜SQL語法兼容方面做得還可以。不過因?yàn)闂l件有限，我目前還沒有做真實(shí)的測試，性能是不是夠好，還不敢說。

可以看出Gaussdb商用版在Oracle語法兼容上做了一定的工作，如果要從Oracle遷移應(yīng)用過來，比起openGauss來會(huì)簡化不少，不過比起這方面做得最好的國產(chǎn)數(shù)據(jù)庫達(dá)夢(mèng)數(shù)據(jù)庫來看，還是有一定的差距的。

語法兼容性還是一些表面的問題，實(shí)際上如果把應(yīng)用從集中式的Oracle數(shù)據(jù)庫遷移到分布式的Gaussdb，還有很多性能方面的問題需要考慮。比如SEQUENECE，在集中式數(shù)據(jù)庫中，哪怕是在rac上，SEQUENCE只要CACHE設(shè)置的合理，就不會(huì)有大的性能問題。而在分布式數(shù)據(jù)庫Gaussdb中，Sequence的申請(qǐng)都會(huì)涉及GTM操作，因此成本是較高的。如果大批量的數(shù)據(jù)寫入要使用Sequence，那么還是要采取一些特殊的做法的，否則性能是無法保證的。

另外一方面SQL的語法上Gaussdb雖然做了大量的優(yōu)化，但是分布式數(shù)據(jù)庫的CBO優(yōu)化器工作機(jī)制與集中式數(shù)據(jù)庫的差異也決定了在語法近似的SQL語句的執(zhí)行上存在巨大的差異，因此我們?cè)谧鰬?yīng)用遷移的時(shí)候還是需要充分考慮的。

目前Gaussdb形成了商用數(shù)據(jù)庫、開源數(shù)據(jù)庫（openGuass）、基于開源數(shù)據(jù)庫的第三方商用數(shù)據(jù)庫這種豐富的生態(tài)，又在大生態(tài)上兼容流行度排名靠前的PostgreSQL數(shù)據(jù)庫。因此在生態(tài)建設(shè)方面具有得天獨(dú)厚的優(yōu)勢(shì)，這十分有利于該生態(tài)的數(shù)據(jù)庫產(chǎn)品的發(fā)展。目前神州通用、南大通用、海量、云和恩墨等數(shù)據(jù)庫廠商都加入了openGauss生態(tài)，使用開源代碼封裝商用數(shù)據(jù)庫產(chǎn)品。其中南大通用的Gbase 8C是基于openGauss內(nèi)核的分布式數(shù)據(jù)庫，其他三家以集中式主備模式的數(shù)據(jù)庫為主。

今天本來想隨便寫兩句，沒想到也寫了這么大一篇了，希望今天我的這篇文章能對(duì)大家在openGauss生態(tài)的數(shù)據(jù)庫選擇中有所幫助。在企業(yè)做信創(chuàng)數(shù)據(jù)庫替代的產(chǎn)品選擇時(shí)，可能會(huì)考慮到成本的問題，對(duì)于比較在乎成本的用戶，或者需要遷移的數(shù)據(jù)庫數(shù)量很多的用戶，商用版與開源版同時(shí)存在的生態(tài)可能比較適合。核心關(guān)鍵應(yīng)用用商用的，普通的應(yīng)用用開源的，其內(nèi)核相同，學(xué)習(xí)與運(yùn)維成本相對(duì)就會(huì)較低。