GreenPlum的并行查询优化策略doc..doc

GreenPlum的并行查询优化策略 文章分类:数据库 1、GreenPlum这种share nothing的架构：  ? ??? 良好的发挥了廉价PC的作用。自此I/O不在是DW的瓶颈，相反网络的压力会大很多。但是greenplum的查询优化策略能够避免尽量少的网络交换。对于初次接触greenplum的人来说，肯定耳目一新。 ? ? 2、greenplum的查询优化器 ? ?????greenplum的查询优化器负责将SQL解析成每个节点(segments)所要走的物理执行计划。也是基于成本的优化策略：评估若干个执行计划，找出最有效率的一个。主节点master负责SQL解析和执行计划的生成。 ? ?不像传统的查询优化器，Greenplum的查询优化器必须全局的考虑整个集群，在每个候选的执行计划中考虑到节点间移动数据的开销。一旦执行计划确定，比如有join，那么join是在各个节点分别进行的（本机只和本机的数据join）。所以它的查询很快。 ? ? 3、查询计划包括了一些传统的操作，比如：扫描、Join、排序、聚合等等。greenplum中有三种数据的移动操作： ? ?? A: ?Broadcast Motion (N:N) ,即广播数据，每个节点向其他节点广播需要发送的数据。 ? ?? B: Redistribute Motion (N:N)?，重新分布数据，利用join的列值hash不同，将筛选后的数据在其他segment重新分布。 ? ?? C: Gather Motion (N:1)，聚合汇总数据，每个节点将join后的数据发到一个单节点上，通常是发到主节点master。 ? ? 4、一个简单的例子: ? ? Sql代码 ?explain?select?d.*,j.customer_id?from?data?d?join??jd1?j?on?d.partner_id=j.partner_id?where?j.gmt_modified?current_date?-80;?? ???????????????????????????????????????QUERY?PLAN????????????????????????????????????????? ----------------------------------------------------------------------------------------?? ?Gather?Motion?88:1??(slice2)??(cost=3.01..939.49?rows=2717?width=59)?? ???-??Hash?Join??(cost=3.01..939.49?rows=2717?width=59)?? ?????????Hash?Cond:?d.partner_id::text?=?j.partner_id::text?? ?????????-??Seq?Scan?on?data?d??(cost=0.00..260.74?rows=20374?width=50)?? ?????????-??Hash??(cost=1.91..1.91?rows=88?width=26)?? ???????????????-??Broadcast?Motion?88:88??(slice1)??(cost=0.00..1.91?rows=88?width=26)?? ?????????????????????-??Seq?Scan?on?jd1?j??(cost=0.00..1.02?rows=1?width=26)?? ???????????????????????????Filter:?gmt_modified??(now::text::date?-?80)?? explain select d.*,j.customer_id from data d join jd1 j on d.partner_id=j.partner_id where j.gmt_modified current_date -80; QUERY PLAN ---------------------------------------------------------------------------------------- Gather Motion 88:1 (slice2) (cost=3.01..939.49 rows=2717 width=59) - Hash Join (c