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

风轻扬

活着就是为了追求幸福

 
 
 

日志

 
 
关于我

关注互联网应用架构、分布式与海量数据处理技术、云计算、数据库技术

网易考拉推荐

Infobright的架构  

2009-01-17 20:57:33|  分类: 数据库 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
Infobright是一个列存数据仓库软件,可以与MySQL集成,作为MySQL的一个存储引擎来使用(后面将会看到这是个非同一般的存储引擎)。主要的技术优势有:
1. 高压缩比,通常是10:1,某些应用可能达到40:1
2. 无需事先做好物理设计规则,不需要建索引,不需要数据分区,对ad-hoc分析型查询执行性能非常高
3. 数据装载非常快

这些技术优势是如何实现的呢,这两天看了Infobright的白皮书和VLDB论文,大概有所了解。Infobright具有上述优势是因为其具有与传统数据仓库软件显著不同的架构。传统的数据仓库软件,基本上还是以传统的事务处理数据库架构为基础,增加位图索引、物化视图等性能优化措施,Infobright的架构则完全不同。

首先Infobright使用是的面向列的存储,传统数据库是面向行的存储,这使得Infobright能够实现很高的压缩比。当然列存这些年来已经有很多人研究,没什么新鲜的。Infobright架构中最新颖的是其数据组织与索引方式与传统数据库完全不同。

在Infobright中,数据的存储单元称为DP(Data Pack),每64K条记录的每个属性的值集成存储在一个DP中,进行压缩。Infobright不支持根据某属性进行分区或排序,因为这通常会影响数据装载的效率。
每个DP有一些统计信息,称为DPN(Data Pack Node),比如对数值类型记录最小值、最大值、和、非空值个数、值个数等。
DPN中包含的信息是比较粗略与局部的,关于数据的更多信息称为KN(Knowledge Node)。一类KN包括高级一点的统计信息,如柱状图(对数值类型采用,1024个分区,记录每个分区是否有满足条件的数据);CMAP(字符串中每个位置是否包含每个字符,如第3个字符是否可能是'b')。另一类KN描述DP之间的数据相关性,如属于不同表的哪些DP对应参与联接,只支持两个属性上的等值条件,是一个矩阵。KN通常在数据装载时生成,也可能根据根据查询需要动态生成。主要用于处理复杂查询或多表联接查询。
DPN和KN合起来称为知识网格(Knowledge Grid),其在Infobright中的地位相当于传统数据库中的索引。但有以下明显区别:
1. 由于这些信息都是针对包含64K行记录数据的DP的汇总数据,相对于传统数据库的索引占用空间要小得多,一般只点1%左右的空间(相对于压缩后的数据)。
2. 对每个DP至少都有相应的DPN,这相当于对所有的数据,都有最基本的索引存在。而传统数据库中索引需要事先规划好,这样对ad-hoc查询的应对能力就很差。

有了知识网格,Infobright优化和执行器就可以访问尽量少的DP来完成查询。查询优化的首要任务是将DP分为三类: DP中所有数据都满足条件、DP中所有数据都不满足条件、DP中可能有部分数据满足条件。这样处理的思路来自于粗糙集理论(没研究过不懂)。通常对于1、2两类都不需要解压DP数据来处理,比如设一个表有A、B两列,分别有五个DP。设DPN中记录中各DP中属性的最小值和最大值如下:
              A的取值范围            B的取值范围
  DP1:     [1, 10]                     [15, 30]
  DP2:     [12,15]                    [3,11]
  DP3:     [5, 9]                      [6, 20]
  DP4:     [6, 17]                    [7, 17]
  DP5:     [9, 13]                    [10, 18]

设要执行以下的SQL语句:
  SELECT max(A) FROM table WHERE B > 12;
根据"B > 12"这个条件,优化器可以很快判断量DP1中的数据一定都满足条件,DP2一定都不满足条件,而DP3、DP4、DP5不能完全确定,这样处理时只需要对DP3-5这三个DP的数据进行进一步分析就可以了。但这只是最简单的分析,Infobright的优化器还可以进行更进一步的智能化分析,有点逻辑推理的味道。比如还是这个例子,优化器根据DP1可以得出max(A)至少是10这个结论,这样,对于A的最大值是9的DP3来说,即使其所有数据都满足条件,那么也不会影响到语句的结果。因此处理是DP3也可以完全不去考虑。这样就可以进一步的将要处理的DP降到两个。此外,Infobright的查询优化与处理过程还是动态的,即在处理过程中会及时的根据目前所得结果对计划进行调整,这与传统的数据库也有明显不同,这样可能可以进一步的降低处理代价。比如上例中根据静态优化,发现要处理DP4和DP5,这时Infobright可能先处理DP4,结果发现满足条件的A的最大值是15,这样,DP5就可以不再处理了,因为其中A的最大值才13,不影响最终结果。

从上面的例子可以看到,相对于传统数据库经典的Selinger优化器,我的感觉是Infobright的查询优化更加复杂,更具有智能性。但官方并没有给出关于Infobright查询优化与处理的框架性描述,只是通过一些示例来演示其优化和处理的基本概念。从上面这个非常简单的例子已经可以看出这里已经涉及到推理、动态查询优化等比较复杂的技术,其实现想来应当相当复杂,具体的细节估计得读源码才能知道了。

目前还在实际应用中使用Infobright的经验,但至少我觉得它的架构还是相当赞的,有必要去试用一下。与MySQL集成作为MySQL的存储引擎使用时,Infobright的优化器会接管MySQL本身的优化器的大部分工作(不知道这是怎么搞定的,完全通过MySQL的存储引擎接口来扩展应该是实现不了这样的功能)。通过粗略的索引数据来减少要处理的数据的思路还是相当实用的,Google的BigTable实现中也使用了布隆过滤器来快速剔除一些不相关的数据。俗话说难得糊涂,何必什么时候都那么精确呢。
  评论这张
 
阅读(2669)| 评论(6)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

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

页脚

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