1

出于测试目的，我部署了：

  • 带有一些数据的 Azure SQL DB
  • Azure Analysis Services 中连接到 SQL DB 以获取数据的表格模型

该测试旨在比较针对 Azure SQL DB 的查询速度与针对表格模型的查询速度。

测试中的表格模型由 4 个维度组成，但查询中仅使用了其中的 2 个维度。我想对表格模型的查询不能处理超过 2 个维度？

查询从本地计算机上运行的 .NET 控制台应用程序运行。针对表格模型的查询使用 ADOMD.NET 客户端库，并使用 DAX（我没有使用过的一种语言）编写，并且来自 SSMS 中的设计工具。针对 SQL DB 的查询使用 ADO.NET 客户端库（包含一个聚合函数、7 个内部连接和一些“where 子句”参数）。

测试由每个系统的 10 个查询组成，每个查询之间的等待时间为 500 毫秒。每个查询的时间加上执行客户端库的控制台应用程序的开销是使用 System.Diagnostics.Stopwatch 测量的。与 SQL SB 查询 (529.1ms) 相比，表格模型查询的平均持续时间 (957.6ms) 是两倍。

我预计对表格模型的查询会更快，因为 Analysis Services 针对包含聚合和连接的此类分析查询进行了优化。

谁能解释为什么它没有表现得更好？或者为什么要使用表格模型而不是直接在关系数据库上运行 SQL 查询？

4

1 回答 1

1

除非您手工制作的 SQL 性能特别差，否则查询在 SQL DB 上执行的时间应该大致相同。Analysis Services 使从 SQL DB 返回的数据适合您的语义模型所花费的时间是额外延迟的来源。

在这里使用 Direct Query 的价值在于，您可以为用户提供对他们来说更直观的语义模型，因为预计用户不会是 DBA。除此之外，语义模型很可能包括计算、度量、KPI 等。

如果您不需要提供以业务为中心的语义模型，并且您乐于在 SQL 查询中进行所有计算和聚合，那么您可能不需要 Analysis Services。

当然，在关闭 Direct Query 模式的情况下使用 Analysis Service 的另一个优点是您可以将数据存储在内存中而不是磁盘上，以提高查询性能时间。另一个主要好处是您可以将语义模型指向多个数据源，因此您的模型可以成为业务用户的集中数据源。

最后，表格模型可以使用的维度数量没有限制......

测试中的表格模型由 4 个维度组成，但查询中仅使用了其中的 2 个维度。我想对表格模型的查询不能处理超过 2 个维度？

于 2018-03-02T10:50:43.150 回答