幫你了解一下Gaussdb,你學(xué)會(huì)了嗎?
大家都已經(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ì)較低。