前言
在数据库诞生到现在，我们所能耳熟能详的数据库如oracle，mysql，sqlserver等，都属于关系型数据库，它们主要是基本的、日常的事务处理，记录即时的增、删、改、查，实时性要求很高，但数据量不会很大，不会做很多复杂的逻辑，这一类归于OLTP(联机事务处理)型数据库，而分布式数据库是对海量的数据进行管理，解决的是海量的数据处理及分析能力，更多的是对数据进行读的操作，增、删、改是比较低频的操作，它对实时性要求不高，更强调的是数据的分析处理能力，属于OLAP(联机分析处理)型数据库。
以下是OLAP和OLTP的比较：
OLTP
OLAP
适用场景
主要供基层人员使用，进行一线业务操作
探索并挖掘数据价值，作为企业高层进行决策的参考
数据特点
当前的、新的、细节的, 二维的、分立的
历史的, 聚集的, 多维的，集成的, 统一的
存取能力
可以读/写数十条记录
读上百万条记录
复杂度
简单的事务
复杂任务
可承载用户
可承载用户数量为上千个
上百万个
DB大小
大小为100GB
可以达到100TB
时效性
实时
时间的要求不严格
greenplum属于OLAP型的一种分布式的关系型数据库，应用于数据仓库，它的底层是基于开源的关系型数据库postgresql进行开发完成的，postgresql拥有丰富的数据类型，强容错能力及存储结构等优点，因而也一跃而上，成为目前主流的数据库之一，由于greenplum底层是postgresql的原因，因此greenplum也继承了postgresql的这些优点，并且两者之间进行数据迁移可以做到完全兼容，避免进行数据转换。
postgresql排名图：
结构
主从结构
greenplum采用一主(Master)多从(Segment)的结构，Master负责查询解析、优化及任务分发，Segment负责查询处理、数据存储，双方通过Interconnect通信，总体架构如下：
master节点：
是整个系统的控制中心和对外的服务接入点，它负责接收用户SQL请求，将SQL生成查询计划并进行并行处理优化，然后将查询计划分配(dispatch)到所有的Segment节点进行并行处理，协调组织各个Segment节点按照查询计划一步一步地进行并行处理，后获取到Segment的计算结果，再返回给客户端；从用户的角度看Greenplum集群，看到的只是Master节点,无需关心集群内部的机制，所有的并行处理都是在Master控制下自动完成的。Master节点一般只有一个或两个(互为备份)，主备方案实现高可用；
segment节点：
是Greenplum执行并行任务的并行运算节点，它接收Master的指令进行MPP并行计算，因此所有Segment节点的计算性能总和就是整个集群的性能，通过增加Segment节点，可以线性化得增加集群的处理性能和存储容量，Segment节点可以是1~10000个节点，它的数量决定greenplum的算力，可通过横向扩容提升整个数据库的算力及性能；
Interconnect：
是Master节点与Segment节点、Segment节点与Segment节点之间的数据传输组件，它基于千兆交换机或万兆交换机实现数据在节点间的高速传输；
无共享/MPP架构
Greenplum数据库软件将数据平均分布到系统的所有节点服务器上，所以节点存储每张表或表分区的部分行，所有数据加载和查询都是自动在各个节点服务器上并行运行，并且该架构支持扩展到上万个节点，做到数据完全的物理隔离。
Greenplum的架构采用了MPP(大规模并行处理)，在 MPP 系统中，每个 SMP节点也可以运行自己的操作系统、数据库等。换言之，每个节点内的 CPU 不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的，这个过程一般称为数据重分配(Data Redistribution) 。
SMP(SymmetricMulti-Processing)，对称多处理结构的简称，是指在一个计算机上汇集了一组处理器(多CPU),各CPU之间共享内存子系统以及总线结构。在这种技术的支持下，一个服务器系统可以同时运行多个处理器，并共享内存和其他的主机资源。传统的ORACLE和DB2均是此种类型，ORACLE RAC 是半共享状态；
与传统的SMP架构明显不同，通常情况下，MPP系统因为要在不同处理单元之间传送信息，所以它的效率要比SMP要差一点，但是这也不是的，因为 MPP系统不共享资源，因此对它而言，资源比SMP要多，当需要处理的事务达到一定规模时，MPP的效率要比SMP好。这就是看通信时间占用计算时间的比例而定，如果通信时间比较多，那MPP系统就不占优势了，相反，如果通信时间比较少，那MPP系统可以充分发挥资源的优势，达到高效率。
特性
greenplum是用于海量存储数据进行计算与分析的，它做数据分析跟计算时，往往所做的大量查询都是全表检索的模式进行的，是不建议添加索引的，而是用它分区、分布键的特性结合多个segment的并行将算力达到大化。
分区
分区是对存储的数据进行逻辑划分，通过 "partition by" 子句完成的，它允许将一个大表划分为多个子表。"subpartition by" 子句可以将子表划分为更小的表 。从理论上讲，Greenplum对于根表(root table)可以拥有多少级(level)或多少个分区表(partitioned table)并没有限制，但是对于任一级分区(表的层次结构级别)，一个分区表多可以有32,767个子分区表。
以时间为例，一个table表可以按字段month(月份)分区成table_01，table_02，... table_11，table_12，但都是在一个segment上。
分布键
与分区不同，分布键是进行物理划分，它是分布在不同的segment上，以指定的分布键字段或字段组合进行哈希/随机的策略分布，散布到不同的segment上，将数据平均分布到每一个节点机器上，为了避免数据倾斜导致算力不均，建议使用哈希策略进行分布，创建表使用 “distributed by(column，[…])” 子句。
同样以时间为例，t_test表中'2020-01-01'的数据散布在segment1的t_test_01表上，'2020-01-02'的数据散布在segment2的t_test_02表上 ...
create tablet_test
(
idint,month varchar(10),
namevarchar(64)
)distributed by (month)
partitionby range(month)
(
partition01 start ('2020-01-01') inclusive end ('2020-01-31') inclusive,
partition02 start ('2020-02-01') inclusive end ('2020-02-31') inclusive,
partition03 start ('2020-03-01') inclusive end ('2020-03-31') inclusive,
partition04 start ('2020-04-01') inclusive end ('2020-04-31') inclusive,
partition05 start ('2020-05-01') inclusive end ('2020-05-31') inclusive,
partition06 start ('2020-06-01') inclusive end ('2020-06-31') inclusive,
partition07 start ('2020-07-01') inclusive end ('2020-07-31') inclusive,
partition08 start ('2020-08-01') inclusive end ('2020-08-31') inclusive,
partition09 start ('2020-09-01') inclusive end ('2020-09-31') inclusive,
partition10 start ('2020-10-01') inclusive end ('2020-10-31') inclusive,
partition11 start ('2020-11-01') inclusive end ('2020-11-31') inclusive,default partition 12);
存储和执行
Master和Segment都是一个单独的PostgreSQL数据库。每一个都有自己单独的一套元数据字典。
Master节点一般也叫主节点，Segment叫做数据节点。
为了实现高可用，每个Segment都有对应的备节点 Mirror Segment分别存在与不同的机器上。
Client一般只能与Master节点进行交互，Client将SQL发给Master，然后Master对SQL进行分析后再将其分配给所有的Segment进行操作。
Greenplum没有Windows版本，只能安装在类UNIX的操作系统上。
Greenplumn极度消耗I/O资源，所以对存储的要求比较高。————————————————版权声明：本文为CSDN博主「火星天文學家」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/weixin_31002061/article/details/113514996
