分布列选择黄金法则

由于Greenplum是一个分布式的数据库，数据是分散存储在各个数据节点的，所以需要告诉Greenplum数据应该如何分布。

短板效应

当用户请求QUERY时，Greenplum会在所有的节点并行执行，所以最慢的节点会成为整个系统的瓶颈。

Greenplum 支持的分布算法 :

用户可以指定 分布列(允许指定多个列) ，或者使用 随机分布 算法。

那么用户应该如何选择分布列，或者是否要使用随机分布算法呢？

总结起来，需要考虑以下几点

• JOIN

  当JOIN的列都是分布列时，不需要重分布或广播小表，可以在segment内完成JOIN。

两个表在JOIN时，如果JOIN列不是表的分布列，那么其中一个更小的表会发生数据重分布，或者broadcast，以继续完成JOIN的动作。

例如a和b都是随机分布的，在JOIN时，要么广播小表，要么两个表都根据JOIN 列重分布。

例如a和b，其中a是JOIN列分布，b不是，那么b可以选择广播，或者重分布。

重分布或广播的动作都是自动完成的，但是这样一定会带来额外的网络开销。

想象一下，如果你的QUERY并发很高，而且大量的QUERY中涉及到JOIN的数据重分布或broadcast的话，网络很快就会成为瓶颈。

法则1，分布列尽量选择需要经常JOIN的列，这类查询的并发越高，越应该考虑。

• 防止数据倾斜

  Greenplum依据指定的分布列，hash取模存放到对应的segment中。

  如果选择的分布列值分布不均匀，就可能导致数据倾斜，某些segment可能非常大，而某些segment非常小。

  数据倾斜的显著危害，1. 空间不均匀，不好规划存储。2. 数据分布过多的节点，容易成为整个系统的短板。

  法则2，尽量选择分布均匀的列，或者多列

• 高并发查询，选择性好

  如果数据经常被高并发的键值或离散查询，建议将查询条件的列作为分布列，这样不需要连接到所有的segment去查，可以大大提高并发能力。

  例子

  aa01 的分布列是aaz499

  查询分布列时，定位到一个segment查询

postgres=# explain analyze select * from aa01 where aaz499=1;  QUERY PLAN
----------------------------------------------------------------------------------  Gather Motion 1:1  (slice1; segments: 1)  (cost=0.00..120.00 rows=1 width=1973)  Rows out:  0 rows at destination with 1.352 ms to end, start offset by 144 ms.  ->  Seq Scan on aa01  (cost=0.00..120.00 rows=1 width=1973)  Filter: aaz499 = 1  Rows out:  0 rows with 0.031 ms to end, start offset by 145 ms.  Slice statistics:  (slice0)    Executor memory: 330K bytes.  (slice1)    Executor memory: 176K bytes (seg10).  Statement statistics:  Memory used: 128000K bytes  Optimizer status: legacy query optimizer  Total runtime: 145.822 ms
(12 rows)

查询非分布列，需要所有的segment参与查询

postgres=# explain analyze select * from aa01 where cae007='t';  QUERY PLAN
------------------------------------------------------------------------------------  Gather Motion 16:1  (slice1; segments: 16)  (cost=0.00..120.00 rows=2 width=1973)  Rows out:  0 rows at destination with 2.001 ms to end, start offset by 146 ms.  ->  Seq Scan on aa01  (cost=0.00..120.00 rows=1 width=1973)  Filter: cae007::text = 't'::text  Rows out:  0 rows (seg0) with 0.047 ms to end, start offset by 147 ms.  Slice statistics:  (slice0)    Executor memory: 330K bytes.  (slice1)    Executor memory: 176K bytes avg x 16 workers, 176K bytes max (seg0).  Statement statistics:  Memory used: 128000K bytes  Optimizer status: legacy query optimizer  Total runtime: 147.813 ms
(12 rows)

法则3，尽量选择高并发查询的条件列（指该查询条件产生的中间结果集小的，如果中间结果集很大，那就让所有节点都来参与运算更好，因此不选），如果有多个条件，请先权衡前面的法则

法则4，不要轻易使用随机分布

分区黄金法则

目前Greenplum支持LIST和RANGE两种分区类型。

分区的目的是尽可能的缩小QUERY需要扫描的数据量，因此必须和查询条件相关联。

法则1，尽量选择和查询条件相关的字段，缩小QUERY需要扫描的数据

法则2，当有多个查询条件时，可以使用子分区，进一步缩小需要扫描的数据

例子，一个用户发起了带两个查询条件col1=xx and col2 between ?1 and ?2 的请求，通过分区，如果表已经根据col1进行了LIST分区，同时根据col2进行了range的分区，那么查询范围可以大大的缩小。

小结

• 分布列选择法则

  原则，避免短板效应。

  法则1，分布列尽量选择需要经常JOIN的列，这类查询的并发越高，越应该考虑。

  法则2，尽量选择分布均匀的列，或者多列

  法则3，尽量选择高并发查询的条件列（指该查询条件产生的中间结果集小的，如果中间结果集很大，那就让所有节点都来参与运算更好，因此不选），如果有多个条件，请先权衡前面的法则

  法则4，不要轻易使用随机分布

• 分区法则

  原则，缩小查询范围。

  法则1，尽量选择和查询条件相关的字段，缩小QUERY需要扫描的数据

  法则2，当有多个查询条件时，可以使用子分区，进一步缩小需要扫描的数据

转载自：

https://github.com/zuozi2810/blog/blob/master/201607/20160719_02.md