关于数据库:如何设计好分布式数据库这个策略很重要

51次阅读

共计 3824 个字符,预计需要花费 10 分钟才能阅读完成。

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

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

GaussDB(for openGauss)是企业级分布式数据库,具备分布式强统一、无效升高容灾老本、反对 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 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 反对如下表所示的数据分布策略:

上面这张图能够帮忙咱们清晰地了解复制表和散布表,前者每个 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);
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…

点击关注,第一工夫理解华为云陈腐技术~

正文完
 0