Project REAL分析服务技术探讨

分析服务2005中的维度缓存

SQL Server 2000和SQL Server 2005各自的分析服务在处理维度成员时，有很大的不同。在SQL Server 2000中，在启动的时候，所有数据库中的所有维度成员都需要被加载到服务器的地址空间上。这种情况下，内存就不能为其它程序提供很好的服务，数据缓存也将超出维度的内存。这样局限性就很大。这意味着，在一个32位的系统上（只有3GB的虚拟地址空间，但分析服务无法意识到这点），你能够具有的所有维度成员最大的数目也就几百万而已。如果你限制你成员属性的数量，并且保持这些属性很短的名称，这样你才可能达到3到4百万个成员。只要超出这个限制，你就不得不使用64位的服务器，以得到更大的虚拟地址空间。这是因为就Item维度就大概包含了七百万个成员。Customer维度大约有5百万条记录。这已经大大超出SQL Server 2000分析服务在32位系统上的承受力。

在SQL Server 2005种，分析服务使用一个动态的维度缓存，并不是将所有的成员都静态的映射到内存中。系统会在成员被要求的时候才把它们加载到内存中。在其它维度成员被请求的时候，会释放先前的成员。我们成功的在32位硬件和64位硬件上构建了整个Project REAL系统（事实上，存在这个系统的很多个版本）。并且对于这种大型系统，在32位系统上也能良好的运转。

我们也发现了那些不能构建到32位系统上的维度。但这里的上限跟SQL Server 2000的上限比，那就要大的多了。这主要取决于用来处理维度键属性的属性层次的hash表。当你使用太多的属性（或者如果属性的规模太大），然后最终超出了可用的内存，这个维度就不能被处理了。

对于维度来说，恰好落到不能被构建的界限里面是因为它们太大以至于不能加载到内存上，下面有两种方法减少需要的内存，来处理它们。

首先，确保所有的属性都确实需要被用来进行分析。如果不是必须的，从维度中去除它们。这能使得Hash表要求的空间更小。

第二，使用级联的属性关系，这样能够最少化属性的数量，因为它们都直接依赖于键。每个属性必须直接地或者间接地关联到一个维度地键。当你第一次创建维度地时候，你将注意到，所有属性都直接地关联到一个键。这也是键属性的特征之一，所有属性都能关联到它。然而，作为为维度定义的自然用户定义层次，一些属性会生成额外的关联。这样，它们既直接关联到键，也通过自然层次，间接的关联到键。例如，如果你清楚Time维度中的Day，你也将知道Year（Year直接被Day暗示）。同时，Day也暗示了Week、也暗示了Month、也暗示Quarter、也暗示了年。因而，在定义自然的用户定义层次后，你就能把Week、Month、Quarter和Year从Day的直接关联中去掉。如果间接的关联存在，就删除直接的关联。

依赖的属性能被移除，因此它们不再直接依赖于键，但它们通过在自然层次中通过属性关联能够间接的关联到键。并且，它们也能从维度的键属性中移除。这是一个很好的例子，详细参见图2。

图2：一个时间维度的良好设计

对比如何将属性关联定义到calendar属性上和如何将属性关联定义到fiscal属性上。绝大部分calendar属性不是直接关联的键属性（Day）的；仅仅只有Week。相反，绝大部分calendar属性能够向上级联到calendar自然层次。Fiscal属性关系也是这样一种情况，只是属性都是直接关联到键属性上的。

这个方法认为calendar属性应该是首选的方法。如果你定义了自然的用户定义层次，或者其它具有级联效果的属性关系，你就必须将直接的关联移除掉。这里有两个原因。首先是这样消耗更少的内存。第二是当集合设计向导（Aggregation Design Wizard）运行的时候，多余的直接关联将导致更慢的集合设计。

属性关联

在图2种，标记了两个属性之间定义的关联。标记了日和周、周和月、月和季以及季和年之间的关联。当你这么定义的时候，这代表了什么呢？有趣的是，这意味着那里有一种多对一的层次关系。只要给定一个周，你就知道有也只有一个月包含这个周；给定一个月，你知道有也只有一个季包含这个月；同样，给定一个季，你就知道有也只有一个年包含这个月。基于此，系统能优化它的计算，因此它能够向上滚动，体现出这种层次关系。

最佳实践：多花点时间用于维度的设计，在维度种捕获这种属性关系

重点：如果你想设计有效的集合；如果你想通过计算引擎，实现有效的计算；或者你想验证MDX时间函数的结果，你就必须定义属性之间的关联。

在SQL Server 2000分析服务中这种基于层次（仅仅支持自然层次）的性质，集合就是根据层次来设计的。在SQL Server 2005分析服务中，集合可以和属性绑定。用户定义的层次是不能使用的。存储设计向导（Storage Design Wizard）使用属性关联来决定什么时候绑定属性向上滚动，这是很有用的（因而，需要为那些属性设计集合）。没有关联，任何一个属性都和其它的属性一样重要，因此，存储向导会简单的忽略属性，并为维度使用All级别。因此，如果你想要设计一个有效的集合，你必须定义属性关联。没有关联，系统仍然会返回适当的数目，但必须在运行的时候才能得到计算的值。这样，集合就没有用了。

当计算复杂的MDX表达式的时候，规则引擎也会用到属性关联。没有属性关联，例如non-empty交叉连接这样的操作不能被优化或者有效的处理。因此，如果你想从规则引擎有效的执行运行时计算，你也必须定义属性关联。

最后，在时间维度中，属性关联也很重要。许多和时间相关的MDX函数只有当属性关联和属性类型被设置正确的时候，才能返回有效的结果。一般地，你能依靠商业时间智能向导（BI Time Intelligence Wizard）来设置适当的结构和关联。无论如何，在你手工的定义时间维度以及使用MDX时间函数的时候，如果你想获得有效的结果，你必须在你的时间维度中定义属性关联。

有两种类型的属性关联。第一种关联类型，也就是到目前为止我们一直在讨论的，当需要设计集合的时候，系统用来表达在哪里向上滚动的关联。如果读者对SQL Server 2000分析服务比较熟悉，他将会注意到，同时还存在另外一种关联类型。这就是类型的成员属性。

例如，在Project REAL的逻辑模式中，我们有一些属性，例如地方经理的名字以及他(她)的电话号码。这些属性被我们分别规格化到Store维度表中。这些属性由于不同的显示目的或者不同的分析要求，因此都是各不相同的，例如地方、地区和仓库等。一些分析是基于地区的，而不是基于经理的电话号码的。当经理名字和电话号码不必用于分析，我们就可以将它们关联到地区。如果你知道经理的名字或者电话号码，然后就将自动的获得经理所在的地区。因而，在这两个属性之间表达了一种关联。然而这种关联对于分析是没有用处的，但对于终端客户工具是有帮助的。因此将这种成员属性表达为关联，必须在适当的位置标识这种关联，以至于当终端用户右键单击成员的时候，客户端工具能够显示成员属性的列表。

总的来讲，为了确保你设计和实现一个能正常工作的系统，就需要指定属性关联。否则，将会带来隐患。

共20页: 6 下一页

【内容导航】

原文：Project REAL分析服务技术探讨(6)