基于MySQL和Infobright的数据仓库技术
除非你最近在一个荒岛上，否则你不可能不知道，数据仓库/分析/商务智能( BI
)领域正在飞速发展。许多年前，当行业分析师群体调查CIO最优先考虑的事时，BI排第十位
。然而，他于2006年跃升到了第二位，今天，根据Gartner
Group分析已经跃居第一位了。这没有什么神秘的原因：在激烈的经济竞争中所有行业和智能企业需要利用其内部的数据来做出重要的商业决策，包括战术和战
略两方面，以保持行业的领先地位。
但有个问题：在公司组建主要的BI部门将要花费很大一笔资金。很多数据仓库和BI厂商较好的实现你的AMEX金卡态度，对部分IT负责人造成了一些挫折;事实上，2007年信息周刊调查发现， 39 %的IT经理抱怨说，软件许可费用阻碍他们想要推广BI的倡议。
但是进入开源!正如最近，开放源码已经革新了软件的许多领域，几乎为任何公司创造研发操作系统，开发工具，以及数据库，等具有竞争力的IT环境
打开了方便之门，那么现在同样的事情也发生在了数据仓库和商务智能(BI)领域。目睹事实，数据仓库(如对MySQL的一次重大社会和客户调查)目前是
MySQL的第五种最常见的应用。
但这里的另一个统计称：根据TDWI ，数据仓库每年的平均增长速度的介于33和50
%之间，然而这一数据对一些企业来说还是相对比较保守的。现在用于MySQL数据仓库最流行的存储引擎是MyISAM (第二个是InnoDB的)
，当数据达到1TB左右是他的性能依然很优越。在此之后，大量的用户往往将数据仓库分布在多个服务器，以提高性能。现在，从分析公司IDC统计资料来看，
大多数的数据仓库是6TB下(据IDC称只有4 %超过25TB)，因此这意味着大多数人成天都只在管理数百GB和6TB之间的数据仓库。
如果是你，并且你希望有一个基于MySQL的解决方案，那么你应该为亲自去留意一下Infobright存储引擎。
Infobright，MySQL /
Sun公司的合作伙伴之一，供应的引擎能突破MyISAM和其他存储引擎限制，并提供了一个非常尖端的技术(令人吃惊...
)，当进行安装，设置和数据库设计以获得难以置信的快速的反应时间时，你并不需要繁重的工作。
让我们先来看看在Infobright架构，看看它是如何完成这些事情，然后对他进行测试以了解其是如何更好的执行解析式查询。
列非常酷
概括地说，
Infobright存储引擎是一个列导向的架构，结合高速数据装载机，高度的数据压缩和一个灵活的，外部优化器以及'知识网格'
，提供令人印象深刻的数据仓库功能。从MySQL的角度来看，
Infobright就像其他任何存储引擎，因此从界面的角度来看没有什么新的东西要理解。
Infobright是一个单独的安装，然而，从总体MySQL服务器，但它安装很简单(我发现实际速度超过一个标准MySQL的安装)
，以及下载也只有17MB，这是一个非常了不起的引擎，可以管理10万亿字节的数据。
首先要说明的是， Infobright引擎是一列导向的设计。列导向的数据库的存在已经有一段时间(如Sybase公司的IQ )
，但现在才给人以强烈的印象，归功于其能很好的满足数据仓库的需求。2008年3月Infobright研究报告“What’s Cool About
Columns”，菲利普霍华德写道，
“在过去十年，对于大部分使用列导向的做法是非常合理的。不过...我们相信，现在是列走出阴影，成为数据仓库和相关的市场主要力量的时候。”他接着补充
说， “列以较低的成本和更小的封装提供更好的性能：但很难理解，为什么任何公司都对查询性能感兴趣，但从不考虑基于列的解决方案。
为什么要作这样的声明?由于像Infobright这样列导向的设计，在数据仓库环境下真的包含着许多优势。出现这种情况有许多原因，但在这里
仅仅是少数几个。大多数数据仓库/解析查询，只关心一个或多个表中的两列，而不是所有的列。在这种情况下，为数据仓库目的，数据以典型的行格式存储是没有
效率，而更应该采取列导向的格式存储。在像Infobright这样列导向设计的数据库中，全表扫描将永远不会被执行(除非查询请求一个表中全部或大部分
列) ; 可能只需进行全列扫描。最终的结果是更少I / O操作并且提高列导向数据库的响应时间。
Infobright采用列导向的设计并结合任何人都喜欢的其它设计：高强度的数据压缩。因为它是列导向，当Infobright压缩数据，它
对每一列这样做，这通常是比标准的行导向的压缩更有效率，因为压缩算法可被每一列数据类型精调。在正常的行导向的压缩中，你最多看到2或3比1的压缩;但
采用Infobright ，10比1压缩是最基本的(在某些情况下会高得多) ，所以1TB的数据库可以被压缩到100GB
。当Sun性能组一些成员的看到这种性能，他们对Inforbright压缩数据的能力很吃惊，他的性能比他们以往使用过的任何数据库(行导向和列导向)
都要强。当然，数据压缩的结果是，不仅有助于提高性能，同时也有助于降低数据仓据的存储成本，这将受到更多IT经理的青睐。
Infobright的其他技术优势
虽然您可以通过所有标准路线加载数据到MySQL Infobright表，
Infobright还提供了一个特殊的高速装载机，他在加载数据到一个数据库时采用了完全不一样的算法。该加载算法是多线程，使每个列能并行载入。采用
Infobright企业版，单表加载100GB的数据通常需要一个小时，而多表加载一个小时可以实现300GB左右的二进制数据载入，这不是太寒酸。
Infobright社区版已降低载入速度，因为它只能处理文字输入(而不是二进制) ，但你仍然可以看一个小时载入40GB左右数据的速度。
但是，也许在Infobright架构主要的最突出的技术是它的“知识网格”和相应的优化器。
Infobright在数据加载到数据库中(无论初始化或递增)时候就开始建造知识网格。知识网格本质上是数据库中数据和数据统计的一个统计描述。这里关
键要记住知识网格：它可以替代索引，这意味着你永远不需要在Infobright表中创建索引。不用创建索引，这是一件好事!
Infobright知识网格没有索引维护的缺点，从所周知，造成数据库插入和更新的响应时间随着时间的推移而增加的原因，是因为对据库越来越
多的修改操作。另一个优点Infobright在做非常难以预测的查询服务时，做得非常好，这正是许多数据仓库需要处理的。这种查询是数据库管理员的恶
梦，因为他们不能设计一个有效的索引或分割策略，因此数据库性能从来没有到达最大。但随着Infobright
出现，所有这些问题都迎刃而解，因为它能自动完成这些工作。
Infobright的实际数据是按照列存储的。这些列被分为64K的大小，称作数据包，其元数据存储在知识网格。当一个查询提交给
Infobright执行时，优化器咨询知识网格，以便产生一个粗略的想法，哪些数据包包含查询结果集所需的数据。当出现以下两种情况( a
)有相对较少的数据包中包含结果集的数据;( b )优化工具能够准确地确定一系列所需的数据包，查询速度将异常快速。
考虑数据分布方法类似于自动数据分割。再次，这是一件好事。随着Infobright 出现，得到性能优越的数据仓库，你不必是一个数据仓库的设计专家，因为它几乎为你做了所有困难的工作-没有索引或分割战略，这以前都是你工作的一部分。
在某些情况下，查询根本不需要任何数据包就可以执行;只要咨询过知识网格，像这样的查询将立即执行。由于知识网格包含了许多聚合信息，因为在数
据仓库的应用中，聚合是所有查询一个共同的点，对许多数据仓库类型的查询执行来说，很少或根本没有这些必要处理是不寻常的(例子后续下文) 。
Infobright趋向的应用框架是有深的、宽的实际表和低维度表的星型模式(尽管真正的星型设计不需要)，并且数据库中表的设计基本上是非
格式化的。在包括高度标准化架构的应用和更多的随机数据的分布的使用情况下，Infobright可能无法执行。这是因为这些数据不会以数据集中的模式压
缩，并且数据的查询结果集遍布数据库，因此大量的数据包需要被扫描。
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/91250/showart_2004007.html
)领域正在飞速发展。许多年前，当行业分析师群体调查CIO最优先考虑的事时，BI排第十位
。然而，他于2006年跃升到了第二位，今天，根据Gartner
Group分析已经跃居第一位了。这没有什么神秘的原因：在激烈的经济竞争中所有行业和智能企业需要利用其内部的数据来做出重要的商业决策，包括战术和战
略两方面，以保持行业的领先地位。
但有个问题：在公司组建主要的BI部门将要花费很大一笔资金。很多数据仓库和BI厂商较好的实现你的AMEX金卡态度，对部分IT负责人造成了一些挫折;事实上，2007年信息周刊调查发现， 39 %的IT经理抱怨说，软件许可费用阻碍他们想要推广BI的倡议。
但是进入开源!正如最近，开放源码已经革新了软件的许多领域，几乎为任何公司创造研发操作系统，开发工具，以及数据库，等具有竞争力的IT环境
打开了方便之门，那么现在同样的事情也发生在了数据仓库和商务智能(BI)领域。目睹事实，数据仓库(如对MySQL的一次重大社会和客户调查)目前是
MySQL的第五种最常见的应用。
但这里的另一个统计称：根据TDWI ，数据仓库每年的平均增长速度的介于33和50
%之间，然而这一数据对一些企业来说还是相对比较保守的。现在用于MySQL数据仓库最流行的存储引擎是MyISAM (第二个是InnoDB的)
，当数据达到1TB左右是他的性能依然很优越。在此之后，大量的用户往往将数据仓库分布在多个服务器，以提高性能。现在，从分析公司IDC统计资料来看，
大多数的数据仓库是6TB下(据IDC称只有4 %超过25TB)，因此这意味着大多数人成天都只在管理数百GB和6TB之间的数据仓库。
如果是你，并且你希望有一个基于MySQL的解决方案，那么你应该为亲自去留意一下Infobright存储引擎。
Infobright，MySQL /
Sun公司的合作伙伴之一，供应的引擎能突破MyISAM和其他存储引擎限制，并提供了一个非常尖端的技术(令人吃惊...
)，当进行安装，设置和数据库设计以获得难以置信的快速的反应时间时，你并不需要繁重的工作。
让我们先来看看在Infobright架构，看看它是如何完成这些事情，然后对他进行测试以了解其是如何更好的执行解析式查询。
列非常酷
概括地说，
Infobright存储引擎是一个列导向的架构，结合高速数据装载机，高度的数据压缩和一个灵活的，外部优化器以及'知识网格'
，提供令人印象深刻的数据仓库功能。从MySQL的角度来看，
Infobright就像其他任何存储引擎，因此从界面的角度来看没有什么新的东西要理解。
Infobright是一个单独的安装，然而，从总体MySQL服务器，但它安装很简单(我发现实际速度超过一个标准MySQL的安装)
，以及下载也只有17MB，这是一个非常了不起的引擎，可以管理10万亿字节的数据。
首先要说明的是， Infobright引擎是一列导向的设计。列导向的数据库的存在已经有一段时间(如Sybase公司的IQ )
，但现在才给人以强烈的印象，归功于其能很好的满足数据仓库的需求。2008年3月Infobright研究报告“What’s Cool About
Columns”，菲利普霍华德写道，
“在过去十年，对于大部分使用列导向的做法是非常合理的。不过...我们相信，现在是列走出阴影，成为数据仓库和相关的市场主要力量的时候。”他接着补充
说， “列以较低的成本和更小的封装提供更好的性能：但很难理解，为什么任何公司都对查询性能感兴趣，但从不考虑基于列的解决方案。
为什么要作这样的声明?由于像Infobright这样列导向的设计，在数据仓库环境下真的包含着许多优势。出现这种情况有许多原因，但在这里
仅仅是少数几个。大多数数据仓库/解析查询，只关心一个或多个表中的两列，而不是所有的列。在这种情况下，为数据仓库目的，数据以典型的行格式存储是没有
效率，而更应该采取列导向的格式存储。在像Infobright这样列导向设计的数据库中，全表扫描将永远不会被执行(除非查询请求一个表中全部或大部分
列) ; 可能只需进行全列扫描。最终的结果是更少I / O操作并且提高列导向数据库的响应时间。
Infobright采用列导向的设计并结合任何人都喜欢的其它设计：高强度的数据压缩。因为它是列导向，当Infobright压缩数据，它
对每一列这样做，这通常是比标准的行导向的压缩更有效率，因为压缩算法可被每一列数据类型精调。在正常的行导向的压缩中，你最多看到2或3比1的压缩;但
采用Infobright ，10比1压缩是最基本的(在某些情况下会高得多) ，所以1TB的数据库可以被压缩到100GB
。当Sun性能组一些成员的看到这种性能，他们对Inforbright压缩数据的能力很吃惊，他的性能比他们以往使用过的任何数据库(行导向和列导向)
都要强。当然，数据压缩的结果是，不仅有助于提高性能，同时也有助于降低数据仓据的存储成本，这将受到更多IT经理的青睐。
Infobright的其他技术优势
虽然您可以通过所有标准路线加载数据到MySQL Infobright表，
Infobright还提供了一个特殊的高速装载机，他在加载数据到一个数据库时采用了完全不一样的算法。该加载算法是多线程，使每个列能并行载入。采用
Infobright企业版，单表加载100GB的数据通常需要一个小时，而多表加载一个小时可以实现300GB左右的二进制数据载入，这不是太寒酸。
Infobright社区版已降低载入速度，因为它只能处理文字输入(而不是二进制) ，但你仍然可以看一个小时载入40GB左右数据的速度。
但是，也许在Infobright架构主要的最突出的技术是它的“知识网格”和相应的优化器。
Infobright在数据加载到数据库中(无论初始化或递增)时候就开始建造知识网格。知识网格本质上是数据库中数据和数据统计的一个统计描述。这里关
键要记住知识网格：它可以替代索引，这意味着你永远不需要在Infobright表中创建索引。不用创建索引，这是一件好事!
Infobright知识网格没有索引维护的缺点，从所周知，造成数据库插入和更新的响应时间随着时间的推移而增加的原因，是因为对据库越来越
多的修改操作。另一个优点Infobright在做非常难以预测的查询服务时，做得非常好，这正是许多数据仓库需要处理的。这种查询是数据库管理员的恶
梦，因为他们不能设计一个有效的索引或分割策略，因此数据库性能从来没有到达最大。但随着Infobright
出现，所有这些问题都迎刃而解，因为它能自动完成这些工作。
Infobright的实际数据是按照列存储的。这些列被分为64K的大小，称作数据包，其元数据存储在知识网格。当一个查询提交给
Infobright执行时，优化器咨询知识网格，以便产生一个粗略的想法，哪些数据包包含查询结果集所需的数据。当出现以下两种情况( a
)有相对较少的数据包中包含结果集的数据;( b )优化工具能够准确地确定一系列所需的数据包，查询速度将异常快速。
考虑数据分布方法类似于自动数据分割。再次，这是一件好事。随着Infobright 出现，得到性能优越的数据仓库，你不必是一个数据仓库的设计专家，因为它几乎为你做了所有困难的工作-没有索引或分割战略，这以前都是你工作的一部分。
在某些情况下，查询根本不需要任何数据包就可以执行;只要咨询过知识网格，像这样的查询将立即执行。由于知识网格包含了许多聚合信息，因为在数
据仓库的应用中，聚合是所有查询一个共同的点，对许多数据仓库类型的查询执行来说，很少或根本没有这些必要处理是不寻常的(例子后续下文) 。
Infobright趋向的应用框架是有深的、宽的实际表和低维度表的星型模式(尽管真正的星型设计不需要)，并且数据库中表的设计基本上是非
格式化的。在包括高度标准化架构的应用和更多的随机数据的分布的使用情况下，Infobright可能无法执行。这是因为这些数据不会以数据集中的模式压
缩，并且数据的查询结果集遍布数据库，因此大量的数据包需要被扫描。
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/91250/showart_2004007.html