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

核心提示：在 SQL Server 2000 分析服务中使用分区SQL Server Enterprise Edition 中的分析服务显式支持分区多维数据集，这种分区多维数据集与关系型数据库中的分区表相当，在Microsoft SQL Server 2000数据仓库中使用分区(4)，对于中等或大型的多维数据集，分区可以大大改善

在 SQL Server 2000 分析服务中使用分区

SQL Server Enterprise Edition 中的分析服务显式支持分区多维数据集，这种分区多维数据集与关系型数据库中的分区表相当。对于中等或大型的多维数据集，分区可以大大改善查询性能、加载性能，并使多维数据集维护更容易。分区可以按一个或多个矢量来设计，但多维数据集通常仅按日期矢量分区。分区多维数据集的渐变加载（包括创建新分区）应该由自定义应用程序执行。

注意：分区可以在本地存储或分布在多个物理服务器上。尽管跨多个服务器的分布式分区对非常大的系统可能有好处，但我们的测试表明，多维数据集尺寸达数万亿字节时，分布式分区解决方案才能提供最大的好处。本文仅考虑本地分区多维数据集。分区多维数据集的渐变加载（包括创建新分区）应该由自定义应用程序执行。

分区的优点

查询性能

对多维数据集进行分区将极大地改善查询性能。甚至中等大小的多维数据集（基于 100 GB 来自关系型数据库的数据）也会从分区中受益。多维数据集分区的优势在多用户加载的情况下更显著。

每个应用程序查询性能的改善随多维数据集结构、使用方式和分区设计的不同而变化。如果仅需要按月分区多维数据集中一个月的数据，那么查询就只访问一个分区。一般情况下，放弃单个分区中的大多维数据集，转而采用精心设计的本地分区策略，我们预计查询性能可以平均改善 100% 至 1000%。

修剪旧数据

对于关系型数据仓库，分析服务系统管理员可能选择仅在多维数据集中保留最新的数据。如果是单个分区，清除旧数据的唯一方法就是重新处理多维数据集。通过按日期矢量分区，管理员可以不关闭系统就丢弃旧分区。

维护

从管理的观点来看，分区是在不影响其他分区的情况下可以被独立添加和丢弃的数据单位。这有助于在系统中管理数据的生命周期。每个多维数据集分区单独存储在一组文件中。由于分区文件相对较小，备份和还原这些数据文件的操作更容易管理。这对大小在 2 GB 以下的分区文件尤为明显。这种情况下，存档和还原实用程序也会有效。如果多维数据集的一部分损坏，或发现这部分包含不正确或不一致的数据，那么可以仅重新处理该分区，这比处理整个多维数据集更为迅速。另外，为节省空间，也可能更改以及合并旧分区的存储模式和设计。

不同的分区可以使用不同的数据源。单个多维数据集可以组合多个关系型数据库的数据。例如，建立企业数据仓库时，可以使来自欧洲和北美的数据驻留在不同的服务器上。如果多维数据集按地理分区，在逻辑上多维数据集可以合并这些完全隔离的数据源。单个多维数据集定义的多个源服务器上的关系架构必须几乎完全相同，这样才能正常工作。

加载性能

可以并行加载多个分区，因此分区多维数据集的加载速度可以比未分区多维数据集更快。后面我们将讨论，要并行处理分区，您必须获取第三方工具或创建一个简单的自定义工具。在多处理器计算机上，性能改善很明显。并行处理工具应该可以将 CPU 利用率提高到 90%。通常情况下，每两个处理器同时处理一到两个分区可获得这样高的性能。例如，在一个所有的处理器都用来处理多维数据集的四处理器的计算机上，您可能希望同时处理两到四个分区。如果试图处理的分区的个数多于您拥有的处理器的个数，性能将显著降低。每两个处理器处理一个分区是比较保守的；理想的数字取决于来自源数据库的数据流的速度、聚合设计、存储和其他一些因素。

在某些情况下，重新创建分区比渐变处理分区效率更高。当然，如果整个多维数据集保留在单个分区中，这种情况发生的可能性很小。

分区的缺点

复杂性

分区的主要缺点是需要管理员创建应用程序来管理分区。在尚未设计、测试和试运行应用程序来管理分区之前，将分区多维数据集投入正式运行是不恰当的。本文的目的之一就是讨论与分区管理应用程序有关的问题和设计决策。

元数据操作

随着分区数量的递增，元数据操作（如浏览多维数据集定义）的性能将下降。对于管理员（而不是最终用户）而言，管理分区多维数据集是一个负担，而管理一个过度分区的多维数据集将是一个难题。

设计时要考虑的因素

分区概述

一个有效的查询计划要权衡多个因素：

分区的数量：分析服务对多维数据集中分区的数量没有实际限制，但管理一个有几千个分区的多维数据集将极具挑战性。另外，当分区达到一定数量时，从多个分区合并结果集的开销将超过分区选择产生的查询性能改善。由于它取决于多维数据集设计、查询模式和硬件，我们很难给出明确的规则来确定这个数量。但是，如果将每 GB 多维数据集存储或每一千万行事实数据划分为一个分区，那多半是安全的。换言之，在适当硬件上的 100 GB 多维数据集（或者 10 亿项事实）应该可以轻松的支持 100 个分区。如果分区设计要求比上述数量更多的分区，我们就应该测试一下其他分区计划的性能。

加载和维护：数据可能沿着某一矢量（例如时间）自然流入多维数据集。要支持分阶段应用程序来填充和渐变更新多维数据集，这些矢量可以是自然的分区片。例如，日期矢量通常是第一个分区矢量。其他应用程序可能接收按地理区域、客户群等分段的数据。因为不同的分区可以使用不同的数据源，多维数据集填充应用程序可以高效地从分布式数据仓库或其他源系统加载数据。

查询性能：设计有效的分区需要了解用户查询的常见模式。理想的分区矢量应对最详细的用户查询具有很好的选择性。例如，由于许多查询都集中在最近的时期内，按日期分区通常可以改查询性能。与此类似，也可能有许多用户按地理或组织进行查询。为了最大限度的改善查询性能，您可能希望查询涉及尽可能少的分区。

如果采用静态的，或者象日期这样变化易于预测的矢量，分区就较容易管理。例如，按“美国各州”进行的分区是相对静态，应用程序设计者可预期并不会收到来自第五十一州的大量警告。相反，由于可能会较频繁地添加新产品，因此按产品矢量划分的分区可能会随时间而更改。设计者仍然可以用动态矢量来分区，但应该认识到管理系统会更加复杂。如果一个矢量被标记为“变化中”，那么就不允许以该矢量进行分区。无论如何，创建“其他”分区来容纳未知矢量成员的数据是明智的。

分区片和筛选

与关系分区一样，必须由管理员来为分析服务分区定义每个分区要包含的数据。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 月的数据加载两次，并且，服务分析不会提示您出现了这种情况。

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

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