UML软件工程组织

在Microsoft SQL Server 2000数据仓库中使用分区
来自 Microsoft
 

上一页  1 2 3 4 5 6 7 8  下一页

  分区片和筛选

  与关系分区一样,必须由管理员来为分析服务分区定义每个分区要包含的数据。RDBMS 使用 CHECK CONSTRAINT 执行此功能;分析服务使用分区片执行此功能。在一个矢量中,分区片被设置为单个成员,例如 [Dates].[1999] 或 [Dates].[1999].[Q1]。在分析管理器向导中,分区片是在标题为“Select the data slice (optional)”的屏幕中设置的。在 DSO 中,可以使用分区矢量级别对象中的 SliceValue 属性访问和设置分区片。本文后面有语法示例。

  每个分区的定义也包括流入该分区的源数据流的信息。分区元数据存储填充分区所需的信息。管理员可以使用分区向导设置数据源和事实表,也可以使用 DSO 编程设置。处理分区期间,SliceValue 属性的设置将自动成为对数据源的筛选。分区定义可以包括一个可选的附加筛选,即 SourceTableFilter 属性,该属性可用于细化填充该分区的查询。处理分区期间,对源数据发出的查询的 WHERE 子句将包括基于分区片定义的默认条件和由 SourceTableFilter 属性定义的任意附加筛选。

  要使分区正常工作,分区片和筛选都必须按顺序正确定义。分区片的作用是改善查询性能。分析服务引擎通过分区片定义中的信息,使查询仅在包含相关数据的分区中进行。在没有已定义分区片的分区多维数据集上,查询将精确解析,但由于缺少分区片定义而必须检查所有的分区,性能并不会得到优化。

  筛选和源元数据的作用是定义流入分区的数据。必须正确定义这些要素,否则整个多维数据集都会包含不正确的数据。处理分区时,分区服务限制存储在多维数据集中的数据,使之与分区片相匹配。但是,不会执行任何检查来确保数据也不被加载到其他分区。

  例如,假设按年对多维数据集进行分区,您错误地将 1998 分区设置为 [Dates].[Year].[1997],但将筛选约束设置为 1998。处理时,分区将包含零行:这并非您所希望的结果。相反,如果您已有一个 1998 年的分区,又添加了一个 1998 年 12 月的新分区,这就很可能将 1998 年 12 月的数据加载两次,并且,服务分析不会提示您出现了这种情况。

  使分区片和筛选对齐并不困难,但分区管理系统的设计者必须意识到这个问题。

  高级分区片和筛选

  大多数分区策略是将一个矢量级别定为分区,将该矢量的每个成员的数据放入各自的分区。例如,“按年分区”或“按州分区”。

  抽取多维数据集某个部分的分区计划也很常见。例如,较新数据可能按日或星期分区,但较旧的数据按月或年分区。

  根据使用方式和数据基数不同,可能会需要设计更为复杂的分区计划。例如,假设客户中的 80% 居住在加利福尼亚、10% 居住在俄勒冈,其余 10% 平均分布在这个国家的其他地区。另外,大多数分析集中在加利福尼亚的客户。这种情况下,管理员可能希望为加利福尼亚创建县级分区、为俄勒冈创建州级分区、为所有其他地区创建一个分区。

  该分区片可能会类似于:

  • California counties: [All USA].[CA].[Amador] ... [All USA].[CA].[Yolo]

  • Oregon state: [All USA].[OR]

  • Rest of the country: [All USA]

  • 如前面所讨论的,必须正确定义源数据筛选,以确保正确填充这些分区。请注意,如果一个查询需要合并加利福尼亚和俄勒冈的数据,那么它可能也需要查看“Rest of the country”分区。尽管服务分析查看“Rest of the country”映射表以了解那里是否有相关数据的花销不大,但如果多维数据集统一按州分区,然后进一步分解 CA(加利福尼亚),查询性能会更好。维护不均匀分区的应用程序逻辑也更加复杂,通常不推荐这种分区方法。然而,如果适当考虑维护应用程序的设计,同时理解查询性能的取舍,这项技术可以用来解决某些特定的设计问题。
   对齐分区

  由于本文的前半部分讨论的是 RDBMS 中的分区,读者很自然地会问服务分区是否必须与关系分区对齐。这两种分区策略不需要完全相同,但如果分区比较相似,分区管理应用程序更容易设计、创建和理解。常见的策略是在两个系统中按日期进行相同的分区,此外可以选择性地按多维数据集中的第二个甚至第三个矢量定义分区片。

  最简单的策略就是使用 UNION ALL 视图作为所有多维数据集分区的源事实表。如果多维数据集分区与关系分区对齐,每个多维数据集分区都可以绕过 UNION ALL 视图直接指向它的相关联的关系分区。在这种配置中,从关系型数据库中提取数据的多维数据集处理查询将运行得最快。这种性能改善办法的代价是维护应用程序需要确保源表与每个分区都正确地相关联。

  如果关系型数据库仅用于填充分析服务多维数据集,并不为其他查询提供服务,系统管理员可以选择不创建和管理 UNION ALL 视图。可适当设计关系表的索引,优化把数据加载到多维数据集的单个查询。这种情况下,关系型数据库的作用更象分阶段区域,而不是完全的数据仓库。

  存储模式和聚合计划

  每个分区可以拥有自己的存储和聚合计划。不经常被访问的数据可以是轻度聚合的,或作为 ROLAP 或 HOLAP 而不是 MOLAP 存储。由于更改这些参数需要重新处理分区,所以按时间渐变加载的多维数据集不大可能沿其分区的时间矢量使用此功能。大多数情形下,处理时间和系统复杂性的开销似乎使得最小多维数据集带来的节约变得几乎没有必要。

  相反,沿其他矢量划分的分区可能具有不同的聚合计划。基于使用情况的优化向导可为每个分区设计聚合方式。系统管理员应该使优化向导集中于最近的分区,并以最近的分区上的每个新分区集的聚合设计作为基础,使聚合设计尽可能新。

上一页  1 2 3 4 5 6 7 8  下一页

 

版权所有:UML软件工程组织