sql-server - 聚集的列存储索引是否影响SSAS查询最终用户性能

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

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

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

当前在SSAS Cube中实现多维模型。

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

最佳答案

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

当在处理步骤中馈入有序数据时，

SSAS多维性能更好。此article提供了原因以及对数据排序的见解。

SSAS索引和聚合处理将无法修复未排序的源数据。因此，它不能解决上述问题。这些处理任务根据接收到的数据构建工件，并且无法解决数据本身的问题。

MS SQL列存储索引大致是一种新的存储技术-应用于堆表的列存储压缩。与具有聚簇索引的表相比，这可以实现快速插入(无需索引，无需进行预排序)。缺点-具有聚簇索引的表上的SELECT查询可能返回以聚簇索引为基础的有序行(除非您使用ORDER BY语句设置顺序)，而对聚簇列存储表的相同查询将产生未排序的数据。
带有“群集列存储”索引的未排序数据的问题不仅影响SSAS，而且在CCI可以进行段消除时会降低查询性能。有一些技术可以克服这一问题-在将常规表转换为CCI之前对数据进行排序或在加载到CCI表时对数据进行排序。

discussion you mentioned的主要问题是使用SQL级别的其他 View 来完成数据排序。然后作者在SSAS上定义分区，并报告SSAS生成的查询的执行计划不理想。

关于SSAS在无序数据上的性能。这肯定不是最佳的，但是到什么程度呢？实际上，只有测试才能证明这一点。它可能取决于多种因素-初始数据集，多维数据集设计，最终用户查询。多维数据集结构的增长将减慢操作速度，但是多少呢？根据经验，如果多维数据集为100+ GB，并且其最大的分区/度量值组超过SSAS使用的RAM的10％以上，我将不遗余力，并努力提供数据排序。在其他情况下，我不会理会此类问题。

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

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

使用符合ANSI且限制较少的

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

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

如果这是该项目的第一个实现方案-我将没有采取此类措施，并将其报告为项目风险，这需要关注进行生产，并且可能需要投入额外精力。

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

关于sql-server - 聚集的列存储索引是否影响SSAS查询最终用户性能，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/55639468/