華為公司今年6.30開源了openGauss資料庫，openGauss資料庫核心基于postgresql9.2.4演進而來，pg11.3版本資料庫中共有290個資料庫參數，而openGauss目前有515個資料庫參數，每個參數對應一個資料庫核心功能，是以可以看到華為公司對pg的核心還是做了非常大的改造和增強。
這篇文章對比了openGauss資料庫相比pg做了哪些增強和相比pg的不足之處，本文隻列舉一些較大的增強。
01
核心增強
1.最大可用模式most_available_sync
pg流複制一直有個痛點就是在一主一從同步模式下，如果備庫當機，主庫會hang，同步模式不會自動降級，需要依靠第三方工具進行判斷和監控，或者使用一主多備quorum的方式來防止備庫異常對主庫的影響。openGauss中支援了最大可用模式，開啟該參數後在主從連接配接正常的情況下處于同步模式，如果備機斷連會立刻切為異步模式，如果備機再次啟動會自動連接配接并切為同步模式。這個降級切換時間非常快，切換過程甚至不會hang，而且沒有逾時視窗參數來進行設定，這一點是個不足的地方。
2.xid不可耗盡
這個大家都知道了，openGauss将transactionid由int32改為了int64,64位的xid永遠不可能耗盡，雖然xid改為了64位，但是過期的xid依舊需要freeze清理，隻是永遠不用擔心會發生xid回卷當機的風險。
3.流複制環境自動建立實體複制槽
openGauss中搭建主從流複制環境後會預設自動建立一個slot_name為對端nodename的實體複制槽，為了防住備庫需要的xlog被主庫删除或清理。
4.增量檢查點
openGauss支援了增量檢查點，通過enable_incremental_checkpoint參數開啟。Pg中的檢查點執行時會将buffer中所有的髒頁刷到磁盤，需要在checkpoint_timeout*checkpoint_completion_target時間内完成刷髒頁動作。刷髒對資料庫是消耗非常大的動作，高斯中的增量檢查點會小批量的分階段的滾筒式的去進行髒頁刷盤，同時更新lsn資訊，回收不需要的xlog日志。
5.雙寫double write
我們知道作業系統資料塊是4k，資料庫一般是8k/16k/32k，這樣有可能造成頁面斷裂問題，一個資料庫資料塊刷到作業系統的過程中可能發生當機造成塊損壞資料庫無法啟動。mysql通過雙寫double write來解決這個問題，oracle不管這個問題，出了事情通過rman或者dg備庫來恢複，pg通過full_page_write來解決這個問題，就是在資料頁第一次發生變更的時候将整個頁面記錄到xlog日志中，這樣出了問題就有了完整的資料頁加xlog日志進行恢複，但是這樣帶來的問題就是大大增加了xlog的日志量，也對性能有一定影響。openGauss實作了類似mysql的雙寫，寫資料塊的同時将髒頁也寫到一個共享的雙寫空間裡，如果發生問題會從雙寫空間裡找到完整的資料頁進行恢複。雙寫特性參數enable_double_write需要配合增量檢查點一起使用。
6.用戶端密碼認證增強
pg預設的密碼加密算法為md5，openGauss增強為sha256，該功能需要配合用戶端改造才能相容。
7.xlog預配置設定
pg中的xlog日志是在寫滿後才會配置設定下一個日志，這樣帶來的問題是在作業系統寫一個16M的xlog日志時會有等待，那時候可能會卡一下，這也是為什麼pg在做并發insert測試的時候性能抖動的原因。openGauss中實作了xlog預配置設定，在xlog未寫滿時就配置設定下面一個或者幾個xlog，經壓測性能較穩定。
8.流複制線程連接配接認證
openGauss中主備的複制線程要連接配接對端伺服器時預設需要進行ssl認證，pg是不需要的，增強了安全，可以通過将remote_read_mode設定為non_authentication關閉認證(如果不關閉就需要配置相關ca證書密鑰，否則以-M primary/standby方式啟動資料庫會失敗)。
9.dbe_perf性能監控schema
openGauss在每個庫下面會預設存在一個dbe_perf的性能監控視圖，類似mysql的performance_schema，裡面有幾百個性能視圖，雖然這些視圖大部分pg裡面都有，但是單獨做到一個schema裡友善檢視和管理。
10.流複制環境主庫歸檔xlog數量最大值限制
xlog最大值的硬限制，通過max_size_for_xlog_prune參數控制，他不管xlog的删除會不會影響備機，隻要超過該值就進行删除。可以防止主備長期斷連造成主庫目錄爆掉。
11.public schema安全權限增強
openGauss将每個資料庫下的預設的public schema做了安全增強，預設普通使用者沒有權限在public下建立對象，需要進行授權。不敢說這個是不是改進，因為既然叫public，就是給大家用的。
12.摒除recovery.conf檔案
使用replconninfo配置主備連接配接資訊，application_name等相關配置并入postgresql.conf，簡化流程，友善主備進行來回切換，pg12的流複制也摒棄了recovery.conf檔案。
13.基于資料頁的複制
openGauss支援基于redo的複制、基于資料頁的複制以及兩種混合複制，通過enable_data_replicate和enable_mix_replication參數進行控制。
14.支援列存表，列存緩沖區
openGauss支援了列存表，通過cstore_buffers控制列存緩沖區大小，列存表支援壓縮。并且目前版本的高斯優化了列存表的并發插入性能，解決了插入時一行資料占一個cu造成空間急劇膨脹的問題。通過開啟enable_delta_store參數控制列存表的插入使用臨時表向主表merge的方式進行，既保證了性能，也解決了膨脹的問題
15.記憶體表
支援基于llvm的記憶體查詢引擎，支援高吞吐、低延遲通路。
16.NUMA架構優化
通過numa綁核，減少跨核記憶體通路的時延問題，提升CPU使用率，提升多線程間同步性能，xlog日志批量插入，熱點資料分散處理。
17.使用者資源管理
支援多租戶環境下的cpu記憶體限制，配置資源池，調用作業系統cgroup實作。
18.wdr報告
支援類似oracle awr性能報告。
19.記憶體池memorypool
在更上一層管理資料庫記憶體使用，限制一個資料庫節點可用的最大實體記憶體。
20.查詢記憶體限制query_mem
可以對某個查詢使用的記憶體進行限制。
21.異步直接io
開啟磁盤預配置設定，io預取，提升寫入性能。
22.列存表delta merge性能增強
開啟enable_delta_store參數控制列存表的插入使用臨時表向主表merge，提升性能，解決膨脹。
23.并行回放
支援備機并行回放日志，提高複制性能。
24.會話逾時
Session_timeout參數控制會話逾時時間，防止由于線程長期不釋放造成資料庫意外當機。
25.主備從與一主多備
除了支援一主多備模式，也支援主備從模式，主備機直接實體複制，從機預設沒有資料，當主庫宕，備機和從機組成新的複制關系，從機開始複制資料，這樣節省了空間的同時保證了高可用。
26.線程池
程序模型改為線程模型，線程池支援上萬的并發，通過線程池實作session和thread之間的解耦，提高線程的使用率，高并發下不會導緻線程的頻繁切換。
27.commit log由256k改為16M
為了配合64位xid。
02
正視不足
1.pg_stat_replication視圖丢失
pg中檢視複制狀态的基本視圖被丢掉了，雖然使用gs_ctl query指令也可以複制狀态，但是pg_stat_replication還可以檢視主從lag資訊，高斯中無法查詢。
2.編譯過于複雜，依賴過多
編譯需要很多依賴，而且版本固定，造成跨平台編譯難度很大，平台通用性差，你可能發現編譯華為的第三方編譯工具比編譯資料庫還麻煩。
3.不支援并行
目前高斯還不支援并行，希望後續引入pg9.6開始支援的并行功能。
4.沒有postgresql.auto.conf
無法使用alter system set配置相關參數
5.不支援pitr
目前還不支援基于時間點的恢複，據說830版本會支援。
6.不支援插件
這是一個極大的劣勢，pg良好的擴充性在于他支援插件，吸引了很多開發者開發基于pg的插件，而openGauss中已經不支援插件。
7.社群剛剛起步，參與度不高
openGauss社群剛剛起步，目前活躍度不高，希望未來越來越好吧，也希望高斯中的優秀特性也能被pg吸收。
8.周邊工具
高可用工具、資料同步工具不具備。
9.性能與原生pg存在差距
使用并發工具壓測資料庫代碼速度發現與原生pg存在差距，同時目前不支援并行，是以分析類場景也有不足。
8.copydir限制
openGauss中将資料庫資料導入目錄限制到資料目錄下的pg_copydir中，這個是很不人性化的設計，試想生産環境需要導數，需要先拷貝到資料目錄下，容易造成資料目錄滿。
