sql-server - 聚集列存储索引会影响 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 语句设置排序)，而对聚集列存储表将产生未排序的数据。
  聚集列存储索引的未排序数据问题不仅影响 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 查询生成引擎不允许神奇的选项(重新编译)。同样，如果这是一个严重的问题 - 定义一个表值函数(参数 View )来实现最佳执行计划，并在 SSAS 分区定义中使用此 TVF。

如果这是该项目的第一次实现 - 我会不采取此类措施，并将其报告为项目风险，这需要关注如何富有成效，并可能需要之后的额外努力。

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