[转]Greenplum 执行计划之广播与重分布
关联数据在不同节点上,对于普通关系型数据库来说,是无法进行连接的。关联的数据需要通过网络流入到一个节点中进行计算,这样就需要发生数据迁移。数据迁移有广播和重分布两种。在GP中,每一个广播或重分布会产生一个切片,每一个切片在每个数据节点上都会对应发起一个进程来处理该slice负责的数据,上一层负责该slice的进程会读取下级slice广播或重分布的数据,然后进行相应的计算。
当两张表关联的时候,如果有一张表的关联键不是分布键,那么就会发生表的广播或者重分布,将数据移动到一个节点上进行关联,从而获得数据。
分布式的关联有两种:
单库关联:关联键与分布键一致,只需要但单个库关联后得到结果即可。
跨库关联:关联键与分布键不一致,数据需要重新分布。转换成单库关联,从而实现表的关联。
表关系如下:
表A
字段:id,id2
分布键:id
数据量:M
表B
字段:id,id2
分布键:id
数据量:N
内连接
情况1:
select * from A,B where A.id=B.id;
分布键与关联键相同,属于单库关联,不会造成广播或者重分布。
情况2:
select * from A,B where A.id=B.id2;
表A的关联键是分布键,表B的关联键不是分布键,那么可以通过两种凡是来实现关联。
1. 将表B按照id2字段将数据重分布到一个节点上,然后再与表A进行关联。重分布的数据量是N。
2. 将表A广播,每一个节点都放一份全量数据,然后再与表B关联得到结果。广播的数据量是M*节点数。
所以,当N>M*节点数的时候,选择表A广播,否则选择B重分布。
情况3:
select * from A,B where A.id2=B.id2;
两个表的关联键与分布键都不一样,那么还有两种做法:
1. 将表A与表B按照id2字段,将数据重分布到每个节点,重分布的代价是M+N。
2. 将其中一张表广播后再关联,当然选取小表广播,代价小。广播的代价是min(M,N)*节点数。
所以当M+N>min(M,N)*节点数的时候,选择小表广播,否则选择两个表都重分布。
左连接
情况1:
select * from A left join B on A.id=B.id;
单库关联,不涉及数据库跨库关联。
情况2:
select * from A left join B on A.id=B.id2;
由于左表的分布键是关联键,鉴于左连接的性质,无论表B数据量多大,都必须将表B按照字段id2重分布数据。
情况3:
select * from A left join B on A.id2=B.id;
左表的关联键不是分布键,由于左连接A表肯定不是被广播的,所以有两种方式。
1. 将表A按照id2重分布数据,转换成情况A,代价为M。
2. 将表B广播,代价为N*节点数。
情况4:
select * from A left join B on A.id2=B.id2;
有两种处理方式。
1. 将表A与表B都按照id2字段将数据重分布一遍以,转换成情况1,代价是M+N。
2. 表A不能被广播,只能将表B广播,代价是N*节点数。
全连接
情况1:
select * from A full outer join B on A.id=B.id;
关联键是分布键,在GP中全连接只能采用Merge Join来实现。
情况2:
select * from A full outer join B on A.id=B.id2;
将不是关联键不是分布键的表重分布数据,转换成情况1解决。无论A、B大小分别为多少,为了实现全连接,不能讲表广播,只能是重分布。
情况3:
select * from A full outer join B on A.id2=B.id2;
将两张表都重分布,转换成情况1进行处理。
《Greenplum企业应用实战》
(原文地址:http://www.jpblog.cn/greenplum-%E6%89%A7%E8%A1%8C%E8%AE%A1%E5%88%92%E4%B9%8B%E5%B9%BF%E6%92%AD%E4%B8%8E%E9%87%8D%E5%88%86%E5%B8%83.html)
[转]Greenplum 执行计划之广播与重分布的更多相关文章
- Greenplum 执行计划之广播与重分布
关联数据在不同节点上,对于普通关系型数据库来说,是无法进行连接的.关联的数据需要通过网络流入到一个节点中进行计算,这样就需要发生数据迁移.数据迁移有广播和重分布两种.在GP中,每一个广播或重分布会产生 ...
- Greenplum查询计划分析
这里对查询计划的学习主要是对TPC-H中Query2的分析. 1.Query的查询语句 select s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_a ...
- SQL Server中参数化SQL写法遇到parameter sniff ,导致不合理执行计划重用的一种解决方案
parameter sniff问题是重用其他参数生成的执行计划,导致当前参数采用该执行计划非最优化的现象.想必熟悉数据的同学都应该知道,产生parameter sniff最典型的问题就是使用了参数化的 ...
- 关于T-SQL重编译那点事,内联函数和表值函数在编译生成执行计划的区别
本文出处:http://www.cnblogs.com/wy123/p/6266724.html 最近在学习 WITH RECOMPILE和OPTION(RECOMPILE)在重编译上的区别的时候,无 ...
- SQL Server 利用Profiler观察执行计划是否重用时SP:Cachemiss,SP:CacheInsert以及SP:CacheHit的含义
本文出处:http://www.cnblogs.com/wy123/p/6913055.html 执行计划的缓存与重用 在通过SQL Profile观察一个SQL语句或者存储过程是否有可用的缓存执行计 ...
- MSSQLSERVER执行计划详解
序言 本篇主要目的有二: 1.看懂t-sql的执行计划,明白执行计划中的一些常识. 2.能够分析执行计划,找到优化sql性能的思路或方案. 如果你对sql查询优化的理解或常识不是很深入,那么推荐几骗博 ...
- SQL Server 执行计划缓存
标签:SQL SERVER/MSSQL SERVER/数据库/DBA/内存池/缓冲区 概述 了解执行计划对数据库性能分析很重要,其中涉及到了语句性能分析与存储,这也是写这篇文章的目的,在了解执行计划之 ...
- 谈一谈SQL Server中的执行计划缓存(下)
简介 在上篇文章中我们谈到了查询优化器和执行计划缓存的关系,以及其二者之间的冲突.本篇文章中,我们会主要阐述执行计划缓存常见的问题以及一些解决办法. 将执行缓存考虑在内时的流程 上篇文章中提到了查询优 ...
- 浅析SqlServer简单参数化模式下对sql语句自动参数化处理以及执行计划重用
我们知道,SqlServer执行sql语句的时候,有一步是对sql进行编译以生成执行计划, 在生成执行计划之前会去缓存中查找执行计划 如果执行计划缓存中有对应的执行计划缓存,那么SqlServer就会 ...
随机推荐
- mysql_union操作符
MySQL UNION操作符 union操作符合并两个或多个 SELECT 语句的结果集. union:去重 union all:不去重 UNION 结果集中的列名总是等于 UNION 中第一个 S ...
- gitlab发送邮件
1.修改配置文件,建议使用企业邮箱 #vim /etc/gitlab/gitlab.rb gitlab_rails['smtp_enable'] = true gitlab_rails['smtp_a ...
- vscode下Python设置参考
用于VS代码的Python扩展是高度可配置的.此页面介绍了可以使用的关键设置. 请参阅用户和工作区设置,以了解有关在VS代码中使用设置的更多信息. 常规设置 设置 默认 描述 python.pytho ...
- 关于 tensorflow-gpu 中 CUDA 和 CuDNN 版本适配问题
问题 今天在使用 tensorflow-yolov3 的时候,发现报错 Loaded runtime CuDNN library: but source was compiled with: . Cu ...
- go语言学习-基础知识
go程序的基本结构 一个可以最简单的可运行的go程序需要满足下面两个条件: 有一个main()函数 main()函数在main包中 例如: 在go语言中的 hello world 程序如下: // m ...
- racket 学习笔记
length: (define (my-length lst) (if (empty? lst) 0 (+ (my-length (rest lst)) 1))) map: (define (my-m ...
- guacamole部署
centos7.6 安装java export JAVA_HOME=/usr/jvm/javaexport JRE_HOME=$JAVA_HOME/jreexport CLASSPATH=.:$JAV ...
- bzoj 2013 上升计数
题意: 给一个数集和一个数d,问满足下列要求的排列数(相同的数要区分): a[i]+d>=a[i+1] ( i in [1,n) ) 因为数的给出顺序不重要,所以先排序,假如我们已经解决了前i ...
- db2文件系统已满
文章主要讲述的是DB2文件系统已满的正确解决方案,此文首先是以列举错误案例来对其进行分析,之后再给出正确的解决方案,以下就是文章的主要内容的具体描述,望大家浏览之后会对其有更好的了解. DB2文件系统 ...
- pt-query-digest简介使用
简介 pt-query-digest 是用于分析mysql慢查询的一个工具,与mysqldumpshow工具相比,py-query_digest 工具的分析结果更具体,更完善. 有时因为 ...