Infobright的架构

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 实现中也使用了布隆过滤器来快速剔除一些不相关的数据。俗话说难得糊涂，何必什么时候都那么精确呢。