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

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

CN是Coordinator Node的簡稱，負責數據庫系統元數據存儲、查詢任務的分解和部分執行，以及將DN中查詢結果匯聚在一起。DN是數據存儲節點，負責存儲本地數據，并且負責分布式執行計劃的本地算子執行。

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

從這張圖上，我們可以看出Gaussdb執行SQL的邏輯。客戶端通過CN的監聽端口連接到數據庫上，在CN上發起一個SQL查詢。CN進行SQL解析，生成分布式執行計劃，并將查詢計劃下推到多個DN，DN啟動執行線程完成查詢，將結果返回CN，CN匯總執行結果，對客戶端返回結果。

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

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

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

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

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

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

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

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

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

希望今天我的這篇文章能對大家在openGauss生態的數據庫選擇中有所幫助。在企業做信創數據庫替代的產品選擇時，可能會考慮到成本的問題，對于比較在乎成本的用戶，或者需要遷移的數據庫數量很多的用戶，商用版與開源版同時存在的生態可能比較適合。核心關鍵應用用商用的，普通的應用用開源的，其內核相同，學習與運維成本相對就會較低。