簡單瞭解一下GaussDB

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

這是一個 Gaussdb的分散式形態的架構圖。從這張圖上，我們可以看出Gaussdb分為C N/DN/GTM 三種節點。 C N 是計算節點， D N 是儲存節點， G TM 是分散式事務管理器。實際上還有一些其他的元件，比如叢集管理 C M ，管理配置資訊的 E TCD 等，這裡就不一一羅列了。

CN 是 Coordinator Node 的簡稱 ，負責資料庫系統後設資料儲存、查詢任務的分解和部分執行，以及將 DN 中查詢結果匯聚在一起。 D N 是資料儲存節點，負責儲存本地資料，並且負責分散式執行計劃的本地運算元執行。

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

從這張圖上，我們可以看出 Gaussdb執行S QL 的邏輯。客戶端透過 C N 的監聽埠連線到資料庫上，在 C N 上發起一個 S QL 查詢。 C N 進行 S QL 解析，生成分散式執行計劃，並將查詢計劃下推到多個 D N ， D N 啟動執行執行緒完成查詢，將結果返回 C N ， C N 彙總執行結果，對客戶端返回結果。

針對網上對 Gaussdb的質疑，認為Gaussdb僅僅是P G 套殼，實際上也是不夠嚴肅的。實際上在 Gaussdb的官方文件中也沒有遮遮掩掩，直接表明了Gaussdb與P G 以及 P G - XC 的關係。 Gaussdb與P G 的主要區別在於程序模型與執行緒池模型的差異，以及 Gaussdb在P G 的 A STORE 基礎上自研了記憶體引擎，列存和 U STORE 。目前在 openGauss中U STORE 還是處於 B ETA 版本，而在商用的 Guassdb上，U STORE 已經正式商用了。

另外在 G TM 上， Gaussdb改寫了P GXC 的 G TM ，打破了 P GXC 在高併發環境下的 GTM 效能瓶頸。開源的 PGXC 因為 G TM 過重，並且 G TM 無法橫向擴充套件而導致高併發的負載下， G TM 會成為一個十分明顯的瓶頸點。

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

在語法上， Gaussdb支援( +) 外連線， “||”拼接字串等Oracle資料庫的操作，還是做了一定的友好性相容的，N VL,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在複雜S QL 語法相容方面做得還可以。不過因為條件有限，我目前還沒有做真實的測試，效能是不是夠好，還不敢說。

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

語法相容性還是一些表面的問題，實際上如果把應用從集中式的 Oracle資料庫遷移到分散式的Gaussdb，還有很多效能方面的問題需要考慮。比如S EQUENECE ，在集中式資料庫中，哪怕是在 rac上，S EQUENCE 只要 C ACHE 設定的合理，就不會有大的效能問題。而在分散式資料庫 Gaussdb中，Sequence的申請都會涉及G TM 操作，因此成本是較高的。如果大批次的資料寫入要使用 Sequence，那麼還是要採取一些特殊的做法的，否則效能是無法保證的。

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

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

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