Greenplum最佳部署

Greenplum最佳部署

Greenplum的分布式架构方案MPP对于海量数据处理还是很给力的。它里面几乎囊括了所有的主从角色概念，比如GP节点就类似于一个集群分发器，是有standby的角色的，数据节点是segment,是有primary和mirror做为互备高可用的。

一个DB实例实际上是由多个独立的PostgreSQL实例组成的，它们分布在不同的物理主机上，协同工作，呈现给用户的是一个DB的效果。

1. 平衡

每台机器配置最好一致，对于MPP数据库存在木桶效应，某个节点的性能过低，这个机器就会成为整个集群的短板，制约整个集群的性能。

1. 高可用

硬件和软件的设计上都要冗余，硬件上网络和磁盘做冗余，软件上数据做镜像备份冗余。

部署方案

1. Master和Standby Master分机部署
2. Primary Segment与Mirror Segment分机部署

     Segment Mirroring有两种方案

1. Group方案

公司这么用的

缺点：如果某台主机宕机，那么该主机所在的下一台主机（mirror所在主机），将承受双倍负荷，集群的整体性能将严重退化。

优点：扩展代价低，最少只需两台Segment主机。最多可以有一半的主机出现故障宕机（极端的情况是同一个Segment实例和primary和mirror都宕了，那么整个集群都会停止服务），相对与spread而言可用性更高。

2、Spread方案

机器多的时候可以用这种

注意点：集群中的Segment主机数至少为每台主机上Segment数加一。

优点：对于单机故障，性能影响比较小。

缺点：集群中，两台以上主机出现故障，集群大概率不可用。

3、Block 方案（group+spread）

优点：出现故障时，性能介于group和spread之间，只要故障主机处于不同块中，能够容忍多主机故障。

缺点：实现起来比较繁琐，需要用户自己创建配置。

1. 同一个节点的Segment数量

CPU/Core数目

查询并发数

查询复杂度

单机Primary Segment总数不能过多

复杂查询较多，Segment数量少一点；查询不复杂，并发量高的情况，Segment数量可以多一点。

硬件选型

Master节点（存储的负载轻）

（1）网络是Segment主机内所有Segment进程共享的，可以配置多网卡，同一个Segment主机的不同Segment实例与不同网卡进行绑定，实现网络负载均衡。

（2）内存对查询性能影响非常大，内存要足够，推荐256GB。

（3）磁盘优先选择SAS盘，容量大稳定性高。硬盘采用RAID5或者RAID10进行磁盘数据冗余，必须配置带有缓存的RAID卡，只有配置带有缓存的RAID卡，I/O性能才能得到提升。

Segment节点

网络性能和内存与master节点类似

磁盘要求更高，需要的存储容量更大，磁盘也不是越多越好，磁盘过多了，虽说整体的I/O性能变高，但是RAID卡就会成为集群性能的瓶颈，整体性能还是上不去。

经验总结

磁盘故障时Greenplum集群最常见的故障

分析型查询：SAS盘>SATA盘

高并发小IO查询：优先SSD或者NVMe （通过表空间的方式，将这部分业务数据部署在独立的磁盘组里）

RAID级别：RAID5磁盘利用率更高，读写性能高；RAID10数据冗余度高，可靠性高，磁盘利用率低。

RAID卡一定要带Cache功能

RAID主要是提高系统本次存储的I/O性能，如果生产环境有其他的代替方案，同样可以使磁盘的I/O性能不成为瓶颈，也是可以的。官方推荐的是RAID方案。