为何选MPP架构?

介绍

像Greenplum(GPDB),ClickHouse,Impala,Presto,Tidb,Greenplum衍生物AnalyticDB PostgreSQL(adbpg)等都是采用MPP架构的,采用MPP架构的很多OLAP引擎号称:亿级秒开,正因为MPP引擎逐渐表现出强大的高吞吐、低时延计算能力;

MPP即大规模并行处理结构,是由多台SMP服务器通过一定的节点互联网络进行连接,协同工作,完成相同的任务,从用户的角度来看是一个服务器系统。每个节点只访问自己的资源,所以是一种完全无共享(Shared Nothing)结构。

MPP结构扩展能力最强,它最早出现是为了解决关系型数据库扩展性差的问题,消除共享存储。由于MPP是多台SPM服务器连接的,每个节点都有独立的磁盘存储系统和内存系统每个节点的CPU不能访问另一个节点内存,所以也不存在异地访问的问题。

MPP架构图:

虽然MPP虽然具有扩展性,但是节点我理解实际上不会无限扩展,市面上MPP架构的集群规模也并不会太大;对于MPP架构来说,因为task和Executor是绑定的,如果某个Executor执行过慢或故障,将会导致整个集群的性能就会受限于这个故障节点的执行速度(所谓木桶的短板效应),所以MPP架构的最大缺陷就是——短板效应。另一点,集群中的节点越多,则某个节点出现问题的概率越大,而一旦有节点出现问题,对于MPP架构来说,将导致整个集群性能受限,所以一般实际生产中MPP架构的集群节点不易过多,这也是我们看到很多存储都有节点上限。再考虑硬件的损耗,维护成本居高不下。

架构特征&机制

MPP是多机可水平扩展的架构,符合“分布式”的基本要求;上面也说了每个节点只访问自己的资源,所以是一种完全无共享(Shared Nothing)架构。

一般来说,MPP架构特征:

  • 分布式计算;
  • 数据分布式存储(本地化);
  • 任务并行执行,
  • 一定的并发访问能力;
  • 横向扩展,支持集群节点的扩容;
  • Shared Nothing(完全无共享)架构。

GPDB具有较高的开源程度,通过分析他来分析MPP架构工作机制;GPDB属于主从架构,Slave称为Segment是主要的数据加工节点,是在PostgreSQL基础上的封装和修改,天然具备事务处理的能力,可进行水平扩展;集群内有唯一Active状态的Master节点,除了元数据存储和调度功能外,同时承担一定的工作负载,即所有外部对集群的数据联机访问都要经过Master节点;

在高可靠设计方面,首先设置了Standby Master节点,可以通过外部的HA监控模块发现并激活,在Master节点宕机时接管其任务,其次将Segment节点则细分为两类不同角色Primary和Mirror,后者是前者的备节点,数据提交时在两者间进行强同步,以此保证Primary宕机时,Mirror可以被调度起来接替前者的任务。

并发

由于MPP的“完全对称性”,即当查询开始执行时,每个节点都在并行的执行完全相同的任务,这意味着MPP支持的并发数和集群的节点数完全无关;看下面计算公式:rds_segment_expansion_coeff 并行最大倍数上限,是个默认固定值

通过外面的测试数据,几个节点的集群和上百个节点的集群支持的并发查询数是相同的,随着并发数增加,这二者几乎在相同的时点出现性能骤降。笔者在使用adbpg时候也发现了,随着节点的扩充,单个节点的并发数增加,在一定的时候,水位飙升,都会出现性能骤降情况;

传统MPP的联机查询主要面向企业管理层的少数用户,对并发能力的要求较低。而在大数据时代,数据的使用者从战略管理层转向战术执行层乃至一线人员,从孤立的分析场景转向与业务交易场景的融合。对于联机查询的并发能力已经远超传统MPP时代,这也是分布式数据库要考虑的一个重要问题。

除上述两点以外,通过adbpg来看,架构中的Master节点承担了一定的工作负载,所有联机查询的数据流都要经过该节点,这样Master也存在一定的性能瓶颈。同时,在实践中adbpg对数据库连接数量的管理也是非常谨慎的,虽然adbpg本身也支持了多master。Pivotal专家给出了一个建议的最大值且不会随着集群规模扩大而增大。

横向扩展

上面也提到了短板效应,相比MapReduce,MapReduce如果某个Executor执行过慢,那么这个Executor会慢慢分配到更少的task执行,批处理架构有个推测执行策略,推测出某个Executor执行过慢或者有故障,则在接下来分配task时就会较少的分配给它或者直接不分配;MPP后续结合这种能力融合进来,我理解会更加强大。

当然相比MapReduce,MPP架构性能上也是有很大优势的,它不需要将中间数据写入磁盘,因为一个单一的Executor只处理一个单一的task,因此可以简单直接将数据stream到下一个执行阶段。这个过程称为pipelining,它提供了很大的性能提升。

举个例子:要实现两个大表的join操作,对于批处理而言,如Spark将会写磁盘3次(第一次写入:表1根据join key进行shuffle;第二次写入:表2根据join key进行shuffle;第三次写入:Hash表写入磁盘), 而MPP只需要一次写入(Hash表写入)。这是因为MPP将mapper和reducer同时运行,而MapReduce将它们分成有依赖关系的tasks(DAG),这些task是异步执行的,因此必须通过写入中间数据共享内存来解决数据的依赖。

Share Nothing

数据库架构设计的三种模式:share nothing , share everythong , share disk

数据库构架设计中主要有Shared Everthting、Shared Nothing、和Shared Disk:

  • Shared Everthting:一般是针对单个主机,完全透明共享CPU/MEMORY/IO,并行处理能力是最差的,典型的代表SQLServer
  • Shared Disk:各个处理单元使用自己的私有 CPU和Memory,共享磁盘系统。典型的代表Oracle Rac, 它是数据共享,可通过增加节点来提高并行处理的能力,扩展能力较好。其类似于SMP(对称多处理)模式,但是当存储器接口达到饱和的时候,增加节点并不能获得更高的性能 。
  • Shared Nothing:各个处理单元都有自己私有的CPU/内存/硬盘等,不存在共享资源,类似于MPP(大规模并行处理)模式,各处理单元之间通过协议通信,并行处理和扩展能力更好。典型代表DB2 DPF和Hadoop ,各节点相互独立,各自处理自己的数据,处理后的结果可能向上层汇总或在节点间流转。我们常说的 Sharding 其实就是Share Nothing架构,它是把某个表从物理存储上被水平分割,并分配给多台服务器(或多个实例),每台服务器可以独立工作,具备共同的schema,比如MySQL Proxy和Google的各种架构,只需增加服务器数就可以增加处理能力和容量。最后总的来说,MPP架构或许也有短板效应,现在也有方案解决,比如HAQW, 但凭借着在一定大数据下强大的高吞吐、低时延计算能力等,相比而言MPP架构还是很多存储的选择。

你可能感兴趣的:(java数据库框架)