本文属于专栏100个问题解决大数据理论系统。本专栏为作者原创。请注明参考资料的来源。请在评论区指出缺点和错误。非常感谢。

本专栏目录结构及文献参考请参见100个问题

MPP DB是一款 Shared Nothing架构的分布式并行结构化数据库集群具有高性能、高可用性和高扩展性。它可以为超大型数据管理提供一个具有成本效益的通用计算平台，并广泛应用于支持各种数据仓库系统BI系统和决策支持系统. 

从系统架构的角度来看，服务器应该如何分类？

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它声称可以扩展到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左右)的场景。