多维数据库分区

在Oracle 和 SQL Server 数据库中都有一个非常重要的概念，分区。分区，顾名思义，就是把数据分布到不同的文件，甚至是硬盘上来存储，以便加速数据的检索。有的同学可能会问，我直接针对查询，创建相应的索引，同样可以达到加速查询的目的。你是对的，但是但是数据量达到几百万，几千万，G，甚至是T 的时候，你怎么样，这个时候，光是索引文件就够我们扫描一段时间的。SQL Server2008在SQL Server2005原来分区的基础上加大了对分区的支持。微软在多维数据库cube中对分区的支持，与relational database一样，强劲，什么在操作上更加简便一些。

SQL Server Analysis Services使用分区来加速MDX查询。每个分区都包含一个XML文件，它定义了某个分区内的成员维度标识范围。当执行一个MDX查询时，Analysis Services引擎将根据每个分区中的XML文件value来决定扫描那些分区文件。  
XML文件是在处理分区时创建的，它存储在每个分区文件夹中。不要试图编辑它，因为维度的关键参考值是内部值，SQL Server Analysis Services不可以进行检索。  
如果MDX查询的数据请求遍布度量组的所有分区时，Analysis Services就不得不读取所有分区。想要知道度量组中哪些分区被读取了，你可以记录一个SQL Profiler追踪。如果查询数据请求只存在于单一分区中，你的查询只需扫描一个分区文件就可以了。  SQL Profiler 确实是一个好东西，他不仅可以检测任何对relational database的请求，还可以检测对cube的MDX query 请求。使用他我们可以做好多东西，如查询的调优等。

为达到最佳MDX查询性能，你应该调整分区设计以适应普通查询。大多数SQL Server Analysis Services方案都以使用数据或周期维度的度量组分区开始，每个分区生成一个月或一天的数据。 
如果你的查询通常集中在某个月内，这不失为一种好的方法。但是如果查询检验所有月份的数据并具体到产品类别该怎么办?这样的话，按月分区并不是最佳方法。  
如果你有十年内的有用数据，并按月分区(这种情况并不常见)，那每个查询将检索120个分区。这种情况下，如果按照产品类别维度来适当增长分区日期跨度，那么查询性能无疑会更好。  
       根据我目前analysis service的经验，我发现美国中国的开发人员对cube partion有一个认识误区，那就是，cube 一定要分区，而且一定根据时间维度来分区。就像上面说的一样，如果你很少在时间维度上来分析，或者时间并不是你唯一关注的维度，为什么不依据其他维度创建更多的分区？

当我们思考创建分区的时候，主要考虑的还是哪些查询是经常使用的，这里顺便强调一下，千万不要随便创建分区，如果数据量不够大，创建分区反而会降低效率，就像创建索引似的，觉得自己创建了这么索引很酷，但是你在增删改数据，还有磁盘资源上都做了重大牺牲。

分区是要管理的，并不是创建好了我这辈子也不理了，如，我很少去查询20年前的数据，当前的2009年的数据，20年后，我就没有必要还把他们保持在不同的分区中了，我只要把他和2008年的合并，或者和前19年的数据合并为一个分区就可以了。这样，不仅可以给我们节省很多磁盘空间，还可以在process cube的时候节省很多时间。多维数据库上的所有操作都是通过 XMLA 来实现的，即请求的发送是以XML片段的形式发送的。下面是一个XMLA例子用来合并两个分区的，

<MergePartitions    
xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">    
  <Sources>    
    <Source>    
      <DatabaseID>Adventure Works DW 2008</DatabaseID>    
      <CubeID>Adventure Works</CubeID>    
      <MeasureGroupID>Fact Internet Sales 1</MeasureGroupID>    
      <PartitionID>Internet_Sales_2002</PartitionID>    
    </Source>    
  </Sources>    
  <Target>    
    <DatabaseID>Adventure Works DW 2008</DatabaseID>    
    <CubeID>Adventure Works</CubeID>    
    <MeasureGroupID>Fact Internet Sales 1</MeasureGroupID>    
    <PartitionID>Internet_Sales_2001</PartitionID>    
  </Target>    
</MergePartitions>