Продуктивність запитів до сховища даних SQL Server 2008

Автор: Sunil Agarwal, Torsten Grabs і Dr. Joachim Hammer, Іcточнік: TechNet Magazine


Логічна структура бази даних: багатовимірне моделювання


Трансакційні бізнес-програми зазвичай мають нормалізовану схему бази даних. Логічна структура схеми бази даних для реляційних сховищ даних не так пов'язана з нормалізацією. Багато сучасних структури реляційних сховищ даних засновані на підході багатовимірного моделювання, який став популярним після виходу книги Ральфа Кімбол (Ralph Kimball) і Марджі Росс (Margy Ross) "The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling "(Інструментарій сховища даних: повне керівництво по багатовимірному моделювання).


Ті, хто працює зі сховищами даних, напевно знайомі зі звичайними схемами для реляційних сховищ даних (такі, як "зірка" і "сніжинка"). У багатовимірному моделюванні виділяються таблиці вимірів і таблиці фактів. Таблиці вимірювань містять основні дані (продукти, клієнти, магазини або країни), а таблиці фактів містять дані транзакцій (продажу, замовлення, купівлі або повернення).


Таблиці вимірювань і фактів мають зв'язок "первинний (PK)-зовнішній (FK) ключ". Багато сховища даних не використовують обмеження FK для зменшення вимог до обсягу сховища. Це рятує від додаткових витрат на зберігання підлягають індексів і скорочує вартість підтримання таблиці фактів. Таблиці вимірювань в сховище даних зазвичай невеликі, вони містять у середньому тисячі і до декількох мільйонів рядків. Таблиці фактів, з іншого боку, можуть бути дуже великими і містити від сотень мільйонів до мільярдів рядків. Тому логічна структура повинна приділяти особливу увагу вимогам таблиці фактів до обсягом сховища.


Цей фактор розміру впливає на те, який ключ слід вибрати з таблиці вимірів, щоб підтримувати співвідношення таблиці фактів до таблиці вимірювання. Складові ключі, засновані на бізнес-ключі вимірювання (Тобто на реальному ідентифікаторі об'єкта, представленого виміром), зазвичай займають кілька стовпців. Слід знати, що це проблема для відповідного зовнішнього ключа в таблиці фактів, тому що складовою ключ з декількох стовпців буде повторюватися для кожного рядка таблиці фактів.


Щоб цього не було, для реалізації відносин між таблицею фактів і її вимірами часто застосовують маленькі сурогатні ключі. Сурогатний ключ – це стовпець ідентифікаторів типу integer, який служить штучним первинним ключем таблиці вимірювання. Великі таблиці фактів, що посилаються на маленькі сурогатні ключі, вимагають значно менше місця. На Рис. 1 показана схема сховища даних на основі багатовимірної моделі, що використовує таблиці фактів і вимірювань з сурогатними ключами.

Рис. 1Приклад схеми "зірка" з таблицею фактів і двома таблицями вимірювань


Схема "сніжинка" поширює одне або кілька вимірів на безліч рівнів (наприклад, клієнт, країна і регіон для вимірювання "клієнт"), нормалізуючи великі вимірювання, які можуть бути перевантажені надлишковими даними. Рівні представлені окремими таблицями, тому схема схожа на сніжинку. Структура схеми "зірка", навпаки, не поширює вимірювання на таблиці. Ця схема має форму зірки, де центром служить таблиця фактів, а навколо неї зібрані таблиці вимірів.


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

select ProductAlternateKey,
CalendarYear,sum(SalesAmount)
from FactInternetSales Fact
     join DimTime
on Fact.OrderDateKey = TimeKey
     join DimProduct
on DimProduct.ProductKey =
   Fact.ProductKey
where CalendarYear between 2003 and 2004
      and ProductAlternateKey like “BK%”
group by ProductAlternateKey,CalendarYear

SQL Server 2008 запропонує більш потужні можливості надійного зберігання даних, ніж його попередник, але, можливо, ви все ще ворожите, як можна використовувати всі ці нові технології для створення продуктивного сховища даних для підтримки рішення більше мільярда рядків. Ви, можливо, також хочете дізнатися, які функції допоможуть отримати кращу продуктивність для запитів і звітів підтримки рішень і яких поліпшень продуктивності слід очікувати від нової версії SQL Server.

У міру наближення підсумкового випуску, накопичується все більше питань. Ми сподіваємося, що цей детальний огляд деяких найважливіших функцій зберігання даних SQL Server 2008, пов'язаних з продуктивністю, допоможе вам підготуватися.


Фізична модель


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


Зазвичай під SQL Server розробники сховищ даних починають з плану або фізичної моделі, яку вони покращують і коригують за розвитком робочого навантаження. Ви можете скористатися таким планом для власного середовища сховища даних. У цьому випадку, не забувайте про рекомендації для побудови фізичних моделей баз даних, таких, як вплив на швидкість за рахунок підтримки індексів для оновлення і вимоги індексів до обсягу сховища.


Таблиця фактів


План повинен бути розрахований на типову форму запиту "зірка" і він повинен будувати індекси на таблиці фактів. Кластерізованний індекс таблиці фактів використовує кілька стовпців сурогатних ключів вимірювань (Стовпці зовнішнього ключа) в якості ключів індексу. Стовпці, які використовуються найчастіше, повинні з'явитися в списку ключів індексу. Не завадить перевірити, що таким чином дійсно виходять хороші шляхи доступу для найбільш частих запитів в робочому навантаженні.


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


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


Таблиця вимірів


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


Кластерізованний індекс збільшує ефективність вилучення, перетворення і завантаження (ETL) у період обслуговування сховища даних, яке часто обмежений у часі. Наприклад, у разі повільно мінливих вимірювань, існуючі рядки оновлюються на місці, а нові – додаються до таблиці вимірювання. Така схема доступу може бути ефективною тільки за хороших перегляді та оновленні таблиці вимірювання під час ETL.


План, описаний вище, служить гарною відправною точкою для фізичних моделей реляційних сховищ даних на SQL Server. Грунтуючись на цьому типовому пристрої реляційного сховища даних, ми можемо розглянути ключові нові функції SQL Server 2008.


Оптимізація запиту типу "зірка"


Обробка таблиці фактів – звичайно найдовша частина виконання запиту "зірка" в реляційному сховище даних на багатовимірної моделі. У цьому легко переконатися, тому що навіть дуже виборчі запити отримують на порядок більше рядків з таблиці фактів, ніж з будь-якого вимірювання. Тому використання найкращого шляхи доступу в таблицю фактів важливо для високої продуктивності запиту.


SQL Server використовує оптимізатор запиту на основі вартості, тобто намагається створити план виконання з мінімальною оцінною вартістю. У контексті зберігання даних, головне завдання – переконатися, що оптимізатор запиту оцінює однозначні альтернативи шляхів доступу для плану виконання запиту "зірка". У оптимізатор запитів SQL Server включено кілька функцій, автоматично забезпечують продуктивні плани виконання запитів типу "зірка".


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

Figure 2Діапазони вибірковості для запитів типу "зірка"


У перший клас включені виявляли високу запити, обробні до 10 відсотків рядків таблиці фактів. Другий клас, із середньою вибірковістю, містить запити, обробні від 10 до 75 відсотків рядків таблиці фактів. Запити в третьому класі, з низькою вибірковістю, вимагають обробки понад 75 відсотків рядків таблиці фактів. Прямокутники на малюнку показують основні плани виконання запитів для кожного класу вибірковості.


Вибір плану на підставі ізібрательності


Так як виявляли високу запити "зірка" зазвичай отримують не більше 10 відсотків рядків таблиці фактів, їм можна дозволити випадковий доступ до таблиці. Тому плани запитів для цього класу засновані на з'єднаннях вкладених циклів разом з пошуками індексів (некластерізованних) і пошуком закладок в таблиці фактів. Так як вони виконують довільний введення / висновок у таблицю фактів, послідовне введення / висновок, при отриманні великих кількостей таблиці фактів, виходить більш продуктивним. Тому в міру зростання кількості рядків, одержуваних з таблиці фактів, вище певної межі, застосовується інший план запиту.


Так як запити типу "зірка" середньої вибірковості обробляють значну частину рядків таблиці фактів, для доступу до таблиці фактів звичайно застосовуються хеш-з'єднання зі скануванням таблиці фактів або сканування діапазону таблиці фактів. SQL Server використовує растрові фільтри для поліпшення продуктивності хеш-з'єднань.


На рис. 3 показано, як SQL Server використовує растрові фільтри для поліпшення продуктивності з'єднання при виконанні запиту типу "зірка". На малюнку показаний план запитів до двох таблиць вимірів, продукту і часу, які з'єднуються з таблицею фактів через сурогатні ключі. Запит використовує предикати фільтрів, такі, як оператор WHERE, проти обох таблиць вимірів так, що тільки один рядок підходить для кожного вимірювання. Це позначається маленькими червоними таблицями поруч з двома операторами з'єднання.

Рис 3План запиту типу "зірка" з обробкою зменшення з'єднання


Реалізація з'єднання для кожного з'єднання – хеш-з'єднання, яке дозволяє SQL Server взяти інформацію про відповідних рядках з таблиць вимірів і отримати те, що ми називаємо інформацією про зменшення з'єднання, для обох таблиць вимірів. Зеленими рамками на малюнку позначені структури даних інформації про зменшення з'єднання. Заповнивши їх з підлягають таблиць вимірів, SQL Server автоматично передає під час виконання запиту ці структури даних оператору, обробляє таблицю фактів, такому, як сканування таблиці. Цей оператор використовує інформацію про рядках таблиці вимірювання, щоб виключити рядки таблиці фактів, які не відповідають умовам з'єднання проти вимірювань.


SQL Server прибирає ці рядки таблиці фактів дуже рано в процесі обробки запиту – після отримання рядка з таблиці фактів. Це дозволяє економити час роботи ЦП і, можливо, скоротити введення / висновок з диска, тому що прибрані рядки не потрібно обробляти в подальших операторах плану запиту. SQL Server використовує растрове уявлення, щоб ефективно реалізувати структури даних інформації про зменшення з'єднання під час виконання запиту.


Конвеєр оптимізації запитів типу "зірка"


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


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


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


Евристика з'єднання типу "зірка"


Багато фізичні моделі сховищ даних використовують схему "зірка", але не повністю вказують відносини між таблицями вимірювання і фактів, як, наприклад, із згаданими вище обмеженнями зовнішнього ключа. Якщо обмеження зовнішнього ключа не встановлені явно, SQL Server повинен визначати послідовності запитів у схемі "зірка" за допомогою евристики. Для цього застосовується така евристика.



  1. Найбільша з таблиць, які беруть участь у n-арном з'єднанні, вважається таблицею фактів. Є додаткові обмеження на мінімальний розмір таблиці фактів. Наприклад, якщо навіть найбільша таблиця менше певного розміру, n-арне не вважається з'єднанням типу "зірка".

  2. Всі умови з'єднання двійкових сполук запиту типу "зірка" повинні бути предикатами рівності обного стовпця. З'єднання повинні бути внутрішніми. Це може здатися обмеженням, але сюди потрапляє більшість з'єднань між таблицею фактів і таблицями вимірювань на сурогатних ключах типових схемах типу "зірка". Якщо з'єднання має більш складні умови, що не відповідають описаній вище схемою, воно виключається із з'єднання типу "зірка". Наприклад, п'ятисторонню з'єднання може призвести до тристороннього (з двома додатковими пізніше), якщо дві сполуки мають більш складні предикати.

Зауважте, що це правила евристики. У дійсності ситуацій, в яких евристика переплутає таблицю фактів з таблицею вимірювань, небагато. Це впливає на вибір плану, але не змінює правильності обраного плану. Двійкові з'єднання, залучені в запит типу "зірка", потім сортуються за спаданням вибірковості. Вибірковість з'єднання в цьому контексті визначається як відношення потужності введення таблиці фактів та підсумкової потужності з'єднання, тобто вибірковість з'єднання означає, наскільки певний вимір зменшує потужність таблиці фактів. У загальному випадку слід розглядати з'єднання з більшою вибірковістю першими.


Процесор запиту SQL Server автоматично застосовує оптимізацію до запитів, відповідним схемою "зірка" і згаданим вище умовам, коли одержувані плани запиту оцінюються як вигідні. Тому немає необхідності змінювати свій додаток, щоб скористатися цим способом збільшення продуктивності. Зауважте, що деякі з оптимізацій запиту типу "зірка", такі, як зменшення з'єднання, доступні тільки у версії сервера SQL Server Enterprise Edition.


Результати дослідження продуктивності з'єднання типу "зірка"


У рамках проекту з оптимізації з'єднання типу "зірка" в SQL Server 2008, ми виконали декілька досліджень швидкодії, грунтуючись на експериментальних і реальних клієнтських робочих навантаженнях. Варто подивитися на результати трьох з цих навантажень.


Сховище даних з організації продажу копрораціі Майкрософт Ця робоча навантаження простежує швидкодію сховища даних, що використовується для підтримки прийняття рішень у відділі організації продажів корпорації Майкрософт. Ми взяли фрагмент бази даних розміром близько 750 ГБ (включаючи індекси). Запити це робочого навантаження складні для обробки, тому що багато хто має більше 10 з'єднань.


Роздрібна торгівля Ця серія експериментів заснована на сховище даних клієнта, зайнятого в роздрібній торгівлі (звичайний магазин і робота в Інтернеті). Особливості клієнта – багатовимірна схема типу "сніжинка" і звичайні запити типу "зірка". Для заповнення фрагмента сховища ми використовували в наших експериментах близько 100 ГБ необроблених даних.


Робоче навантаження підтримки рішення Ця серія експериментів досліджує продуктивність робочого навантаження підтримки рішення в багатовимірної базі даних розміром 100 ГБ. На рис. 4 показані результати цих трьох навантажень. На малюнку зображено графік часу відповіді на запит для всіх запитів робочого навантаження. Цей захід – хороший показник того, якою повинна бути продуктивність запиту при виконанні довільних запитів з робочого навантаження. Стовпці на малюнку порівнюють базову продуктивність (1.0) без використання оптимізації запиту типу "зірка" з продуктивністю, оптимізованої для такого запиту. Всі досліди були виконані на SQL Server 2008.

Рис 4Поліпшення продуктивності за рахунок оптимізації з'єднання типу "зірка"


Як видно на малюнку, всі робочі навантаження значно покращилися, від 12 до 30 відсотків. Конкретні числа можуть відрізнятися, але ми прогнозуємо поліпшення робочих навантажень підтримки рішення щодо SQL Server Engine на 15-20 відсотків за рахунок розширення оптимізацій запитів типу "зірка", яка включена в SQL Server 2008.


Паралелізм секціонованими таблиць


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


У SQL Server 2005 була додана можливість секціонованими великі співвідношення на менші логічні фрагменти, щоб покращити управління та адміністрування великих таблиць. Це також успішно застосовувалося для поліпшення обробки запитів, особливо в великих програмах підтримки рішень.


На жаль, деякі клієнти, що використовують SQL Server 2005, зіткнулися з проблемами продуктивності, особливо при роботі на багатопроцесорних комп'ютерах з паралельною що використовується спільно пам'яттю. При обробці паралельних запитів на секціонованими таблицях в SQL Server 2005, може виникати ситуація, при якій тільки частина доступних потоків використовується для виконання запитів.


Візьмемо 64-розрядний комьютер, де запити можуть використовувати до 64 потоків одночасно. Запит при цьому зачіпає дві секції. У SQL Server 2005 він отримає тільки 2 з 64 потоків, використовуючи, таким чином, тільки 2 / 64 (3.1 відсотка) потужності ЦП комп'ютера. Для деяких запитів повідомлялося про десятикратному погіршенні продуктивності разі секціонування в порівнянні з виконанням того ж запиту на тому ж комп'ютері на несекціонірованной версії тієї ж таблиці фактів.


Слід зазначити, що SQL Server 2005 був оптимізований для роботи із запитами, що зачіпають одну секцію. У цьому випадку процесор запитів передасть всі доступні потоки для виконання сканування. Ця особлива оптимізація призвела до значного збільшення продуктивності односекційних запитів на багатоядерних комп'ютерах, тому клієнти, звичайно, чекали того ж від запитів, які зачіпають кілька секцій.


Нова функція в SQL Server 2008, паралелізм секціонованими таблиць (PTP), покращує продуктивність запитів у разі секціонування, краще використовуючи обчислювальні потужності наявного обладнання, незалежно від того, скільки секцій зачіпає запит, або який відносний розмір окремих секцій. У типовому випадку сховища даних з секціонованими таблицею фактів, користувачі зможуть помітити значне поліпшення запитів, що виконуються паралельно, особливо якщо кількість доступних ядер процесора більше числа секцій, уражених запитом. І ця нова функція працює відразу, без додаткової налаштування або змін.


Нехай у нас є таблиця фактів, що представляє дані продажів, розділені за датою продажу на чотири секції. Уявити собі це допоможе діаграма на рис. 5. Зауважте, що замість одного кластерізованного індексу для всього діапазону даних, як у случе без секціонування, зазвичай є кластерізованний індекс у стовпці даних для кожної секції таблиці фактів. Припустимо, що запит Q підсумовує продажу за останні сім днів. Так як нові дані про продажі постійно додаються у таблицю фактів через останню секцію (позначену як P4), запит буде зачіпати різноманітні секції, в залежності від того, коли він виконується. Це показано в першому ряду діаграми, де запит Q1 зачіпає тільки одну секцію, а запит Q2 – дві, так як відповідні дані під час виконання перебувають в секціях P3 і P4.

Рис 5Нови функція PTP в роботі


Тепер припустимо, що є вісім потоків. Виконання Q1 і Q2 під SQL Server 2005 може привести до несподіваного поведінки. SQL Server 2005 влаштований так, що оптимізатор знає під час компіляції, що запитом буде порушена тільки одна секція, що секція буде вважатися однією несекціонірованной таблицею і що буде створений план, який одержує доступ до таблиці через усі наявні потоки.


У результаті для Q1, що зачіпає одну секцію (P3), виникне план, що обробляє вісьмома потоками (не показано на малюнку). У разі Q2, який зачіпає дві секції, виконавець передає кожній секції по одному потоку, навіть якщо обладнання має додаткові вільні потоки. Тому Q2 буде використовувати тільки малу частину потужності ЦП і напевно буде виконуватися значно повільніше, ніж Q1.


При виконанні Q1 і Q2 під SQL Server 2008 доступне обладнання буде використовуватися повніше, що забезпечить кращу продуктивність і передбачувана поведінка. У разі Q1, виконавець знову передає всі вісім доступних потоків обробці даних у P2 (не показано на малюнку). Q2, тим часом, викличе паралельний план, в якому виконавець передасть всі доступні потоки і P3 і P4 циклічним способом, ефект чого можна бачити в нижньому ряду діаграми, де обидві секції одержують по чотири потоки. ЦП зайняти повністю, а продуктивність Q1 і Q2 порівнянна.


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


Виграш в продуктивності SQL Server 2008 у порівнянні з SQL Server 2005 для випадку багатоядерного комп'ютера проілюстрований ще на рис. 6. Цей характерний графік демонструє продуктивність сканування для секціонованими таблиць. Для цього тесту, який проводився в системі з 64 ядрами і 256 ГБ оперативної пам'яті, ми розділили одну таблицю розміром 121 ГБ на 11 секцій по 11 ГБ. Для набору тестів на цьому малюнку ми організували файли в структуру сортують дерева, як з холодним, так і з гарячим запуском. Всі запити виробляють прості сканування даних.

Рис 6Продуктивність сканування для SQL Server при включенні нової функції PTP


По осі ординат відкладено час (у секундах), а по осі абсцис – ступінь паралелізму (DOP), яка аналогічна кількості потоків, відданих запитом. Можна бачити, що і при гарячому, і при холодному запусках час відгуку зменшується до тих пір, поки DOP не досягне 22. У цей момент для випадку холодного запуску насичується система введення-виведення. Це пов'язано з тим, що запит в цьому прикладі залежимо від введення-виведення. Для більш ЦП-орієнтованих навантажень це обмеження може не наступити або наступити при більш високій DOP.


Крива, що представляє випадок гарячого запуску, тим не менш, продовжує показувати зменшення часу відгуку зі збільшенням рівня DOP. У SQL Server 2005 обидві криві почали б падати приблизно на DOP 11, тому що при роботі з декількома секціями кількість потоків на секцію було б обмежена 1.


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


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


Нарешті, що важливо, нова функція PTP в SQL Server 2008 покращує легкість для читання планів запитів і дозволяє краще зрозуміти виконання деяких робочих навантажень. Наприклад, завдяки функції PTP, покращився то, як представлені у Showplan XML паралельні і серійні плани, також вдосконалено надання інформації про секціонування для планів при компіляції і планів при виконанні.


 

Стиснення даних


У міру того, як бізнес-аналітика стає популярною, підприємства додають все більше даних для аналізу в свої сховища. Результат – експонентний зростання обсягу керованих даних. У 1995 першим дослідження розміру баз даних корпорацією Winter Corporation дозволило з'ясувати, що найбільша система в світі содежіт терабайт даних. Через десять років найбільша база даних була вже в 100 разів більше. Вражає те, що розмір сховищ даних потроюється кожні два роки. Це ставить нові питання про управління такими великими обсягами даних і забезпечення пріемлімогой швидкості виконання запитів до сховищ даних. Ці запити зазвичай складні, що включають багато з'єднань і агрегатів, їм потрібен доступ до великих обсягів даних. І багато запити в робочій навантаженні залежать від введення-виведення.


Цю проблему допомагає вирішити власне стиснення даних. У SQL Server 2005 SP2 був включений новий формат зберігання змінної довжини під назвою vardecimal, для десяткових і числових даних. Цей новий формат зберігання може значно зменшити розмір баз даних. Виграш в обсязі може, у свою чергу, двома способами поліпшити продуктивність запитів, залежних від введення-виведення. По-перше, потрібно зчитувати менше сторінок, а по-друге, тому що дані зберігаються в буферному пулі стислими, збільшується очікуваний час життя сторінки (інакше кажучи, збільшується ймовірність, що потрібна сторінка опиниться в буфері). Звичайно, вигода в обсязі від стиснення даних призводить до навантаження на ЦП в процесі стиснення та розпакування даних.


SQL Server 2008 використовує формат зберігання vardecimal, забезпечуючи два види стиснення: стиснення ROW і PAGE. Стиснення ROW розширює формат зберігання vardecimal за рахунок зберігання всіх типів даних фіксованої довжини у форматі зберігання змінної довжини.


Деякі приклади типів даних фіксованої довжини – integer, char і вільні типи даних. Незважаючи на те, що SQL Server зберігає ці типи даних в форматі змінної довжини, їх семантика не змінюється (з точки зору програми, тип даних продовжує бути фіксованої довжини). Це означає, що можна скористатися перевагами стиснення даних, не змінюючи свої додатки.


Стиснення PAGE зменшує ізибточность даних у стовпцях в одній або більше рядку на даній сторінці. Воно використовує власну реалізацію алгоритму LZ78 (Лемпеля-Зіва), зберігаючи надлишкові дані один раз на сторінці, посилаючись потім на них з багатьох стовпців. Зауважте, що якщо ви використовуєте стиснення PAGE, стиснення ROW теж використовується.


Стиснення ROW і PAGE можна включити для таблиці, індексу або однієї і більше секцій секціонованими таблиць та індексів. Це дає повну гнучкість вибору таблиць, індексів і секцій для стиснення, дозволяючи знайти баланс між виграшем в об'ємі і навантаженням на ЦП. На рис. 7 це проілюстровано за допомогою таблиці продажів, секціонованими різними способами з вирівняними індексами.

Рис 7Секціонованими таблиця з різними налаштуваннями стиснення


Кожна секція являє квартал, останній квартал – Oct-Dec. Припустимо, що перші дві секції використовуються рідко, третя – середньо, а остання – найбільш активно. У цьому випадку можна включити стиск PAGE для перших двох секцій, щоб отримає максимальну економію місця, мнімально торкнувшись продуктивність робочого навантаження, стиснення ROW для третьої секції і не стискати останню.


Стиснення можна включити в автономному або оперативному режимі за допомогою виразів Alter Table або Alter Index мови DDL. SQL Server також дозволяє оцінити економію місця. Отримана економія місця буде залежати від розподілу даних і схеми стисливого об'єкта.


На підставі результатів тестів баз даних багатьох клієнтів, можна припустити, що більшість клієнтів зможуть зменшити розмір бази даних на 50-64 відсотків і зачительному збільшити продуктивність запитів, залежних від введення-виведення. Однак, оцінка продуктивності запитів, свзанних з ЦП, складніше і залежить від складності запиту. У SQL Server навантаження від розпакування виникає тільки при доступі до індексу або таблицями. Якщо відносна навантаження на ЦП операторів сканування невелика в порівнянні із загальним навантаженням запиту на ЦП, як зазвичай буває з сховищами даних, вплив на використання ЦП не повинно перевищувати 20-30 відсотків.


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


У SQL Server 2008 індексовані подання, вировенние по секціях, дозволяють більш ефективно створювати і управляти загальними агрегатами в реляційному сховище даних, а також використовувати їх у тих сценаріях, в яких раніше це було неефективно. Це підвищує продуктивність запиту. У типовому випадку, є таблиця фактів, секціонованими за датою. Індексовані подання (або загальні агрегати) визначаються на цій таблиці, щоб прискорити запити. При перемиканні на нову секцію таблиці відповідні секції індексованих уявлень, вирівняних по секціях, визначені на секціонованими таблиці, теж переключаються, причому автоматично.


Це значно краще, ніж в SQL Server 2005, де потрібно було видалити всі індексовані подання, визначені на секціонованими таблиці, перш ніж використовувати операцію ALTER TABLE SWITCH, щоб підключити або відключити секцію. Функція індексованих уявлень, вирівняних по секціях, дає в SQL Server 2008 переваги індексованих подань на великих секціонованими таблицях без необхідності перебудовувати агрегати на всій секціонованими таблиці. До цих переваг відносяться автоматична підтримка агрегатів і зіставлення індексованого подання.


Укрупнення блокувань на рівні секції


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


Цікавий момент – схема доступу до даних. Запити та операції DML можуть потребувати доступі або маніпуляціях тільки з частиною секцій. Тому якщо ви, наприклад, аналізуєте дані продажів за 2004 рік, вам вимагається доступ тільки до відповідних секціях; в ідеальному варіанті, запити, які звертаються до даних в інших секціях, не повинні надавати на це ніякого впливу (не рахуючи ресурсів системи). У SQL Server 2005 одночасний доступ до різних секціях може призвести до блокування таблиці, яка може ускладнити доступ до інших секціях.


Щоб зменшити ці перешкоди, в SQL Server 2008 включено на рівні таблиць параметр, що дозволяє контролювати укрупнення блокувань на рівні секції або таблиці. За замовчуванням укрупнення блокувань включено на рівні таблиць, як і в SQL Server 2005. Однак, політику укрупнення блокувань для таблиці можна змінити. Наприклад, можна встановити таке укрупнення блокувань:

Alter table <mytable> set (LOCK_ESCALATION = AUTO)

Ця команда наказує SQL Server вибрати відповідну для схеми таблиці гранулярність укрупнення блокувань. Якщо таблиця не секціонованими, укрупнення блокувань буде на рівні TABLE (таблиці). Якщо вона секціонованими, то гранулярність укрупнення блокувань буде на рівні секції. Цей параметр також використовується в SQL Server як спосіб зменшити ймовірність гранулярності блокування на рівні таблиці.


Висновок


Ми представили короткий огляд нових функцій SQL Server 2008, які допоможуть вам досягти більшої продуктивності запитів підтримки рішень в реляційних сховищах даних. Але не забувайте, що, хоча висока швидкість відгуку на запити підтримки рішень дуже важлива, є й інші принципові умови, не описані в цій статті.


До деяких додаткових функцій, що мають відношення до реляційному зберігання даних, відносяться:



Ми радимо ознайомитися з більш повною інформацією про всіх цих чудових функціях на сторінці SQL Server в Інтернеті, за адресою microsoft.com / sql.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*