关于java:为何选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 架构还是很多存储的抉择。