写点什么

5 分钟教你学会 GaussDB 数据分布策略设计

发布于: 2021 年 04 月 16 日

​​摘要:GaussDB(foropenGauss)是分布式架构,数据分布在各个 DN 上,设计好的数据分布策略是分布式数据库设计中最关键的环节。


数据库是应用和计算机的核心组成,试想,如果没有数据库,就像人的大脑没有了记忆一样,信息也得不到共享,那么,对开发者来说,如何设计一款高效易用的数据库至关重要。


GaussDB(foropenGauss)是企业级分布式数据库,具备分布式强一致、有效降低容灾成本、支持 PB 级海量数据、智能诊断等优点,是当下炙手可热的主流数据库,那么如何更好的设计分布式数据库的数据分布策略呢?首先介绍一下 GaussDB(for openGauss)的基本架构,便于理解后面的分析。



图 逻辑架构

这个是一个典型的基于数据分片的分布式架构(share nothing),底层数据通过一定的规则比如 hash、list 或者 range 等让数据打散分布到不同的数据节点上,计算时底层多个节点共同参与计算。同时数据节点可以扩展,上层由协调节点进行 SQL 解析和转发。


从图中可以看到,主要包括三类节点:协调节点、数据节点、集群类节点(最重要的是全局事务管理器)。协调节点负责 SQL 解析转发,充当的是类似 proxy 的角色,数据节点负责计算和数据存储,全局事务管理器负责全局事务读一致性的保证。



表 关键角色

分布式 SQL 执行过程



​大致执行过程:


  1. 业务应用下发 SQL 给 Coordinator ,SQL 可以包含对数据的 CRUD 操作;

  2. Coordinator 利用数据库的优化器生成执行计划,每个 DN 会按照执行计划的要求去处理数据;

  3. 数据基于一致性 Hash 算法分布在每个 DN,因此 DN 在处理数据的过程中,可能需要从其他 DN 获取数据,GaussDB 提供三种 stream 流(广播流、聚合流和重分布流)实现数据在 DN 间的流动;

  4. DN 将结果集返回给 Coordinate 进行汇总;

  5. Coordinator 将汇总后的结果返回给业务应用。

数据分布策略场景实践


拿电子商城来举例,一个完整的商城会包括很多信息,例如用户、产品、订单、仓库、物流、支付等等很多信息。以下用订单、支付方式、快递公司这 3 个信息为例,这 3 个信息也只列出少量关键属性来举例。


step1、数据库逻辑模型设计



step2、功能设计


常用场景一、查看子订单列表


Select sn, status, money, product_id, product_mount fromorder t1, suborder t2 where t1.id = t2.order_id and t1.sn=’xxx’;
复制代码


常用场景二、查看子订单详情


Select product_id, product_mount, t2.name asshipping_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 支持如下表所示的数据分布策略:



​下面这张图可以帮忙我们清晰地理解复制表和分布表,前者每个 DN 上都是一个完整的表,而后者每个 DN 上只是一个分片。



图 分布策略


语法:


创建复制表


create table region1(ctid_value int) distribute by replication;
复制代码


创建分布表


create table region2(ctid_value int) distribute by hash(ctid_value);
复制代码


说明:当不指定分布方式,创建表默认为(第一个可以作为分布列的列为分布键)分布表

看到这里这里,很多人马上就会明白,订单表和子订单表适合用分布表,支付方式表和快递公司表适合用复制表,那么是为什么呢?让我们先了解下分布表及复制表的关联过程。



分布表及复制表关联过程


(1)分布表和复制表的关联查询



1. T1 为 hash 表,T2 为复制表。

2. T1 表的每一部分在各 DN 上分别与 T2 表进行连接。

3. 各 DN 上的连接结果集在 CN 上进行汇聚,产生最终输出的结果集。


(2)分布表与分布表关联查询



  1. T1 表和 T3 表都为分布表。

  2. 在 DN1 实例上,T1 表的 p1 部分与 T3 表的 T1 部分进行关联。

  3. T3 表的 p2、p3、p4 复制到 DN1 上,与 T1 的 p1 部分进行关联。

  4. DN2、DN3、DN4 实例操作与 DN1 类似。

  5. 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);​createtable 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);createtable 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 内元组数目相差较大(如相差数倍、数十倍),则表明已发生数据倾斜现象,请按照下面原则调整分布列。


重新选择分布列,重新建表


当前不支持通过 ALTERTABLE 语句调整分布列,因此,调整分布列时需要重新建表。


选择原则如下: 分布列的列值应比较离散,以便数据能够均分布到各个 DN。


例如,考虑选择表的主键为分布列,如在人员信息表中选择身份证号码为分布列。在满足上面原则的情况下,考虑选择查询中的连接条件为分布列,以便 Join 任务能够下推到 DN 中执行,且减少 DN 之间的通信数据量。

总结


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



​作为华为 ICT 基础设施业务面向全球开发者的年度盛会,华为开发者大会2021(Cloud)将于 2021 年 4 月 24 日-26 日在深圳举行。本届大会以 #每一个开发者都了不起 #为主题,将汇聚业界大咖、华为科学家、顶级技术专家、天才少年和众多开发者,共同探讨和分享云、计算、人工智能等最新 ICT 技术在行业的深度创新和应用。智能时代,每一个开发者都在创造一往无前的奔腾时代。世界有你,了不起!


点击链接,了解大会详细信息。

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


点击关注,第一时间了解华为云新鲜技术~

发布于: 2021 年 04 月 16 日阅读数: 123
用户头像

提供全面深入的云计算技术干货 2020.07.14 加入

华为云开发者社区,提供全面深入的云计算前景分析、丰富的技术干货、程序样例,分享华为云前沿资讯动态,方便开发者快速成长与发展,欢迎提问、互动,多方位了解云计算! 传送门:https://bbs.huaweicloud.com/

评论

发布
暂无评论
5分钟教你学会GaussDB数据分布策略设计