从架构特点到功能缺陷，重新认识分析型分布式数据库

MPP架构下，工作负载节点(对GPDB而言是Segment节点)是完全对称的，数据均匀的存储在这些节点，处理过程中每个节点(即该节点上的Executor)使用本地的CPU、内存和磁盘等资源完成本地的数据加工。这个架构虽然提供了较好的扩展性，但隐藏了极大的问题——Straggler，即当某个节点出现问题导致速度比其他节点慢时，该节点会成为Straggler。

此时，无论集群规模多大，批处理的整体执行速度都由Straggler决定，其他节点上的任务执行完毕后则进入空闲状态等待Straggler，而无法分担其工作。导致节点处理速度降低的原因多数是磁盘等硬件损坏，考虑到磁盘本身的一定故障率(根据Google统计前三个月内2%损坏率，第二年时达到8%)当集群规模达到一定程度时，故障会频繁出现使straggler成为一个常规问题。

并发

由于MPP的“完全对称性”，即当查询开始执行时，每个节点都在并行的执行完全相同的任务，这意味着MPP支持的并发数和集群的节点数完全无关。根据该文中的测试数据，4个节点的集群和400个节点的集群支持的并发查询数是相同的，随着并发数增加，这二者几乎在相同的时点出现性能骤降。

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

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

综上，大致可以得出结论，MPP(至少是GPDB)在集群规模上是存在一定限制的。

2000-2010年代，大多数股份制以上银行和少部分城商行都建立了数据仓库或ODS系统，主要采用了MPP产品。可以说，这十余年是MPP产品最辉煌的时代。到目前为止，MPP仍然是银行业建设数据仓库和数据集市类系统的主要技术选择。为了规避MPP并发访问上的缺陷以及批量任务对联机查询的影响，通常会将数据按照应用粒度拆分到不同的单体OLTP数据库中以支持联机查询。

2. Hadoop生态体系

MPP在相当长的一段时期内等同于一体机方案(以TD为代表)，其价格高昂到普通企业无法承受，多数在银行、电信等行业的头部企业中使用。2010年代，随着大数据时代的开启，Hadoop生态体系以开源优势，获得了蓬勃发展和快速普及。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!