Infobright是开源的MySQL数据仓库解决方案，引入了列存储方案，高强度的数据压缩，优化的统计计算(类似sum/avg/group by之类)，

infobright 是基于mysql的，但不装mysql亦可，因为它本身就自带了一个。mysql可以粗分为逻辑层和物理存储引擎，infobright主要实现的就是一个存储引擎，但因为它自身存储逻辑跟关系型数据库根本不同，所以，它不能像InnoDB那样直接作为插件挂接到mysql，它的逻辑层是mysql的逻辑 层加上它自身的优化器。

1、高压缩比率，平均压缩比可达10：1，甚至可以达到40:1，我用infobright把3.1G的数据存成不足300M。

2、列存储，即使数据量十分巨大，查询速度也很快。用于数据仓库，处理海量数据没一套可不行。

3、不需要建索引，就避免了维护索引及索引随着数据膨胀的问题。把每列数据分块压缩存放，每块有知识网格节点记录块内的统计信息，代替索引，加速搜 索。

4、单一台服务器可以高效地读写30T数据。具有可扩展性，这里是指对于同样的查询，当数据量是10T时，它耗费的时间不应该比1T数据量时慢太 多，基本是一个数量级内。

下面是Infobright的架构图：

灰色部分是mysql原有的模块，白色与蓝色部分则是 infobright自身的。

Infobright与其他分布式大数据产品，譬如Yonghong Z-DataMart一样是采用MPP分布式架构，可以有多节点组成集群。节点内是跟mysql一样的两层结构，上面的逻辑层处理查询逻辑，下面的是存储引擎。逻辑层右端的loader与unloader是infobright的数据导入导出模块，也即处理SQL语句里LOAD DATA INFILE … 与SELECT … INTO FILE任务，由于infobright面向的是海量数据环境，所以这个数据导入导出模块是一个独立的服务，并非直接使用mysql的模块。逻辑层的infobright优化器包在mysql查询优化器的外面，如下面将会提到的，因为它的存储层有一些特殊结构，所以查询优化方式也跟 mysql有很大差异。存储层底层是一个个的Data Pack（数据块）。每一个Pack装着某一列的64K个元素，所有数据按照这样的形式打包存储，每一个数据块进行类型相关的压缩（即根据不同数据类型采 用不同的压缩算法），压缩比很高。它上层的压缩器与解压缩器就做了这个事情。压缩层再向上就是infobright重要的概念：Knowledge Grid（知识网格），这也是infobright放弃索引却能应用于大量数据查询的基础。它包含两类结点：每个Data Pack Node（知识节点）对应于一个Data Pack，存储该Data Pack的一些统计信息，如min, max, avg, null的个数，甚至不同值的量等等；Knowledge Node则存储了一些更的统计信息，以及与其它表的连接信息，这里面的信息有些是数据载入时已经算好的，有些是随着查询进行而计算的，所以说是具备一 定的“智能”的。

Infobright里面支持所有的MySQL原有的数据类型。其中Integer类型比其他数据类型更加高效。尽可能使用以下的数据类型：

TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT

DECIMAL（尽量减少小数点位数）

DATE ，TIME

效率比较低的、不推荐使用的数据类型有：

BINARY VARBINARY

FLOAT

DOUBLE

VARCHAR

TINYTEXT TEXT

Infobright数据类型使用的一些经验和注意点：

（1）Infobright的数值类型的范围和MySQL有点不一样，比如Infobright的Int的小值是-2147483647，而MySQl的Int小值应该是-2147483648。其他的数值类型都存在这样的问题。

（2）能够使用小数据类型就使用小数据类型，比如能够使用SMALLINT就不适用INT，这一点上Infobright和MySQL保持一致。

（3）避免效率低的数据类型，像TEXT之类能不用就不用，像FLOAT尽量用DECIMAL代替，但是需要权衡毕竟DECIMAL会损失精度。

（4）尽量少用VARCHAR，在MySQL里面动态的Varchar性能就不强，所以尽量避免VARCHAR。如果适合的话可以选择把VARCHAR改成CHAR存储甚至转成INTEGER类型。VARCHAR的优势在于分配空间的长度可变，既然Infobright具有那么的压缩性能，个人认为完全可以把VARCHAR转成CHAR。CHAR会具有更好的查询和压缩性能。

（5）能够使用INT的情况尽量使用INT，很多时候甚至可以把一些CHAR类型的数据往整型转化。比如搜索日志里面的客户id、客户id等等数据就可以用BIGINT存储而不用CHAR存储。其实把时间分割成year、month、day三列存储也是很好的选择。在我能见到的系统里面时间基本上是使用频率高的字段，提高时间字段的查询性能显然是非常重要的。当然这个还是要根据系统的具体情况，做数据分析时有时候很需要MySQL的那些时间函数。

（6）varchar和char字段还可以使用comment lookup，comment lookup能够显著地提高压缩比率和查询性能。