摘要：本文從總體架構、數據分布方式、計算下推、數據強一致等方面進行介紹GaussDB(for openGauss)。
1.前言
隨着雲計算規模越來越大，企業業務數據量呈指數級增長，傳統數據庫在海量數據存儲與管理方面顯得力不從心，面臨“存不下，算得慢、算不准”的問題。
面對挑戰，華為雲數據庫深度融合華為在數據庫領域多年的經驗，充分結合了企業級場景需求，基於openGauss自研生態推出了企業級分布式關系型數據庫GaussDB(for openGauss)。GaussDB(for openGauss)目前支持單分片和分布式兩種部署形態，在支撐傳統業務的基礎上，持續構建競爭力特性，為企業面向數字化轉型提供了無限可能。
4月9日，由華為雲主辦的GaussDB(for openGauss)系列技術直播第2期《華為雲數據庫 GaussDB(for openGauss)數據存儲與訪問》於線上開啟，直播詳細介紹了GaussDB(for openGauss)的數據分布方式和數據讀寫流程，為方便大家快速了解GaussDB(for openGauss)，本文結合第2場直播內容從總體架構、數據分布方式、計算下推、數據強一致等方面進行介紹。
2.分布式架構
GaussDB(for openGauss)是一個典型的基於數據分片的雙層分布式架構(share nothing)，數據通過一定的規則比如hash、list或者range等讓數據打散分布到不同的數據節點上，計算時底層多個數據節點共同參與，上層協調節點負責執行計划生成和結果匯聚。
3.讓數據“存得下、算得快、算得准”
隨着5G時代的到來，單一節點是難以應對數據規模的不斷增長並確保性能的需要，業務面臨“存不下、算得慢、算不准”的問題。而GaussDB(for openGauss)可橫向擴展的分布式架構可以很好滿足大規模海量數據的計算存儲需求，讓數據“存得下、算得快、算得准”。
3.1海量數據“存得下”
GaussDB(for openGauss) 支持1000+的數據節點擴展能力，數據通過一定的規則比如hash、list或者range等讓數據打散分布到不同的數據節點上，讓數據“存得下”。
數據分布方式
GaussDB(for openGauss)支持hash、list、range、replication分布方式，下圖以hash和replication為例，示意了數據在DN節點上的分布情況。create table通過distribute by語法指定表的數據分布方式。hash分布把數據散列存儲到所有DN，適合數據量比較大的表；replication分布把數據復制存儲到所有DN，數據更新時，會同時更新所有DN，采用2PC(兩階段提交)保證分布式事務的一致性，適合更新頻率比較低的小表。
一致性hash
GaussDB的hash分布采用類似一致性hash的方式，數據通過兩層映射，第一層通過hash映射把數據映射到N個hash bucket中，或者叫vnode中；第二層映射把vnode映射到物理的datanode上。擴容時，只需要調整二層映射，保證數據搬遷最小：數據只會搬遷到新節點，已有節點之間不會互相搬遷數據；
分布鍵的選擇
對於數據分布來講，分布鍵的選擇至關重要，不合適的分布鍵會導致數據傾斜，導致木桶效應。分布鍵的選擇一般遵循如下原則：
a. 盡量選擇distinct值比較多的列，保證數據均勻分布。分布均勻是為了避免木桶效應，各個節點對等執行。
b. 盡量選擇Join列或group 列做分布列。盡量選擇Join列或group 列是為了避免數據節點之間數據流動, 提高性能。
數據傾斜
當我們選擇了一個分布鍵之后，如何判斷數據是否分布均勻呢？GaussDB(for openGauss)提供了SQL語句可以方便的查詢是否發生了數據傾斜。
通過如下方法，可以查詢數據存儲在那個DN，其中xc_node_id就是DN的內部標識，取值於系統表pgxc_node的xc_node_id列。
通過如下SQL，就可以查看表在各個DN上的數據分布情況，一般來說，DN的數據量相差10%以上，則可能發生了數據傾斜，就要考慮按照前面的原則調整分布列。
SELECT a.count,b.node_name FROM (SELECT count(*) AS count,xc_node_id FROM tablename GROUP BY xc_node_id) a, pgxc_node b WHERE a.xc_node_id=b.node_id ORDER BY a.count DESC;
3.2計算下推，“算得快”
GaussDB(for openGauss) 的優化器和全並行分布式執行能力，把計算下推到DN節點，減少數據移動，讓數據“算得快”。
數據讀寫流程
大致執行過程：
- 業務應用下發SQL給Coordinator ，SQL可以包含對數據的CRUD操作；
- Coordinator利用數據庫的優化器生成執行計划，每個DN會按照執行計划的要求去處理數據；
- 數據基於一致性Hash算法分布在每個DN，因此DN在處理數據的過程中，可能需要從其他DN獲取數據，GaussDB提供三種stream流（廣播流、聚合流和重分布流）實現數據在DN間的流動，使得join無需抽取到CN執行；
- DN將結果集返回給Coordinate進行匯總；
- Coordinator將匯總后的結果返回給業務應用。
華為在SQL執行優化方面有多年的沉淀，即使是復雜的SQL、事務分析混合（HTAP）的場景也能得到最佳的執行，我給大家舉一些列子：
- 基於代價的優化
- 基數估算：Feedback增強、AI基數增強
- 代價估算：行存/列存代價估算、網絡通信代價估算
- 搜索算法：動態規划方法、遺傳算法、AI搜索
- 分布式執行計划能力
- Light Proxy
- Fast Query Shipping
- Remote Query Shipping
- 自研Cascade優化器
- 對象化處理規則應用及搜索任務
- 基於分支限界的剪枝技術
計算下推
優化器是GaussDB(for openGauss)關鍵技術之一，可以把各種復雜的SQL進行下推執行，最小化數據移動，這是GaussDB相對於基於分庫分表的中間件方案的核心優勢（對於復雜查詢，由於計算無法下推，中間件很容易成為性能瓶頸，需要業務做比較大的改造來規避）。
以下案例的表結構為：
create table t1(a int, b int, c int) distribute by hash(a);
create table t2(a int, b int, c int) distribute by hash(a);
單表查詢下推
單表查詢，不管SQL的where條件是否帶有分片鍵，優化器都可以生成下推的執行計划，包括sort/group by等復雜算子，都可以下推。
1）分片鍵上的where條件，直接下推到DN
2）非分片鍵where條件，DN先計算，CN做匯總，sort/group by可以直接下推到DN
Join查詢下推
1）分片鍵上的join條件，直接下推到DN執行
2）非分片鍵join條件，DN直接做數據交換，避免CN成為性能瓶頸
1，Join下推到DN執行，DN之間直接進行數據重分布，交換數據，無需CN參與；CBO優化器選擇小表t2做重分布；
2，Sort下推到DN，CN只需做歸並排序，避免CN成為性能瓶頸；
3.3數據強一致，“算得准”
數據強一致是GaussDB(for openGauss)相對於基於分庫分表的中間件方案的另一個核心優勢，基於中間件的方案由於不感知事務的快照邏輯，只能做到最終一致性，部分場景需要業務做比較大的改造來規避陷阱。GaussDB(for openGauss)提供數據強一致能力，讓數據“算得准”。
- 分布式強一致：
1）兩階段提交保證寫的原子性。
2）兩階段提交對用戶透明，寫操作如果只涉及一個節點，無需使用兩階段提交。
3）全局CSN保證讀的強一致。
- 高性能事務管理：
GTM線程池、原子的CSN分配，中心節點無性能瓶頸。
4.總結
綜上所述，GaussDB(for openGauss)基於可橫向擴展的分布式架構，提供了海量存儲、快速響應、數據強一致的能力，可以很好滿足大規模海量數據的計算存儲需求，讓數據“存得下、算得快、算得准”。
值得一提的是，openGauss是開放的生態：架構開放、代碼開放、技術開放和社區開放，方便企業選擇開放的生態，讓自己的業務具備更好的連續性。畢竟如果讓企業從一個封閉的生態走向為另外一個封閉的生態，本質上並沒有解決業務連續性的問題，不開放的生態是沒有活力的，數據庫軟件尤甚，所以華為十分重視生態開放。
目前openGauss單分片版本的源代碼已經開源，社區地址為：https://opengauss.org，歡迎大家自行下載、安裝和體驗。
Ps：錯過直播的小伙伴不要灰心，點擊鏈接回播視頻看起來：https://bbs.huaweicloud.com/live/cloud_live/202104091600.html
本文分享自華為雲社區《華為雲GaussDB(for openGauss)專場直播第2期：讓數據“存得下、算得快、算得准”》，原文作者：心機胖 。