其实MPP架构的关系型数据库与Hadoop的理论基础是极其相似的,都是将运算分布到节点中独立运算后进行结果合并。个人觉得区别仅仅在于前者跑的是SQL,后者底层处理则是MapReduce程序。
但是我们会经常听到对于MPP而言,虽说是宣称也可以横向扩展Scale OUT,但是这种扩展一般是扩到100左右,而Hadoop一般可以扩展1000+,这也是经常被大家拿来区分这两种技术的一个说词。这是为什么呢?其实可以从CAP理论上来找到一些理由。因为MPP始终还是DB,一定要考虑C(Consistency),其次考虑 A(Availability),最后才在可能的情况下尽量做好P(Partition-tolerance)。而Hadoop就是为了并行处理和存储设计的,所有数据都是以文件存储,所以优先考虑的是P,然后是A,最后再考虑C。所以后者的可扩展性当然好于前者。
以下几个方面制约了MPP数据库的扩展
1、高可用:MPP DB是通过Hash计算来确定数据行所在的物理机器(而Hadoop无需此操作),对存储位置的不透明导致MPP的高可用很难办。
2、并行任务:数据是按照Hash来切分了,但是任务没有。每个任务,无论大小都要到每个节点去走一圈。
3、文件系统:数据切分了,但是文件数没有变少,每个表在每个节点上一定有一到多个文件。同样节点数越多,存储的表就越多,导致每个文件系统上有上万甚至十万多个文件。
4、网络瓶颈:MPP强调对等的网络,点对点的连接也消耗了大量的网络带宽,限制了网络上的线性扩展(想象一台机器可能要给1000台机器发送信息)。更多的节点并没有提供更高的网络带宽,反而导致每个组节点间平均带宽降低。
5、其他关系数据库的枷锁:比如锁、日志、权限、管理节点瓶颈等均限制了MPP规模的扩大。
但是MPP数据库有对SQL的完整兼容和一些事务处理功能,对于用户来说,在实际的使用场景中,如果数据扩展需求不是特别大,需要的处理节点不多,数据都是结构化数据,习惯使用传统RDBMS的很多特性的场景,可以考虑MPP如Greenplum/Gbase等。
但是如果有很多非结构化数据,或者数据量巨大,有需要扩展到成百上千个数据节点需求的,这个时候Hadoop是更好的选择。
其实MPP架构的关系型数据库与Hadoop的理论基础是极其相似的,都是将运算分布到节点中独立运算后进行结果合并。个人觉得区别仅仅在于前者跑的是SQL,后者底层处理则是MapReduce程序。
但是我们会经常听到对于MPP而言,虽说是宣称也可以横向扩展Scale OUT,但是这种扩展一般是扩到100左右,而Hadoop一般可以扩展1000+,这也是经常被大家拿来区分这两种技术的一个说词。
这是为什么呢?其实可以从CAP理论上来找到一些理由。因为MPP始终还是DB,一定要考虑C(Consistency),其次考虑 A(Availability),最后才在可能的情况下尽量做好P(Partition-tolerance)。而Hadoop就是为了并行处理和存储设计的,所有数据都是以文件存储,所以优先考虑的是P,然后是A,最后再考虑C。所以后者的可扩展性当然好于前者。
以下几个方面制约了MPP数据库的扩展
1、高可用:MPP DB是通过Hash计算来确定数据行所在的物理机器(而Hadoop无需此操作),对存储位置的不透明导致MPP的高可用很难办。
2、并行任务:数据是按照Hash来切分了,但是任务没有。每个任务,无论大小都要到每个节点去走一圈。
3、文件系统:数据切分了,但是文件数没有变少,每个表在每个节点上一定有一到多个文件。同样节点数越多,存储的表就越多,导致每个文件系统上有上万甚至十万多个文件。
4、网络瓶颈:MPP强调对等的网络,点对点的连接也消耗了大量的网络带宽,限制了网络上的线性扩展(想象一台机器可能要给1000台机器发送信息)。更多的节点并没有提供更高的网络带宽,反而导致每个组节点间平均带宽降低。
5、其他关系数据库的枷锁:比如锁、日志、权限、管理节点瓶颈等均限制了MPP规模的扩大。
但是MPP数据库有对SQL的完整兼容和一些事务处理功能,对于用户来说,在实际的使用场景中,如果数据扩展需求不是特别大,需要的处理节点不多,数据都是结构化数据,习惯使用传统RDBMS的很多特性的场景,可以考虑MPP如Greenplum/Gbase等。
但是如果有很多非结构化数据,或者数据量巨大,有需要扩展到成百上千个数据节点需求的,这个时候Hadoop是更好的选择。
具体的不同
特性 | Hadoop | MPP数据仓库 |
计算节点数 | 可到数千个 | 一般1000个以内 |
数据量 | 支持大于10P | 一般不大于10P |
数据类型 | 关系型,半关系型,无结构化,语音,图像,视频 | 关系型 |
时延 | 中/高 | 低(但还是要看数据量和维度的数量) |
应用生态 | 创新型/人工智能 | 传统数据库型/BI类 |
应用开发接口 | SQL,MR,丰富的编程语言接口 | 标准数据库SQL |
可扩展性 | 无穷的可能,完整的编程接口 | 有限扩展能力,主要通过UDF支持 |
事务支持 | 有限 | 完整 |
价格 | 低 | 高 |
网友回复