群集列存储索引是否会影响SSAS查询最终用户性能

Question

群集列存储索引是否会影响最终用户的SSAS性能查询，以及如何解决此问题？阅读下面的文章，排序顺序如何影响SSAS查询客户用户的表现。

有什么方法可以解决这个问题吗？

重建SSAS索引/聚合是否有效？已经知道将数据仓库中的多维数据集处理到SSAS的时间会受到影响。真正关心的是终端客户 - 用户SSAS查询体验。

目前在SSAS Cube中实现Multidimension模型。

• Cube processing is slower and produces larger measure groups after switching relational source to Columnstore indexes

Answer 1

这得看情况。让我们从问题定义开始。

• 当在处理步骤上馈送有序数据时，SSAS多维执行得更好。这个article为您提供了数据排序的原因和见解。
• SSAS索引和聚合处理不会修复未订购的源数据;因此，它不会解决上述问题。这些处理任务基于接收到的数据构建工件，并且无法修复数据本身的问题。
• MS SQL Columnstore Index大致是一种新的存储技术 - 应用于堆表的列存储压缩。与具有聚集索引的表相比，这提供了快速插入（无索引，无需预先排序）。缺点 - 具有聚簇索引的表上的SELECT查询可能会返回在聚簇索引基础上排序的行（除非您使用ORDER BY语句设置排序），而Clustered Columnstore表上的相同查询将产生未排序的数据。 带有Clustered Columnstore索引的未排序数据的这个问题不仅影响SSAS，而且当CCI可以执行所谓的段消除时，它会降低查询性能。有一些技术可以解决这个问题 - 在将常规表转换为CCI或将数据加载到CCI表之前对数据进行排序。
• discussion you mentioned的主要问题是数据排序是通过SQL级别的其他视图完成的。然后作者在SSAS上定义分区，并报告SSAS生成的查询具有次优的执行计划。

关于无序数据的SSAS性能。它肯定不是最理想的，但在多大程度上呢？事实上，只有测试会显示出来;它可以取决于多种因素 - 初始数据集，立方体设计，最终用户查询。立方体结构的增长将减缓运营速度，但是多少？根据经验 - 如果cube是100+ GB并且其最大的分区/度量组超过SSAS使用的RAM的10％，我会费心并努力提供数据排序。在其他情况下，我不会打扰这样的问题。

从CCI订购数据。首先，避免使用过时的语法

SELECT TOP 2147483647 ... FROM ... ORDER BY ...  

使用ANSI兼容且限制较少

SELECT ... FROM ... ORDER BY ... OFFSET 0 ROWS  

关于在SSAS分区定义中使用时的次优执行计划。不幸的是，SSAS查询生成引擎不允许神奇的option (recompile)。同样，如果这是一个严重的问题 - 定义表值函数（参数视图）以实现最佳执行计划，并在SSAS分区定义中使用此TVF。

如果这是项目的第一次实施 - 我会没有这样的措施，并将其作为项目风险报告，需要注意生产和可能 - 之后的额外努力。

不幸的是，重建SSAS索引/聚合不会改善这种情况。在进入SSAS时，您需要对数据库查询级别的数据进行预排序。