摘要：GaussDB(for openGauss)是分佈式架構，數據分佈在各個DN上，設計好的數據分佈策略是分佈式數據庫設計中最關鍵的環節。
數據庫是應用和計算機的核心組成，試想，若是沒有數據庫，就像人的大腦沒有了記憶同樣，信息也得不到共享，那麼，對開發者來講，如何設計一款高效易用的數據庫相當重要。html
GaussDB(for openGauss)是企業級分佈式數據庫，具有分佈式強一致、有效下降容災成本、支持PB級海量數據、智能診斷等優勢，是當下煊赫一時的主流數據庫，那麼如何更好的設計分佈式數據庫的數據分佈策略呢？首先介紹一下GaussDB(for openGauss)的基本架構，便於理解後面的分析。node
圖 邏輯架構算法
這個是一個典型的基於數據分片的分佈式架構(share nothing)，底層數據經過必定的規則好比hash、list或者range等讓數據打散分佈到不一樣的數據節點上，計算時底層多個節點共同參與計算。同時數據節點能夠擴展，上層由協調節點進行SQL解析和轉發。數據庫
從圖中能夠看到，主要包括三類節點：協調節點、數據節點、集羣類節點（最重要的是全局事務管理器）。協調節點負責SQL解析轉發，充當的是相似proxy的角色，數據節點負責計算和數據存儲，全局事務管理器負責全局事務讀一致性的保證。網絡
表 關鍵角色架構
分佈式SQL執行過程
大體執行過程：併發
- 業務應用下發SQL給Coordinator ，SQL能夠包含對數據的CRUD操做；
- Coordinator利用數據庫的優化器生成執行計劃，每一個DN會按照執行計劃的要求去處理數據；
- 數據基於一致性Hash算法分佈在每一個DN，所以DN在處理數據的過程當中，可能須要從其餘DN獲取數據，GaussDB提供三種stream流（廣播流、聚合流和重分佈流）實現數據在DN間的流動；
- DN將結果集返回給Coordinate進行彙總；
- Coordinator將彙總後的結果返回給業務應用。
數據分佈策略場景實踐
拿電子商城來舉例，一個完整的商城會包括不少信息，例如用戶、產品、訂單、倉庫、物流、支付等等不少信息。如下用訂單、支付方式、快遞公司這3個信息爲例，這3個信息也只列出少許關鍵屬性來舉例。數據庫設計
step一、數據庫邏輯模型設計
step二、功能設計
經常使用場景1、查看子訂單列表分佈式
Select sn, status, money, product_id, product_mount from order t1, suborder t2 where t1.id = t2.order_id and t1.sn=’xxx’;
經常使用場景2、查看子訂單詳情性能
Select product_id, product_mount, t2.name as shipping_name, t3.name as pay_type_name from suborder t1, shipping_com t2, pay_type t3 where t1.id=’xx’ and t1.shipping_id=t2.id and t1.pay_type_id=t3.id;
step三、物理數據模型設計
電子商城天天的訂單量很是巨大，使用傳統的主備庫模式顯然沒法知足如此大數據量的請求和存儲須要。而跨節點、可橫向擴展的分佈式數據庫能夠很好解決大規模海量數據的計算存儲問題。GaussDB(for openGauss)分佈式模式最大能夠支持1000+節點，PB級存儲，分佈式事務強一致等特性能夠很好地知足政府、交通、金融、能源等行業的互聯網+的訴求。
這個場景中，訂單表和支付方式表表明着兩類數據，前者同客戶數、時間正相關，一箇中型的商城天天的數據可能就達到了百萬條記錄，暫記爲A類數據；後者數據變化較小，每每是配置類的數據，暫記爲B類數據。功能模塊中存在A類數據之間的相互關聯以及A與B類數據的關聯。那麼在分佈式數據庫下，當數據分佈在不一樣的節點上，以上可否直接關聯呢？若是可以關聯的話，怎麼樣設計才能更好的達到性能上的要求呢？
對於分佈式數據庫而言，如何使得以上的場景可以獲得更好的性能，關鍵的是把表的數據分佈策略選擇好，而像分區、索引等設計同傳統的單機差異不大。所以要回答這個問題，咱們須要先了解GaussDB (for openGauss)的數據分佈策略。
數據分佈策略
GaussDB支持的數據分佈策略
分佈存儲和併發查詢是MPP架構數據庫的主要優點所在。將一個大數據量表中的數據，按合適分佈策略分散存儲在多個DN實例內，可極大提高數據庫性能。
GaussDB V5支持以下表所示的數據分佈策略：
下面這張圖能夠幫忙咱們清晰地理解複製表和分佈表，前者每一個DN上都是一個完整的表，然後者每一個DN上只是一個分片。
圖 分佈策略
語法：
建立複製表 create table region1(ctid_value int) distribute by replication; 建立分佈表 create table region2(ctid_value int) distribute by hash(ctid_value); 說明：當不指定分佈方式，建立表默認爲（第一個能夠做爲分佈列的列爲分佈鍵）分佈表
看到這裏這裏，不少人立刻就會明白，訂單表和子訂單表適合用分佈表，支付方式表和快遞公司表適合用複製表，那麼是爲何呢？ 讓咱們先了解下分佈表及複製表的關聯過程。
分佈表及複製表關聯過程
（1）分佈表和複製表的關聯查詢
- T1爲hash表，T2爲複製表。
- T1表的每一部分在各DN上分別與T2表進行鏈接。
- 各DN上的鏈接結果集在CN上進行匯聚，產生最終輸出的結果集。
（2）分佈表與分佈表關聯查詢
- T1表和T3表都爲分佈表。
- 在DN1實例上，T1表的p1部分與T3表的T1部分進行關聯。
- T3表的p二、p三、p4複製到DN1上，與T1的p1部分進行關聯。
- DN二、DN三、DN4實例操做與DN1相似。
- CN節點對各DN生成的結果集進行匯聚，生成最終數據結果集。
注：細心的朋友可能看到，不一樣的DN之間可能會進行數據同步，在這種狀況下，執行效率會就變差，如何避免這種狀況，下面會講到。
分佈鍵的選擇
- 儘可能選擇distinct值比較多的列，保證數據均勻分佈。分佈均勻是爲了不木桶效應，各個主機對等執行。
- 儘可能選擇Join列或group 列作分佈列。儘可能選擇Join列或group 列是爲了不數據節點之間數據流動, 提升性能。
避免數據廣播
在分佈表關聯分佈時，分佈列不一樣時，存在Streaming(type: BROADCAST）廣播，不一樣DN節點之間數據存在交互，會增長網絡開銷，而分佈列相同或關聯複製表數據時，不存在DN節點間數據交互。下面咱們進行下實際測試：
例如對於表t1，t2，咱們使用不一樣的分片列進行關聯：select * from t1, t2 where t1.a = t2.b;
方式1：t一、t2都選擇a作分佈列
create table t1 (a int, b int) distribute by hash (a); create table t2 (a int, b int) distribute by hash (a);
其執行計劃以下：
方式2：將a做爲t1的分佈列，將b做爲t2的分佈列：
create table t1 (a int, b int) distribute by hash (a); create table t2 (a int, b int) distribute by hash (b);
從新查看執行計劃以下：
分析：方式1因爲存在「Streaming」，致使Datanode之間存在較大通訊數據量。
避免數據傾斜
- 判斷是否已發生數據傾斜現象
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;
若是各DN內元組數目相差較大（如相差數倍、數十倍），則代表已發生數據傾斜現象，請按照下面原則調整分佈列。
- 從新選擇分佈列，從新建表
當前不支持經過ALTER TABLE語句調整分佈列，所以，調整分佈列時須要從新建表。
選擇原則以下： 分佈列的列值應比較離散，以便數據可以均分佈到各個DN。
例如，考慮選擇表的主鍵爲分佈列，如在人員信息表中選擇身份證號碼爲分佈列。 在知足上面原則的狀況下，考慮選擇查詢中的鏈接條件爲分佈列，以便Join任務可以下推到DN中執行，且減小DN之間的通訊數據量。
總結
GaussDB(for openGauss)是分佈式架構，數據分佈在各個DN上，設計好的數據分佈策略是分佈式數據庫設計中最關鍵的環節。本文結合電子商城場景講述了支持的數據分佈策略、分佈鍵的選擇以及關聯過程，還講述了應該規避的問題。理解了以上這些內容後，相信你能夠結合本身的業務場景，設計出最佳的數據分佈策略。
做爲華爲ICT基礎設施業務面向全球開發者的年度盛會，華爲開發者大會2021（Cloud）將於2021年4月24日-26日在深圳舉行。本屆大會以#每個開發者都了不得#爲主題，將匯聚業界大咖、華爲科學家、頂級技術專家、天才少年和衆多開發者，共同探討和分享雲、計算、人工智能等最新ICT技術在行業的深度創新和應用。智能時代，每個開發者都在創造勇往直前的奔騰時代。世界有你，了不得！
點擊連接，瞭解大會詳細信息：https://developer.huaweicloud.com/HDC.Cloud2021.html