infobright原理Word文档格式.docx
《infobright原理Word文档格式.docx》由会员分享,可在线阅读,更多相关《infobright原理Word文档格式.docx(7页珍藏版)》请在冰豆网上搜索。
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'
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优化器虽然已经很强大,但是编写查询语句的时候很多的细节问题还是需要程序员注意。