[心得] 近期更新&关于Infobright

新的环境，新的机会，喜欢自由的我现在感觉不错，终于可以自在的记录我想记录的东西了，哈哈~关于GoogleApp的企业套件我也给自己弄了一套，感觉挺不错，和Outlook可以直接整合起来，不过只能以POP3的形式，IMAP的还是不行（国内还是不行啊）

 

最近发现一个不错的东西 [Infobright] ，Mysql的数据仓库解决方案~

 

首先我们来做一些性能测试：

 

测试数据是一个1.5GB大的文本数据，数据格式类似：

用户ID  内容ID  用户打分
765331  3868    5
716091  3868    3
1663216 3868    3
51971   3868    5

在测试数据库中新建两张表，一个为Infobright支持的brighthouse存储引擎，一个为MySQL原生的MyISAM存储引擎，其他 内容一致：

CREATE TABLE `t_ib` (
`uid` mediumint(9) NOT NULL,
`cid` smallint(6) NOT NULL,
`rating` tinyint(4) NOT NULL
) ENGINE=BRIGHTHOUSE;

CREATE TABLE `t_mis` (
`uid` mediumint(9) NOT NULL,
`cid` smallint(6) NOT NULL,
`rating` tinyint(4) NOT NULL
) ENGINE=MyISAM

将数据load进表：

load data infile ‘path/to/data.txt’ into table table_name;

我们比较一下文件大小：

数据类型      数据大小
data.txt      1.5GB
data.tar.gz   429MB
MyISAM表      671MB
Infobight表   280MB

超过5：1的压缩比，虽然没有传说中10:1，但数据的大小比tar.gz过还要小近一半，压缩能力可见一斑。

准备进行SQL的测试，不能在BRIGHTHOUSE存储引擎上建索引，因为根本就不需要建，我们在MyISAM引擎表上建立如下索引：

create index id on t_mis(cid);

执行下列SQL语句，查询内容ID大于9527的条目数（为了节省篇幅，略去结果集，只返回执行时间）：

mysql> select count(*) from t_mis where cid > 9527;
1 row in set (41.81 sec)
mysql> select count(*) from t_ib where cid > 9527;
1 row in set (13.66 sec)

Infobright花费的时间只有MyISAM的1/4左右，再测试一下找出被用户打分最多的10条内容：

mysql> select cid from t_mis group by cid order by count(*) desc limit 10;
10 rows in set (1 min 21.30 sec)
mysql> select cid from t_ib group by cid order by count(*) desc limit 10;
10 rows in set (39.02 sec)

Infobright大概只花费了MyISAM 1/3多一点的时间。再查询一下评价最好的10条内容：

mysql> select cid from t_mis group by cid order by avg(rating) desc limit 10;
10 rows in set (6 min 16.15 sec)
mysql> select cid from t_ib group by cid order by avg(rating) desc limit 10;
10 rows in set (1 min 1.25 sec)

不到1/6时间。

 

下面深入介绍其结构及工作原理：

 

下图是infobright白皮书中展示的系统架构，灰色部分 是mysql原有的模块，白色与蓝色部分则是 infobright自身的。下面说说它的几个主要概念及其相互协作原理。

infobright 架构图

系统结构分析：

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

查询原理（为什么infobright能处理大量数据的查询）：

1. 例如一个infobright表T，按列存储了两列A与B。A包含A1，A2，A3，A4；B包含B1，B2，B3，B4几个Data Pack。
2. 输入一条查询语句：SELECT MAX(B) FROM T WHERE A>3。
3. 根据查询infobright会先把A的知识网格数据取出来，因为A1-4都有相应的知识节点存储其范围，所以仅根据知识网络就能知道哪些数据块 符合A>3这个查询要求。这里假设A1，A2，A3全部符合或半符合（半符合是指根据知识网格无法准确判断）要求。
4. 然后取出B1，B2，B3的知识网格，仅凭知识网格中的max信息即可判断哪个数据块是全部符合或半符合要求的，这里假设是B2。
5. 把B2取出来，解压缩，获取B2中的最大值。
6. 返回结果。