MDX性能与T

Question

我有一个数据库，其中包含有6亿多条记录的表和一组在数据库上进行复杂搜索操作的存储过程。即使在表上有适当的索引，存储过程的性能也是如此缓慢。数据库的设计是一种普通的关系型数据库设计。我想将数据库设计改为多维的，使用MDX查询而不是传统的the查询，但问题是：在性能上是否优于传统的the查询？如果是，这将在多大程度上提高查询的性能？

谢谢你的帮助。

Answer 1

苹果和桔子:分析服务OLAP多维数据集是一种与Server数据库根本不同的存储类型，它们被设计用来做不同的事情。从技术上讲，MDX并不比they“快”，反之亦然--它们只是语言，但针对不同的需求而设计。

话虽如此，多维数据集通常是对静态数据进行数值分析的最佳方法，例如聚合大量的销售/事务/任何记录。相反，如果模式和索引构造得很好，则传统的关系数据库通常工作得很好，以便进行搜索。判断的一个简单方法是:如果您的SQL查询需要执行大量的

select grock, sum/min/max/avg( foo ) 
from bar 
group by grock -- Ideal Analysis Services problem

然后，多维数据集可能会有所帮助(它是为聚合数学函数- sum()和group而设计的)。如果您的查询做了大量的

select cols 
from foo 
where <complicated search> -- Not so much

然后，多维数据集可能不会有帮助，我将重点放在调优模式、查询和索引，以及如果数据可以适当地分区的话，也许还可以进行表分区。

是否有与查询匹配的聚集索引和覆盖非聚集索引？

Answer 2

多维数据集可用于多种存储模式：

1. Relational (OLAP) --数据和元数据保留在DB中，很少添加更多的物化视图。
2. 混合(HOLAP)元数据和(预计算的)聚合存储在运行SSAS实例的新服务器上。这将加速使用聚合的所有查询，比如“去年按月计算的员工总时数”，但是深入到特定记录的查询可能是before.
3. Multi-dimensional OLAP，其中您的所有数据以及元数据和聚合都被复制到SSAS服务器上。这通常是最快的，但会重复存储。

在开始之前，您应该考虑优化用于报告和分析的表布局，换句话说，使用数据仓库(DW) --将数据放在Kimball星型维度和事实表中。然后定期使用ETL(SSIS)加载DW，并将报告和分析指向DW。您可能根本不需要使用SSAS --对星表布局运行的SQL查询通常比针对规范化DB的SQL查询快得多。如果这仍然太慢，请在DW之上构建SSAS多维数据集。一旦您开始加载您的数据仓库，您可能能够删除您的操作数据库的记录，使它更快的每一天使用。

总之，我的经验法则是：

1. 构建DW并设置您的ETL进程
2. 针对DW尝试T报告，这可能足够好。如果
3. 仍然运行缓慢，则在HOLAP模式下构建SSAS多维数据集(DW之上)，并使用MDX查询它们。

Answer 3

“即使有适当的索引，存储过程的性能也是如此缓慢”

如果存储过程是真正的问题，我会感到惊讶，也许使用过程的方式是缓慢的，但是根据定义，存储过程并不会使它变慢。你有没有发现你的程序很慢？你的侧写了吗？在重新设计我的数据库之前，我会仔细研究一下这条路线。多维数据库是用于OLAP的，您的数据库严格来说是OLAP数据库，还是OLAP和OLTP的混合体？也许您需要将OLTP设计中的数据非规范化并复制到非规范化的d结构中?一个表中的6亿条记录一点也不庞大，并不小，但这并不能让我相信丢弃存储过程会神奇地使事情变得更快。在进入一个更大的项目来解决这个问题之前，对存储的过程进行分析，看看性能瓶颈在哪里。