性能测试 监控数据库 分析 合理处理SSAS数据库的几点建议(2)

将超过 2 千万行或大小超过 250 MB 的大分区拆分为较小的分区以改进性能

出处：

(v=sql.105).aspx

这里仅是一个大体的参考，数据行数还需要具体考察每一行的数据两大小。

合理设置维度属性

合理设置维度属性关系，设置刚性或者柔性关系类型。这里主要摘录微软文档中的内容进行简单的介绍。

关于属性维度属性的关系，摘录文档中的一句话：

属性关系具备以下优点：

减少维度处理所需的内存量。 加快维度、分区和查询的处理速度。

提高查询性能，因为存储访问速度更快而且执行计划更优化。

如果用户定义的层次结构是沿关系路径定义的，则聚合设计算法会选择更有效的聚合。

引用地址：

关于刚性和柔性关系的说明，摘录文档中的一句话：

指示成员关系是否随时间而更改。 值为 Rigid 和 Flexible，前者表示成员之间的关系不随时间而更改，后者表示成员之间的关系随时间而更改。 默认值为 Flexible。 如果您将关系定义为 Flexible（柔性），则将删除聚合并作为增量更新的一部分重新计算（如果只添加了新成员，则将不删除聚合）。 如果您将关系定义为 Rigid（刚性），则 Analysis Services 会在增量更新维度时保留聚合。 如果定义为刚性的关系发生了实际更改，Analysis Services 会在增量处理过程中生成错误。 指定适当的关系和关系属性，可提高查询和处理性能。

引用地址：

总体来说，通过属性关系和关系类型的设置，虽然对处理时间的影响不见得最明显，但这都是设计SSAS数据库的一个很好的标准和习惯。

数据粒度提升

有很多项目为了能让数据仓库足够"大"，会把数据的粒度收集的足够细。比如某系统一天收集的数据量就有一个G。而浏览了所有报表之后，发现报表中大多数的时间粒度都是到月，只有部分是到天的。

当然，我不否认数据粒度越细，越容易发现更有用的信息。但是对于SSAS数据库这层，对于通常的统计分析，对数据粒度要求不高，可以考虑将事实数据GROUP到上一级的粒度，比如秒到小时，或者小时到天，依次降低事实数据的数量。

对于确实需要小粒度统计分析的，建议只保留近段时间的数据就可以，这样通常都可以满足大部分需求。而粒度上升到什么层次才合适，建议根据实际的需求然后重新考察数据粒度的确定是否合适。

总之，原则就是，在资源有限的情况下，尽量"把钱用在刀刃上"，然后根据不同需求的不同特点，再去做单独的设计。

数据样本抽取

在开发和测试过程中，没有必要直接把全部的历史数据拿过来做测试。这主要是因为在各个环节中都可能要消耗很多时间等待，后续的开发和测试发现失败或者有错误后，将流程进行修正，还需要再重新完整的跑一遍。

你可以认为，一个流程只要一个晚上能处理完，到第二天上班时能看到结果就可以了。但是，如果后续的测试验证数据流程有bug，那么就意味着还要跑一个晚上，这样项目进度很难保证。即使是一个要跑一个小时的流程，你可以算算一天有几个小时可以反复的开发和测试然后又去验证这个过程呢？

所以这里建议在开发和测试的过程中，只拿一小部分数据，比如在10年的数据中，只取一年或者一个月的，或者在所有产品品牌中，只取一个或者几个品牌做整个项目的BI流程测试，最后验证的也只是这一小部分数据，等这些小数据处理成功后，再去处理完整的数据。

数据的抽取方法，可以在数据源视图中进行限制，也可以通过分区来动态控制。我个人建议选择前者，操作起来比较容易些，不需要经常更改Cube的结构。

总结：

解决处理慢的问题，基本上就是从性能，方法和设计上下手，根据不同的场景可以选择不同的方案。

此外，可以参考这篇《设计警告规则（Analysis Services - 多维数据）》

(v=sql.105).aspx

总之，解决问题的方法很多，这里只列举一些比较常见的问题以及我个人的建议，其它有代表性的问题也欢迎大家列出来在这里做进一步的探讨。

最后，希望这篇对大家有帮助。