greenplum 底层 mysql_分布式数据库greenplum详解

2023-03-17 00:00:00 数据 并行 数据库 节点 分布

前言

在数据库诞生到现在,我们所能耳熟能详的数据库如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

相关文章