[转]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就会 ...
随机推荐
- zstu-4243 牛吃草
贴一发两圆相交面积模板 #include<bits/stdc++.h> #define pi acos(-1.0) using namespace std; ; double _abs(d ...
- 练习题|python常用模块
re模块练习 1.验证手机号是否合法 import re phone_pat = re.compile('^(13\d|14[5|7]\d|15\d|166|17[3|6|7]|18\d)\d{8}$ ...
- hdu 2546 饭卡【01背包】
题目链接:https://vjudge.net/contest/103424#problem/C 饭卡 Time Limit: 5000/ ...
- Hash值破解工具(findmyhash与hash-identifier破解Hash值)
Hash值破解工具(findmyhash与hash-identifier破解Hash值) 前言: Kali Linux提供各种哈希密文破解工具,如hashcat.john.rainbows.不论哪一种 ...
- FSMN结构快速解读
参考文献如下: (1) Feedforward Sequential Memory Neural Networks without Recurrent Feedback (2) Feedforward ...
- 收缩自编码器(CAE)
自编码器是一种很好的降维技术,它可以学习到数据中非常有用的信息.而收缩自编码器作为正则自编码器的一种,其非线性降维效果非常好,并且它的过程可以通过流形知识来解释. 基础知识 1.自编码器 自编码器是一 ...
- Java设计模式从精通到入门一 责任链模式
一直都想对设计模式有一个深刻的认识,这样对于阅读源码的时候就不会那么吃力了.于是有了想要记录下设计模式的笔记.打算从自己不怎么熟悉的设计模式开始写,里面穿插着一点自己的想法,希望自己写完后,会又一 ...
- BZOJ.2287.[POJ Challenge]消失之物(退背包)
BZOJ 洛谷 退背包.和原DP的递推一样,再减去一次递推就行了. f[i][j] = f[i-1][j-w[i]] + f[i-1][j] f[i-1][j] = f[i][j] - f[i-1][ ...
- Python3面向对象——案例-01
经典的策略模式案例 问题描述 使用"策略"设计模式处理订单折扣的 UML 类图 定义一系列算法,把它们一一封装起来,并且使它们可以相互替换.本模式使得算法可以独立于使用它的客户而变 ...
- iOS离屏渲染之优化分析
在进行iOS的应用开发过程中,有时候会出现卡顿的问题,虽然iOS设备的性能越来越高,但是卡顿的问题还是有可能会出现,而离屏渲染是造成卡顿的原因之一.因此,本文主要分析一下离屏渲染产生的原因及避免的方法 ...