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

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

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

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

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

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

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

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

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

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

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

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

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

目前Gaussdb形成了商用數(shù)據(jù)庫、開源數(shù)據(jù)庫（openGuass）、基于開源數(shù)據(jù)庫的第三方商用數(shù)據(jù)庫這種豐富的生態(tài)，又在大生態(tài)上兼容流行度排名靠前的PostgreSQL數(shù)據(jù)庫。因此在生態(tài)建設(shè)方面具有得天獨厚的優(yōu)勢，這十分有利于該生態(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ù)庫為主。

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