Greenplum数据库整体架构

    Greenplum数据库基本由PostgreSQL核心增强数据库实例组合并衔接成的数据库管理系统，即Greenplum

 

数据在PostgreSQL基础上扩展开发出来的。

 

    每个Greenplum数据库由1个master实例和2个或2个以上segment实例组成，客户端使用PostgreSQL规范

 

与Master交互。接下来的插图，展示Greenplum数据库实例由1个master和6 segement实例组成：

 

 

 

   上述插图中Master Host部署在专用服务器上，1台Host就是1台计算机(物理机或虚拟机)-包括操作系统、

 

内存、硬盘存储、1个或多个网络接口。Master Host或Master实例就是GreenPlum数据服务端，服务端通过

 

端口(默认端口5432)监听客户端连接。

 

    6个Segement部署在3个Segement Host，每个Segement Host是一台独立计算机含有操用系统、内存、

 

CPU、存储、网络接口。与Master Host类似，Segement Host也是独立计算机或虚拟机。

   每个Segement是数据库服务端分配并管理一部份数据存储，每个Segement在Segement Host采用独立端

 

口监听。

 

    Master实例协调所有数据库实例、分布式请求Segement并且合并从Segement返回的结果。

 

Shared Nothing vs. Shared Disk

 

    GreenPlum数据库是Shared Nothing架构，因为每个Segement拥有自己的CPU、内存、硬盘来管理部份

 

数据库。相反，基于共享磁盘的Shared Disk(或Shared Everything)架构的分布数据库管理系统拥有多个数据

 

库服务实例管理单个数据库实例。Shared Nothing与Shared Disk架构有不同的优缺点。

    在磁盘共享系统中所有数据存储在本地数据库服务端，不需要通过网络发送数据到另一服务器执行连表查

 

询；然而网络磁盘存储解决方案和软件磁盘共享限制数据与数据库服务器数量添加到数据库集群。昂贵服务

 

器和网络附属存储软件需要增加容量和保持可接受的查询响应时间。

    Shared Disk架构中, 每个CPU都有自己的内存, 但是所有CPU共享一组硬盘, 这些硬盘以SAN或者NAS的形

 

式组织在一起。

    SD架构的缺点

       1. 连接CPU和硬盘驱动的连接会成为系统的瓶颈.

       2. 因为各个CPU都有自己的内存, 所以没有一个地方可以放置锁表(lock table)或者缓存池(buffer pool).

 

         为了设置锁, 只能在一个CPU上设置一个公共的锁管理器或者使用复杂的分布式锁协议. 当CPU数量增

 

         多 时, 上述两种两种方法的可扩展性都不是很好。

     Shared Nothing架构中, 每个CPU有自己的内存和硬盘. 数据按行被水平划分, 这样不同节点上存储的是不

 

同行的数据. 每个节点只负责处理自己硬盘上的数据. 每个节点有自己的锁表和缓存池, 这样就避免了复杂的

 

分布式锁机制. SN的可扩展性非常好。

 

      下一节将我们谈论数据分布策略及存储方式（列式存储或行式存储）。