关注我「 程序猿 集锦」，获取更多分享。

什么是Greenplum

Greenplum是什么鬼？绿色的李子？干啥用的？能吃吗？

Greenplum是分布式的数据库。

分布式 vs 集群

什么是分布式

项目组团队、乐队等

大家各司其职，但又密切沟通，共同来完成一件事情。

什么是集群

滥竽充数、拔河比赛等

大家齐心协力，各自都做相通的事情，共同完成一件事情。

分布式和集群的区别

• 相同点：都是多人或多个节点共同合租来达到某一个目的，或完成某一项任务。
• 不同点：分布式：要求各个节点、个体之间需要密切的沟通。集群：各个节点之间不一定需要密切的沟通，当然沟通效果可能更好，但是这个不是必须的条件。

分布式和集群的联系

• 分布式一般也都会有集群的体现，

例如：足球比赛中，后卫一般不是只有1名后卫，也不是1名中场，也不是只有1名前锋。

多名后卫之间的关系就是一个集群关系，他们都是来参与防守的任务；

多名中超直接的关系就是一个集群关系，他们都是来参与组织进攻的任务；

多名前锋直接的关系就是一个集群关系，他们都是来参与进攻的任务；

• 而集群中也会有分布式的体现(但不是必须的，例如多人吹竽，大家各自按照乐谱吹，基本就OK)。

例如：龙舟比赛中，不仅仅只有划船的人，还有一个敲鼓的人，还有一个复制掌舵的人。

这样整个龙舟上的人分为三个角色：敲鼓的、划船的、掌舵的。他们三个角色各司其职共同来完成比赛。这也是一种分布式的体现。

数据库架构演变历史

SMP

SMP(Symmetric Multi Processing)架构，对称多处理架构(share everything)。例如单机版本的mysql、oracle、sqlserver等。所有的CPU共享全部资源，如总线，内存和I/O系统等，操作系统或管理数据库的副本只有一个，这种系统有一个最大的特点就是共享所有资源

UNMA

NUMA(Non-Uniform Memory Access)架构，半共享架构(share disk)，例如：oracle rac、db2 pureScale，它是磁盘共享(share disk)，数据共享，可以通过增加节点来提处理能力，但是当共享存储接口达到瓶颈后，增加节点并不能获得更高当性能。

MPP

MPP(Massively Parallel Processing)架构，海量并行处理架构(share nothing)，每一个节点有自己的Merry、CPU、Disk、OS，不共享任何资源，各个处理单元之间通过协议通讯。各个单元相互独立，各自处理自己的数据，处理完成后向上汇总。

smp numa mpp的对比，请参考下图：

如何理解MPP

PostgreSQL

与PostgreSQL的关系？GP是由PostgreSQL演化而来，多个PostgreSQL实例共同组成GreenPlum集群。

相比PostgreSQL，GP的优点是什么

增加并行处理，支持数据仓库，增加BI特性支持。

增加外部表，支持并行加载，查询的优化等。

相比PostgreSQL，Greenplum对PostgreSQL底层功能模块进行了修改和提升，以此来满足多个PostgreSQL来协同完成相关SQL语句的操作。

• 外部表并行数据加载
• 可更新数据压缩表
• 行、列混合存储
• 数据表多级分区
• Bitmap索引
• Hadoop外部表
• Gptext全文检索
• 并行查询计划优化器和Orca优化器
• Primary/Mirror镜像保护机制
• 资源队列管理
• WEB/Brower监控

Greenplum体系架构

GP高层的Greenplum数据库架构如下图所示：

• Client：客户端。
• Master Host：master所在的主机。
• Interconnect：以太网络接口。
• Segment Host：segment实例所在的主机，一个Segment Host可以有多个Segment。有多少可以Segment取决于物理主机的CPU内核数目。

Client

支持多种客户端，如下：

Master

1. GP数据库系统的入口(entry point)
2. GP集群元数据的聚集地
3. 协调集群中Segment数据库实例一起工作
4. 用户权限的认证
5. 接受用户的请求
6. 检查、分析SQL语句
7. 生成并分发执行计划
8. 收集执行结果并交给Client端
9. 记录操作日志

Standby Master

Standby Master是Primary Master的热备份，当primary master不可用当时候，接管primary master当职能。

由于master节点不存储任何用户当数据，只是存储GP集群当元数据信息(catalog)和操作日志，所以在primary和standby之间，只要同步这心元数据信息和操作日志信息。

standby master可以单独部署在一个独立机器上，可以部署在某一个segment节点上。如果部署在某一个segment节点后，那么这个segment节点除了会存储用户当数据、参与数据查询处理之外，在当primary master不可用当时候，还会承担master节点的工作。

Segment host

1. 包含多个segment instance，每一个instance就是一个PostgreSQL数据库的实例
2. 存储每个表中的一部分数据
3. 执行master分发下来的执行计划

每一个segment host节点具体的的配置见下图：

注意：各个segment的硬件配置应该是相同。这样才能保证某个操作，不会因为硬件配置低的segment而拖慢整个操作（木桶原理）。

Mirror Segment instance

当某一个segment host主机或者某一个主机上面的某一个segment不可用之后，我们的GP集群就失效了，不能提供完整的数据了。因为数据是分布在各个segment上。为了保证高可用，那么segment也需要做荣誉存储。

如下是GP中常用的两种荣誉存储的方式。从中，我们可以看出，任何一个主机或segment失效，都不影响数据的访问。因为他们都有镜像存储在其他主机上。

group mirroring(default)

这种配置方式是gp默认的配置方式。它是把某一台主机上面所有的primary segment所对应的mirror segment，全部放在另外一台主机上面。如下图所示：

spread mirroring

这种配置方式，是把某一台主机上面的所有的primary segment所对应的mirror segment，分开放在不同的主机上面。

Interconnect

1. 集群中的网络链接层
2. 负责各个segment节点之间的通讯
3. 默认采用UDP协议
4. TCP协议也支持(segment节点小于1000)

为了提高整个集群的性能，减少每一个segment instance实例之间网络资源的竞争，可以为每一个segment instance配置一个独享的网卡接口。如下图所示：

Interconnect Redundancy

数据存储方式

数据如何分布

数据分布示例

均匀分布

倾斜分布

数据如何存储

按照时间热度存储

压缩存储

• 压缩存储

1. 支持ZLIB和QUICKLZ方式的压缩,压缩比可到10:1
2. 压缩表只能是Append Only方式
3. 压缩数据不一定会带来性能的下降，压缩表将消耗CPU资源，而减少I/O资源占用

• 语法

CREATE TABLE foo (a int, b text)
WITH (appendonly=true, compresstype=zlib, compresslevel=5);

行列存储

如果常用的查询只取表中少量字段，则列模式效率更高，如查询需要取表中的大量字段，行模式效率更高

• 效率比较测试

• 测试1：需要去表中所有字段，此时行存储更快。

 select * from dw_ods.s1_sema_scmcaccp_row where crdacct_nbr= '4033930000166380411';
 41秒

 select * from dw_ods.s1_sema_scmcaccp_col where crdacct_nbr= '4033930000166380411';
 116秒

• 测试2：只取表中少量字段，列存储更快

 select crdacct_status from dw_ods.s1_sema_scmcaccp_row where crdacct_nbr= '4033930000166380411';
 35秒

 select crdacct_status from dw_ods.s1_sema_scmcaccp_col where crdacct_nbr= '4033930000166380411';
 3秒

外部表存储

• 外部表的特征

1. Read-only
2. 数据存放在数据库外
3. 可执行SELECT, JOIN, SORT等命令，类似正规表的操作

• 外部表的优点

1. 并行方式加载
2. ETL的灵活性
3. 格式错误行的容错处理
4. 支持多种数据源

• 两种方式

1. External Tables: 基于文件
2. Web Tables: 基于URL或指令

分区存储

• rang范围分区：根据字段值的范围进行分区存储数据。如日期、数字、价格区间等范围进行分区
• list列表分区：根据字段值等内容进行分区存储数据。如地区、产品类别、性别等列表进行分区。
• 组合分区：列表和范围组合在一起进行分区。如先进性别的行列表分区，在进行日期的范围分区，如下图所示：

• 将一张大表逻辑性地分成多个部分，如按照分区条件进行查询，将减少数据的扫描范围，提高系统性能。
• 提高对于特定类型数据的查询速度和性能
• 也可以更方便数据库的维护和更新
• Greenplum中的表分区在使用中具有总表的继承性，并通过Check参数指定相应的子表
• 分区的子表依然根据分布策略分布在各segment上
• 分区是一种非常有用的优化措施，例如一年的交易按交易日期分区后，查询某一天的交易，性能将大大提升。

GreenPlum的访问控制

客户端授权

是否允许从某个客户端的连接

用户是否可以连接到所请求的数据库

默认是只能在master节点本地登陆。如果需要从远程客户端访问，需要在pg_hba.conf配置文件中进行配置。

pg_hba.conf file

基于host address, database, and/or DB user account控制权限。

位于master节点，文件路径：/data/master/gpseg-1/pg_hba.conf

• TYPE：主机类型local：使用Unix-domainsockethost：使用TCP/IP连接，可以是SSL的，也可以不是hostssl：必须是SSL的hostnossl：必须是非SSL的
• DATABASE：可以被访问的数据库名称，可以是all, database1, database2等。all表示所有，多个数据库用“,”隔开。
• USER：允许哪些用户访问，all表示任何用户，和database的配置一样，多个用户名之间逗号隔开。还可以写到文件里面，文件名前面用“@”标识。
• CIDR-ADDRESS：允许访问的IP地址，只有在这个IP地址或IP地址段内，才可以访问数据库。
• METHOD：登陆的方式，trust表示可以直接登陆不需要任何密码信息，md5表示需要输入密码才可以访问，密码以md5的方式存储在数据库元数据中。该值可以为"trust", "reject", "md5", "password", "scram-sha-256","gss", "sspi", "ident", "peer", "pam", "ldap", "radius" or "cert"注意 若为`password`则发送的为明文密码

示例：

控制SQL执行的顺序

角色Role

GPDB 通过角色(Role)的概念来管理数据库的访问权限。Role 的概念包含两个子概念用户 (User)和组(Group)。

一个 Role 可以是一个用户User或者一个组Group。

Role可以拥有DB对象(比如 Table)并可以分配该对象的权限给其他Role从而实现对该对象的控制。

Role 还可以成为其他 Role 的成员，因此 Role 可以继承其父级 Role 的对象权限。

示例如下：

用户User

创建role的时候，如果指定了login的属性，则表示该角色是一个用户user，否则是一个组group。

例如：

--创建一个用户
create role myaccount with login identified by '123456';

组Group

创建role的时候，如果指定了login的属性，则表示该角色是一个用户user，否则是一个组group。

--创建一个角色
create role myrole;

角色使用示例

--创建一个角色
create role myrole;

--创建一个用户
create role myaccount1 with login identified by '123456';
create role myaccount2 with login identified by '123456';
create role myaccount3 with login identified by '123456';

--把角色授权给用户
grant myrole to myaccount1;
grant myrole to myaccount2;
grant myrole to myaccount3;
--grant myrole to myaccount1,myaccount2,myaccount3;

--把某一个schema的使用权限授权给指定的角色
grant usage on schema myschema to myrole;

--把某一个schema的使用权限从指定的角色中收回
revoke usage on schema myschema from myrole;

--把某一个schema的下面某一个表的查询权限从指定的角色中收回
grant select on table myschema.mytable to myrole;

--把某一个schema的下面某一个表的查询权限从指定的角色中收回
revoke select on table myschema.mytable from myrole;

资源队列

resource queue资源队列，是在4.x版本才加入的概念，资源队列是为了限制GP资源的消耗，更加合理地分配资源。

• active_statements：该资源队列中，所允许同时运行的活动查询的数量。
• max_cost：每条sql最大消耗的cost数量，cost的值，就是explain时候可以看到的cost
• min_cost：最少cost数量，如果sql需要的cost小于这个，无论什么情况都会马上执行这个sql
• cost_overcommit：判断某一个sql的cost超过了设置的max_cost阀值之后是否还可以允许该sql，只有设置了max_cost的值之后，该参数才有必要配置，否则不用配置。配置了max_cost的值。表示限制了单条sql最大的cost那么此时cost_overcommit=1的时候，也就是它的默认值的时候，即true，表示此时如何有sql的cost超过了max_cost的值，那么这个sql也将会被允许。但是只能在系统资源空闲的时候才可以执行。如何此时cost_overcommit=0的时候，表示false，那么此时如果有sql的cost超过了max_cost的值，那么这个sql将永远不能被执行。没有配置max_cost的值，表示不限制单条sql最大的cost此时cost_overcommit=0，表示不允许超过最大cost的sql被执行。这种情况不存在。
• priority：CPU优先级，分为min|low|medium|high|max，如果没有设置，默认值是medium
• memory_limit：设置此资源队列中用户提交的所有语句的总内存配额。默认值是-1，表示没有限制。

GreenPlum的查询过程

查询命令的执行

查询机制的处理

并行执行查询计划

监控

pgAdmin

GPCC

greenplum command center