设为首页 收藏本站
查看: 1293|回复: 0

[经验分享] greenplum数据库引擎探究

[复制链接]

尚未签到

发表于 2016-11-22 09:33:51 | 显示全部楼层 |阅读模式
  Greenplum做为新一代的数据库引擎,有着良好的发展与应用前景。强大的工作效率,低成本的硬件平台对数据仓库与商业智能建设有很大的吸引力。要清楚的了解其特点最好从架构着手。 DSC0000.gif
  架构分析
  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架构,数据存储共享,节点间内存可以相互访问。
   DSC0001.gif
                                         Oracle RAC架构
  Greenplum是一种基于postgresql(开源数据库)的分布式数据库。其采用shared nothing架构(MPP),主机,操作系统,内存,存储都是自我控制的,不存在共享。主要由master host,segment host,interconnect三大部分组成。
   DSC0002.png
                                                Greenplum架构图
  了解完Greenplum的架构后,对其工作流程也就相对简单了。因greenplum采用了MPP架构,其主要的优点是大规模的并行处理能力,应该把精力主要放在大规模存储与并行处理两个方面。
  大规模存储
  Greenplum数据库通过将数据分布到多个节点上来实现规模数据的存储。数据库的瓶颈经常发生在I/O方面,数据库的诸多性能问题最终总能归罪到I/O身上,久而久之,IO瓶颈成为了数据库性能的永恒的话题。
  Greenplum采用分而治之的办法,将数据规律的分布到节点上,充分利用segment主机的IO能力,以此让系统达到最大的IO能力(主要是带宽)。
  在greenplum中每个表都是分布在所有节点上的。Master host首先通过对表的某个或多个列进行hash运算,然后根据hash结果将表的数据分布到segment host中。整个过程中master host不存放任何用户数据,只是对客户端进行访问控制和存储表分布逻辑的元数据。
   DSC0003.png
  并行处理
  Greenplum的并行处理主要体现在外部表并行装载,并行备份恢复与并行查询处理三个方面。
  数据仓库的主要精力一般集中在数据的装载和查询,数据的并行装载主要是在采用外部表或者web表方式,通常情况下通过gpfdist来实现。
   DSC0004.png
                                                    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调度的执行计划。
DSC0005.png
Greenplum最为一个严格的数据库系统,同样支持线性扩展,高可用性架构,数据与主机的容错机制,还有数据的分区与压缩功能。
想要充分的发挥出greenplum的性能,还要对greenplum的运行机制有更加深入的了解。<欢迎大家一起讨论>

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-303829-1-1.html 上篇帖子: Hibernate的generator属性之意义 下篇帖子: Visual Entity 下载列表(最新版为 2.0.0 ,已支持Visual Studio 2013)
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表