Infobright是一款开源列式数据仓库引擎，采用他们自己的Knowledge Grid架构（一直没有明白这两个单词），该引擎采取内部管理自身优化查询的方式，给用户带来更为轻松的体验。我们所要做的就是写出“漂亮”的SQL，后面我会关于SQL语句说点有趣的东西。

Infobright像很多优秀的开源软件一样，也都具有两个版本，社区版（ICE）和企业版（IEE），多数情况下，如果免费的能满足我们的实际需求，领导更愿意采用社区版；企业版需要付费，那么自然就会给用户提供更加完善的功能、保证运行的稳定性以及良好的后期服务。下面具体介绍一下Infobright在我的实际环境中的应用。

系统环境：CentOS 5.4 64位、 infobright-3.3.1-x86_64-ice、4G内存、8核CPU

Infobright安装：

在http://www.infobright.org/Download/ICE/下载适合的版本，通常我会下载二进制tar包的版本，解压缩后，按照里面有个叫做README的文件，去一步步操作就可以了，各个参数的介绍里面都有，其中，-datadir和-cachdir这两个安装选项，可以将data目录和cache目录安装到我们制定的目录下。（不是我懒得写，真地，是非常简单!）

Infobright目录结构：

解压后，你会发现这不就是一个MySQL吗，infobright-3.3.1是集成于mysql-5.1.40，很自然的就会把infobright理解成MySQL的一个特殊引擎，这又进一步体现出MySQL具有可插拔引擎接口的特点。

cache目录：README里面说是临时文件生成和存放地，但是我一直没有看到里面有文件按出现。

data目录：

bh.err  ――  错误日志这个和MySQ记录启动关闭信息以及一些错误和警告提示，但在infobright中它还有一个特殊的任务就是记录执行计划，因为 infobright没有explain/profile这样的工具。

brighthouse.ini   ――    infobright的配置文件，里面有使用内存大小的分配规则、选择是否开启执行计划记录功能等。

brighthouse.log  ――    这个日志中记录了infobright引擎启动和关闭操作，已经我们在导入数据是遇到的错误。

brighthouse.seq ――    这个文件中记录的数字我也不是很理解；查了下，说是被使用的最大的表的号码。我的那个文件里面是708，在BH_RSI_Repository中，可以找到这样的数字，但是我没有看到708，最大的那个数字就是707。

general_query.log ――  这个和MySQL中的那个什么都能记录下来的日志一样。

slow_query.log  ――   慢查询日志，里面有那个用户在什么时间那条语句的执行时间和锁消耗的时间。

BH_RSI_Repository子目录：里面都是rsi文件，似乎和Knowledge Grid相关，一类是HIST开头的，一类是CMAP开头的。

相关数据库子目录：里面分别是对应各个表的frm文件，和bht目录。

Infobright实际应用：

我们之所以使用数据仓库，是因为目前MySQL数据库中的数据增长很快，定期会对一些历史记录表进行清除，但后期的统计分析还会用到这些历史数据，随着数据量的增大，查询也越来越慢，而数据库仓库特有的存储格式能够减小磁盘空间内的占用，同时列式的特点使得查询速度大为改观。于是，我们就将数据仓库作为存储历史数据的地方。很多数据库仓库软件，基于数据的压缩比和查询速度考虑，我看上了其中两个Infobright和Infinidb，Infobright的压缩比最高（我测试的结果是25：1），但是查询速度慢于Infinidb,Infinidb是所有比较的开源数据仓库中查询速度最优的，但是压缩比远不及Infobright。最后选择Infobright是因为它锁支持的数据类型更多些，更接近于mysql，更节省磁盘空间，毕竟主要的统计查询还不是在数据仓库上，偶尔的查询一下速度倒不是要求最优，但是ICE最大的不变用了后你是不能做DM操作的，这点我深有体会，每次如果插入数据有些不合适的地方，需要删除，你只能drop table，然后从新建表和导入数据，麻烦呀。而Infinidb在这方便就让你很开心。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Infobright遇到的问题：

昨天加班，同事需要在infobright上做一个需求的统计，查询3个月的数据，牵扯到4个表的外连接查询，其中有两张大表都在1亿条以上，结果我的infobright每次执行到2分钟以后就crash掉了，连续尝试了几次，按照查询计划里面的提示，修改的了my-ib.cnf里面的一些参数还是无济于事（我同事一直在嘲笑我的数据仓库，说mysql也比它好，我也觉得很有意思，怎么就被一条语句给弄崩溃了）。我还是很挺infobright的，决定改他的sql，将之前的4个表，我通过一个目标大表和2个小表现做内连接，然后将该结果与另一个大表再做外连接，调整后再查2分钟左右看到结果。这就是我之前说的，我们要给infobright提供漂亮的sql。

之前试图尝试使用infobright与mysql搭建主从复制，考虑到每次手动导来导去的很麻烦，但是没能成功，即便主库mysql的语句已经被记录到relay log中，但由于ICE版不支持DML语句，所以数据也就无法同步过来。

Infobright执行计划：

如果你想知道infobright是如何去处理你发过来的sql语句的，通过开启infobright记录执行计划的功能，便可清楚可见（说实话，不太好看懂-_-0），修改brighthouse.ini配置文件，将ControlMessages = 2，默认是0，不开启执行计划记录，1为详细记录，但不带时间。下面我截了两张执行计划的图，大家可以看看。

第一张是一条内连接sql语句的执行过程；

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

第二张就是infobright垮掉后记录的错误提示。

建议继续学习：

1. 阿里巴巴国际站P4P引擎系统简介    (阅读：3673)
2. 【转】基于lucene实现自己的推荐引擎    (阅读：3490)
3. Infobright的架构    (阅读：2939)
4. MySQL数据库存储引擎和分支现状    (阅读：2832)
5. MySQL Infobright 数据仓库快速安装笔记[原创]    (阅读：2624)
6. MyISAM和InnoDB两种“引擎”的区别    (阅读：2482)
7. JS游戏引擎列表    (阅读：2505)
8. Javascript模板引擎分享    (阅读：2345)
9. Infobright 数据仓库    (阅读：2216)
10. Impala：新一代开源大数据分析引擎    (阅读：2072)