HDC.Cloud2021|如何設計好分布式數據庫，這個策略很重要

數據庫是應用和計算機的核心組成，試想，如果沒有數據庫，就像人的大腦沒有了記憶一樣，信息也得不到共享，那么，對開發者來說，如何設計一款高效易用的數據庫至關重要。

GaussDB(for openGauss)是企業級分布式數據庫，具備分布式強一致、有效降低容災成本、支持PB級海量數據、智能診斷等優點，是當下炙手可熱的主流數據庫，那么如何更好的設計分布式數據庫的數據分布策略呢？首先介紹一下GaussDB(for openGauss)的基本架構，便于理解后面的分析。

圖?邏輯架構

這個是一個典型的基于數據分片的分布式架構(share nothing)，底層數據通過一定的規則比如hash、list或者range等讓數據打散分布到不同的數據節點上，計算時底層多個節點共同參與計算。同時數據節點可以擴展，上層由協調節點進行SQL解析和轉發。

從圖中可以看到，主要包括三類節點：協調節點、數據節點、集群類節點（最重要的是全局事務管理器）。協調節點負責SQL解析轉發，充當的是類似proxy的角色，數據節點負責計算和數據存儲，全局事務管理器負責全局事務讀一致性的保證。

名稱

描述

OM

運維管理模塊（Operation Manager）。提供集群日常運維、配置管理的管理接口、工具。

CM

集群管理模塊（Cluster Manager）。管理和監控分布式系統中各個功能單元和物理資源的運行情況，確保整個系統的穩定運行。

GTM

全局事務管理器（Global Transaction Manager），負責生成和維護全局事務ID、事務快照、時間戳等全局唯一的信息。

CN

協調節點（Coordinator Node）。負責接收來自應用的訪問請求，并向客戶端返回執行結果；負責分解任務，并調度任務分片在各DN上并行執行。

DN

數據節點（Data Node）。負責存儲業務數據、執行數據查詢任務以及向CN返回執行結果。

ETCD

分布式鍵值存儲系統（Editable Text Configuration Daemon）。用于共享配置和服務發現（服務注冊和查找）。

Storage

服務器的存儲資源，持久化存儲數據。

表?關鍵角色

分布式SQL執行過程

大致執行過程：

業務應用下發SQL給Coordinator ，SQL可以包含對數據的CRUD操作；

Coordinator利用數據庫的優化器生成執行計劃，每個DN會按照執行計劃的要求去處理數據；

數據基于一致性Hash算法分布在每個DN，因此DN在處理數據的過程中，可能需要從其他DN獲取數據，GaussDB提供三種stream流（廣播流、聚合流和重分布流）實現數據在DN間的流動；

DN將結果集返回給Coordinate進行匯總；

Coordinator將匯總后的結果返回給業務應用。

數據分布策略場景實踐

拿電子商城來舉例，一個完整的商城會包括很多信息，例如用戶、產品、訂單、倉庫、物流、支付等等很多信息。以下用訂單、支付方式、快遞公司這3個信息為例，這3個信息也只列出少量關鍵屬性來舉例。

step1、數據庫邏輯模型設計

step2、功能設計

常用場景一、查看子訂單列表

Select sn, status, money, product_id, product_mount from order t1, suborder t2 where t1.id = t2.order_id and t1.sn=’xxx’;

常用場景二、查看子訂單詳情

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;

step3、物理數據模型設計

子商城每天的訂單量非常巨大，使用傳統的主備庫模式顯然無法滿足如此大數據量的請求和存儲需要。而跨節點、可橫向擴展的分布式數據庫可以很好解決大規模海量數據的計算存儲問題。GaussDB(for openGauss)分布式模式最大可以支持1000+節點，PB級存儲，分布式事務強一致等特性可以很好地滿足政府、交通、金融、能源等行業的互聯網+的訴求。

這個場景中，訂單表和支付方式表代表著兩類數據，前者同客戶數、時間正相關，一個中型的商城每天的數據可能就達到了百萬條記錄，暫記為A類數據；后者數據變化較小，往往是配置類的數據，暫記為B類數據。功能模塊中存在A類數據之間的相互關聯以及A與B類數據的關聯。那么在分布式數據庫下，當數據分布在不同的節點上，以上能否直接關聯呢？如果能夠關聯的話，怎么樣設計才能更好的達到性能上的要求呢？

對于分布式數據庫而言，如何使得以上的場景能夠得到更好的性能，關鍵的是把表的數據分布策略選擇好，而像分區、索引等設計同傳統的單機差別不大。因此? ? ? ? 要回答這個問題，我們需要先了解GaussDB (for openGauss)的數據分布策略。

數據分布策略

GaussDB支持的數據分布策略

分布存儲和并發查詢是MPP架構數據庫的主要優勢所在。將一個大數據量表中的數據，按合適分布策略分散存儲在多個DN實例內，可極大提升數據庫性能。GaussDB V5支持如下表所示的數據分布策略：

策略

描述

適用場景

散列（Hash）

將表中的數據通過hash方式散列到集群中的所有DN實例上。

數據量較大的表。

復制（Replication）

將表中的數據復制到所有DN實例上，每個DN實例都擁有全量數據。

數據量較小的表（10W行記錄以下），根據集群數量酌情處理。

下面這張圖可以幫忙我們清晰地理解復制表和分布表，前者每個DN上都是一個完整的表，而后者每個DN上只是一個分片。

語法：

創建復制表

create table region1(ctid_value int)?distribute by replication;

創建分布表

create table region2(ctid_value int)?distribute by hash(ctid_value);

說明：當不指定分布方式，創建表默認為（第一個可以作為分布列的列為分布鍵）分布表

看到這里這里，很多人馬上就會明白，訂單表和子訂單表適合用分布表，支付方式表和快遞公司表適合用復制表，那么是為什么呢？?讓我們先了解下分布表及復制表的關聯過程。

表

分布方式

分布列

訂單

Hash

id

子訂單

Hash

order_id

快遞公司

Replication

－

支付方式

Replication

－

分布表及復制表關聯過程

T1為hash表，T2為復制表。

T1表的每一部分在各DN上分別與T2表進行連接。

各DN上的連接結果集在CN上進行匯聚，產生最終輸出的結果集。

T1表和T3表都為分布表。

在DN1實例上，T1表的p1部分與T3表的T1部分進行關聯。

T3表的p2、p3、p4復制到DN1上，與T1的p1部分進行關聯。

DN2、DN3、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：t1、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

HDC2021 云數據庫 GaussDB(for openGauss) 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。