Продуктивність запитів до сховища даних 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 показана схема сховища даних на основі багатовимірної моделі, що використовує таблиці фактів і вимірювань з сурогатними ключами.

Рис 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>

*

*