MPPDB是什么？

写在前面

本文隶属于专栏《100个问题搞定大数据理论体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和文献引用请见100个问题搞定大数据理论体系

解答

MPP DB是一款 Shared Nothing架构的分布式并行结构化数据库集群，具备高性能、高可用、高扩展特性，可以为超大规模数据管理提供高性价比的通用计算平台，并广泛地用于支撑各类数据仓库系统、BI系统和決策支持系统.

补充

MPP

详情请见我的另一篇博客——从系统架构角度出发，服务器该如何分类？

MPP DB特征

1. 低硬件成本：完全使用 x86 架构的 PC Server，不需要昂贵的 Unix 服务器和磁盘阵列；
2. 集群架构与部署：完全并行的 MPP + Shared Nothing 的分布式架构，采用 Non-Master 部署，节点对等的扁平结构；
3. 海量数据分布压缩存储：可处理 PB 级别以上的结构化数据，采用 hash分布、random 存储策略进行数据存储；同时采用先进的压缩算法，减少存储数据所需的空间，可以将所用空间减少 1~20 倍，并相应地提高 I/O 性能；
4. 数据加载高效性：基于策略的数据加载模式，集群整体加载速度可达2TB/h；
5. 高扩展、高可靠：支持集群节点的扩容和缩容，支持全量、增量的备份/恢复;
6. 高可用、易维护：数据通过副本提供冗余保护，自动故障探测和管理，自动同步元数据和业务数据。提供图形化工具，以简化管理员对数据库的管理工作；
7. 高并发：读写不互斥，支持数据的边加载边查询，单个节点并发能力大于 300 用户；
8. 行列混合存储：提供行列混合存储方案，从而提高了列存数据库特殊查询场景的查询响应耗时；
9. 标准化：支持SQL92 标准，支持 C API、ODBC、JDBC、ADO.NET 等接口规范。

MPP DB 适用场景

如果从性能来讲， MPP DB在多维复杂查询方面的性能确实要好于Hive、 Hbase、 Impala等，因此有不少人认为， MPP DB是适合这种场景的未来解决方案。

MPP DB看似对多维度复杂查询性能较好，但是它有两个致命的缺点，大家在选型的时候不得不考虑。

扩展性

MPP DB号称能扩展到1000个节点以上，但在实际应用中不超过100个节点，如在支付宝中用Greenplum来做财务数据分析的一个最大集群只有60多台机器。

MPP DB扩展性不好有很多原因，最根本的原因是架构本身。

MPP DB是基于原DB扩展而来的，DB中天然追求一致性( Consistency)，必然会带来分区容错性较差。

当集群规模变得太大、业务数据太多时， MPP DB的元数据管理就完全是一个灾难。元数据巨大无比，一旦出错，将很难恢复。

所以 MPP DB要在扩展性上有质的提升，就要对元数据及数据存储有架构上的突破，降低对一致性的要求，否则很难相信一个MPP DB数据库是易于扩展的。

并发的支持

一个査询系统设计出来就是供用户使用的，所以能支持的并发数越多越好。

MPP DB的核心原理是将一个大的査询通过分解为一个个子查询，分布到底层执行，最后再合并结果，也就是通过多线程并发来暴力扫描以实现高速。

这种暴力扫描的方法对单个查询来说动用了整个系统的能力，所以单个查询比较快，但同时带来用力过猛的问题，整个系统能支持的并发数必然不多。

从目前的实际经验来看，也就支持50~100的并发能力。

当前 Hbase和 Impala在应对复杂查询时，也是通过全盘扫描的方法来实现的，在这种场景下， 硬盘数量越多越好，转速越快越好。

Hbase为什么号称支持上千并发，这也是在特定的场景下(查询时带用户标识，即带row key)才能实现的。在复杂的查询场景下，任何系统都将崩溃。

所以， MPP DB目前更适合小集群(100以内)、低并发(50左右)的场景。