贵州卫视直播节目表

<随心_句子c><随心_句子c><随心_句子c><随心_句子c><随心_句子c>HDC.Cloud2021|5分(fen)鐘(zhong)教(jiao)妳(ni)學(xue)會(hui)GaussDB數(shu)據(ju)分布(bu)策(ce)略(lve)設(she)計(ji)

数据庫(ku)是(shi)應(ying)用(yong)和(he)计算(suan)機(ji)的(de)核(he)心(xin)組(zu)成(cheng)，試(shi)想(xiang)，如(ru)果(guo)沒(mei)有(you)数据库，就(jiu)像(xiang)人(ren)的大(da)腦(nao)没有了(le)記(ji)憶(yi)壹(yi)樣(yang)，信(xin)息(xi)也(ye)得(de)不(bu)到(dao)共(gong)享(xiang)，那(na)麽(me)，對(dui)開(kai)發(fa)者(zhe)來(lai)說(shuo)，如何(he)设计一款(kuan)高(gao)效(xiao)易(yi)用的数据库至(zhi)關(guan)重(zhong)要(yao)。

GaussDB(for openGauss)是企(qi)業(ye)級(ji)分布式(shi)数据库，具(ju)備(bei)分布式強(qiang)一致(zhi)、有效降(jiang)低(di)容(rong)災(zai)成本(ben)、支(zhi)持(chi)PB级海(hai)量(liang)数据、智(zhi)能(neng)診(zhen)斷(duan)等(deng)優(you)點(dian)，是當(dang)下(xia)炙(zhi)手(shou)可(ke)熱(re)的主(zhu)流(liu)数据库，那么如何更(geng)好(hao)的设计分布式数据库的数据分布策略呢(ne)？首(shou)先(xian)介(jie)紹(shao)一下GaussDB(for openGauss)的基(ji)本架(jia)構(gou)，便(bian)於(yu)理(li)解(jie)後(hou)面(mian)的分析(xi)。

邏(luo)輯(ji)架构

這(zhe)個(ge)是一个典(dian)型(xing)的基于数据分片(pian)的分布式架构(share nothing)，底(di)層(ceng)数据通(tong)過(guo)一定(ding)的規(gui)則(ze)比(bi)如hash、list或(huo)者range等讓(rang)数据打(da)散(san)分布到不同(tong)的数据節(jie)点上(shang)，计算時(shi)底层多(duo)个节点共同參(can)與(yu)计算。同时数据节点可以(yi)擴(kuo)展(zhan)，上层由(you)協(xie)調(tiao)节点進(jin)行(xing)SQL解析和轉(zhuan)发。

從(cong)圖(tu)中(zhong)可以看(kan)到，主要包(bao)括(kuo)三(san)類(lei)节点：协调节点、数据节点、集(ji)群(qun)类节点（最(zui)重要的是全(quan)局(ju)事(shi)務(wu)管(guan)理器(qi)）。协调节点負(fu)責(ze)SQL解析转发，充(chong)当的是类似(si)proxy的角(jiao)色(se)，数据节点负责计算和数据存(cun)儲(chu)，全局事务管理器负责全局事务讀(du)一致性(xing)的保(bao)證(zheng)。

关鍵(jian)角色

分布式SQL執(zhi)行过程(cheng)

大致执行过程：

业务应用下发SQL給(gei)Coordinator ，SQL可以包含(han)对数据的CRUD操(cao)作(zuo)； Coordinator利(li)用数据库的优化(hua)器生(sheng)成执行计劃(hua)，每(mei)个DN会按(an)照(zhao)执行计划的要求(qiu)去(qu)處(chu)理数据； 数据基于一致性Hash算法(fa)分布在(zai)每个DN，因(yin)此(ci)DN在处理数据的过程中，可能需(xu)要从其(qi)他(ta)DN獲(huo)取(qu)数据，GaussDB提(ti)供(gong)三種(zhong)stream流（廣(guang)播(bo)流、聚(ju)合(he)流和重分布流）實(shi)現(xian)数据在DN間(jian)的流動(dong)； DN將(jiang)結(jie)果集返(fan)回(hui)给Coordinate进行匯(hui)總(zong)； Coordinator将汇总后的结果返回给业务应用。

数据分布策略場(chang)景(jing)实踐(jian)

拿(na)電(dian)子(zi)商(shang)城(cheng)来舉(ju)例(li)，一个完(wan)整(zheng)的商城会包括很(hen)多信息，例如用戶(hu)、產(chan)品(pin)、訂(ding)單(dan)、倉(cang)库、物(wu)流、支付(fu)等等很多信息。以下用订单、支付方(fang)式、快(kuai)遞(di)公(gong)司(si)这3个信息為(wei)例，这3个信息也只(zhi)列(lie)出(chu)少(shao)量关键屬(shu)性来举例。

step1、数据库逻辑模(mo)型设计

step2、功(gong)能设计

常(chang)用场景一、查(zha)看子订单列表(biao)

常用场景二(er)、查看子订单詳(xiang)情(qing)

step3、物理数据模型设计

电子商城每天(tian)的订单量非(fei)常巨(ju)大，使(shi)用傳(chuan)統(tong)的主备库模式顯(xian)然(ran)無(wu)法滿(man)足(zu)如此大数据量的請(qing)求和存储需要。而(er)跨(kua)节点、可橫(heng)向(xiang)扩展的分布式数据库可以很好解決(jue)大规模海量数据的计算存储問(wen)題(ti)。GaussDB(for openGauss)分布式模式最大可以支持1000+节点，PB级存储，分布式事务强一致等特(te)性可以很好地(di)满足政(zheng)府(fu)、交(jiao)通、金(jin)融(rong)、能源(yuan)等行业的互(hu)聯(lian)網(wang)+的訴(su)求。

这个场景中，订单表和支付方式表代(dai)表著(zhe)兩(liang)类数据，前(qian)者同客(ke)户数、时间正(zheng)相(xiang)关，一个中型的商城每天的数据可能就達(da)到了百(bai)萬(wan)條(tiao)记錄(lu)，暫(zan)记为A类数据；后者数据變(bian)化較(jiao)小(xiao)，往(wang)往是配(pei)置(zhi)类的数据，暂记为B类数据。功能模塊(kuai)中存在A类数据之(zhi)间的相互关联以及(ji)A与B类数据的关联。那么在分布式数据库下，当数据分布在不同的节点上，以上能否(fou)直(zhi)接(jie)关联呢？如果能夠(gou)关联的話(hua)，怎(zen)么样设计才(cai)能更好的达到性能上的要求呢？

对于分布式数据库而言(yan)，如何使得以上的场景能够得到更好的性能，关键的是把(ba)表的数据分布策略選(xuan)擇(ze)好，而像分區(qu)、索(suo)引(yin)等设计同传统的单机差(cha)別(bie)不大。因此要回答(da)这个问题，我(wo)們(men)需要先了解GaussDB (for openGauss)的数据分布策略。

数据分布策略

GaussDB支持的数据分布策略

分布存储和並(bing)发查詢(xun)是MPP架构数据库的主要优勢(shi)所(suo)在。将一个大数据量表中的数据，按合適(shi)分布策略分散存储在多个DN实例內(nei)，可極(ji)大提升(sheng)数据库性能。

GaussDB V5支持如下表所示(shi)的数据分布策略：

下面这張(zhang)图可以幫(bang)我们清(qing)晰(xi)地理解復(fu)制(zhi)表和分布表，前者每个DN上都(dou)是一个完整的表，而后者每个DN上只是一个分片。

分布策略

語(yu)法：

看到这裏(li)，很多人馬(ma)上就会明(ming)白(bai)，订单表和子订单表适合用分布表，支付方式表和快递公司表适合用复制表，那么是为什(shen)么呢？ 让我们先了解下分布表及复制表的关联过程。

分布表及复制表关联过程

（1）分布表和复制表的关联查询

T1为hash表，T2为复制表。 T1表的每一部(bu)分在各(ge)DN上分别与T2表进行連(lian)接。 各DN上的连接结果集在CN上进行汇聚，产生最終(zhong)輸(shu)出的结果集。

（2）分布表与分布表关联查询

T1表和T3表都为分布表。 在DN1实例上，T1表的p1部分与T3表的T1部分进行关联。 T3表的p2、p3、p4复制到DN1上，与T1的p1部分进行关联。 DN2、DN3、DN4实例操作与DN1类似。 CN节点对各DN生成的结果集进行汇聚，生成最终数据结果集。

註(zhu)：細(xi)心的朋(peng)友(you)可能看到，不同的DN之间可能会进行数据同步(bu)，在这种情況(kuang)下，执行效率(lv)会就变差，如何避(bi)免(mian)这种情况，下面会講(jiang)到。

分布键的选择

盡(jin)量选择distinct值(zhi)比较多的列，保证数据均(jun)勻(yun)分布。分布均匀是为了避免木(mu)桶(tong)效应，各个主机对等执行。 尽量选择Join列或group 列做(zuo)分布列。尽量选择Join列或group 列是为了避免数据节点之间数据流动, 提高性能。

避免数据广播

在分布表关联分布时，分布列不同时，存在Streaming(type: BROADCAST）广播，不同DN节点之间数据存在交互，会增(zeng)加(jia)网絡(luo)开銷(xiao)，而分布列相同或关联复制表数据时，不存在DN节点间数据交互。下面我们进行下实際(ji)測(ce)试：

例如对于表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);

重新(xin)查看执行计划如下：

分析：方式1由于存在“Streaming”，導(dao)致Datanode之间存在较大通信数据量。

避免数据傾(qing)斜(xie)

判(pan)断是否已(yi)发生数据倾斜现象(xiang)

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内元(yuan)组数目(mu)相差较大（如相差数倍(bei)、数十(shi)倍），则表明已发生数据倾斜现象，请按照下面原(yuan)则调整分布列。

重新选择分布列，重新建(jian)表

当前不支持通过ALTER TABLE语句(ju)调整分布列，因此，调整分布列时需要重新建表。

选择原则如下： 分布列的列值应比较離(li)散，以便数据能够均分布到各个DN。

例如，考(kao)慮(lv)选择表的主键为分布列，如在人員(yuan)信息表中选择身(shen)份(fen)证號(hao)碼(ma)为分布列。 在满足上面原则的情况下，考虑选择查询中的连接条件(jian)为分布列，以便Join任(ren)务能够下推(tui)到DN中执行，且(qie)減(jian)少DN之间的通信数据量。

总结

GaussDB(for openGauss)是分布式架构，数据分布在各个DN上，设计好的数据分布策略是分布式数据库设计中最关键的環(huan)节。本文(wen)结合电子商城场景讲述(shu)了支持的数据分布策略、分布键的选择以及关联过程，還(hai)讲述了应該(gai)规避的问题。理解了以上这些(xie)内容后，相信你可以结合自(zi)己(ji)的业务场景，设计出最佳(jia)的数据分布策略。

作为華(hua)为ICT基礎(chu)设施(shi)业务面向全球(qiu)开发者的年(nian)度(du)盛(sheng)会，华为开发者大会2021（Cloud）将于2021年4月(yue)24日(ri)-26日在深(shen)圳(zhen)举行。本屆(jie)大会以#每一个开发者都了不起(qi)#为主题，将汇聚业界(jie)大咖(ka)、华为科(ke)学家(jia)、頂(ding)级技(ji)術(shu)專(zhuan)家、天才少年和眾(zhong)多开发者，共同探(tan)討(tao)和分享雲(yun)、计算、人工(gong)智能等最新ICT技术在行业的深度創(chuang)新和应用。智能时代，每一个开发者都在创造(zao)一往无前的奔(ben)騰(teng)时代。世(shi)界有你，了不起！返回搜(sou)狐(hu)，查看更多

责任編(bian)辑：