MPP DB 是 大数据及时说明体系

大数据规模，及时说明体系（在线查询）是最常见的一种场景，前面写了一个《 及时说明体系 (HIVE/HBASE/IMPALA) 浅析 》接头业界当前常见的方案。互联网公司用得较量多是 HIVE/HBASE ，如腾讯基于 HIVE 深度定制改革，更名为 TDW ，小米等公司选用 HBASE 等。关于 HIVE/HBASE/IMPALA 先容等可以看我前面的文章。

当前在及时说明体系中，最难的是多维度伟大查询，今朝没有一个很好的办理方案，这两天和人接头到 MPP?DB （漫衍式数据库，以 Greenplum 为最典范代表）。假如从机能来讲， MPP?DB 在多维伟大查询机能确实要好于 HIVE/HBASE/IMPALA 等，因此有不少声音以为， MPP?DB 是得当这种场景的将来的办理方案。 MPP?DB 看似对多维度伟大查询机能较好，可是同时有两个致命的弱点，各人选型的时辰不得不思量：

1、 扩展性：

MPP?DB 都号称都能扩展到 1000 个节点以上，现着实应用进程中，就我今朝从果真资料看到的不高出 100 个节点，如付出宝顶用 Greenplum 来做财政数据说明的最大一个集群 60 多台呆板。其它和 Greenplum 公司交换，在广东移动最大的用来做数据存储的，也就 100 台以内。这和 hadoop 动不动 4,5 千个节点一个节点集群的确不在一个数目级上。

为什么 MPP?DB 扩展性欠好？

有许多缘故起因，有产物成熟度，也有应用广度的题目，可是最基础的照旧架构自己的题目。讲到架构这里就要先讲下 CAP 原则：

Consistency( 同等性 ),? 数据同等更新，全部数据变换都是同步的
Availability( 可用性 ),? 好的相应机能
Partition?tolerance( 分区容错性 )? 靠得住性

定理：任何 漫衍式 体系只可同时满意二点，没法三者分身。
忠告：架构师不要将精神挥霍在怎样计划能满意三者的美满 漫衍式 体系，而是应该举办弃取。

MPP?DB 照旧基于原 DB 扩展而来， DB 内里自然追求同等性（ Consistency ），肯定带来分区容错性较差。集群局限变得太大，营业数据太多时， MPP?DB 的元数据打点就完满是一个劫难。元数据庞大无比，一旦堕落很难规复，动不动导致毁库。

以是 MPP?DB 要在扩展性上有质的提醒，要对元数据，以及数据存储有架构上的打破，低落对同等性的要求，这样扩展性才气晋升，不然的话很难信托一个 MPP?DB 数据库是可以轻易扩展的。

2、 并发的支持：

一个查询体系，计划出来就是提供人用的，以是能支持的同时并发越高越好。 MPP?DB 焦点道理是一 个大的查询通过说明为逐一个子查询，漫衍到底层的执行，最后再归并功效，说白了就是通过多线程并发来暴力 SCAN 来实现高速。 这种暴力 SCAN的要领，对单个查询来说，动用了整个体系的手段，单个查询较量快，但同时带来用力过猛的题目，整个体系能支持的并发肯定不高，从今朝现实行使的履素来说，也就支持50～100的并发手段。

当前HBASE/IMPALA应对伟大查询时，也是通过通盘SCAN的要领来实现的，这种场景下，硬盘数目越多越好，转速越快越好。HBASE为什么号称支持上千并发，这也是在特定的场景下（查询时带用户标示，即带row?key)才气实现的，伟大查询场景下，什么体系都歇菜。

以是MPP?DB应用场景已经很是明明晰，得当小集群（100以内），低并发的（50阁下）的场景。MPP?DB将来是不是趋势，我不知道，可是至少今朝来看，用MPP?DB来应对大数据的及时说明体系长短常吃力的。

（编辑：湖南网）

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