技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> MySQL --> Infobright的架构

Infobright的架构

浏览:2940次  出处信息
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),BODY { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }P { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }DIV { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }TD { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }比如对数值类型记录最小值、最大值、和、非空值个数、值个数等。

    DPN中包含的信息是比较粗略与局部的,关于数据的更多信息称为KN(Knowledge Node)。一类KN包括高级一点的统计信息,如BODY { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }P { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }DIV { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }TD { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }柱状图(对数值类型采用,1024个分区,记录每个分区是否有满足条件的数据);CMAP(字符串中每个位置是否包含每个字符,如第3个字符是否可能是\'b\')。另一类KN描述DP之间的数据相关性,如BODY { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }P { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }DIV { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }TD { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }属于不同表的哪些DP对应参与联接,只支持两个属性上的等值条件,是一个矩阵。BODY { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }P { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }DIV { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }TD { FONT-FAMILY:Tahoma; FONT-SIZE:10pt }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实现中也使用了布隆过滤器来快速剔除一些不相关的数据。俗话说难得糊涂,何必什么时候都那么精确呢。    

建议继续学习:

  1. 列式数据仓库引擎之Infobright    (阅读:3529)
  2. MySQL Infobright 数据仓库快速安装笔记[原创]    (阅读:2624)
  3. Infobright 数据仓库    (阅读:2216)
  4. Infobright 数据仓库心得总结    (阅读:1880)
  5. 关于Infobright 的几种数据格式    (阅读:1706)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1