研究云计算的两个多月之后，脑子确实‘晕’了。云计算在我看来就是用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）。这是个新鲜玩意，有兴趣可以一同研究下！