注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

白鸟无言

Welcome to theWraith's space

 
 
 

日志

 
 

列存数据库——美丽的谎言?  

2009-03-31 21:49:22|  分类: 技术 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

既然被批评不原创了,那就原创一篇吧。

这篇文章我在去年下半年写某申请报告的时候就想写了,然而迟迟不敢动笔,因为在数据库界,列存数据库这几年实在是有些炙手可热。更加关键的是,列存数据库并不是像现在充斥于理论研究界的那些纯属意淫的概念,它已经确确实实做成了产品,并且开始在决策支持领域使用。在wiki上搜一下column-oriented dbms,词条里以Sybase IQ为首的十余家商业产品一字排开,真有点百家争鸣的气势。

然而当我开始了一段时间对于列存数据库的研究之后,我却始终没有接受列存数据库是一个令人信服的技术产品,或者说,它不可能像当年关系数据库的提出那样,对信息界产生革命性的影响。相反,它最终可能的结局是技术理念被传统数据库巨头吸纳,仅仅成为庞大的关系数据库中的一个面向应用环境的配置参数。

好的,首先还是介绍一下列存数据库的基本概念吧:传统的数据库以行方式组织数据,像下面的一张表:

 姓名  年龄  性别  单位
 张三  23 男   杭州第一百货公司
 王丽  21  女  杭州第一百货公司
 李四  27  男  杭州市红十字会医院

在物理上一定是以行为单位存的,通俗点就是说,你从数据文件读过去,一定是像下面这样的:

 张三23男杭州第一百货公司王丽21女杭州第一百货公司李四27男杭州市红十字会医院

而如果是列存数据库,它就会以列为连续的组织单位来存,也就是像下面这样

 张三王丽李四232127男女男杭州第一百货公司杭州第一百货公司杭州市红十字会医院

那么这两种数据库究竟有什么不同呢,从数据组织上来说,列存以属性连续组织数据,这就使得对同一个属性的访问更集中,可以减少IO量,加快存取速度;而行存必须以行为单位访问数据,但可以避免掉不同属性之间的关联维护。例如这样一条SQL语句:

select  姓名 from  table  where  性别='男';

列存数据库在执行只需要访问这么多数据量(当然它需要知道两列之间的对应关系,有一些额外开销):

 张三王丽李四232127男女男杭州第一百货公司杭州第一百货公司杭州市红十字会医院

而行存数据库需要访问所有的数据才能得到,明显的,它在IO性能上亏了很多。

但是请注意!如果我们抛开“列存数据库”这个美丽的名词来看,其实这种优化需求关系数据库早就考虑过了。索引技术,以及早在上世纪八十年代就提出的垂直分区技术,其实都可以解决这个问题。那么列存数据库到底有什么创新的东西?它有什么闪光点是真的让传统数据库望尘莫及呢?在2008年的sigmod上,abadi同学发了篇《Column-Stores  vs   Row-Stores: How different  Are  they really?》,下面让我们来看看这篇文章的思想吧。

在文章里作者首先对传统数据库优化技术作了讨论,并且说明了它们的弱点,然而我认为他的观点完全站不住脚。首先对比的是列存数据库与垂直分区,作者认为,在垂直分区的一般化实现中(他用来做对比实验的行存数据库叫做SYSTEM   X,这不是IBM的服务器么,还是指用的DB2?完全迷茫了......),需要在每个分区上标识出此属性所属的列,而这样会增加空间开销和增加连接的难度,而列存数据库天生就可以把列按物理顺序存放,从而避免了这一问题。这个解释完全无法让我信服——为什么垂直分区要用这么愚蠢的实现方案呢?完全可以用主分区带附分区ID的方法啊,这样甚至避免了位图连接,可以直接定位到副分区属性的位置上。而且更直观的一个观点是,为什么列存就可以保持按物理顺序存放?如果增长更新来了怎么办?我想了很久也想不通,这里有什么技术是列存可以使用而垂直分区确实天生就无法使用的....

下面是索引,这儿更让我有点迷茫了,它的原文是这样写的“第二种优化方法是在SYSTEM X上,所有的数据存在一个普通的表里,并建立非聚簇索引用来帮助查找,但是如果在查找时有一个属性没有谓词(predicate),那索引就需要被完全扫描,而这种扫描比扫描表还要慢。”这儿我初一看完全莫名其妙,还好他举了个例子:SELECT AVG(salary) FROM emp WHERE age>40,如果我们有一根单独的索引在age上和一根单独的索引在salary上,那我们就必须从age索引上得到满足条件的rid,再从salary索引上得到所有的(salary rid),在内存中作merge,再得到满足条件的salary结果。我真的无语了,有哪个数据库规定了使用索引就不能去访问表?又有谁规定我不能建(age, salary)索引?这样愚昧的执行计划mysql也不至于产生出来吧。

最后是物化视图,他说了一段话我看了半天也没看出来到底物化视图有什么不好,当然他用强大的SYSTEM X做实验做出来物化视图的效果是不如列存, 我只好暂时认为他正确了。

好的,接着作者阐述列存数据库的优秀技术。总共有四点,罗列如下:

1.压缩技术,因为列存按列组织数据,而列中的distinct值往往是很少的,因此这种语义压缩会很有效。这点我完全承认,可是这也不是新技术啊,prefix压缩oracle老早就有了,sql server 2008也宣称支持了,当然它们不可能把压缩做到页面以外,因为这样会影响到恢复协议,但列存数据库无所谓啊,OLAP环境本来就没啥更新,所以理论上,一亿行一样的值,在它里面只需要存一个。所以如果抛开恢复等其它方面带来的困难不谈,垂直分区和索引,甚至表也完全可以做到和列存数据库一样的压缩效果(而作者也承认,实际上压缩技术带来的性能好处是最大的)。

2.延时物化,这是指在执行计划中用位图来标识行的位置,直到取属性时再去实际取相应列的值,避免了数据不停传递的开销。这个倒是有些道理,至少行存的结构特点不是那么容易移植这个技术的,从某种意义上来说,索引的成组访问表思想和这个有点像。

3.成组迭代,还是认为传统的流水线方式每一次处理都会去调用许多函数,这个代价不划算,所以成组去做,不过这个思想本来就是IBM的人针对传统数据库提出的,行存数据库仍然适用。

4.Invisible join,这个是作者新提出的,看了半天没看懂。写了很长的逻辑,但是实验中它起的优化效果不怎么样,而且使用条件很苛刻,必须在很规则的星型OLAP模式中才起作用。个人认为有凑篇幅嫌疑。

看了这篇文章后,我就对列存数据库产生了怀疑思想,因为确实没看处有哪项技术是垂直分区和索引不可以使用的,如果有,也是因为其它原因(比如恢复协议),而这个原因列存数据库同样没法绕过去,哦,不对,它可以绕过去,本来我列存数据库就是针对决策支持应用的,干嘛要考虑更新啊,恢复啊,吃饱了撑的。

那么到底在决策支持领域,列存数据库有多大的优势呢,我们知道,在tpc国际标准测试中,TPCH测试是模拟这类应用的。打开TPCH测试结果前十名,可以看到,在3000GB以下,一个名叫EXASOLUTION的数据库占据了所有榜首,它是一个列存\内存数据库,OK。然后其它的位置上,SQL Server、DB2和Oracle已经开始像TPCC测试中表现的那样霸占榜单了(去年下半年我记得在100GB的榜单上还全是列存数据库啊,看来我的判断还是有点道理的嘛,嘿嘿)。到了3000GB以上,Oh my god,又成了那三家比拼财力的游戏了....看来在可扩展性方面,这些新生的列存产品还是根本无法和传统巨头们竞争啊。

那么列存数据库在小数据量应用中到底有多强呢?在100GB的测试中,EXASOLUTION的QphH值是惊人的209298,排在第四位的SQL Server 2005只有34989,足足差了6倍!然而详细检查看看EXASOLUTION的测试报告,它使用了自己的服务器,自己的操作系统,24个4核的Intel  3G的CPU(这里还有个很搞笑的细节,为了降低性价比,它这样一台24CPU,100G内存的服务器居然不带任何额外的外存设备,只挂两个146G的硬盘,能放下数据就足够了......ORZ)。而SQL Server只使用了4个4核的Intel 2.93G的CPU(MS就老实的多了,买了台HP的服务器,175个36G的硬盘,真亏大了...)。由于TPCH全是内存行为,因此CPU开销是主要开销,计算一下就可以发现,单个CPU提供的QphH值,EXASOLUTION与SQL Server其实根本没啥差异....

这个结论无疑撕下了列存数据库的新装!想像一下吧,一个专门面对OLAP应用的,内存的、列存的专用数据库(甚至有可能针对TPCH测试做了代码级别的优化),在和一个通用的、面向外存的大型关系数据库比起来,竟然没有任何性能优势。因此无论stonebraker同学这几年如何鼓吹在专用领域应该使用定制的数据库,我都不认为,关系数据库的年代已经看到了尽头,相反,在结构化甚至半结构化数据处理的领域里,它们的地位只会越来越重要。

最后为了学术道德问题,特此声明,本文感谢本课题组某牛人的指点思想,本人虽然是小菜鸟,但是是严格遵守学术道德规范的!!看完文章的同学,请和我一起大声朗读下面的话:

有两件事我愈思考,愈觉神奇,心中也愈充满敬畏,一是我头顶上的这方星空,一是人们心中的道德准则                ————康德

  评论这张
 
阅读(2034)| 评论(11)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017