Как улучшить распараллеливание выполнения запросов для одного пользователя в хранилище данных SQL Azure?

У нас есть новая панель мониторинга отчетов, загруженная в наше веб-приложение, где данные поступают из Azure SQLDataWareHouse.

Панель инструментов состоит примерно из 8–10 плиток, каждая из которых отображает разные показатели, загружаемые по разным запросам.

Различные запросы выполняются из веб-приложения с использованием простого кода ADO.NET для подключения к DW с учетной записью пользователя dashboard.

Я прочитал обе статьи о памяти и параллелизме. Ограничения и Классы ресурсов, но я чего-то не понимаю.

Для нашего уровня обслуживания DW (Gen2 — DW200c) сервер должен поддерживать выполнение 8 одновременных запросов. Точно так же мы добавили нашего пользователя dashboard в группу ресурсов staticrc80, которая должна предоставить ему доступ ко всем 8 слотам параллелизма.

Но это, похоже, не помогает. Правильно ли я понимаю, что независимо от этих конфигураций ресурсов он по-прежнему будет выполнять только один запрос для одного пользователя за раз? И что несколько запросов, выполняемых под одной и той же учетной записью пользователя, все равно будут стоять в очереди?

Одна из альтернатив, по-видимому, заключается в том, что я мог бы иметь разные учетные записи пользователей для каждой плитки, сделать 8 отдельных подключений, выполнить 8 отдельных запросов, где каждая учетная запись запроса назначается роли staticrc10.

Я упускаю что-то фундаментальное здесь. Это хранилище предназначено для одного приложения с одной учетной записью пользователя для чтения. Как мне настроить эту учетную запись с точки зрения класса ресурсов и т. д., чтобы в полной мере использовать 8 параллельных распределений ресурсов запроса/200 DWU.


azure azure-sql-data-warehouse
person Eoin Campbell    schedule 07.01.2020    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Согласно documentation, статический класс ресурсов staticrc80 в DWU200c использует 8 слотов ресурсов, поэтому там, где DWU200c имеет максимум 8 одновременных слотов, я ожидаю, что одно соединение будет использовать их все, и поэтому ваши одновременные запросы будут поставлены в очередь. , один за раз.

классы статических ресурсов и слоты параллелизма Рассмотрите возможность переключения пользователя на staticrc10, что позволит выполнять до 8 одновременных запросов. Не нужно делать 8 разных пользователей.

Могу я спросить, вы используете Power BI? Кроме того, DWU200c довольно низок для любой рабочей нагрузки, он действительно нужен только для того, чтобы все работало.

person wBob    schedule 07.01.2020
comment
Неа. Tableau для отчетов об операциях, но у нас есть несколько плиток панели мониторинга, размещенных в приложении ASP.NET MVC, которые напрямую извлекают метрики/числа высокого уровня из хранилища данных (Dapper + ADO.NET). Моя проблема здесь в том, что я просто не вижу 100%-го использования уровня обслуживания DWU. мы никогда не приблизимся к 200 DWU. Большинство показателей лазурного портала, которые мы когда-либо видели, составляют 50-60, и тем не менее отчеты очень медленные, а на страницах, где вызывается несколько плиток, кажется, что они выполняются последовательно, каждая из которых загружается одна за другой. - person Eoin Campbell; 07.01.2020
comment
И вы уверены, что это не тот код, который выполняет их последовательно, как сказал Дэвид? Я думаю, с диагностической точки зрения вы могли бы i) временно увеличить масштаб, скажем, до 1000, посмотреть, что произойдет, ii) переназначить пользователя на staticrc10, посмотреть, что произойдет и т. д. - person wBob; 07.01.2020
comment
Я вернулся и подтвердил это локально, проведя 4 разных теста. учетная запись пользователя @ staticrc10 | staticrc40 последовательное выполнение sproc по сравнению с их параллельным выполнением Во всех 4 сценариях общее время выполнения составляет ~ 75-80 секунд. когда вы переходите к staticrc10, больше запускается параллельно, но занимает больше времени - (подтверждено через представление [dm_pdw_exec_requests]). Похоже, я просто вернулся к чертежной доске для написания perf/query и рассматриваю реализацию некоторых решений для кэширования результатов. - person Eoin Campbell; 08.01.2020
comment
Хм кажется давно. Вы пробовали какие-либо тесты на более высоком DWU? Мы могли бы рассмотреть перфомансную настройку запросов, если вы хотите поднять отдельный вопрос, включая DDL, выборочные данные и т. д. Возможно, вы уже рассмотрели / рассмотрели план выполнения SQL DW, распределение хэша / циклического перебора, материализованные представления, вторичные некластеризованные индексы. , предварительная агрегация ваших результатов, новая функция кэширования результатов, упомянутая Дэвидом, исключила, что ваш пользователь не принадлежит ни к какому другому классу ресурсов и так далее. Я бы повторил, что ИМХО DW200c довольно низок, чтобы проводить какое-либо тестирование производительности. - person wBob; 08.01.2020
comment
да вот где я сейчас. попали в некоторые из запросов, и есть obv. проблемы производительности, которые необходимо решить. как и все остальное. - person Eoin Campbell; 08.01.2020
comment
комментарий о том, что 200c немного мал... для нас это немного проблематично. это действительно небольшой проект с небольшим бюджетом для некоторых исследований и разработок на наборе данных, который оказался довольно большим. прямо сейчас включить циферблаты (даже если это окажется решением) будет трудно продать. 200c DW стоит почти столько же, сколько наш 1000DTU prod db, так что.... - person Eoin Campbell; 08.01.2020
comment
Хорошо, желаю удачи. Дайте мне знать, если я могу помочь с настройкой. Также пейджинг @RonDunn (MS), который давал отличные ответы на SQLDW в прошлом году или около того. - person wBob; 08.01.2020

arrow_upward
1
arrow_downward

несколько запросов, выполняемых под одной и той же учетной записью пользователя, все равно будут стоять в очереди?

Наблюдаемое вами поведение может не иметь никакого отношения к слотам параллелизма. Возможно, клиент не отправляет все запросы параллельно. Клиентское соединение с SQL Server (или Synapse) может обрабатывать только один запрос за раз. Клиент может открывать столько соединений, сколько хочет, но обычно они этого не делают. Два соединения на клиента — это максимум, который вы обычно видите.

Если вы работаете над повышением производительности панели мониторинга, смотрели ли вы Кэширование набора результатов? Он предназначен для улучшения времени ответа на распространенные запросы, что часто происходит с плитками панели мониторинга.

person David Browne - Microsoft    schedule 07.01.2020
comment
Спасибо за это Дэвид. Кэширование набора результатов - это не то, на что я наткнулся. Я обязательно посмотрю. Re: Второй момент... мы уже решили проблему синхронизации и асинхронности. Каждая плитка загружается отдельными вызовами контроллера MVC. Все вызовы используют отдельные соединения (хотя и с одной и той же учетной записью пользователя), но я попрошу разработчиков вернуться и трижды проверить, нет ли какого-то странного синхронного поведения. - person Eoin Campbell; 07.01.2020
comment
Я вернулся и подтвердил это локально, проведя 4 разных теста. учетная запись пользователя @ staticrc10 | staticrc40 последовательное выполнение sproc по сравнению с их параллельным выполнением Во всех 4 сценариях общее время выполнения составляет ~ 75-80 секунд. когда вы переходите к staticrc10, больше запускается параллельно, но занимает больше времени - (подтверждено через представление [dm_pdw_exec_requests]). Похоже, я просто вернулся к чертежной доске для написания perf/query и рассматриваю реализацию некоторых решений для кэширования результатов. - person Eoin Campbell; 08.01.2020
comment
Я ожидаю, что решение для панели мониторинга выиграет (требует меньшего DWU) от кэширования либо в Synapse со сводными таблицами/материализованными представлениями/кэшированием набора результатов, либо в Power BI/Azure Analysis Services. - person David Browne - Microsoft; 08.01.2020
comment
спасибо за совет по RESULT_SET_CACHING, который имеет большое значение в качестве быстрого решения для пластыря, пока мы получаем производительность. с тюнингом разобрались за кулисами. очень признателен. - person Eoin Campbell; 09.01.2020