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

1.前言

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

面对挑战，华为云数据库深度融合华为在数据库领域多年的经验，充分结合了企业级场景需求，基于 openGauss 自研生态推出了企业级分布式关系型数据库 GaussDB(for openGauss)。GaussDB(for openGauss)目前支持单分片和分布式两种部署形态，在支撑传统业务的基础上，持续构建竞争力特性，为企业面向数字化转型提供了无限可能。

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

2.分布式架构

GaussDB(foropenGauss)是一个典型的基于数据分片的双层分布式架构(share nothing)，数据通过一定的规则比如 hash、list 或者 range 等让数据打散分布到不同的数据节点上，计算时底层多个数据节点共同参与，上层协调节点负责执行计划生成和结果汇聚。

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

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

3.1 海量数据“存得下”

GaussDB(foropenGauss) 支持 1000+的数据节点扩展能力，数据通过一定的规则比如 hash、list 或者 range 等让数据打散分布到不同的数据节点上，让数据“存得下”。

数据分布方式

GaussDB(foropenGauss)支持 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(foropenGauss)关键技术之一，可以把各种复杂的 SQL 进行下推执行，最小化数据移动，这是 GaussDB 相对于基于分库分表的中间件方案的核心优势（对于复杂查询，由于计算无法下推，中间件很容易成为性能瓶颈，需要业务做比较大的改造来规避）。

以下案例的表结构为：

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

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

单表查询下推

单表查询，不管 SQL 的 where 条件是否带有分片键，优化器都可以生成下推的执行计划，包括 sort/group by 等复杂算子，都可以下推。

1）分片键上的 where 条件，直接下推到 DN

​2）非分片键 where 条件，DN 先计算，CN 做汇总，sort/groupby 可以直接下推到 DN

Join 查询下推

1）分片键上的 join 条件，直接下推到 DN 执行

2）非分片键 join 条件，DN 直接做数据交换，避免 CN 成为性能瓶颈

1，Join 下推到 DN 执行，DN 之间直接进行数据重分布，交换数据，无需 CN 参与；CBO 优化器选择小表 t2 做重分布；

2，Sort 下推到 DN，CN 只需做归并排序，避免 CN 成为性能瓶颈；

3.3 数据强一致，“算得准”

数据强一致是 GaussDB(foropenGauss)相对于基于分库分表的中间件方案的另一个核心优势，基于中间件的方案由于不感知事务的快照逻辑，只能做到最终一致性，部分场景需要业务做比较大的改造来规避陷阱。GaussDB(for openGauss)提供数据强一致能力，让数据“算得准”。

​分布式强一致：

1）两阶段提交保证写的原子性。

2）两阶段提交对用户透明，写操作如果只涉及一个节点，无需使用两阶段提交。

3）全局 CSN 保证读的强一致。

高性能事务管理：

GTM 线程池、原子的 CSN 分配，中心节点无性能瓶颈。

4.总结

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

值得一提的是，openGauss 是开放的生态：架构开放、代码开放、技术开放和社区开放，方便企业选择开放的生态，让自己的业务具备更好的连续性。毕竟如果让企业从一个封闭的生态走向为另外一个封闭的生态，本质上并没有解决业务连续性的问题，不开放的生态是没有活力的，数据库软件尤甚，所以华为十分重视生态开放。

目前 openGauss 单分片版本的源代码已经开源，社区地址为：opengauss.org，欢迎大家自行下载、安装和体验。

Ps：错过直播的小伙伴不要灰心，点击链接回播视频看起来：bbs.huaweicloud.com/live/cloud_…