infobright原理.docx
《infobright原理.docx》由会员分享，可在线阅读，更多相关《infobright原理.docx（7页珍藏版）》请在冰豆网上搜索。
infobright原理
Infobright构架分析
Infobright的总体构架图如下:
如上图所示，Infobright采用了和MySQL一致的构架，分为两层。
上层是服务及应用管理，下层是存储引擎。
Infobright的默认存储引擎是brighthouse，但是Infobright还可以支持其他的存储引擎，比如MyISAM、MRG_MyISAM、Memory、CSV。
Infobright通过三层来组织数据，分别是DP（DataPack）、DPN（DataPackNode）、KN（KnowledgeNode）。
而在这三层之上就是无比强大的知识网络（KnowledgeGrid）。
数据块（DP）是存储的最低层，列中每64K个单元组成一个DP。
DP比列更小，具有更好的压缩比率；又比单个数据单元更大，具有更好的查询性能。
数据块节点（DPN），DPN和DP之间是一对一的关系。
DPN记录着每一个DP里面存储和压缩的一些统计数据，包括最大值、最小值、null的个数、单元总数count、sum等等。
KN里面存储着指向DP之间或者列之间关系的一些元数据集合，比如值发生的范围（MIin_Max）、列数据之间的关联。
大部分的KN数据是装载数据的时候产生的，另外一些事是查询的时候产生。
在这三层之上是知识网络（KnowledgeGrid），KnowledgeGrid构架是Infobright高性能的重要原因。
KnowledgeGrid可分为四部分，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是否满足查询条件。
如上图所示，比如selectidfromcustomerInfowhereid>50andid<70。
那么很容易就可以得到当前DP不满足条件。
所以Histogram对于那种数字限定的查询能够很有效地减少查询DP的数量。
CMAP是针对于文本类型的查询，也是装载数据的时候就产生的。
CMAP是统计当前DP内，ASCII在1-64位置出现的情况。
如下图所示
比如上面的图说明了A在文本的第二个、第三个、第四个位置从来没有出现过。
0表示没有出现，1表示出现过。
查询中文本的比较归根究底还是按照字节进行比较，所以根据CMAP能够很好地提高文本查询的性能。
Pack-To-Pack是Join操作的时候产生的，它是表示join的两个DP中操作的两个列之间关系的位图，也就是二进制表示的矩阵。
KnowledgeGrid还是比较复杂的，里面还有很多细节的东西，可以参考官方的白皮书和Brighthouse:
ananalyticdatawarehouseforad-hocqueries这篇论文。
Infobright工作原理
前面已经简要分析了Infobright的构架，现在来介绍Infobright的工作原理。
粗糙集（RoughSets）是Infobright的核心技术之一。
Infobright在执行查询的时候会根据知识网络（KnowledgeGrid）把DP分成三类：
相关的DP（RelevantPacks），满足查询条件限制的DP
不相关的DP（IrrelevantPacks），不满足查询条件限制的DP
可疑的DP（SuspectPacks），DP里面的数据部分满足查询条件的限制
下面是一个案例：
如图所示，每一列总共有5个DP，其中限制条件是A>6。
所以A1、A2、A4就是不相关的DP，A3是相关的DP，A5是可疑的DP。
那么执行查询的时候只需要计算B5中满足条件的记录的和然后加上Sum（B3），Sum（B3）是已知的。
此时只需要解压缩B5这个DP。
从上面的分析可以知道，Infobright能够很高效地执行一些查询，而且执行的时候where语句的区分度越高越好。
where区分度高可以更精确地确认是否是相关DP或者是不相关DP亦或是可以DP，尽可能减少DP的数量、减少解压缩带来的性能损耗。
在做条件判断的使用，一般会用到上一章所讲到的Histogram和CMAP，它们能够有效地提高查询性能。
多表连接的的时候原理也是相似的。
先是利用Pack-To-Pack产生join的那两列的DP之间的关系。
比如：
SELECTMAX（X.D）FROMTJOINXONT.B=X.CWHERET.A>6。
Pack-To-Pack产生T.B和X.C的DP之间的关系矩阵M。
假设T.B的第一个DP和X.C的第一个DP之间有元素交叉，那么M[1,1]=1，否则M[1,1]=0。
这样就有效地减少了join操作时DP的数量。
前面降到了解压缩，顺便提一提DP的压缩。
每个DP中的64K个元素被当成是一个序列，其中所有的null的位置都会被单独存储，然后其余的non-null的数据会被压缩。
数据的压缩跟数据的类型有关，infobright会根据数据的类型选择压缩算法。
infobright会自适应地调节算法的参数以达到最优的压缩比。
Infobright的数据类型
Infobright里面支持所有的MySQL原有的数据类型。
其中Integer类型比其他数据类型更加高效。
尽可能使用以下的数据类型：
TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT
DECIMAL（尽量减少小数点位数）
DATE，TIME
效率比较低的、不推荐使用的数据类型有：
BINARYVARBINARY
FLOAT
DOUBLE
VARCHAR
TINYTEXTTEXT
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字段还可以使用commentlookup，commentlookup能够显著地提高压缩比率和查询性能。
Infobrightcommentlookup使用
前面的章节一直涉及到commentlookup，这里将简单介绍commentlookup的使用。
commentlookup只能显式地使用在char或者varchar上面。
CommentLookup可以减少存储空间，提高压缩率，对char和varchar字段采用commentlookup可以提高查询效率。
CommentLookup实现机制很像位图索引，实现上利用简短的数值类型替代char字段已取得更好的查询性能和压缩比率。
CommentLookup的使用除了对数据类型有要求，对数据也有一定的要求。
一般要求数据类别的总数小于10000并且当前列的单元数量/类别数量大于10。
CommentLookup比较适合年龄，性别，省份这一类型的字段。
commentlookup使用很简单，在创建数据库表的时候如下定义即可：
act char（15） comment'lookup',
part char（4）comment'lookup',
Infobright查询优化
前面已经分析了Infobright的构架，简要介绍了Infobright的压缩过程和工作原理。
现在来讨论查询优化的问题。
（1）配置环境
在Linux下面，Infobright环境的配置可以根据README里的要求，配置brighthouse.ini文件。
（2）选取高效的数据类型
参见前面章节。
（3）使用commentlookup
参见前面章节。
（4）尽量有序地导入数据
前面分析过Infobright的构架，每一列分成n个DP，每个DPN列面存储着DP的一些统计信息。
有序地导入数据能够使不同的DP的DPN内的数据差异化更明显。
比如按时间date顺序导入数据，那么前一个DP的max（date）<=下一个DP的min（date），查询的时候就能够减少可疑DP，提高查询性能。
换句话说，有序地导入数据就是使DP内部数据更加集中，而不再那么分散。
（5）使用高效的查询语句。
这里涉及的内容比较多了，总结如下：
尽量不适用or，可以采用in或者union取而代之
减少IO操作，原因是infobright里面数据是压缩的，解压缩的过程要消耗很多的时间。
查询的时候尽量条件选择差异化更明显的语句
Select中尽量使用where中出现的字段。
原因是Infobright按照列处理的，每一列都是单独处理的。
所以避免使用where中未出现的字段可以得到较好的性能。
限制在结果中的表的数量，也就是限制select中出现表的数量。
尽量使用独立的子查询和join操作代替非独立的子查询
尽量不在where里面使用MySQL函数和类型转换符
尽量避免会使用MySQL优化器的查询操作
使用跨越Infobright表和MySQL表的查询操作
尽量不在groupby里或者子查询里面使用数学操作，如sum（a*b）。
select里面尽量剔除不要的字段。
Infobright执行查询语句的时候，大部分的时间都是花在优化阶段。
Infobright优化器虽然已经很强大，但是编写查询语句的时候很多的细节问题还是需要程序员注意。
升级会员 