Infobright是一款基于独特的专利知识网格技术的列式数据库。Infobright是开源的MySQL数据仓库解决方案，引入了列存储方案，高强度的数据压缩，优化的统计计算(类似sum/avg/group by之类)，infobright 是基于mysql的，但不装mysql亦可，因为它本身就自带了一个。mysql可以粗分为逻辑层和物理存储引擎，infobright主要实现的就是一个存储引擎，但因为它自身存储逻辑跟关系型数据库根本不同，所以，它不能像InnoDB那样直接作为插件挂接到mysql，它的逻辑层是mysql的逻辑层加上它自身的优化器。
Infobright特征
优点：
- 大数据量查询性能强劲、稳定：百万、千万、亿级记录数条件下，同等的SELECT查询语句，速度比MyISAM、InnoDB等普通的MySQL存储引擎快5～60倍。高效查询主要依赖特殊设计的存储结构对查询的优化，但这里优化的效果还取决于数据库结构和查询语句的设计。
- 存储数据量大：TB级数据大小，几十亿条记录。数据量存储主要依赖自己提供的高速数据加载工具（百G/小时）和高数据压缩比（>10:1）
- 高数据压缩比：号称平均能够达到 10:1 以上的数据压缩率。甚至可以达到40:1，极大地节省了数据存储空间。高数据压缩比主要依赖列式存储和 patent-pending 的灵活压缩算法.
- 基于列存储：无需建索引，无需分区。即使数据量十分巨大，查询速度也很快。用于数据仓库，处理海量数据没一套可不行。不需要建索引，就避免了维护索引及索引随着数据膨胀的问题。把每列数据分块压缩存放，每块有知识网格节点记录块内的统计信息，代替索引，加速搜 索。
- 快速响应复杂的聚合类查询：适合复杂的分析性SQL查询，如SUM, COUNT, AVG, GROUP BY
Infobright的价值
- 节约设计开销。没有复杂的数据仓库模型设计要求(比如星状模型、雪花模型)，无需要物化视图、数据分区、索引建立
- 节省存储资源。高压缩比率通常是10:1，某些应用可能达到40:1
- 集成利用广泛。和众多的BI套件相容，比如Pentaho、Cognos、Jaspersof
- 降低运维成本。随着数据库的逐渐增大，查询和装载性能持续保持稳定，实施和管理简单，需要极少的管理
- 商业保证。第一个商业支持的开源仓储分析数据库，是Oracle/MySQL 官方推荐的仓储集成架构
Infobright的适用场景
- 大数据量的分析应用。网页/在线分析、移动分析、客户行为分析、分析营销和广告
- 日志/事件管理系统。电信详单分析和报告、系统/网络 安全认证记录
- 数据集市。企事业单位特定数据仓库、为中小企业提供数据仓库
- 嵌入式分析。为独立软件供应商/ SaaS供应商提供嵌入式分析应用
限制：
- 不支持数据更新：社区版Infobright只能使用“LOAD DATA INFILE”的方式导入数据，不支持INSERT、UPDATE、DELETE。这使对数据的修改变得很困难，这样就限制了它作为实时数据服务的数据仓库来使用。
- 不支持高并发：只能支持10多个并发查询，虽然单库 10 多个并发对一般的应用来说也足够了，但较低的机器利用率对投资者来说总是一件不爽的事情，特别是在并发小请求较多的情况下。
- 没有提供主从备份和横向扩展的功能。如果没有主从备份，想做备份的话，也可以主从同时加载数据，但只能校验最终的数据一致性，使得从机在数据加载时停服务的时间较长；横向扩展方面，它本身就不是分布式的存储系统。
与MySQL对比
- infobright适用于数据仓库场合：即非事务、非实时、非多并发；分析为主；存放既定的事实，例如日志，或汇总的大量的数据。所以它并不适合于应对来自网站用户的请求。实际上它取一条记录比mysql要慢很多，但它取100W条记录会比mysql快。
- mysql的总数据文件占用空间通常会比实际数据多，因为它还有索引。infobright的压缩能力很强大，按列按不同类型的数据来压缩。
- 服务形式与接口跟mysql一致，可以用类似mysql的方式启用infobright服务，然后原来连接mysql的应用程序都可以以类似的方式连接与查询infobright。这对熟练mysql者来说是个福音，学习成本基本为0。
infobright有两个发布版：开源的ICE及闭源商用的IEE。ICE提供了足够用的功能，但不能 INSERT，DELETE，UPDATE，只能LOAD DATA INFILE。IEE除提供更充分的功能外，据说查询速度也要更快。
社区ICE版，国内各大企业均有测试，投入生成系统的较少，主要有以下原因：
- 对DML、alter语句限制
- 需定时增量load导出导入
- 自带的MyISAM难以支持高并发，若想充分利用服务器资源，需开启另外的MySQL实例
- 对中文等多字节文字支持不好
- 仅支持单核调度
- 缺少原厂的支持
ICE与IEE版本区别
IEE包含针对大多数企业工作需求的附加特性，如：更好的查询性能、DML语句支持、分布式导入等。另外，IEE版本还包含了一定级别的Infobright原厂或代理商的支持救援服务、产品培训等。
- 明显的查询性能差异。虽然IEE和ICE版本均具有明显超出例如Oracle、SQL Server、MySQL等行式数据库的查询性能，但IEE还要比ICE版本快50-500%。这个明显差距来自于IEE核心引擎中特有的——多线程调度模块(自IEE3.5引入).而在ICE中，一个独立的查询只能使用单个CPU核心，其他的查询进程只能使用其他核心。对于需要筛选和区分大量数据的复杂查询，使用IEE多线程调度模块可以显著地节约查询时间。
- 支持DML语句。IEE支持标准的SQL 数据操作语言，使用insert、update、delete操控数据。而ICE只支持Load data infile进行数据导入，任何数据的变化都需要重新导入全部数据。DML语句的使用会降低数据查询性能，随次数递增。
- 支持DDL语句。包括alter table rename,add column,drop column（但是列操作只能对最后列生效）
- 支持Hadoop接口（通过DLP）
- 高级复制和高可用。IEE版本包含主从功能，基于SQL statement
- 更简易的导入和更快的导入速度。IEE支持分布式导入工具-DLP；且包含标准的MySQL原生loader，用于处理一些复杂数据的导入，另一方面也说明IBloader的容错性较差
- Load或DML同时的一致性查询
- 支持临时表
- 其他商业授权，售后支持等
架构
基于MySQL的内部架构 – Infobright采取与MySQL相似的内部架构，下面是Infobright的架构图：
灰色部分是mysql原有的模块，白色与蓝色部分则是 infobright自身的。
Infobright跟mysql一样的两层结构：
- 逻辑层：处理查询逻辑（服务及应用管理）,逻辑层右端的loader与unloader是infobright的数据导入导出模块，也即处理SQL语句里LOAD DATA INFILE … 与SELECT … INTO FILE任务，由于infobright面向的是海量数据环境，所以这个数据导入导出模块是一个独立的服务，并非直接使用mysql的模块。逻辑层的infobright优化器包在mysql查询优化器的外面，如下面将会提到的，因为它的存储层有一些特殊结构，所以查询优化方式也跟 mysql有很大差异。
- 存储引擎：Infobright的默认存储引擎是brighthouse，但是Infobright还可以支持其他的存储引擎，比如MyISAM、MRG_MyISAM、Memory、CSV。Infobright通过三层来组织数据，分别是DP(Data Pack)、DPN（Data Pack Node）、KN（Knowledge Node）。而在这三层之上就是无比强大的知识网络（Knowledge Grid）。
Infobright的模块
- Optimizer优化器。最小化的解压缩数据，有效提高执行计划。
- Knowledge Grid知识网格。存储元数据、列信息、表关系，数据块分布状态统计信息，同等查询状态缓存信息
- Data Pack数据块。真实数据压缩存放位置，按照数据存储块保存
Data Pack（数据块）压缩层
存储引擎最底层是一个个的Data Pack（数据块）。每一个Pack装着某一列的64K个元素，所有数据按照这样的形式打包存储，每一个数据块进行类型相关的压缩（即根据不同数据类型采用不同的压缩算法），压缩比很高。它上层的压缩器与解压缩器就做了这个事情。
Infobright号称数据压缩比率是10:1到40:1。前面我们已经说过了Infobright的压缩是根据DP里面的数据类型，系统自动选择压缩算法，并且自适应地调节算法的参数以达到最优的压缩比。先看看在实验环境下的压缩比率，如下图所示：
整体的压缩比率是20.302。但是这里有一个误区，这里的压缩比率指的是数据库中的原始数据大小/压缩后的数据大小，而不是文本文件的物理数据大小/压缩后的数据大小。很明显前者会比后者大出不少。在我的实验环境下，后者是7:1左右。一般来说文本数据存入数据库之后大小会比原来的文本大不少，因为有些字段被设置了固定长度，占用了比实际更多的空间。还有就是数据库里面会有很多的统计信息数据，其中就包括索引，这些统计信息数据占据的空间绝对不小。Infobright虽然没有索引，但是它有KN数据，通常情况下KN数据大小占数据总大小的1%左右。
既然Infobright会根据具体的数据类型进行压缩，那我们就看看不同的