SQL Server 2016: агрегатный оконный оператор пакетного типа | Строки с разделителями UNBOUNDED и CURRENT ROW
SQL Server 2016: агрегатный оконный оператор пакетного типа | Строки с разделителями UNBOUNDED и CURRENT ROW

SQL Server 2016: агрегатный оконный оператор пакетного типа | Строки с разделителями UNBOUNDED и CURRENT ROW

❤ 541 , Категория: Новости,   ⚑ 11 Авг 2017г

Содержание:
1. Строки с разделителями UNBOUNDED и CURRENT ROW (Вы читаете данный раздел);
2. RANGE с разделителями UNBOUNDED и CURRENT ROW;
3. Разделители, отличные от UNBOUNDED и CURRENT ROW;
4. Оконные функции смещения, функции LAG и LEAD;
5. Функции FIRST.VALUE и LAST.VALUE.


Наиболее распространенная спецификация фрейма, на мой взгляд, выглядит следующим образом ROWS UNBOUNDED PRECEDING (это достаточно гуманное сокращение ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW). Суть ее сводится в представление строк от самого начала раздела (естественно, с учетом отсечения точки нижней границы) и до актуальной строки. В общем и целом, данный фрейм служит для того, чтобы произвести вычесление промежуточной суммы.

Запрос в коде выше (давайте назовем его Query 1) к таблице Transactions (rowstore) обеспечивает получение простой промежуточной суммы. План выполнения этого запроса показан на рисунке ниже.

Поскольку в таблице Transactions нет индекса columnstore, оптимизатор в данном случае может использовать только построчный режим обработки данных. Этот план последовательный. В ходе его реализации выполняется упорядоченная проверка кластеризованного индекса, и при таком подходе нет необходимости в явной сортировке строк при расчете оконной функции. План предусматривает использование операторов Segment и Sequence Project для определения числа строк. Таким образом выясняется, какие строки являются частью фрейма текущей строки. Сведения о том, как вычисляется количество строк, можно найти во второй статье серии. Далее в плане предусмотрено сегментирование строк для получения агрегирующего значения в соответствии с содержимым разделяющего столбца actid. Для этого используется еще один оператор Segment.

Затем планируется запись строк в буфер (оператор Window Spool). Предполагается, что буфер окна содержит фрейм строк, который будет агрегироваться оператором Stream Aggregate. Поскольку фрейм имеет спецификацию ROWS UNBOUNDED PRECEDING, теоретически буфер окна должен содержать одну строку для первой строки раздела, две строки для второй и т. д.; для n-ной строки предполагается наличие n строк. Если бы дела обстояли именно таким образом, буфер должен был бы иметь (n+n2)/2 строк для раздела, содержащего n строк, и, соответственно, масштабироваться квадратично.

К счастью, всякий раз, когда фрейм начинается со спецификации UNBOUNDED PRECEDING, выбирается ускоренный порядок оптимизации: берется результат предыдущей строки и вычисляется новая промежуточная сумма посредством добавления значения текущей строки. Любопытно здесь нот что: почему в буфер поступает 10000000 строк, а выходит их из него в два раза больше?

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

При выполнении данного запроса на своем компьютере я получил следующие статистические данные: продолжительность — 28 секунд, процессор — 28 секунд, логические операции считывания — 31 К, записи — 0.

Для демонстрации обработки в пакетном режиме данных в представлении columnstore с помощью нового оператора Window Aggregate я буду использовать запрос, приведенный в коде выше (буду называть его Query 2).


Используете SQL Server 2016 исключительно для обеспечения работы камер системы безопасности? Значит, вас определенно точно заинтересует сайт Magazun.com. Здесь вы найдете охранные системы которые могут работать автономно и без подключения к сети. Их преимущество неоспоримо, так что они определенно точно заслуживают вашего самого пристального внимания.



По теме: ( из рубрики Новости )

Оставить отзыв

Ваш адрес email не будет опубликован. Обязательные поля помечены *

*
*

пять + четыре =

Похожие записи

наверх