开源MySQL数据仓库解决方案：Infobright

Infobright是一款基于独特的专利知识网格技术的列式数据库。Infobright是开源的MySQL数据仓库解决方案，引入了列存储方案，高强度的数据压缩，优化的统计计算(类似sum/avg/group by之类)，infobright 是基于mysql的，但不装mysql亦可，因为它本身就自带了一个。mysql可以粗分为逻辑层和物理存储引擎，infobright主要实现的就是一个存储引擎，但因为它自身存储逻辑跟关系型数据库根本不同，所以，它不能像InnoDB那样直接作为插件挂接到mysql，它的逻辑层是mysql的逻辑层加上它自身的优化器。

一、Infobright特征

1.大数据量查询性能强劲、稳定：百万、千万、亿级记录数条件下，同等的SELECT查询语句，速度比MyISAM、InnoDB等普通的MySQL存储引擎快5～60倍。高效查询主要依赖特殊设计的存储结构对查询的优化，但这里优化的效果还取决于数据库结构和查询语句的设计。

2.存储数据量大：TB级数据大小，几十亿条记录。数据量存储主要依赖自己提供的高速数据加载工具（百G/小时）和高数据压缩比（>10:1）

3.高数据压缩比：号称平均能够达到 10:1 以上的数据压缩率。甚至可以达到40:1，极大地节省了数据存储空间。高数据压缩比主要依赖列式存储和 patent-pending 的灵活压缩算法.

4.基于列存储：无需建索引，无需分区。即使数据量十分巨大，查询速度也很快。用于数据仓库，处理海量数据没一套可不行。不需要建索引，就避免了维护索引及索引随着数据膨胀的问题。把每列数据分块压缩存放，每块有知识网格节点记录块内的统计信息，代替索引，加速搜索。

5.快速响应复杂的聚合类查询：适合复杂的分析性SQL查询，如SUM, COUNT, AVG, GROUP BY

二、Infobright的价值

1.节约设计开销。没有复杂的数据仓库模型设计要求(比如星状模型、雪花模型)，无需要物化视图、数据分区、索引建立

2.节省存储资源。高压缩比率通常是10:1，某些应用可能达到40:1

3.集成利用广泛。和众多的BI套件相容，比如Pentaho、Cognos、Jaspersof

4.降低运维成本。随着数据库的逐渐增大，查询和装载性能持续保持稳定，实施和管理简单，需要极少的管理

5.商业保证。第一个商业支持的开源仓储分析数据库，是Oracle/MySQL 官方推荐的仓储集成架构

三、Infobright的适用场景

1.大数据量的分析应用。网页/在线分析、移动分析、客户行为分析、分析营销和广告

2.日志/事件管理系统。电信详单分析和报告、系统/网络 安全认证记录

3.数据集市。企事业单位特定数据仓库、为中小企业提供数据仓库

4.嵌入式分析。为独立软件供应商/ SaaS供应商提供嵌入式分析应用

四、Infobright的限制

1.不支持数据更新：社区版Infobright只能使用“LOAD DATA INFILE”的方式导入数据，不支持INSERT、UPDATE、DELETE。这使对数据的修改变得很困难，这样就限制了它作为实时数据服务的数据仓库来使用。

2.不支持高并发：只能支持10多个并发查询，虽然单库 10 多个并发对一般的应用来说也足够了，但较低的机器利用率对投资者来说总是一件不爽的事情，特别是在并发小请求较多的情况下。

3.没有提供主从备份和横向扩展的功能。如果没有主从备份，想做备份的话，也可以主从同时加载数据，但只能校验最终的数据一致性，使得从机在数据加载时停服务的时间较长；横向扩展方面，它本身就不是分布式的存储系统。

五、与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除提供更充分的功能外，据说查询速度也要更快。

六、社区ICE版投产少的原因

社区ICE版，国内各大企业均有测试，投入生成系统的较少，主要有以下原因：

1.对DML、alter语句限制

2.需定时增量load导出导入

3.自带的MyISAM难以支持高并发，若想充分利用服务器资源，需开启另外的MySQL实例

4.对中文等多字节文字支持不好

5.仅支持单核调度

6.缺少原厂的支持

七、ICE与IEE版本区别

IEE包含针对大多数企业工作需求的附加特性，如：更好的查询性能、DML语句支持、分布式导入等。另外，IEE版本还包含了一定级别的Infobright原厂或代理商的支持救援服务、产品培训等。

1.明显的查询性能差异。虽然IEE和ICE版本均具有明显超出例如Oracle、SQL Server、MySQL等行式数据库的查询性能，但IEE还要比ICE版本快50-500%。这个明显差距来自于IEE核心引擎中特有的——多线程调度模块(自IEE3.5引入).而在ICE中，一个独立的查询只能使用单个CPU核心，其他的查询进程只能使用其他核心。对于需要筛选和区分大量数据的复杂查询，使用IEE多线程调度模块可以显著地节约查询时间。

2.支持DML语句。IEE支持标准的SQL 数据操作语言，使用insert、update、delete操控数据。而ICE只支持Load data infile进行数据导入，任何数据的变化都需要重新导入全部数据。DML语句的使用会降低数据查询性能，随次数递增。

3.支持DDL语句。包括alter table rename,add column,drop column（但是列操作只能对最后列生效）

4.支持Hadoop接口（通过DLP）

5.高级复制和高可用。IEE版本包含主从功能，基于SQL statement

6.更简易的导入和更快的导入速度。IEE支持分布式导入工具-DLP；且包含标准的MySQL原生loader，用于处理一些复杂数据的导入，另一方面也说明IBloader的容错性较差

7.Load或DML同时的一致性查询

8.支持临时表

9.其他商业授权，售后支持等

八、Infobright查询优化

1）配置环境：在Linux下面，Infobright环境的配置可以根据README里的要求，配置brighthouse.ini文件。

2）选取高效的数据类型

Infobright里面支持所有的MySQL原有的数据类型。其中Integer类型比其他数据类型更加高效。尽可能使用以下的数据类型：

1.TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT

2.DECIMAL（尽量减少小数点位数）

3.DATE ，TIME

4.效率比较低的、不推荐使用的数据类型有：

5.BINARY VARBINARY

6.FLOAT

7.DOUBLE

8.VARCHAR

9.TINYTEXT TEXT

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字段还可以使用comment lookup，comment lookup能够显著地提高压缩比率和查询性能。

3）使用comment lookup

comment lookup只能显式地使用在char或者varchar上面。Comment Lookup可以减少存储空间，提高压缩率，对char和varchar字段采用comment lookup可以提高查询效率。Comment Lookup实现机制很像位图索引，实现上利用简短的数值类型替代char字段已取得更好的查询性能和压缩比率。Comment Lookup的使用除了对数据类型有要求，对数据也有一定的要求。一般要求数据类别的总数小于10000并且当前列的单元数量/类别数量大于10。Comment Lookup比较适合年龄，性别，省份这一类型的字段。

comment lookup使用很简单，在创建数据库表的时候如下定义即可：

act char(15) comment 'lookup',

part char(4) comment 'lookup',

4）尽量有序地导入数据

前面分析过Infobright的构架，每一列分成n个DP，每个DPN列面存储着DP的一些统计信息。有序地导入数据能够使不同的DP的DPN内的数据差异化更明显。比如按时间date顺序导入数据，那么前一个DP的max（date）<=下一个DP的min(date)，查询的时候就能够减少可疑DP，提高查询性能。换句话说，有序地导入数据就是使DP内部数据更加集中，而不再那么分散。

5）使用高效的查询语句。

这里涉及的内容比较多了，总结如下：

1.尽量不适用or，可以采用in或者union取而代之

2.减少IO操作，原因是infobright里面数据是压缩的，解压缩的过程要消耗很多的时间。

3.查询的时候尽量条件选择差异化更明显的语句

4.Select中尽量使用where中出现的字段。原因是Infobright按照列处理的，每一列都是单独处理的。所以避免使用where中未出现的字段可以得到较好的性能。

5.限制在结果中的表的数量，也就是限制select中出现表的数量。

6.尽量使用独立的子查询和join操作代替非独立的子查询

7.尽量不在where里面使用MySQL函数和类型转换符

8.尽量避免会使用MySQL优化器的查询操作

9.使用跨越Infobright表和MySQL表的查询操作

10.尽量不在group by 里或者子查询里面使用数学操作，如sum（a*b）。

11.select里面尽量剔除不要的字段。

12.避免使用select * from table

13.避免使用union all

14.尽量使用系统提供的函数

Infobright执行查询语句的时候，大部分的时间都是花在优化阶段。Infobright优化器虽然已经很强大，但是编写查询语句的时候很多的细节问题还是需要程序员注意。

九、Infobright导入工具

1.Insert

2.MySQL 导入工具 （@bh_dataformat=’mysql’）

3.ETL工具：http://www.infobright.org/Downloads/Contributed‐Software/

4.Infobright 自身的导入工：CSV格式(@bh_dataformat=’txt_variable’),二进制格式(@bh_dataformat=’binary’)

5.DLP 分布式导入工具（1.6TB/小时）