HadoopDB

首先思考一个问题:针对弱关系型数据的数据仓库解决方案会是怎样的?

耶鲁大学的这个 HadoopDB 研究项目挺有意思。这是个并行 DBMS(PostgreSQL) 技术和 MapReduce 的结合的产物。

HadoopDB_Arch.jpg
(上图来源)

上图中的 SMS 是 “SQL to MapReduce to SQL” 的缩写。这是 HadoopDB 的一个设计难点。经过了两层转换,对于 SQL 执行的效率多少会是个问题。

也可以对比一下 Facebook 的 Hive :
HiveDB.jpg

说起 DBMS 和 MapReduce 结合,自然要提起 GreenPlum, 原来是 Hadoop 的间接竞争对手,现在变成直接的了。相比来说,GreenPlum 要更成熟一些。HadoopDB 毕竟是学院派的东西。

GreenPlum_GPDB_Arch.jpg

二者都是典型的 Share-Nothing 结构。类似 Oracle 集群的 Share-Storage 的模式现在已经有点过时了。更多混搭出来的技术解决方案让人喜忧参半,喜的是有很多东西可以选择,忧的是你不知道哪个项目生命期更长久。

EOF


  • Anonymous

    和greenplum的思路差不多吧
    这种DB商用也不怎么看好吧
    MPP的节点多了之后
    master node的管理成本是几何级数的增加

  • Fenng

    管理成本 其实未必增加,
    要看软件实现的如何

  • http://brisbane.at9t.com/ 布里斯班

    赫赫~
    俺的水平也就是mysql的境界啦~~

  • CJ

    HadoopDB其实是构建在HIVE上面的,现在没多少代码。

  • wormwang

    现代的数据库瓶颈多是DiskIO。
    Greenplum这样的架构可以支撑到Master节点处理40Gbps。
    如果数量处理量超过40Gpbs,现有技术类似Parallel NFS,Lustree,都可以进一步扩展Master的性能。

  • http://www.dbanotes.net Fenng

    要按照你这么一说,Parallel NFS,Lustree 还是要比 Greenplum 技术更先进才行呢,可惜不是

  • http://coderplay.javaeye.com coderplay

    分析它的源代码后, 会觉得这只是一个没有前途的实验项目. 首先它的数据hash到各节点是手工做的, 没有parser,没有planner,及optimizer;其次,如果用pg做存储实例,而不用hdfs的datanode,则会失去hdfs的redundancy,这个得自己做,而那paper只字未提;再次, 它没有支持INSERT INTO操作,它只是手工hash数据至各pg节点后, 算出来的结果放到hdfs之上,而不是返回给pg实例的另一张表,这是没有实用价值的;三次,hadoop是一个多人用户环境, 带有调度器去分配资源给各组/用户, hadoopdb这种作法无法做各节点的metrics; 最后它的join假设了要join的两张表,它们的hash key是一致的, 也就是greenplum最理想的状态。Therefore…