greenplum数据库引擎探究
时间:2010-10-13 来源:大肚熊
Greenplum做为新一代的数据库引擎,有着良好的发展与应用前景。强大的工作效率,低成本的硬件平台对数据仓库与商业智能建设有很大的吸引力。要清楚的了解其特点最好从架构着手。
架构分析
Greenplum的高性能得益于其良好的体系结构。Greenplum的架构采用了MPP(大规模并行处理)。在 MPP 系统中,每个 SMP 节点也可以运行自己的操作系统、数据库等。换言之,每个节点内的 CPU 不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的,这个过程一般称为数据重分配 (Data Redistribution) 。与传统的SMP架构明显不同,通常情况下,MPP系统因为要在不同处理单元之间传送信息,所以它的效率要比SMP要差一点,但是这也不是绝对的,因为MPP系统不共享资源,因此对它而言,资源比SMP要多,当需要处理的事务达到一定规模时,MPP的效率要比SMP好。这就是看通信时间占用计算时间的比例而定,如果通信时间比较多,那MPP系统就不占优势了,相反,如果通信时间比较少,那MPP系统可以充分发挥资源的优势,达到高效率。当前使用的OTLP程序中,用户访问一个中心数据库,如果采用SMP系统结构,它的效率要比采用MPP结构要快得多。而MPP系统在决策支持和数据挖掘方面显示了优势,可以这样说,如果操作相互之间没有什么关系,处理单元之间需要进行的通信比较少,那采用MPP系统就要好,相反就不合适了。
Shared nothing架构
常见的OLTP数据库系统常常采用shared everything架构来做集群,例如oracle RAC架构,数据存储共享,节点间内存可以相互访问。
Oracle RAC架构
Greenplum是一种基于postgresql(开源数据库)的分布式数据库。其采用shared nothing架构(MPP),主机,操作系统,内存,存储都是自我控制的,不存在共享。主要由master host,segment host,interconnect三大部分组成。
Greenplum架构图
了解完Greenplum的架构后,对其工作流程也就相对简单了。因greenplum采用了MPP架构,其主要的优点是大规模的并行处理能力,应该把精力主要放在大规模存储与并行处理两个方面。
大规模存储
Greenplum数据库通过将数据分布到多个节点上来实现规模数据的存储。数据库的瓶颈经常发生在I/O方面,数据库的诸多性能问题最终总能归罪到I/O身上,久而久之,IO瓶颈成为了数据库性能的永恒的话题。
Greenplum采用分而治之的办法,将数据规律的分布到节点上,充分利用segment主机的IO能力,以此让系统达到最大的IO能力(主要是带宽)。
在greenplum中每个表都是分布在所有节点上的。Master host首先通过对表的某个或多个列进行hash运算,然后根据hash结果将表的数据分布到segment host中。整个过程中master host不存放任何用户数据,只是对客户端进行访问控制和存储表分布逻辑的元数据。
并行处理
Greenplum的并行处理主要体现在外部表并行装载,并行备份恢复与并行查询处理三个方面。
数据仓库的主要精力一般集中在数据的装载和查询,数据的并行装载主要是在采用外部表或者web表方式,通常情况下通过gpfdist来实现。
Gpfidist架构
Gpfdist程序能够以370MB/s装载text格式的文件和200MB/s装载CSV格式文件,ETL带宽为1GB的情况下,我们可以运行3个gpfdist程序装载text文件,或者运行5个gpfdist程序装载CSV格式文件。例如图例中采用了2个gpfdist程序进行数据装载。可以根据实际的环境通过配置postgresql.conf参数文件来优化装载性能。
查询性能的强弱往往由查询优化器的水平来决定,greenplum主节点负责解析SQL与生成执行计划。Greenplum的执行计划生成同样采用基于成本的方式,基于数据库是由诸多segment实例组成,在选择执行计划时主节点还要综合考虑节点间传送数据的代价。
工作原理:
在主节点上存在query dispatcher (QD)进程,该进程前期负责查询计划的创建和调度,segment instance返回结果后,该进程再进行聚合与向用户展示;segment host存在query executor (QE)进程,该进程负责其它节点相互通信与执行QD调度的执行计划。
Greenplum最为一个严格的数据库系统,同样支持线性扩展,高可用性架构,数据与主机的容错机制,还有数据的分区与压缩功能。
想要充分的发挥出greenplum的性能,还要对greenplum的运行机制有更加深入的了解。<欢迎大家一起讨论>