Infobright的架构
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实现中也使用了布隆过滤器来快速剔除一些不相关的数据。俗话说难得糊涂,何必什么时候都那么精确呢。
建议继续学习:
- 列式数据仓库引擎之Infobright (阅读:3529)
- MySQL Infobright 数据仓库快速安装笔记[原创] (阅读:2624)
- Infobright 数据仓库 (阅读:2216)
- Infobright 数据仓库心得总结 (阅读:1880)
- 关于Infobright 的几种数据格式 (阅读:1706)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:风轻扬 来源: 风轻扬
- 标签: Infobright
- 发布时间:2009-10-20 22:20:29
- [67] Go Reflect 性能
- [67] Oracle MTS模式下 进程地址与会话信
- [67] 如何拿下简短的域名
- [61] IOS安全–浅谈关于IOS加固的几种方法
- [60] 图书馆的世界纪录
- [59] 【社会化设计】自我(self)部分――欢迎区
- [58] android 开发入门
- [56] 视觉调整-设计师 vs. 逻辑
- [49] 给自己的字体课(一)——英文字体基础
- [47] 界面设计速成