Новость из категории: Информация

Агрегатный оконный оператор пакетного режима в SQL Server 2016 | Агрегатные оконные функции без фрейма. Часть III

Агрегатный оконный оператор пакетного режима в SQL Server 2016 | Агрегатные оконные функции без фрейма. Часть III

Чтобы протестировать производительность выполнения того же запроса в пакетном режиме обработки данных в формате rowstore, используйте в качестве целевой таблицу TransactionsDCS следующим образом (назовем этот запрос Query 3):
SELECT actid, tranid, val,

  SUM(val) OVER(PARTITION BY actid) AS acttotal

FROM dbo.TransactionsDCS;

Агрегатный оконный оператор пакетного режима в SQL Server 2016 | Агрегатные оконные функции без фрейма. Часть III
План для запроса Query 3 (пакетный режим, применяемый к данным в формате rowstore)

План выполнения данного запроса показан на рисунке выше.

Если вы пришли к заключению, что предыдущий план прост, то что же вы скажете об этом плане?! Он предусматривает извлечение данных с помощью сканирования в порядке режима построчного индекса, преобразование их в пакеты и выполнение всей оставшейся работы с помощью операторов пакетного режима Window Aggregate и Compute Scalar. Выполнять явные операции сортировки не требуется.

Вот статистика по выполнению данного запроса: продолжительность — 7 секунд, процессор — 7 секунд, логические операции считывания — 31 Кбайт, записи — 0.

Любопытно, что, несмотря на исключение операций явной сортировки, на выполнение этого запроса уходит столько же времени, сколько на выполнение запроса Query 2. Понятно, что в ходе сканирования индекса двоичного дерева потребляется больше ресурсов, чем при сканировании индекса columnstore, что видно из сравнения числа операций считывания данных (31 Кбайт против 6 Кбайт), но в обоих случаях сканирование составляет лишь малую часть времени выполнения запроса. Главный недостаток данного плана — отсутствие паралеллизма. По состоянию на данный момент SQL Server не имеет возможности извлекать упорядоченные данные из индекса двоичного дерева и распределять их постепенно и динамично по рабочим потокам способом, оптимальным для оператора Window Aggregate, без такого посредника, как пакетный оператор Sort. Для того чтобы обеспечить выполнение этих действий без посредника, разработчикам Microsoft нужно будет дополнительно поработать над процессором SQL Server. Будем надеяться, что такая работа будет выполнена в дальнейшем. А пока оптимизатору приходится делать выбор между последовательным планом без привлечения оператора Sort и параллельным планом с использованием этого оператора. Как видите, он склонился к первому варианту, поскольку счел его оптимальным. Чтобы реализовать пример второго варианта в рамках поиска неисправностей, можете форсировать выполнение параллелльного плана с помощью флага трассировки 8649 следующим образом (назовем этот запрос Query 4):
SELECT actid, tranid, val,

  SUM(val) OVER(PARTITION BY actid) AS acttotal

FROM dbo.TransactionsDCS

OPTION (QUERYTRACEON 8649);

Агрегатный оконный оператор пакетного режима в SQL Server 2016 | Агрегатные оконные функции без фрейма. Часть III
План для запроса Query 4 (пакетный режим, применяемый к данным в формате rowstore с форсированным параллелизмом)

План выполнения этого запроса показан на рисунке выше.

Как вы можете убедиться, этот план предусматривает применение параллельного сканирования индекса двоичного дерева со свойством Ordered: False (порядок индекса значения не имеет) и далее использование оператора Sort пакетного режима.

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

Агрегатный оконный оператор пакетного режима в SQL Server 2016 | Агрегатные оконные функции без фрейма. Часть III
Время выполнения агрегатных оконных функций без фрейма

Что дальше

Реализованный в версии SQL Server 2016 новый оператор пакетного режима Window Aggregate operator значительно повышает скорость выполнения большинства оконных функций.

В данный момент возможность применения операторов пакетного режима рассматривается лишь в тех случаях, когда в одной из опрашиваемых таблиц имеется по крайней мере один индекс columnstore. Однако я показал, как это ограничение можно обойти, создав фиктивный пустой фильтрованный индекс columnstore. Правда, пока создавать индексы columnstore могут только пользователи редакции Enterprise. Но будем надеяться, что в дальнейшем специалисты Microsoft обеспечат возможность использовать операторы пакетного режима и без наличия в таблицах индексов columnstore. И тогда мы сможем пользоваться обладающим более высоким быстродействием процессором пакетного выполнения, не прибегая к созданию фиктивного индекса columnstore.

А может быть, такая возможность будет предоставлена и пользователям редакции Standard.

В этой статье мы рассмотрели агрегатные оконные функции без фрейма. В следующих статьях серии речь пойдет о ранжирующих и статистических оконных функциях, об агрегатных оконных функциях с фреймом и об оконных функциях смешения.

Агрегатный оконный оператор пакетного режима в SQL Server 2016 | Агрегатные оконные функции без фрейма. Часть III


Хотите выиграть миллион, а не работать по 12 часов в день, мучаясь с агрегатным оконным оператором пакетного режима в SQL Server 2016. Что ж, ваша мечта вполне осуществима! На страничке www.vulkanstavkaslots.com/vulkan-stavka-na-sport/ вы можете поставить деньги на спортивные соревнования. И, кто знает, возможно вам улыбнется удача и ваша ставка принесет вам небывалую прибыль!

1. Часть I;
2. Часть II ;
3. Часть III (Вы читаете данный раздел).

Рейтинг статьи

Оценка
0/5
голосов: 0
Ваша оценка статье по пятибальной шкале:
 
 
   

Поделиться

Перевести статью:

Похожие новости

Комментарии

Информация

^ Наверх