最近看了一篇文章，介绍了SQL Server 2008 R2提供的并行数据仓库；看了一下原理，和Greenplunm类似，都是基于massively parallel processing (MPP)架构；主要的思想就是分布和并行。这在Big Data盛行的今天，无疑大大增强了传统RDBMS对大数据的处理能力。对于大数据来说，处理性能固然重要，但是丰富计算功能，以及简单易用这一点也不容忽视。很明显，传统RDBMS提供的SQL接口无论是在易用性、以及计算功能上都是要强现有的Greenplunm、hive等产品的。
个人觉得，传统的RDBMS接合MPP架构更适合数据仓库这类应用。
不过遗憾的是Oracle到现在都还没有提供并行数据仓库功能(我们所熟悉的RAC只不过是基于SMP的)。那使用Oracle的我们除了加大机器的配置就没有其它办法了么？
答案当然是否定的，在互联网领域，对于提高数据库的并发，有一个很常见的手段－分表、分库，其背后的原理不就是分布和并行么？
那数据仓库能不能这按照这样的思路来做呢？
有人说互联网分表和分库是因为数据间没有关系，可以单独存放；而数据仓库则不一样，维表和事实表之间是有主外键关系的，分表分库之后的跨库查询性能会非常差！
初一想的确是这样，不过呢，我们有变通的方法的！
既然维表和事实表之间有主外键关系，且跨库查询性能低下；那么我们就避免它呗。
一个简单的思路就是，对于事实表进行分表、分库。而对于维表则不分表，取而代之的是在每个库里都存一份完整的拷贝(一般来说这是可行的，因为维度是数量不会太大)。
举个简单的例子，事实表总共有10年的数据，单独放在一台server上处理起来可能有点吃力；但是如果一台server只有两年的数据，也许处理起来就会比较轻松了。
那么好，我们按时间进行最简单的事实表分表，同时在分到5个单独的数据库上，每个数据库上存2年的数据。
同时把所有维表都分别在每个数据库中存一份，这样对于单台数据库上的事实表来说，他们可以直接同库上的维表进行关联而无需跨库查询。
这种分表的方式呢比较简单，如果用户的大部分查询的时间范围都在2年之内，这样很明显并不能发挥多台机器的性能，因为始终只会去访问一台机器(2年内的数据在一台上已经全部包括了)；这个时间我们就可能需要考虑一下另外的分表方式了。
表分好了，现在让我们来回答一些业务上的问题，这10年的销售额是多少？
额，这下好像麻烦了，以前在一台数据库上的时候，我们只需要一个简单的SQL就搞定了，现在得发5条SQL，得到5个值，最后在把这5个值加起来才是我们要的结果，我列个去。。。。
擦，现在怎么办？
回到我们的题目来吧，因为我们用的是BIEE，所以这个问题是很好解决的
。
还记得BIEE中逻辑层中，逻辑表源的碎片功能么？
首先，在物理层把5个数据库的表都导进来，分别建立关联(此时应该是5个星型)；类似于下图所示：
注：上图仅为2个库的示例
我们新建一张逻辑表(事实表)，然后在建5张逻辑表源，分别指向不同数据库中的表，并写好碎片中的碎片条件(要与分表的条件相同)。
接下来创建逻辑维表，并将5个数据库中名字相同的物理维表作为其逻辑表源(逻辑维表则无须设置碎片功能)。
OK，至此，我们已经把它们在逻辑上整合成了一张表。最终对于用户来说，也是一张表。而BIEE会根据前端用户的问题生成不同的SQL，
之前10年的销售问题，BI Server则会生成5条SQL分别发送到对应的数据库服务器，最终BI Server会把返回的5个结果集合并成一个结果集返回给用户。
这样一来，总的执行时间就等于，单条SQL最大执行时间+BI Server的合并时间，理论上相当于之前只有一台服务器的1/5(忽略合并时间)。
这样就相当于实现了MPP！
有人可能会说了，你这个BI Server合并结果集的性能会是一个问题吧？是的，这可能会是一个问题，但是一般情况下，由于结果集不大，所以性能不会是问题。
当然了，这只是一般情况下。
到这里我们可以看到，结合前端工具来实现MPP，需要前端功能支持类似于BIEE的这种多路SQL的功能，这是关键。
其实BIEE的碎片功能还有另外的用途，比如说用来实现实时BI，至于怎么实现，请听下回分解。