Почему у служб Azure Analysis Services скорость запросов ниже по сравнению с прямыми SQL-запросами

Для тестирования я развернул:

  • база данных Azure SQL с некоторыми данными
  • табличная модель в службах Azure Analysis Services, подключенная к базе данных SQL для получения данных.

Тест предназначался для сравнения скорости запросов к базе данных Azure SQL и к табличной модели.

Табличная модель в тестах состоит из 4 измерений, но только 2 из них используются в запросах. Я полагаю, что запросы к табличной модели не могут обрабатывать более двух измерений?

Запросы выполняются из консольного приложения .NET, запущенного на локальном компьютере. Запросы к табличной модели используют клиентскую библиотеку ADOMD.NET и написаны на DAX (языке, с которым у меня нет опыта) и поступают из средства проектирования в SSMS. Запросы к базе данных SQL используют клиентскую библиотеку ADO.NET (содержащую агрегатную функцию, 7 внутренних соединений и некоторые параметры "where clause").

Тест состоял из 10 запросов для каждой системы с временем ожидания 500 мс между каждым запросом. Время каждого запроса плюс накладные расходы консольного приложения, выполняющего клиентскую библиотеку, измеряется с помощью System.Diagnostics.Stopwatch. Средняя продолжительность запросов для табличной модели была вдвое больше (957,6 мс) по сравнению с запросами SQL SB (529,1 мс).

Я ожидал, что запросы к табличной модели будут быстрее, поскольку службы Analysis Services оптимизированы для таких аналитических запросов, содержащих агрегаты и объединения.

Может ли кто-нибудь объяснить, почему он не работает лучше? Или зачем использовать табличные модели вместо выполнения SQL-запросов непосредственно в реляционной БД?


comment
Не могли бы вы поделиться примером выполнения запроса к SSAS?   -  person GregGalloway    schedule 02.03.2018
comment
Модель SSAS находится в кэшированном режиме или в DirectQuery?   -  person GregGalloway    schedule 02.03.2018
comment
Режим DirectQuery отключен, поэтому он находится в режиме кэширования. Запрос к SASS находится в DAX и выглядит следующим образом: EVALUATE SUMMARIZECOLUMNS( 'Users'[FirstName], 'Users'[LastName], 'Users'[Email], FILTER(VALUES('Users'[ChannelId]), ('Users'[ChannelId] = ""9EB2B93B - 003E-4249 - 9F15 - 10F4264A6AD5"")), ""Count of sessions"", [Count of sessions], ""Average of session score"", [Average of session score] )   -  person sdec    schedule 07.03.2018


Ответы (1)


Время выполнения запросов к базе данных SQL должно быть примерно одинаковым, если только ваш созданный вручную SQL не будет особенно плохо работать. Время, затрачиваемое службами Analysis Services на соответствие данных, возвращаемых из базы данных SQL в вашу семантическую модель, является источником дополнительной задержки.

Ценность использования Direct Query здесь заключается в том, что вы можете предоставить пользователю более интуитивно понятную семантическую модель, поскольку ожидается, что пользователь не будет администратором баз данных. Вдобавок к этому семантическая модель, по всей вероятности, будет включать вычисления, меры, ключевые показатели эффективности и т. Д.

Если вам не нужно предоставлять семантическую модель, ориентированную на бизнес, и вы довольны выполнением всех вычислений и агрегатов в запросе SQL, тогда вам могут не понадобиться службы Analysis Services.

Конечно, другим преимуществом использования службы Analysis Service с отключенным режимом прямого запроса является то, что вы можете хранить данные в памяти, а не на диске, чтобы сократить время выполнения запросов. Еще одно важное преимущество заключается в том, что вы можете указать семантической модели на несколько источников данных, чтобы ваша модель могла быть централизованным источником данных для бизнес-пользователя.

Наконец, количество измерений, которые может использовать табличная модель, не ограничено ...

Табличная модель в тестах состоит из 4 измерений, но только 2 из них используются в запросах. Я полагаю, что запросы к табличной модели не могут обрабатывать более двух измерений?

person Peadar Doyle    schedule 02.03.2018