试验环境：gentoo, ICE3.2

试验前提：

建立了两个库db1和db2，两个库内有一个同名表testlog，两个表存储的数据类型除了BID一个字段之外其余都是一样的。db1的BID字段是BIGINT型，db2的BID字段是VARCHAR(12)型。BID字段实际是一段cookie，原本是字符串类型的，在python里通过

struct.unpack(‘Q’, base64.b64decode(bid[:12])[0])

把它转换为BIGINT型。

说明：

在mysql里，INT占用4个字节，BIGINT占用8个字节，VARCHAR(12)占用12个字节。

测试查询涉及的总记录条数：414360862

查询语句：select distinct uid from weblog where date between ‘xxxx’ and ‘xxxx’ and bid=”xxxxxxx”。bid条件根据类型为BIGINT或VARCHAR而不同。

衡量指标：查询效率、查询时载入数据量、占用硬盘空间量（因为db1和db2总数据量有差异，这个指标以BID/另一个INT字段容量的比率来衡量）。

ICE配置：db1和db2两个服务的配置都是一样的，ServerMainHeapSize=10000M

BIGINT：

查询后载入数据占内存空间4112M， 查询效率：126 rows in set (2 min 32.17 sec)

相对另一INT字段的空间占用量比率：1.43

VARCHAR(12):

查询后载入数据占内存空间7266M，查询效率：126 rows in set (9 min 18.84 sec)

相对另一INT字段的空间占用量比率：2.04

结论：能用INT/BIGINT的就用它们吧，减少varchar或text了。

另外一个就是把nurl从数字恢复为原来的字符串（varchar），做成lookup columns以减少存储空间，当然导入前要做些预处理，把出现频率少的置空，因为lookup columns的distinct个数不能超过10000个。这下子就可以对nurl字段作like ‘/pattern/%’这类前缀查询了。

自我感觉，这两个SORT和LOOKUP优化相当成功。又得要花几天的时间来重导数据啦！

所谓lookup columns相当于把具体的值定义为一个索引，一串字符串就可以只用一个数字索引来表示了。它只对显式定义为char或varchar的字段适用。定义方法是在该列定义的最后加上COMMENT ‘lookup’。注意的是这种定义只适用于行数很多但实际出现不同的值很少的字段，也即count(item)/count(distinct(item))非常大。典型的例子如类别、性别、年份字段。count(distinct(item))大于10000的则一定不要使用。

1. 先把一个旧表的数据导出来，依据旧表的结构建了一个新表，给新表的几个字段加上lookup属性，再把原数据导入到新表。用show full columns from table_name可以查看新表和旧表各个字段的实际占用空间及压缩率。我的新旧表对比结果如下：
   • 原来一个char(4)的字段，加上lookup columns定义后压缩率有较大的提升。
   • 两个char(1)的字段，压缩率稍有提升，但是不是很明显，原因可能是作为索引的数字也是一个字段来表示。
   • 原来一个tinyint字段的数字，为了能用lookup，改为用char(1)定义。查询时可以用 … where x in (’2′, ’3′)的方式，也可用… where x > 1的方式，不过应该是按照ascii码比较而不是按照数字比较。
2. 再改一下sorting的顺序，假设这次以（cat, rating, dt）三个字段排序的方式来导入数据，cat字段和rating字段是lookup columns，dt是INT。这次得到的结果比较有代表性，cat字段得到了最大的压缩，压缩率为999.9，实际表示已经超过1000。类似地rating和dt字段都得到了极大的压缩，这说明字段是否有序对压缩率影响巨大。随后我的实验表明sorting对查询效率也会有很大的影响，比如在这种排序情况下，对cat的查询效率得到最大优化，对rating和dt也有一定程度的优化。从infobright的存储与查询原理也很容易得出这点。

补充一下，如果数据量不大（比如少于百万），可能这些效果都不明显。

转载请保留本文原始链接：http://www.wentrue.net/blog/?p=418

从这里把源代码包下载下来，就是那个名为*64src-ice*的包。

解压，以下参考解压后目录的README文件操作即可，编译安装都很方便。需要注意的是最好自己配置一下my-ib.conf文件，修改datadir指向一个空间比较大的磁盘，因为用infobright就是为了处理大数据量的。如果原来已经安装过mysql，默认的3306端口会被占用，所以port属性也得改一下。安装完成之后datadir下有一个brighthouse.ini文件，会让初用者很茫然，其实最主要是设置好几个内存参数，可参看这里的叙述。

装好之后，我把用3.1版里的整个datadir打了个包，再解压缩到3.2版的datadir目录，就可以在新版本里使用原数据库了。实际上，据官方文档所说，最简单的升级是只要把编译好的mysqld和loader置换原来的即可。

然后试验3.2版的查询，以我使用的几个查询来看，查询速度提升了一倍左右，不见得有官方所说的提升10倍。但官方说的是“对于某些原来耗时1个多小时的只需要数秒，有些20分钟的查询只要一秒不到“，也有可能是我使用的范围还不是这次升级所覆盖的范围。

转载请保留本文原始链接：http://www.wentrue.net/blog/?p=388

我是从这里下载的infobright开源版本ICE3.1（据说刚出的ICE3.2查询速度更快）。用DEB包在ubuntu装过一个，后来觉得内存不够大体现不出它的优势，就下载了源代码包在64位的gentoo服务器编译安装了一个。编译源代码的话，按照压缩包里的README文件做就行了，基本没遇到什么问题。

装好之后，要作一些配置，才能使它发挥出最大的效能。我从源码安装好之后在/usr/local/infobright/share/mysql/有一个brighthouse.ini文件，那就是用来配置infobright运行时参数的（DEB包安装的没注意找放在哪）。把这个文件拷贝到infobright服务配置文件my-ib.conf定义的data-dir目录下。

brighthouse.ini的几个主要参数如下：

• ServerMainHeapSize：服务进程的主堆栈空间，存储临时数据，如果可能，尽量把它设置得大一些，以免跟磁盘的IO过多。
• ServerCompressedHeapSize：服务进程的压缩堆栈空间，存放压缩数据。
• LoaderMainHeapSize：infobright独有的数据loader进程的堆栈空间。

自带的brighthouse.ini有一些根据不同系统的推荐值，要注意给系统其它进程留下空间，以免得使用swap区会使效率大大下降。我32G内存的系统当16G来用，设置参数为：

• ServerMainHeapSize：10GB
• ServerCompressedHeapSize：1GB
• LoaderMainHeapSize：800MB

内存自然是越大越好。但在我的实验环境下服务进程从未超过5G，可以认为infobright应对我实验这些数据量完全不在话下。

运行服务：sudo /usr/local/infobright/bin/mysqld_safe –defaults-file=/etc/mysql/my-ib.cnf –user=mysql

以下对一个包含7亿条记录的数据表tt进行实验，原数据文本大小约为100G，infobright存储的压缩文件总共占空间14G，压缩比超过7（其中有一些我自己的数据转换）。

tt表包含了DATE、TIME、INT、BIGINT、TINYINT、SMALLINT、MEDIUMINT、FLOAT、VARCHAR等多种数据类型，正好拿来对比（TEXT等类型就不要拿来捣乱了）。现在看看infobright针对不同类型的数据采用不同压缩算法的威力：

• DATE：因为实际中不同的DATE非常少，而且是连在一起的，所以infobrigt把这个字段的信息绝大多都以统计信息的形式存放于知识网格（Knowledge Grid），这个字段的数据文件大小为1.4K！！！
• TIME：TIME类型与DATE类似，但不同的TIME比DATE多，所以它的数据文件的大小是3.6M。
• INT：4个byte的INT视实际情况而定，从几百M到1G多不等。
• MEDIUMINT(3 byte)、SMALLINT(2 byte)、TINYINT(1 byte)：通常都比INT小。
• BIGINT：8个byte的bigint在tt表里有将近2G的大小。
• FLOAT：4个byte的FLOAT占空间跟INT差不多。
• VARCHAR(255)：基本都是在3G以上。

压缩包的大小直接影响了解压缩时的效率以及IO量。所以：1、能用小类型就不要用大类型；2、尽量少用varchar；3、分布在高值的数值类型压缩比有限，但要是数据主要分布在低值且分布集中，则可获得可观的压缩比。

查询操作：

1. select count(*) from tt，不耗费时间，因为infobright存储引擎跟MyISAM一样，是存储记录数目的。
2. 范围查询：select * from tt where xx=xx，有赖于知识网格，infobright对这类查询友好，无论是=<>这些查询还是between，大数据集与小数据集的查询时间差不远。良好的数据可扩展性。
3. 群组操作：select date, count(1) count from tt group by date order by date，在1秒内得到结果，这类操作也是infobright擅长的。
4. DISTINCT操作：select count(distinct f1) from tt，2千万的数据用了2秒多，全部7亿的数据用了6分半钟。distinct在知识网格里不能存储太多的信息，所以会比较慢，ICE3.1还没有太好的方法，看后面的版本怎么对付这个问题吧。但需知对于大量数据这从来就不是个容易的问题。
5. 全取：select * from tt。这样的操作总是费劲的，因为瓶颈在磁盘IO，但因为infobright的高压缩比，所以取出数据还是要比mysql快不少。（补充：解压缩的过程也很耗费时间）

注意：

• 从之前的架构分析可以知道，infobright的查询条件越多越好，越有区分度越好，因为这样经过对知识网格过滤之后，需要取出来解压缩查询的数据块就少了，速度就上来了。
• 尽量使用范围性的查询，因为这些知识就存储在知识网格里。
• 要对varchar之类的文本类型进行查询，最好先用其它类型把范围缩小。

ICE3.2刚出来，据说查询速度有了较大提升，等源代码包放出来再研究研究。

转载请保留本文原始链接：http://www.wentrue.net/blog/?p=289

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. 返回结果。

下次再介绍一下这些天我使用infobright的一些实践经验。

转载请保留本文原始链接：http://www.wentrue.net/blog/?p=291

根据这几天看到的介绍与白皮书，又做了些试验，依据自己的理解先作一个概述性的介绍，下次再描述一下infobright的技术架构。

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

几大优点：

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

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

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

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

与mysql对比：

1、infobright适用于数据仓库场合，即非事务、非实时、非多并发；分析为主；存放既定的事实（基本不会再变），例如日志，或汇总的大量的 数据。所以它并不适合于应对来自网站用户的请求。实际上它取一条记录比mysql要慢很多，但它取100W条记录会比mysql快。

2、mysql的总数据文件占用空间通常会比实际数据多，因为它还有索引。infobright的压缩能力很强大，按列按不同类型的数据来压缩。

3、服务形式与接口跟mysql一致，可以用类似mysql的方式启用infobright服务，然后原来连接mysql的应用程序都可以以类似的方式连接与查询infobright。这对熟练mysql者来说是个福音，学习成本基本为0。

infobright有两个发布版：开源的ICE及闭源商用的IEE。ICE提供了足够用的功能，但不能INSERT，DELETE，UPDATE，只能LOAD DATA INFILE。IEE除提供更充分的功能外，据说查询速度也要更快。

参考：

1、infobright商业网站：http://www.infobright.com/

2、infobright社区交流网站：http://www.infobright.org/

3、mysql对infobright的介绍：http://dev.mysql.com/tech-resources/articles/datawarehousing_mysql_infobright.html

4、关于infobright的介绍视频：http://www.infobright.com/Resource-Library/Webcasts-Podcasts/?infobright_product_demo

转载请保留本文原始链接：http://www.wentrue.net/blog/?p=283