最近有部分工作涉及到了 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；此外官网上的白皮书不能直接下载，但在搜索引擎中能搜到一些。
转自: http://blog.solrex.org/articles/infobright-data-warehouse.html
