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的可扩展性非常好。