Индексация данных в Vertipaq: хранилище строк по сравнению с хранилищем столбцов

В этом руководстве мы рассмотрим разницу в том, как работает индексация данных в реляционной базе данных и в Vertipaq.

Реляционные базы данных хранят данные построчно. С другой стороны, Vertipaq делает это столбец за столбцом.

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

Оглавление

• Индексация данных на строку
• Индексация данных по столбцу
• Сравнение времени выполнения простых запросов
• Сравнение времени выполнения более сложных запросов
• Заключение

Индексация данных на строку

Хранение данных построчно — это традиционный способ хранения данных. Однако этот процесс занимает больше времени, что повлияет на производительность вашего запроса.

Допустим, у нас есть таблица, которая содержит марку, цвет, пол, количество и цену нетто.

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

Во-первых, в той же строке будут храниться заголовки столбцов из первой строки — Марка, Цвет, Пол, Количество и Цена нетто. Затем он переходит к следующей строке для хранения первых элементов в каждом столбце — A. Datum, Azure, пробел, 1 и 103.2. Так продолжается ряд за рядом.

Итак, как мы собираемся вычислять СУММУ , используя этот метод индексации данных?

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

Как только он отложил все количества из каждой строки, это единственный раз, когда расчет завершен.

Вы, вероятно, можете себе представить, насколько утомительным является этот процесс, если вы готовите отчет LuckyTemplates, в котором используется подключение DirectQuery к источнику данных SQL. В этом случае службы анализа преобразуют код DAX в язык SQL, а затем начинают последовательно обрабатывать структуру данных.

Индексация данных по столбцу

Чтобы избежать длительного процесса, у вас есть возможность хранить данные по столбцам через Vertipaq, когда вы выбираете режим импорта.

Когда вы используете хранилище столбцов вместо хранилища строк, бренд, цвет, пол, количество и чистая цена будут храниться в разных структурах данных.

Допустим, мы хотим получить СУММУ значений в столбце Количество. Не нужно будет проходить через марку, цвет и другие элементы данных за пределами столбца «Количество». За одно сканирование он считывает весь столбец Quantity сверху вниз и суммирует все значения.

Из-за этого запросы будут выполняться быстрее, чем если бы они выполнялись слева направо.

Сравнение времени выполнения простых запросов

Чтобы действительно увидеть огромную разницу между хранилищем строк и хранилищем столбцов, давайте выполним несколько тестовых запросов как в SQL, так и в Vertipaq. Время выполнения должно сказать нам, насколько быстро один процесс сравнивается с другим.

Начнем с простого запроса на SQL. Мы собираемся вычислить СУММУ столбца «Количество» в таблице «Продажи».

Как видите, общее время выполнения составляет 2,2 секунды.

Теперь давайте перейдем в DAX Studio и воспользуемся функцией EVALUATE для выполнения того же запроса. Нам нужно включить тайминги сервера и дождаться завершения трассировки.

Нам также необходимо убедиться, что при выполнении запроса выбрана опция «Очистить кэш, затем выполнить».

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

Набор результатов также должен совпадать как для SQL, так и для DAX Studio. Если мы поместим их рядом, вы увидите, что мы возвращаем одно и то же значение.

Вы можете попробовать запустить запрос еще несколько раз, чтобы увидеть, насколько стабильно время выполнения.

Сравнение времени выполнения более сложных запросов

На этот раз давайте сравним время выполнения при выполнении более сложных запросов.

Допустим, мы хотим определить СУММУ объема продаж для каждого бренда. Для этого мы можем использовать вместо каждого бренда продукта. В низком контексте мы также создадим новую таблицу под названием «Общее количество», в которой мы собираемся ВЫЧИСЛИТЬ объема продаж .

Если мы запустим этот код, то увидим, что общее время выполнения составляет 7 миллисекунд.

В фоновом режиме этот код фактически выполняет два запроса. Первый берет столбец «Бренд» из таблицы «Продукты», затем выполняет OUTER JOIN для столбцов «Ключ продукта» как из столбца «Продажи», так и из столбца «Продукты».

Второй запрос просто извлекает столбец «Бренд» из таблицы «Продукты».

Если я перейду к экрану результатов, вы увидите, что мера «Общее количество» была разделена на основе каждого бренда.

Теперь давайте перейдем к SQL-серверу и напишем тот же запрос.

Мы перенесем таблицу DaxStudio Sales на следующую строку, ссылаясь на таблицу Sales как S. Затем мы также собираемся выполнить LEFT JOIN в таблице DaxStudio Products, на которую ссылается AS P, с ключом S.Product, равным P.Ключ продукта. Мы также собираемся использовать P.Brand с СУММОЙ количества и общего количества в операторе SELECT . Наконец, мы собираемся использовать для P.brand.

Как только мы запустим этот код, мы получим таблицу, содержащую общее количество, разделенное по каждому бренду, то же самое, что мы ранее получили в Vertipaq.

Что касается общего времени выполнения, то оно остается намного медленнее — 2,5 секунды.

DAX для LuckyTemplates: оптимизация с помощью обработчиков формул в DAX Studio
Методы оптимизации запросов DAX и уроки
Производительность запросов и настройка DAX Studio

Заключение

Очевидно, насколько быстро работает хранилище столбцов Vertipaq по сравнению со хранилищем строк в базе данных SQL. Это показывает важность реального понимания того, как работает индексация данных на разных платформах.

Сначала это может показаться небольшой жертвой, если вы все же решите использовать 2,5 секунды, в течение которых хранилище строк выполняет ваш запрос, по сравнению с 7 миллисекундами. Но мы все запускаем несколько запросов при создании отчетов, и все эти времена выполнения складываются, что в конечном итоге влияет на производительность и удобство работы пользователей.