Індексування даних у Vertipaq: зберігання рядків і стовпців

У цьому підручнику ми розглянемо різницю в тому, як працює індексування даних у реляційній базі даних і у Vertipaq.

Реляційні бази даних зберігають дані рядок за рядком. З іншого боку, Vertipaq робить це колонка за колонкою.

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

Зміст

• Індексація даних на рядок
• Індексація даних за стовпцем
• Порівняння часу виконання в простих запитах
• Порівняння часу виконання в більш складних запитах
• Висновок

Індексація даних на рядок

Зберігання даних рядок за рядком є ​​традиційним способом зберігання даних. Однак цей процес займає більше часу, що вплине на продуктивність вашого запиту.

Скажімо, у нас є таблиця, яка містить бренд, колір, стать, кількість і чисту ціну.

Якщо ми збережемо все в цій таблиці в базі даних, то вона зберігатиме дані в рядку за рядком. Ось чому традиційну структуру зберігання даних також називають сховищем рядків.

По-перше, у тому самому рядку він зберігатиме заголовки стовпців, знайдені в першому рядку — бренд, колір, стать, кількість і чиста ціна. Потім він переходить до наступного рядка, щоб зберегти перші елементи під кожним стовпцем — A. Datum, Azure, пробіл, 1 і 103.2. Це продовжується ряд за рядом.

Отже, як ми будемо обчислювати длякількості за допомогою цього методу індексації даних?

По-перше, він починається з першого рядка, який містить заголовки стовпців. Потім він переходить до наступного рядка та пропускає інші фрагменти даних, доки не дійде до першої кількості, яку бачить, тобто 1. Потім він переходить від рядка до рядка, пробігаючи всі дані, які містить кожен рядок, і збирає всі кількості знахідок.

Коли він відкладає всі кількості з кожного рядка, це єдиний раз, коли обчислення завершено.

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

Індексація даних за стовпцем

Щоб уникнути тривалого процесу, у вас є можливість зберігати дані по стовпцях за допомогою Vertipaq, коли ви вибираєте режим імпорту.

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

Припустімо, ми хочемо отримати СУМУ значень у стовпці «Кількість». Не потрібно буде пропускати дані про бренд, колір та інші елементи за межами стовпця "Кількість". За одне сканування він зчитує весь стовпець кількості зверху вниз і підсумовує всі значення.

Через це запити виконуватимуться швидше порівняно з виконанням зліва направо.

Порівняння часу виконання в простих запитах

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

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

Як бачите, загальний час виконання становить 2,2 секунди.

Тепер перейдемо до DAX Studio та використаємо функцію EVALUATE , щоб виконати той самий запит. Нам потрібно ввімкнути таймінг сервера та дочекатися завершення трасування.

Нам також потрібно переконатися, що під час виконання запиту вибрано параметр «Очистити кеш, а потім запустити».

Після виконання запиту ви побачите, що для виконання того самого запиту, який ми робили раніше в SQL, потрібно лише 3 мілісекунди.

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

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

Порівняння часу виконання в більш складних запитах

Цього разу давайте порівняємо час виконання, коли ми запускаємо складніші запити.

Припустімо, ми хочемо визначити СУМУ обсягу продажів для кожного бренду. Для цього ми можемо використовуватипобренду кожного продукту. У нижньому контексті ми також створимо нову таблицю під назвою Загальна кількість, куди ми збираємосяна СУМУ кількості продажів.

Якщо ми запустимо цей код, ви побачите, що загальний час виконання становить 7 мілісекунд.

У фоновому режимі цей код фактично виконує два запити. Перший бере стовпець Brand із таблиці Products, а потім виконує a ЗОВНІШНЄ ПРИЄДНАННЯ в стовпцях «Ключ продукту» зі стовпців «Продажі» та «Продукція».

Другий запит просто отримує стовпець Brand із таблиці Products.

Якщо я перейду на екран результатів, ви побачите, що вимірювання загальної кількості було розділено на основі кожної марки.

Тепер давайте підемо на сервер SQL і напишемо той самий запит.

Ми перемістимо таблицю DaxStudio Sales до наступного рядка, посилаючись на таблицю Sales AS S. Потім ми також виконаємо LEFT JOIN у таблиці DaxStudio Products, на яку посилається AS P, з ключем S.Product, що дорівнює P. Ключ продукту. Ми також будемо використовувати P.Brand із SUM кількості та загальної кількості в операторі SELECT . Нарешті, ми збираємося використовуватидля P.brand.

Щойно ми запустимо цей код, ми отримаємо таблицю, яка містить загальну кількість, розділену за кожною маркою, що є тим самим, що ми раніше отримували у Vertipaq.

Що стосується загального часу виконання, то він залишається набагато повільнішим і становить 2,5 секунди.

Висновок

Очевидно, наскільки швидким насправді є зберігання стовпців через Vertipaq порівняно зі збереженням рядків у базі даних SQL. Це показує важливість справжнього ознайомлення з тим, як працює індексація даних на різних платформах.

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