mpp并行数据库架构优缺点

MPP架构

MPP解决方案的较好原始想法就是消除共享资源。

每个执行器有单独的CPU，内存和硬盘资源。

一个执行器无法直接访问另一个执行器上的资源，除非通过网络上的受控的数据交换。这种资源独立的概念，对于MPP架构来说很完美的解决了可扩展性的问题。

MPP的排名较好个主要概念就是并行。

每个执行器运行着完全一致的数据处理逻辑，使用着本地存储上的私有数据块。

在不同的执行阶段中间有一些同步点(我的理解：了解Java Gc机制的，可以对比GC中stop-the-world,在这个同步点，所有执行器处于等待状态)，这些同步点通常被用于进行数据交换(像Spark和MapReduce中的shuffle阶段)。

MPP的设计缺陷

但是，这样的设计对于所有的MPP解决方案来说都有一个主要的问题——短板效应。如果一个节点总是执行的慢于集群中其他的节点，整个集群的性能就会受限于这个故障节点的执行速度(所谓木桶的短板效应)，无论集群有多少节点，都不会有所提高。

过往记忆大数据大多数情况下，除了Executor 7 其他的所有执行器都是空闲状态。

这是因为他们都在等待Executor 7执行完成后才能执行同步过程，这也是我们的问题的根本。所有的MPP系统都面临这样的问题。

如果你看一下Google的磁盘错误率统计报告，你就能发现观察到的AFR(annualized failure rate,年度故障率)在比较好情况下，磁盘在刚开始使用的3个月内有百分之二十会发生故障。

如果一个集群有1000个磁盘，一年中将会有20个出现故障或者说每两周会有一个故障发生。如果有2000个磁盘，你将每周都会有故障发生，如果有4000个，将每周会有两次错误发生。两年的使用之后，你将把这个数字乘以4，也就是说，一个1000个磁盘的集群每周会有两次故障发生。

事实上，在一个确定的量级，你的MPP系统将总会有一个节点的磁盘队列出现问题，这将导致该节点的性能降低，从而像上面所说的那样限制整个集群的性能。这也是为什么在这个世界上没有一个MPP集群是超过50个节点服务器的。