如何設(shè)計好分布式數(shù)據(jù)庫，這個策略很重要

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

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

圖 邏輯架構(gòu)

這個是一個典型的基于數(shù)據(jù)分片的分布式架構(gòu)(share nothing)，底層數(shù)據(jù)通過一定的規(guī)則比如hash、list或者range等讓數(shù)據(jù)打散分布到不同的數(shù)據(jù)節(jié)點上，計算時底層多個節(jié)點共同參與計算。同時數(shù)據(jù)節(jié)點可以擴展，上層由協(xié)調(diào)節(jié)點進行SQL解析和轉(zhuǎn)發(fā)。

從圖中可以看到，主要包括三類節(jié)點：協(xié)調(diào)節(jié)點、數(shù)據(jù)節(jié)點、集群類節(jié)點（最重要的是全局事務(wù)管理器）。協(xié)調(diào)節(jié)點負(fù)責(zé)SQL解析轉(zhuǎn)發(fā)，充當(dāng)?shù)氖穷愃苝roxy的角色，數(shù)據(jù)節(jié)點負(fù)責(zé)計算和數(shù)據(jù)存儲，全局事務(wù)管理器負(fù)責(zé)全局事務(wù)讀一致性的保證。

表 關(guān)鍵角色

分布式SQL執(zhí)行過程

大致執(zhí)行過程：

業(yè)務(wù)應(yīng)用下發(fā)SQL給Coordinator ，SQL可以包含對數(shù)據(jù)的CRUD操作；

Coordinator利用數(shù)據(jù)庫的優(yōu)化器生成執(zhí)行計劃，每個DN會按照執(zhí)行計劃的要求去處理數(shù)據(jù)；

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

DN將結(jié)果集返回給Coordinate進行匯總；

Coordinator將匯總后的結(jié)果返回給業(yè)務(wù)應(yīng)用。

數(shù)據(jù)分布策略場景實踐

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

step1、數(shù)據(jù)庫邏輯模型設(shè)計

step2、功能設(shè)計

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

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、物理數(shù)據(jù)模型設(shè)計

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

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

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

數(shù)據(jù)分布策略

GaussDB支持的數(shù)據(jù)分布策略

分布存儲和并發(fā)查詢是MPP架構(gòu)數(shù)據(jù)庫的主要優(yōu)勢所在。將一個大數(shù)據(jù)量表中的數(shù)據(jù)，按合適分布策略分散存儲在多個DN實例內(nèi)，可極大提升數(shù)據(jù)庫性能。

GaussDB V5支持如下表所示的數(shù)據(jù)分布策略：

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

圖 分布策略

語法：

創(chuàng)建復(fù)制表 create table region1(ctid_value int) distribute by replication; 創(chuàng)建分布表 create table region2(ctid_value int) distribute by hash(ctid_value); 說明：當(dāng)不指定分布方式，創(chuàng)建表默認(rèn)為（第一個可以作為分布列的列為分布鍵）分布表

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

分布表及復(fù)制表關(guān)聯(lián)過程

（1）分布表和復(fù)制表的關(guān)聯(lián)查詢

T1為hash表，T2為復(fù)制表。

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

各DN上的連接結(jié)果集在CN上進行匯聚，產(chǎn)生最終輸出的結(jié)果集。

（2）分布表與分布表關(guān)聯(lián)查詢

T1表和T3表都為分布表。

在DN1實例上，T1表的p1部分與T3表的T1部分進行關(guān)聯(lián)。

T3表的p2、p3、p4復(fù)制到DN1上，與T1的p1部分進行關(guān)聯(lián)。

DN2、DN3、DN4實例操作與DN1類似。

CN節(jié)點對各DN生成的結(jié)果集進行匯聚，生成最終數(shù)據(jù)結(jié)果集。

注：細(xì)心的朋友可能看到，不同的DN之間可能會進行數(shù)據(jù)同步，在這種情況下，執(zhí)行效率會就變差，如何避免這種情況，下面會講到。

分布鍵的選擇

盡量選擇distinct值比較多的列，保證數(shù)據(jù)均勻分布。分布均勻是為了避免木桶效應(yīng)，各個主機對等執(zhí)行。

盡量選擇Join列或group 列做分布列。盡量選擇Join列或group 列是為了避免數(shù)據(jù)節(jié)點之間數(shù)據(jù)流動, 提高性能。

避免數(shù)據(jù)廣播

在分布表關(guān)聯(lián)分布時，分布列不同時，存在Streaming(type: BROADCAST）廣播，不同DN節(jié)點之間數(shù)據(jù)存在交互，會增加網(wǎng)絡(luò)開銷，而分布列相同或關(guān)聯(lián)復(fù)制表數(shù)據(jù)時，不存在DN節(jié)點間數(shù)據(jù)交互。下面我們進行下實際測試：

例如對于表t1，t2，我們使用不同的分片列進行關(guān)聯(lián)：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);

其執(zhí)行計劃如下：

方式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);

重新查看執(zhí)行計劃如下：

分析：方式1由于存在“Streaming”，導(dǎo)致Datanode之間存在較大通信數(shù)據(jù)量。

避免數(shù)據(jù)傾斜

判斷是否已發(fā)生數(shù)據(jù)傾斜現(xiàn)象

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內(nèi)元組數(shù)目相差較大（如相差數(shù)倍、數(shù)十倍），則表明已發(fā)生數(shù)據(jù)傾斜現(xiàn)象，請按照下面原則調(diào)整分布列。

重新選擇分布列，重新建表

當(dāng)前不支持通過ALTER TABLE語句調(diào)整分布列，因此，調(diào)整分布列時需要重新建表。

選擇原則如下： 分布列的列值應(yīng)比較離散，以便數(shù)據(jù)能夠均分布到各個DN。

例如，考慮選擇表的主鍵為分布列，如在人員信息表中選擇身份證號碼為分布列。 在滿足上面原則的情況下，考慮選擇查詢中的連接條件為分布列，以便Join任務(wù)能夠下推到DN中執(zhí)行，且減少DN之間的通信數(shù)據(jù)量。

總結(jié)

GaussDB(for openGauss)是分布式架構(gòu)，數(shù)據(jù)分布在各個DN上，設(shè)計好的數(shù)據(jù)分布策略是分布式數(shù)據(jù)庫設(shè)計中最關(guān)鍵的環(huán)節(jié)。本文結(jié)合電子商城場景講述了支持的數(shù)據(jù)分布策略、分布鍵的選擇以及關(guān)聯(lián)過程，還講述了應(yīng)該規(guī)避的問題。理解了以上這些內(nèi)容后，相信你可以結(jié)合自己的業(yè)務(wù)場景，設(shè)計出最佳的數(shù)據(jù)分布策略。

作為華為ICT基礎(chǔ)設(shè)施業(yè)務(wù)面向全球開發(fā)者的年度盛會，華為開發(fā)者大會2021（Cloud）將于2021年4月24日-26日在深圳舉行。本屆大會以#每一個開發(fā)者都了不起#為主題，將匯聚業(yè)界大咖、華為科學(xué)家、頂級技術(shù)專家、天才少年和眾多開發(fā)者，共同探討和分享云、計算、人工智能等最新ICT技術(shù)在行業(yè)的深度創(chuàng)新和應(yīng)用。智能時代，每一個開發(fā)者都在創(chuàng)造一往無前的奔騰時代。世界有你，了不起！

點擊鏈接，了解大會詳細(xì)信息：

https://developer.huaweicloud.com/HDC.Cloud2021.html

分布式 分布式數(shù)據(jù)庫中間件 DDM 數(shù)據(jù)庫

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。