GreenPlum简介

最新推荐文章于 2024-08-21 12:04:21 发布

flamimg

最新推荐文章于 2024-08-21 12:04:21 发布

阅读量2.9k

点赞数 1

分类专栏： GreenPlum数据库文章标签： greenplum

本文链接：https://blog.csdn.net/dubo160/article/details/44780061

版权

GreenPlum数据库专栏收录该内容

0 篇文章 0 订阅

订阅专栏

1.GreenPlum简介

（1）GREENPLUM简单的说它就是一个与ORACLE,DB2一样面向对象的关系型数据库。我们通过标准的SQL可以对GP中的数据进行访问存取。

（2）本质上讲GREENPLUM是一个关系型数据库集群。它实际上是由数个独立的数据库服务组合成的逻辑数据库。与RAC（realapplication clusters实时应用集群）不同，这种数据库集群采取的是MPP（massivelyparallel processing大规模并行处理系统）架构。

（3）Greenplum是一种基于postgresql（开源数据库）的分布式数据库。其采用shared nothing架构（MPP），主机，操作系统，内存，存储都是自我控制的，不存在共享。

2.GreenPlum架构

Greenplum主要由masterhost，segmenthost，interconnect三大部分组成。

（1） Master节点：是整个系统的控制中心和对外的服务接入点，它负责接收用户SQL请求，将SQL生成查询计划并进行并行处理优化，然后将查询计划分配（dispatch）到所有的Segment节点进行并行处理，协调组织各个Segment节点按照查询计划一步一步地进行并行处理，最后获取到Segment的计算结果，再返回给客户端；从用户的角度看Greenplum集群，看到的只是Master节点,无需关心集群内部的机制，所有的并行处理都是在Master控制下自动完成的。Master节点一般只有一个或两个（互为备份）。

（2） Master节点：是整个系统的控制中心和对外的服务接入点，它负责接收用户SQL请求，将SQL生成查询计划并进行并行处理优化，然后将查询计划分配（dispatch）到所有的Segment节点进行并行处理，协调组织各个Segment节点按照查询计划一步一步地进行并行处理，最后获取到Segment的计算结果，再返回给客户端；从用户的角度看Greenplum集群，看到的只是Master节点,无需关心集群内部的机制，所有的并行处理都是在Master控制下自动完成的。Master节点一般只有一个或两个（互为备份）。

（3） Segment节点：是Greenplum执行并行任务的并行运算节点，它接收Master的指令进行MPP并行计算，因此所有Segment节点的计算性能总和就是整个集群的性能，通过增加Segment节点，可以线性化得增加集群的处理性能和存储容量，Segment节点可以是1~10000个节点。

3.大规模存储

（1） Greenplum数据库通过将数据分布到多个节点上来实现规模数据的存储。数据库的瓶颈经常发生在I/O方面，数据库的诸多性能问题最终总能归罪到I/O身上，久而久之，IO瓶颈成为了数据库性能的永恒的话题。

（2）Greenplum采用分而治之的办法，将数据规律的分布到节点上，充分利用segment主机的IO能力，以此让系统达到最大的IO能力（主要是带宽）。

（3）在greenplum中每个表都是分布在所有节点上的。Masterhost首先通过对表的某个或多个列进行hash运算，然后根据hash结果将表的数据分布到segmenthost中。整个过程中masterhost不存放任何用户数据，只是对客户端进行访问控制和存储表分布逻辑的元数据。

4.GreenPlum数据分布策略

5.并行数据加载

（1）并行加载技术充分利用分布式计算和分布式存储的优势，保证发挥出每一块Disk的I/O资源

（2）并行加载比串行加载，速度提高40-50倍以上，减少ETL窗口时间

（3）增加Segment和ETL Server，并行加载速度呈线性增长

6.MapReduce&SQL一体环境

7.GreenPlum中的高可用方案

Segment的mirror

当配置了segmentmirror，当segmentprimary不能写的时候，greenplum会自动切换到mirror。当master不能连接到一个segmentinstance时，会把这个instance标记为invalid。

（1）默认情况下，greenplum的失败操作模式是“read-only"模式，也就是说如果一个segment坏了，整个greenplum会变成只读，不能写了。如果模式是“continue”模式时，一个segment坏了的时候，数据库仍然可以继续工作。但由于segment的primary与mirror端的数据不同步了，所以恢复的时候需要花比较长的时间。对于Greenplum3.X的版本，恢复时，需要把好的节点上的所有数据都copy到坏的机器上。而Greenplum4.0版本增加了功能，当备份节点坏的时候，主节点可以把增量数据记下来，这样当备份节点的主机恢复时，只需要恢复增量数据就可以了。要让原先已offline的节点再加入集群中，需要重启集群。

（2）对于Greenplum3.X的版本，segment的primary与mirror之间是做的逻辑同步，mirror端的数据库实际上也是可以读写的。而Greenplum4.0版本后，primary与mirror实际上是物理同步，这时mirror一直处于恢复状态，不能读也不能写。