MPP DB技术分类

随着数据量的增大,传统数据库如Oracle、MySQL、PostgreSQL等单实例模式将无法支撑大量数据的处理,数据仓库采用分布式技术成为自然的选择。

6.2.1 MPP的概念

在讨论MPP DB之前,我们先把MPP本身的概念搞清楚。MPP是系统架构角度的一种服务器分类方法。

从系统架构来看,目前的商用服务器大体可以分为三类,即对称多处理器结构(Symmetric Multi-Processor,SMP)、非一致存储访问结构(Non-Uniform Memory Access,NUMA),以及海量并行处理结构(Massive Parallel Processing,MPP)。它们的特征分别描述如下。

1.SMP(Symmetric Multi-Processor)

所谓对称多处理器结构,是指服务器中的多个CPU对称工作,无主次或从属关系。各CPU共享相同的物理内存,每个CPU访问内存中的任何地址所需时间是相同的,因此SMP也被称为一致存储器访问结构(Uniform Memory Access,UMA)。对SMP服务器进行扩展的方式包括增加内存、使用更快的CPU、增加CPU、扩充I/O(槽口数与总线数)及添加更多的外部设备(通常是磁盘存储)。

SMP服务器的主要特征是共享,系统中的所有资源(如CPU、内存、I/O等)都是共享的。也正是由于这种特征,导致了SMP服务器的主要问题,即它的扩展能力非常有限。对于SMP服务器而言,每个共享的环节都可能造成SMP服务器扩展时的瓶颈,而最受限制的则是内存。由于每个CPU必须通过相同的内存总线访问相同的内存资源,因此,随着CPU数量的增加,内存访问冲突将迅速增加,最终造成CPU资源的浪费,使CPU性能的有效性大大降低。实验证明,SMP服务器CPU利用率最好的情况是2~4个CPU,如图6.1所示。

图6.1

2.NUMA(Non-Uniform Memory Access)

由于SMP在扩展能力上的限制,人们开始探究如何进行有效的扩展从而构建大型系统的技术,NUMA就是这种努力下的结果之一。利用NUMA技术,可以把几十个CPU(甚至上百个CPU)组合在一台服务器内。其CPU模块结构如图6.2所示。

图6.2

NUMA服务器的基本特征是拥有多个CPU模块,每个CPU模块由多个CPU(如4个)组成,并且具有独立的本地内存、I/O槽口等。由于其节点之间可以通过互联模块(如称为CrossbarSwitch)进行连接和信息交互,因此,每个CPU可以访问整个系统的内存(这是NUMA系统与MPP系统的重要区别)。显然,访问本地内存的速度将远远高于访问异地内存(系统内其他节点的内存)的速度,这也是非一致存储访问NUMA的由来。由于这个特点,为了更好地发挥系统性能,开发应用程序时需要尽量减少不同CPU模块之间的信息交互。利用NUMA技术,可以较好地解决原来SMP系统的扩展问题,在一台物理服务器内可以支持上百个CPU。比较典型的NUMA服务器包括惠普的Superdome、SUN15K、IBMp690等。

但NUMA技术同样有一定的缺陷,由于访问异地内存的时延远远超过访问本地内存,因此,当CPU数量增加时,系统性能无法线性增加。如惠普公司发布Superdome服务器时,曾公布了它与惠普其他UNIX服务器的相对性能值,结果发现,64路CPU的Superdome服务器(NUMA结构)的相对性能值是20,而8路N4000(共享的SMP结构)的相对性能值是6.3。从这个结果可以看出,8倍数量的CPU换来的只是3倍性能的提升。

3.MPP(Massive Parallel Processing)

和NUMA不同,MPP提供了另外一种进行系统扩展的方式,它由多台SMP服务器通过一定的节点互联网络进行连接,协同工作,完成相同的任务,从用户角度来看是一个服务器系统。其基本特征是由多台SMP服务器(每台SMP服务器称为节点)通过节点互联网络连接而成,每个节点只访问自己的本地资源(内存、存储等),是一种完全无共享(Share Nothing)结构,因而扩展能力最强,理论上可以无限扩展,目前的技术可以实现512个节点互联,包含数千个CPU。目前业界对节点互联网络暂无标准,如NCR的Bynet、IBM的SPSwitch,它们都采用了不同的内部实现机制。但节点互联网络仅供MPP服务器内部使用,对用户而言是透明的。

在MPP系统中,每个SMP节点也可以运行自己的操作系统、数据库等。但和NUMA不同的是,它不存在异地内存访问的问题。换言之,每个节点内的CPU不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的,这个过程一般称为数据重分配(Data Redistribution)。

但是MPP服务器需要一种复杂的机制来调度和平衡各个节点的负载和并行处理过程。目前,一些基于MPP技术的服务器往往通过系统级软件(如数据库)来屏蔽这种复杂性。举例来说,NCR的Teradata就是基于MPP技术的一个关系数据库软件,基于此数据库来开发应用时,不管后台服务器由多少个节点组成,开发人员所面对的都是同一个数据库系统,而无须考虑如何调度其中某几个节点的负载。

4.NUMA与MPP的区别

从架构来看,NUMA与MPP有许多相似之处:它们都由多个节点组成;每个节点都有自己的CPU、内存、I/O;节点之间都可以通过节点互联机制进行信息交互。那么二者的区别在哪里?通过分析NUMA和MPP服务器的内部架构与工作原理不难发现其差异所在。

首先是节点互联机制不同。NUMA的节点互联机制是在同一台物理服务器内部实现的,当某个CPU需要进行异地内存访问时,它必须等待,这也是NUMA服务器无法实现CPU增加时性能线性扩展的主要原因。而MPP的节点互联机制是在不同的SMP服务器外部通过I/O实现的,每个节点只访问本地内存和存储,节点之间的信息交互与节点本身的处理是并行进行的。因此,MPP在增加节点时,其性能基本上可以实现线性扩展。

其次是内存访问机制不同。在NUMA服务器内部,任何一个CPU都可以访问整个系统的内存,但异地内存访问的性能远远低于本地内存访问,因此,在开发应用程序时应该尽量避免异地内存访问。而在MPP服务器中,每个节点只访问本地内存,不存在异地内存访问的问题。

5.数据仓库的选择

哪种服务器更加适应数据仓库环境?这需要从数据仓库环境本身的负载特征入手。众所周知,典型的数据仓库环境具有大量复杂的数据处理和综合分析,要求系统具有很高的I/O处理能力,并且存储系统需要提供足够的I/O带宽与之匹配。而一个典型的OLTP系统则以联机事务处理为主,每次交易所涉及的数据不多,要求系统具有很高的事务处理能力,能够在单位时间里处理尽量多的交易。显然,这两种应用环境的负载特征完全不同。

从NUMA架构来看,它可以在一台物理服务器内集成多个CPU,使系统具有较高的事务处理能力,但由于异地内存访问时延远长于本地内存访问,因此需要尽量减少不同CPU模块之间的数据交互。显然,NUMA架构更适用于OLTP事务处理环境,当用于数据仓库环境时,由于大量复杂的数据处理必然导致大量的数据交互,将使CPU的利用率大大降低。

相对而言,MPP服务器架构的并行处理能力更优越,更适合复杂的数据综合分析与处理环境。当然,它需要借助支持MPP技术的关系数据库系统来屏蔽节点之间负载平衡与调度的复杂性。另外,这种并行处理能力也与节点互联网络有很大的关系。显然,适应数据仓库环境的MPP服务器,其节点互联网络的I/O性能应该非常突出,这样才能充分发挥整个系统的性能。

6.MPP数据仓库架构分类

前面讲到MPP架构非常复杂,通常用到数据库系统来屏蔽节点间的负载平衡和调度的复杂性。在数据库架构设计中,又有多种架构,主要分为Share Disk和Share Nothing。

(1)Share Disk:各个处理单元使用自己的私有CPU和Memory,共享磁盘系统。典型代表是OracleRac,它共享数据,可以通过增加节点来提高并行处理能力,扩展能力较好。处理节点采用的是MPP架构,但是需要共享一套磁盘系统,因此,当存储器接口达到饱和的时候,增加节点并不能获得更高的性能。

(2)Share Nothing:各个处理单元都有自己私有的CPU、内存、硬盘等,不存在共享资源,类似于MPP(大规模并行处理)模式,各处理单元之间通过协议通信,并行处理和扩展能力更好。典型代表是DB2 DPF版本和Greenplum,各节点相互独立,各自处理自己的数据,处理后的结果可能向上层汇总或在节点间流转。

我们常说的Sharding其实就是Share Nothing架构,它把某张表从物理存储上水平分割,并分配给多台服务器(或多个实例),每台服务器可以独立工作,具备共同的Schema,如MySQL Proxy和Google的各种架构,只需增加服务器数量就可以增加处理能力和容量。

Share Nothing因为数据尤其是元数据存储在不同的服务器上,所以对各台服务器间的元数据同步及故障恢复来说是一个灾难。相对而言,Share Disk不存在同步问题,计算节点故障后简单复位就可以恢复工作,但是存在共享存储导致的存储瓶颈问题。

本文选自本人新作《大数据架构详解:从数据获取到深度学习》6.2.1节。

原文发布于微信公众号 - 大数据和云计算技术(jiezhu2007)

原文发表时间:2017-03-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏网络研发技术

如何防订单重复提交策略方法

#### [原文链接:https://www.cnblogs.com/jett010/articles/9056567.html](https://www.cn...

820
来自专栏IT技术精选文摘

分布式系统一致性保障方案总结

引言 在互联网系统中,理想的情况下,肯定是希望系统能够同时满足“一致性”、“可用性”和“分区容忍性”。 但是基于熟悉的CAP定律也好,还是BASE理论, 我们知...

25310
来自专栏SDNLAB

ONOS高可用性和可扩展性实现初探

ONOS的发布直面OpenDaylight 进行挑战,直接将 SDN领域两大阵营(运营商和设备商)的竞争瞬间升级,之所以 ONOS能做到这一点,首先,ONOS的...

2475
来自专栏QQ音乐技术团队的专栏

如何设计一个可靠的消息系统

全民K歌的消息包含两种:一种是用户作品相关的消息汇聚,用户所有作品的评论、送礼等,按照时间线纵向给用户聚合起来。一种是横向用户与用户之间的交流信息,提供类似QQ...

24210
来自专栏Java职业技术分享

zookeeper-架构设计与角色分工-《每日五分钟搞定大数据》

zookeeper作为一个分布式协调系统,很多组件都会依赖它,那么此时它的可用性就非常重要了,那么保证可用性的同时作为分布式系统的它是怎么保证扩展性的?问题很多...

760
来自专栏JAVA高级架构

一个高性能、轻量级的分布式内存队列系统--beanstalk

Beanstalk是一个高性能、轻量级的、分布式的、内存型的消息队列系统。最初设计的目的是想通过后台异步执行耗时的任务来降低高容量Web应用系统的页面访问延迟。...

3439
来自专栏小狼的世界

SRE学习笔记:分布式共识系统、Paxos协议

日常工作中,我们经常需要一些服务分布式的运行。跨区域如跨城、跨洲部署运行分布式系统往往是容易的,但是如何保证各系统间状态的一致是困难的。如何保证服务的高可靠、高...

621
来自专栏JAVA高级架构

历经8年双11流量洗礼,淘宝开放平台如何攻克技术难关?

淘宝开放平台(open.taobao.com)是阿里系统与外部系统通讯的最重要平台,每天承载百亿级的API调用,百亿级的消息推送,十亿级的数据同步,经历了8年双...

682
来自专栏美团技术团队

服务容错模式

背景 随着美团点评服务框架和服务治理体系的逐步成熟,服务化已成为公司内部系统设计的趋势。本着大系统小做、职责单一的原则,我们度假技术团队对业务系统进行了不少服务...

3534
来自专栏take time, save time

三十天学不会TCP,UDP/IP网络编程 -- TCP中的智慧之连续ARQ

突然发现上一篇文章贴图有问题,关键我怎么调也调不好,为了表达歉意,我再贴一篇gitbook上的吧,虽然违背了我自己的隔一篇在这里发一次的潜规则~其余完整版可以去...

34310

扫码关注云+社区