关于分布式:GaussDBfor-openGauss让数据存得下算得快算得准

8次阅读

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

摘要: 本文从总体架构、数据分布形式、计算下推、数据强统一等方面进行介绍 GaussDB(for openGauss)。

本文分享自华为云社区《华为云 GaussDB(for openGauss) 专场直播第 2 期:让数据“存得下、算得快、算得准”》,原文作者:神思胖。

1. 前言

随着云计算规模越来越大,企业业务数据量呈指数级增长,传统数据库在海量数据存储与治理方面显得力不从心,面临“存不下,算得慢、算不准”的问题。

面对挑战,华为云数据库深度交融华为在数据库畛域多年的教训,充沛联合了企业级场景需要,基于 openGauss 自研生态推出了企业级分布式关系型数据库 GaussDB(for openGauss)。GaussDB(for openGauss) 目前反对单分片和分布式两种部署状态,在撑持传统业务的根底上,继续构建竞争力个性,为企业面向数字化转型提供了有限可能。

4 月 9 日,由华为云主办的 GaussDB(for openGauss) 系列技术直播第 2 期《华为云数据库 GaussDB(for openGauss) 数据存储与拜访》于线上开启,直播具体介绍了 GaussDB(for openGauss) 的数据分布形式和数据读写流程,为不便大家疾速理解 GaussDB(for openGauss),本文联合第 2 场直播内容从总体架构、数据分布形式、计算下推、数据强统一等方面进行介绍。

2. 分布式架构

GaussDB(for openGauss) 是一个典型的基于数据分片的双层分布式架构 (share nothing),数据通过肯定的规定比方 hash、list 或者 range 等让数据打散散布到不同的数据节点上,计算时底层多个数据节点独特参加,下层协调节点负责执行打算生成和后果汇聚。

3. 让数据“存得下、算得快、算得准”

随着 5G 时代的到来,繁多节点是难以应答数据规模的一直增长并确保性能的须要,业务面临“存不下、算得慢、算不准”的问题。而 GaussDB(for openGauss) 可横向扩大的分布式架构能够很好满足大规模海量数据的计算存储需要,让数据“存得下、算得快、算得准”。

3.1 海量数据“存得下”

GaussDB(for openGauss) 反对 1000+ 的数据节点扩大能力,数据通过肯定的规定比方 hash、list 或者 range 等让数据打散散布到不同的数据节点上,让数据“存得下”。

数据分布形式

GaussDB(for openGauss) 反对 hash、list、range、replication 散布形式,下图以 hash 和 replication 为例,示意了数据在 DN 节点上的散布状况。create table 通过 distribute by 语法指定表的数据分布形式。hash 散布把数据散列存储到所有 DN,适宜数据量比拟大的表;replication 散布把数据复制存储到所有 DN,数据更新时,会同时更新所有 DN,采纳 2PC(两阶段提交) 保障分布式事务的一致性,适宜更新频率比拟低的小表。

一致性 hash

GaussDB 的 hash 散布采纳相似一致性 hash 的形式,数据通过两层映射,第一层通过 hash 映射把数据映射到 N 个 hash bucket 中,或者叫 vnode 中;第二层映射把 vnode 映射到物理的 datanode 上。扩容时,只须要调整二层映射,保证数据搬迁最小:数据只会搬迁到新节点,已有节点之间不会相互搬迁数据;

散布键的抉择

对于数据分布来讲,散布键的抉择至关重要,不适合的散布键会导致数据歪斜,导致木桶效应。散布键的抉择个别遵循如下准则:

a. 尽量抉择 distinct 值比拟多的列,保证数据均匀分布。散布平均是为了防止木桶效应,各个节点对等执行。

b. 尽量抉择 Join 列或 group 列做散布列。尽量抉择 Join 列或 group 列是为了防止数据节点之间数据流动, 进步性能。

数据歪斜

当咱们抉择了一个散布键之后,如何判断数据是否散布平均呢?GaussDB(for openGauss) 提供了 SQL 语句能够不便的查问是否产生了数据歪斜。

通过如下办法,能够查问数据存储在那个 DN,其中 xc_node_id 就是 DN 的外部标识,取值于零碎表 pgxc_node 的 xc_node_id 列。

通过如下 SQL,就能够查看表在各个 DN 上的数据分布状况,一般来说,DN 的数据量相差 10% 以上,则可能产生了数据歪斜,就要思考依照后面的准则调整散布列。

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; 

3.2 计算下推,“算得快”

GaussDB(for openGauss) 的优化器和全并行分布式执行能力,把计算下推到 DN 节点,缩小数据挪动,让数据“算得快”。

数据读写流程

大抵执行过程:

  1. 业务利用下发 SQL 给 Coordinator,SQL 能够蕴含对数据的 CRUD 操作;
  2. Coordinator 利用数据库的优化器生成执行打算,每个 DN 会依照执行打算的要求去解决数据;
  3. 数据基于一致性 Hash 算法散布在每个 DN,因而 DN 在解决数据的过程中,可能须要从其余 DN 获取数据,GaussDB 提供三种 stream 流(播送流、聚合流和重散布流)实现数据在 DN 间的流动,使得 join 无需抽取到 CN 执行;
  4. DN 将后果集返回给 Coordinate 进行汇总;
  5. Coordinator 将汇总后的后果返回给业务利用。

华为在 SQL 执行优化方面有多年的积淀,即便是简单的 SQL、事务剖析混合(HTAP)的场景也能失去最佳的执行,我给大家举一些列子:

  • 基于代价的优化
  • 基数估算:Feedback 加强、AI 基数加强
  • 代价估算:行存 / 列存代价估算、网络通信代价估算
  • 搜索算法:动静布局办法、遗传算法、AI 搜寻
  • 分布式执行打算能力
  • Light Proxy
  • Fast Query Shipping
  • Remote Query Shipping
  • 自研 Cascade 优化器
  • 对象化解决规定利用及搜寻工作
  • 基于分支限界的剪枝技术

计算下推

优化器是 GaussDB(for openGauss) 关键技术之一,能够把各种简单的 SQL 进行下推执行,最小化数据挪动,这是 GaussDB 绝对于基于分库分表的中间件计划的外围劣势(对于简单查问,因为计算无奈下推,中间件很容易成为性能瓶颈,须要业务做比拟大的革新来躲避)。

以下案例的表构造为:

create table t1(a int, b int, c int) distribute by hash(a);

create table t2(a int, b int, c int) distribute by hash(a);

单表查问下推

单表查问,不论 SQL 的 where 条件是否带有分片键,优化器都能够生成下推的执行打算,包含 sort/group by 等简单算子,都能够下推。

1)分片键上的 where 条件,间接下推到 DN

2)非分片键 where 条件,DN 先计算,CN 做汇总,sort/group by 能够间接下推到 DN

Join 查问下推

1)分片键上的 join 条件,间接下推到 DN 执行

2)非分片键 join 条件,DN 间接做数据交换,防止 CN 成为性能瓶颈

1,Join 下推到 DN 执行,DN 之间间接进行数据重散布,替换数据,无需 CN 参加;CBO 优化器抉择小表 t2 做重散布;

2,Sort 下推到 DN,CN 只需做归并排序,防止 CN 成为性能瓶颈;

3.3 数据强统一,“算得准”

数据强统一是 GaussDB(for openGauss) 绝对于基于分库分表的中间件计划的另一个外围劣势,基于中间件的计划因为不感知事务的快照逻辑,只能做到最终一致性,局部场景须要业务做比拟大的革新来躲避陷阱。GaussDB(for openGauss) 提供数据强统一能力,让数据“算得准”。

  • 分布式强统一:

1)两阶段提交保障写的原子性。

2)两阶段提交对用户通明,写操作如果只波及一个节点,无需应用两阶段提交。

3)全局 CSN 保障读的强统一。

  • 高性能事务管理:

GTM 线程池、原子的 CSN 调配,核心节点无性能瓶颈。

4. 总结

综上所述,GaussDB(for openGauss) 基于可横向扩大的分布式架构,提供了海量存储、疾速响应、数据强统一的能力,能够很好满足大规模海量数据的计算存储需要,让数据“存得下、算得快、算得准”。

值得一提的是,openGauss 是凋谢的生态:架构凋谢、代码凋谢、技术凋谢和社区凋谢,不便企业抉择凋谢的生态,让本人的业务具备更好的连续性。毕竟如果让企业从一个关闭的生态走向为另外一个关闭的生态,实质上并没有解决业务连续性的问题,不凋谢的生态是没有生机的,数据库软件尤甚,所以华为十分重视生态凋谢。

目前 openGauss 单分片版本的源代码曾经开源,社区地址为:https://opengauss.org,欢送大 …

Ps:错过直播的小伙伴不要灰心,点击链接回播视频看起来:https://bbs.huaweicloud.com/l…

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

正文完
 0