分布式数据库greenplum详解
前⾔
  在数据库诞⽣到现在，我们所能⽿熟能详的数据库如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 table t_test
(
id int,
month varchar(10),
name varchar(64)
) distributed by (month)
partition by range(month)
(
partition 01 start ('2020-01-01') inclusive end ('2020-01-31') inclusive,
partition 02 start ('2020-02-01') inclusive end ('2020-02-31') inclusive,
partition 03 start ('2020-03-01') inclusive end ('2020-03-31') inclusive,
partition 04 start ('2020-04-01') inclusive end ('2020-04-31') inclusive,
partition 05 start ('2020-05-01') inclusive end ('2020-05-31') inclusive,
partition 06 start ('2020-06-01') inclusive end ('2020-06-31') inclusive,
partition 07 start ('2020-07-01') inclusive end ('2020-07-31') inclusive,
partition 08 start ('2020-08-01') inclusive end ('2020-08-31') inclusive,
partition 09 start ('2020-09-01') inclusive end ('2020-09-31') inclusive,
partition 10 start ('2020-10-01') inclusive end ('2020-10-31') inclusive,
partition 11 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资源，所以对存储的要求⽐较⾼。greenplum数据库

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。