当前位置: 首页 > 工具软件 > HadoopDB > 使用案例 >

关注HadoopDB,一个分布式并行数据库系统

闻人嘉悦
2023-12-01

研究云计算的两个多月之后,脑子确实‘晕’了。云计算在我看来就是用mapReduce思想实践于大量廉价的Linux机器上的解决方案,主要涉及存储和处理两方面,当然以上观点都是我固执的偏见罢了。

传统的基于行的关系型数据库里名声最大的要数Oracle了,其分布式集群的RAC解决方案在负载均衡等方面做的也不错。但是它的处理速度确实有限,还没听说过哪个集群解决方案应用到了上百个节点,因为不管集群中有多少个节点,数据却只保存了一份,引用在greenplum文档中提到的观点,这种架构叫‘shared-everything’,多个节点同时读写数据就会抢占磁盘IO,成了瓶颈,限制了处理速度(写到这里想多说一句,看似Oracle多复杂,只不过为弥补自身设计弊端而不断地patching罢了)。当然了,在OLTP系统当中,Oracle还是很吊的。而在与之相对的OLAP领域以及说白了的数据仓库方面,就是别的数据库占据在那里了,我听说比较不错的有Teradata,这都是传闻,还传闻Teradata很贵呢~

提到了基于行的数据库库,不得不说一下基于列的数据库,在OLAP领域,之前研究vertica时才稍明白点这种基于列的数据库有什么好处(其他可基于列存储的数据库还有hypertable、greenplum等等,他们都是‘新秀’数据库),尤其是在海量数据分析中,要是用到了group by、join或sort之类的操作,那处理速度与基于行的可就是不可同日而语了。原因主要有两点,一是在于基于列的数据库的数据就是按列连续存储的,说白了节省的就是磁盘IO扫描的时间(补充:在含聚集函数的查询中能减少磁盘磁头寻道次数),二是在按列存储的基础上进行了很多优化,比如压缩。

上面提到了传统的关系型数据库,不得不再说一下非关系型数据库。在数据库发展的这些年里,非关系型数据库一直处在非主流的地位,但是web2.0对其起到了推进作用。没有严格的行列二维映射关系(上学时好像学过,和第几范式有关系),用key和value来描述插入的数据,比如MongoDB等。

最近云计算很火,hadoop、mapreduce、bigtable都是关键词。现在就有了这么一个问题,对于传统的基于行的关系型数据库,在OLAP领域如何能延续生命?如何存储以及处理,这样就引入了文章标题提到的内容——分布式并行数据库,将数据分布在多个节点存储,执行查询时多个节点进行并行计算,数据汇总并返回结果,用空间换取时间,时间复杂度=执行最慢的那个节点花费的时间+数据汇总的时间。这么好的东西为什么没有早早普及呢,原因很多,比如设计就很复杂,细节问题包括多表做join、添加删除节点等等。greenplum就是一个基于PostgreSQL数据库的分布式并行数据库的商业应用,不去理它,我们主要说说开源的,‘free’的~ 提几个类似的开源项目,比如pgpool、bizgres、pl/proxy、gridsql等,都是基于PostgreSQL数据库的,这个数据库还是很不错的,比如说它是基于BSD协议的开源项目~

下面该提到文章标题的另一个关键词啦——HadoopDB,它是mapReduce和SQL的结合,利用Hadoop系统和PostgreSQL实现的分布式并行数据库系统,它是美国耶鲁大学出来的一个开源项目,基于Apache2.0协议,用java写的。它用hadoop进行数据处理,用PostgreSQL进行数据存储,在处理查询时,执行的是SQL to mapReduce to SQL操作过程(SMS planner)。这是个新鲜玩意,有兴趣可以一同研究下!

研究云计算的两个多月之后,脑子确实‘晕’了。云计算在我看来就是用mapReduce思想实践于大量廉价的Linux机器上的解决方案,主要涉及存储和处理两方面,当然以上观点都是我固执的偏见罢了。

传统的基于行的关系型数据库里名声最大的要数Oracle了,其分布式集群的RAC解决方案在负载均衡等方面做的也不错。但是它的处理速度确实有限,还没听说过哪个集群解决方案应用到了上百个节点,因为不管集群中有多少个节点,数据却只保存了一份,引用在greenplum文档中提到的观点,这种架构叫‘shared-everything’,多个节点同时读写数据就会抢占磁盘IO,成了瓶颈,限制了处理速度(写到这里想多说一句,看似Oracle多复杂,只不过为弥补自身设计弊端而不断地patching罢了)。当然了,在OLTP系统当中,Oracle还是很吊的。而在与之相对的OLAP领域以及说白了的数据仓库方面,就是别的数据库占据在那里了,我听说比较不错的有Teradata,这都是传闻,还传闻Teradata很贵呢~

提到了基于行的数据库库,不得不说一下基于列的数据库,在OLAP领域,之前研究vertica时才稍明白点这种基于列的数据库有什么好处(其他可基于列存储的数据库还有hypertable、greenplum等等,他们都是‘新秀’数据库),尤其是在海量数据分析中,要是用到了group by、join或sort之类的操作,那处理速度与基于行的可就是不可同日而语了。原因主要有两点,一是在于基于列的数据库的数据就是按列连续存储的,说白了节省的就是磁盘IO扫描的时间(补充:在含聚集函数的查询中能减少磁盘磁头寻道次数),二是在按列存储的基础上进行了很多优化,比如压缩。

上面提到了传统的关系型数据库,不得不再说一下非关系型数据库。在数据库发展的这些年里,非关系型数据库一直处在非主流的地位,但是web2.0对其起到了推进作用。没有严格的行列二维映射关系(上学时好像学过,和第几范式有关系),用key和value来描述插入的数据,比如MongoDB等。

最近云计算很火,hadoop、mapreduce、bigtable都是关键词。现在就有了这么一个问题,对于传统的基于行的关系型数据库,在OLAP领域如何能延续生命?如何存储以及处理,这样就引入了文章标题提到的内容——分布式并行数据库,将数据分布在多个节点存储,执行查询时多个节点进行并行计算,数据汇总并返回结果,用空间换取时间,时间复杂度=执行最慢的那个节点花费的时间+数据汇总的时间。这么好的东西为什么没有早早普及呢,原因很多,比如设计就很复杂,细节问题包括多表做join、添加删除节点等等。greenplum就是一个基于PostgreSQL数据库的分布式并行数据库的商业应用,不去理它,我们主要说说开源的,‘free’的~ 提几个类似的开源项目,比如pgpool、bizgres、pl/proxy、gridsql等,都是基于PostgreSQL数据库的,这个数据库还是很不错的,比如说它是基于BSD协议的开源项目~

下面该提到文章标题的另一个关键词啦——HadoopDB,它是mapReduce和SQL的结合,利用Hadoop系统和PostgreSQL实现的分布式并行数据库系统,它是美国耶鲁大学出来的一个开源项目,基于Apache2.0协议,用java写的。它用hadoop进行数据处理,用PostgreSQL进行数据存储,在处理查询时,执行的是SQL to mapReduce to SQL操作过程(SMS planner)。这是个新鲜玩意,有兴趣可以一同研究下!

转载于:https://my.oschina.net/u/218230/blog/672643

 类似资料: