之前的简介与架构分析之后，我做了一些实践，验证infobright用于大量数据存储与查询的可行性。
我是从这里下载的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、分布在高值的数值类型压缩比有限，但要是数据主要分布在低值且分布集中，则可获得可观的压缩比。
查询操作：
select count(*) from tt，不耗费时间，因为infobright存储引擎跟MyISAM一样，是存储记录数目的。
范围查询：select * from tt where xx=xx，有赖于知识网格，infobright对这类查询友好，无论是=<>这些查询还是between，大数据集与小数据集的查询时间差不远。良好的数据可扩展性。
群组操作：select date, count(1) count from tt group by date order by date，在1秒内得到结果，这类操作也是infobright擅长的。
DISTINCT操作：select count(distinct f1) from tt，2千万的数据用了2秒多，全部7亿的数据用了6分半钟。distinct在知识网格里不能存储太多的信息，所以会比较慢，ICE3.1还没有太好的方法，看后面的版本怎么对付这个问题吧。但需知对于大量数据这从来就不是个容易的问题。
全取：select * from tt。这样的操作总是费劲的，因为瓶颈在磁盘IO，但因为infobright的高压缩比，所以取出数据还是要比mysql快不少。（补充：解压缩的过程也很耗费时间）
注意：
从之前的架构分析可以知道，infobright的查询条件越多越好，越有区分度越好，因为这样经过对知识网格过滤之后，需要取出来解压缩查询的数据块就少了，速度就上来了。
尽量使用范围性的查询，因为这些知识就存储在知识网格里。
要对varchar之类的文本类型进行查询，最好先用其它类型把范围缩小。
ICE3.2刚出来，据说查询速度有了较大提升，等源代码包放出来再研究研究。