阿里云apsaradb for greenplum公测以来,已经收到好多用户的公测申请。
要使用greenplum,登陆到数据库后第一件事当然是建表,然后倒入数据开测。
大部分用户以前是使用mysql的,并没有接触过greenplum,语法需要适应一下。
例如mysql中的建表语句
在greenplum中可以写成
greenplum完整的建表语法参考本文末尾。
由于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查询
查询非分布列,需要所有的segment参与查询
法则3,尽量选择高并发查询的条件列(指该查询条件产生的中间结果集小的,如果中间结果集很大,那就让所有节点都来参与运算更好,因此不选),如果有多个条件,请先权衡前面的法则
法则4,不要轻易使用随机分布
目前greenplum支持list和range两种分区类型。
分区的目的是尽可能的缩小query需要扫描的数据量,因此必须和查询条件相关联。
法则1,尽量选择和查询条件相关的字段,缩小query需要扫描的数据
法则2,当有多个查询条件时,可以使用子分区,进一步缩小需要扫描的数据
例子,一个用户发起了带两个查询条件col1=xx and col2 between ?1 and ?2 的请求,通过分区,如果表已经根据col1进行了list分区,同时根据col2进行了range的分区,那么查询范围可以大大的缩小。
分布列选择法则
原则,避免短板效应。
分区法则
原则,缩小查询范围。
《阿里云apsaradb rds用户 - olap最佳实践》
<a href="https://yq.aliyun.com/articles/57778">https://yq.aliyun.com/articles/57778</a>
《greenplum资源隔离指南》
<a href="https://yq.aliyun.com/articles/57763">https://yq.aliyun.com/articles/57763</a>
《三张图读懂greenplum在企业的正确使用姿势》
<a href="https://yq.aliyun.com/articles/57736">https://yq.aliyun.com/articles/57736</a>
《greenplum 公测申请页面》
<a href="https://www.aliyun.com/product/gpdb?spm=5176.7960203.237031.39.3xwera">https://www.aliyun.com/product/gpdb?spm=5176.7960203.237031.39.3xwera</a>
greenplum完整的建表语法如下 :
祝大家玩得开心,欢迎随时来 阿里云促膝长谈 业务需求 ,恭候光临。
阿里云的小伙伴们加油,努力做 最贴地气的云数据库 。