infobright原理.docx

1、infobright原理Infobright构架分析 Infobright的总体构架图如下:如上图所示，Infobright采用了和MySQL一致的构架，分为两层。上层是服务及应用管理，下层是存储引擎。Infobright的默认存储引擎是brighthouse，但是Infobright还可以支持其他的存储引擎，比如MyISAM、MRG_MyISAM、Memory、CSV。Infobright通过三层来组织数据，分别是DP(Data Pack)、DPN（Data Pack Node）、KN（Knowledge Node）。而在这三层之上就是无比强大的知识网络（Knowledge Grid）。数据

2、块（DP）是存储的最低层，列中每64K个单元组成一个DP。DP比列更小，具有更好的压缩比率；又比单个数据单元更大，具有更好的查询性能。数据块节点（DPN），DPN和DP之间是一对一的关系。DPN记录着每一个DP里面存储和压缩的一些统计数据，包括最大值、最小值、null的个数、单元总数count、sum等等。KN里面存储着指向DP之间或者列之间关系的一些元数据集合，比如值发生的范围（MIin_Max）、列数据之间的关联。大部分的KN数据是装载数据的时候产生的，另外一些事是查询的时候产生。在这三层之上是知识网络（Knowledge Grid），Knowledge Grid构架是Infobright

3、高性能的重要原因。Knowledge Grid可分为四部分，DPN、Histogram、CMAP、P-2-P。DPN如上所述。Histogram用来提高数字类型（比如date，time，decimal）的查询的性能。Histogram是装载数据的时候就产生的。DPN中有mix、max，Histogram中把Min-Max分成1024段，如果Mix_Max范围小于1024的话，每一段就是就是一个单独的值。这个时候KN就是一个数值是否在当前段的二进制表示。Histogram的作用就是快速判断当前DP是否满足查询条件。如上图所示，比如select id from customerInfo where

4、 id50 and id6。所以A1、A2、A4就是不相关的DP，A3是相关的DP，A5是可疑的DP。那么执行查询的时候只需要计算B5中满足条件的记录的和然后加上Sum（B3），Sum（B3）是已知的。此时只需要解压缩B5这个DP。从上面的分析可以知道，Infobright能够很高效地执行一些查询，而且执行的时候where语句的区分度越高越好。where区分度高可以更精确地确认是否是相关DP或者是不相关DP亦或是可以DP，尽可能减少DP的数量、减少解压缩带来的性能损耗。在做条件判断的使用，一般会用到上一章所讲到的Histogram和CMAP，它们能够有效地提高查询性能。多表连接的的时候原理也是

5、相似的。先是利用Pack-To-Pack产生join的那两列的DP之间的关系。比如：SELECT MAX(X.D) FROM T JOIN X ON T.B = X.C WHERE T.A 6。Pack-To-Pack产生T.B和X.C的DP之间的关系矩阵M。假设T.B的第一个DP和X.C的第一个DP之间有元素交叉，那么M1,1=1，否则M1,1=0。这样就有效地减少了join操作时DP的数量。前面降到了解压缩，顺便提一提DP的压缩。每个DP中的64K个元素被当成是一个序列，其中所有的null的位置都会被单独存储，然后其余的non-null的数据会被压缩。数据的压缩跟数据的类型有关，infob

6、right会根据数据的类型选择压缩算法。infobright会自适应地调节算法的参数以达到最优的压缩比。Infobright的数据类型 Infobright里面支持所有的MySQL原有的数据类型。其中Integer类型比其他数据类型更加高效。尽可能使用以下的数据类型：TINYINT，SMALLINT，MEDIUMINT，INT，BIGINTDECIMAL（尽量减少小数点位数）DATE ，TIME效率比较低的、不推荐使用的数据类型有：BINARY VARBINARYFLOATDOUBLEVARCHARTINYTEXT TEXTInfobright数据类型使用的一些经验和注意点：（1）Infobr

7、ight的数值类型的范围和MySQL有点不一样，比如Infobright的Int的最小值是-2147483647，而MySQl的Int最小值应该是-2147483648。其他的数值类型都存在这样的问题。（2）能够使用小数据类型就使用小数据类型，比如能够使用SMALLINT就不适用INT，这一点上Infobright和MySQL保持一致。（3）避免效率低的数据类型，像TEXT之类能不用就不用，像FLOAT尽量用DECIMAL代替，但是需要权衡毕竟DECIMAL会损失精度。（4）尽量少用VARCHAR，在MySQL里面动态的Varchar性能就不强，所以尽量避免VARCHAR。如果适合的话可以选择

8、把VARCHAR改成CHAR存储甚至专程INTEGER类型。VARCHAR的优势在于分配空间的长度可变，既然Infobright具有那么优秀的压缩性能，个人认为完全可以把VARCHAR转成CHAR。CHAR会具有更好的查询和压缩性能。（5）能够使用INT的情况尽量使用INT，很多时候甚至可以把一些CHAR类型的数据往整型转化。比如搜索日志里面的客户永久id、客户id等等数据就可以用BIGINT存储而不用CHAR存储。其实把时间分割成year、month、day三列存储也是很好的选择。在我能见到的系统里面时间基本上是使用频率最高的字段，提高时间字段的查询性能显然是非常重要的。当然这个还是要根据系

9、统的具体情况，做数据分析时有时候很需要MySQL的那些时间函数。（6）varchar和char字段还可以使用comment lookup，comment lookup能够显著地提高压缩比率和查询性能。Infobright comment lookup使用 前面的章节一直涉及到comment lookup，这里将简单介绍comment lookup的使用。comment lookup只能显式地使用在char或者varchar上面。Comment Lookup可以减少存储空间，提高压缩率，对char和varchar字段采用comment lookup可以提高查询效率。Comment Lookup实

10、现机制很像位图索引，实现上利用简短的数值类型替代char字段已取得更好的查询性能和压缩比率。Comment Lookup的使用除了对数据类型有要求，对数据也有一定的要求。一般要求数据类别的总数小于10000并且当前列的单元数量/类别数量大于10。Comment Lookup比较适合年龄，性别，省份这一类型的字段。comment lookup使用很简单，在创建数据库表的时候如下定义即可：act char(15) comment lookup,part char(4) comment lookup,Infobright查询优化 前面已经分析了Infobright的构架，简要介绍了Infobrigh

11、t的压缩过程和工作原理。现在来讨论查询优化的问题。（1）配置环境在Linux下面，Infobright环境的配置可以根据README里的要求，配置brighthouse.ini文件。（2） 选取高效的数据类型参见前面章节。（3）使用comment lookup参见前面章节。（4）尽量有序地导入数据前面分析过Infobright的构架，每一列分成n个DP，每个DPN列面存储着DP的一些统计信息。有序地导入数据能够使不同的DP的DPN内的数据差异化更明显。比如按时间date顺序导入数据，那么前一个DP的max（date）=下一个DP的min(date)，查询的时候就能够减少可疑DP，提高查询性能。

12、换句话说，有序地导入数据就是使DP内部数据更加集中，而不再那么分散。（5）使用高效的查询语句。这里涉及的内容比较多了，总结如下： 尽量不适用or，可以采用in或者union取而代之减少IO操作，原因是infobright里面数据是压缩的，解压缩的过程要消耗很多的时间。查询的时候尽量条件选择差异化更明显的语句 Select中尽量使用where中出现的字段。原因是Infobright按照列处理的，每一列都是单独处理的。所以避免使用where中未出现的字段可以得到较好的性能。 限制在结果中的表的数量，也就是限制select中出现表的数量。 尽量使用独立的子查询和join操作代替非独立的子查询 尽量不在where里面使用MySQL函数和类型转换符 尽量避免会使用MySQL优化器的查询操作 使用跨越Infobright表和MySQL表的查询操作尽量不在group by 里或者子查询里面使用数学操作，如sum（a*b）。select里面尽量剔除不要的字段。Infobright执行查询语句的时候，大部分的时间都是花在优化阶段。Infobright优化器虽然已经很强大，但是编写查询语句的时候很多的细节问题还是需要程序员注意。