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



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

有没有办法解决这个问题?

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

当前在 SSAS 多维数据集中实现多维模型。

  • 将关系源切换到列存储索引后,多维数据集处理速度较慢,并生成更大的度量值组

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

  • SSAS 多维在处理步骤中馈送有序数据时性能更好。本文提供了原因和有关数据排序的见解。
  • SSAS 索引和聚合处理不会修复未排序的源数据;因此,它不会修复上述问题。这些处理任务基于接收的数据构建工件,并且无法解决数据本身的问题。
  • MS SQL 列存储索引大致是一种新的存储技术 - 应用于堆表的列存储压缩。与具有聚簇索引的表相比,这提供了快速插入(无需索引,无需预排序)。缺点 - 对具有聚集索引的表进行SELECT查询可能会返回在聚集索引基上排序的行(除非使用ORDER BY语句设置排序),而对聚集列存储表的相同查询将生成未排序的数据。
    使用聚集列存储索引的未排序数据问题不仅会影响 SSAS,还会在 CCI 可以执行所谓的段消除时降低查询性能。有一些技术可以解决这个问题 - 在将常规表转换为 CCI 之前对数据进行排序,或者在加载到 CCI 表时对数据进行排序。
  • 您提到的讨论的主要问题是数据排序是通过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 时,您需要在数据库查询级别对数据进行预排序。

最新更新