GaussDB(for openGauss)让数据“存得下、算得快、算得准”

*) 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节点，减少数据移动，让数据“算得快”。

大致执行过程：

业务应用下发SQL给Coordinator ，SQL可以包含对数据的CRUD操作；
Coordinator利用数据库的优化器生成执行计划，每个DN会按照执行计划的要求去处理数据；
数据基于一致性Hash算法分布在每个DN，因此DN在处理数据的过程中，可能需要从其他DN获取数据，GaussDB提供三种stream流（广播流、聚合流和重分布流）实现数据在DN间的流动，使得join无需抽取到CN执行；
DN将结果集返回给Coordinate进行汇总；
Coordinator将汇总后的结果返回给业务应用。

华为在SQL执行优化方面有多年的沉淀，即使是复杂的SQL、事务分析混合（HTAP）的场景也能得到最佳的执行，我给大家举一些列子：

优化器是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

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

技术图片

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GaussDB(for openGauss)让数据“存得下、算得快、算得准”

标签：管理 tap data order by lan 排序原子性 amp 部署