最近有部分工作涉及到了 Infobright 数据仓库，就浏览了一些相关的资料，感觉很受启发。下面写一些感想，如有谬误，还请指正。

    简单的来讲，Infobright 主要有下面的一些优点：

    1. TB 级的数据存储和高效查询。大数据量存储主要依赖自己提供的高速数据加载工具(百G/小时)和高数据压缩比(>10:1)，高效查询主要依赖特殊设计的存储结构对查询的优化，但这里优化的效果还取决于数据库结构和查询语句的设计。

    2. 高数据压缩比，号称一般能够达到 10:1 以上的数据压缩率。高数据压缩比主要依赖列式存储和 patent-pending 的灵活压缩算法。

    3. 与主要 BI 分析工具的兼容性。兼容性这点主要依赖与 MySQL 的集成，作为 MySQL 的存储引擎自然地能够保证与 BI 分析工具的兼容。

    除了上面的优点外，它也有一些限制：

    1. 不支持数据更新。这使对数据的修改变得很困难，这样就限制了它作为实时数据服务的数据仓库来使用。用户要么忍受数据的非实时或非精确，这样对最(较)新数据的分析准确性就降低了许多；要么将它作为历史库来使用，带来的问题是实时库用什么？很多用户选择数据仓库系统，不是因为存储空间不够，而是数据加载性能和查询性能无法满足要求。

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

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

    在架构方面，Infobright 给我展示了不少新想法，算是受益颇多吧。首先是按列存储，然后把列数据切成小块(Data Pack)，进行压缩和统计(DPN, Data Pack Node)，然后再对多块数据之间进行知识关联(Knowledge Node)，最后对整个表形成知识网格(Knowledge Grid)。虽然说 Infobright 没有提供索引结构，但它 Knowledge Grid 中的 Numerical Histogram、Character Map 和 Pack-to-Pack 结构，怎么看都和 bitmap 索引脱不了关系。只是它的组织形式不像传统数据库中的索引罢了。

    其实我们在设计类似的分布式表格系统时，也可以实现类似于 Knowledge Grid 的结构。这个结构未必跟 Infobright 的一样，但是如果在压缩的基础上，基于系统查询模式(分布式系统的查询模式一般相对简单，复杂的也做不来)，存储一些辅助的块统计信息以及块之间的关联信息，对于减少查询的资源消耗，提高查询效率会非常有帮助，这也正好是针对分布式表格系统很难建立索引这一缺点的弥补。

    参考链接：

    这篇文章对 Infobright 及其安装方法进行了基本介绍，最后的一个查询速度对比有些夸张(105:1)，我觉得这可能跟查询条件正好能匹配上 Knowledge Grid 中的信息所致；这个博客很有趣，从 2010 年 3 月 8 日到 5 月 8 日之间的文章全是 Infobright 相关的，写的还是挺详细的；Brighthouse: An Analytic DataWarehouse for Ad-hoc Queries 是一篇相关的 08 年 VLDB paper；此外官网上的白皮书不能直接下载，但在搜索引擎中能搜到一些。

建议继续学习：

1. 列式数据仓库引擎之Infobright    (阅读：3552)
2. Infobright的架构    (阅读：2949)
3. MySQL Infobright 数据仓库快速安装笔记[原创]    (阅读：2636)
4. Infobright 数据仓库心得总结    (阅读：1898)
5. 关于Infobright 的几种数据格式    (阅读：1729)