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

Question

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

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

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

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

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

Answer 1

嗯，这取决于。让我们从问题定义开始。

当在处理步骤中馈入有序数据时，
• SSAS多维性能更好。这个article为您提供了原因以及对数据排序的见解。
• SSAS索引和聚合处理无法修复未排序的源数据；因此，它不能解决上述问题。这些处理任务根据接收到的数据构建工件，并且无法解决数据本身的问题。
MS SQL列存储索引大致是一种新的存储技术-应用于堆表的列存储压缩。与具有聚簇索引的表相比，这可以实现快速插入（无需索引，无需进行预排序）。缺点-对具有聚簇索引的表的 SELECT 查询可能返回基于聚簇索引的排序的行（除非您使用 ORDER BY 语句设置了排序），而对群集的Columnstore表将产生未排序的数据。
带有“群集列存储”索引的未排序数据问题不仅影响SSAS，而且在CCI可以执行这种称为“段消除”的方法时，也会降低查询性能。有一些技术可以克服这一问题-在将常规表转换为CCI之前对数据进行排序，或在加载到CCI表时对数据进行排序。
• discussion you mentioned的主要问题在于，数据排序是通过SQL级别的其他视图完成的。然后，作者在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)。同样，如果这是一个严重的问题，请定义一个表值函数（参数视图）以实现最佳执行计划，并在SSAS分区定义中使用此TVF。

如果这是该项目的首次实施-我将没有此类措施，而将其报告为项目风险，这需要关注生产效率，并可能需要付出更多努力。

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