Продуктивність БД

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

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

Модель

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

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

Пакетна обробка

Реляційна алгебра, мова SQL і механізми реляційних баз даних оптимізовані для роботи з пакетами даних Погано написана програма, в якій курсор пересувається від рядка до рядка, чи погано написаний запит SQL – головні джерела низької продуктивності

Додаткова Написання хороших пакетних запитів вимагає творчого підходу до ство-інформацій нию обєднань та підзапитів Про це ми поговоримо в главах 9 і 10

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

Індексація

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

■ Група рядків таблиці з кластеризувати індексом може бути лічена за одне (або декілька) звернення до фізичних сторінкам при цьому не доводиться постійно перескакувати по різних сторінках

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

Індексація є ключовим моментом фізичної схеми Її слід розглядати швидше як мистецтво, ніж як науку Водночас розуміння роботи оптимізатора запитів бази даних і структури індексів в поєднанні зі знанням схеми конкретної бази даних і механізму доступу запитів до даних допоможе спроектувати індекси більш точно

Додаткова Стратегії налаштування індексів будуть детально розглянуті в главі 50

інформація

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

Розділи

Як розділити, або, іншими словами, розподіл даних за різними приводам дисків, – це метод підвищення продуктивності особливо великих баз даних (VLD)

Додаткова Особливості операцій розбиття на розділи описані в главі 53

‘. Інформація \

Кешування

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

Доступність

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

Вимоги до доступності часто визначають у термінах девяток. Наприклад, термін пять девяток означає, що система доступна 99,999% необхідного часу (табл 13)

Таблиця 13 Таблиця девяток

Відсотки

Доступність

Недоступність

Опис

99,99999

364 дня 23 години 59 хвилин 56 секунд

3 секунди

7 девяток

99,9999

364 дня 23 години 59 хвилин 29 секунд

31 секунда

6 девяток

99,999

364 дня 23 години 54 хвилини 45 секунд

5 хвилин 15 секунд

5 девяток

99,99

364 дня 23 години 7 хвилин 27 секунд

52 хвилини 33 секунди

4 девятки

99,95

364 дня 19 годин 37 хвилин 12 секунд

4:00 22 хвилини 48 секунд

99,9

364 дня 15 годин 14 хвилин 24 секунди

8:00 45 хвилин 36 секунд

3 девятки

99,8

364 дні 6 годин 28 хвилин 48 секунд

17 годин 31 хвилина 12 секунд

99,72603

364 дня рівно

1 день

Рівне 1 день

99,5

363 днів 4 години 12 хвилин 00 секунд

1 день 19 годин 48 хвилин 00 секунд

99

361 день 8:00 24 хвилини 00 секунд

3 дня 15 годин 36 хвилин 00 секунд

2 девятки

98

357 днів 16 годин 48 хвилин 00 секунд

7 днів 7:00 12 хвилин 00 секунд

97

354 дні 1 годину 12 хвилин 00 секунд

10 днів 22 години 48 хвилин 00 секунд

У розділах 36 і 52 детально викладені засоби забезпечення доступності, пропоновані в SQL Server 2005

Надмірність

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

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

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

Відновлення

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

Масштабованість

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

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

Рівень абстракції

Безліч виробничих баз даних проектується на совість і відмінно функціонує тривалий час Однак як тільки виникає необхідність внесення змін, складність їх впровадження з кожним наступним разом зростає У результаті через кілька років команда розробників може зіткнутися з ситуацією, коли база даних вже перестала відповідати своєму призначенню, але її надзвичайно складно змінити, оскільки доведеться витратити занадто великі кошти на її реанімацію

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

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

Додаткова Розробка і програмування рівня абстракції на мові Т-SQL описано в

інформація главі 25

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

Узагальнення

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

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

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

Я не переоцінюю важливість узагальнення Навіть більше, ніж нормалізація, ця техніка залежить від простоти моделі і гнучкості схеми В останній схемі бази даних, яку мені доводилося аналізувати, містилося близько 80 таблиць За допомогою узагальнення, комбінуючи по пять таблиць в одну сутність, мені вдалося скоротити схему до 17 таблиць, в результаті чого вона стала більш потужною і гнучкою, ніж оригінал Коли розробник хвалиться, що створив базу даних з безліччю таблиць, я зазвичай вважаю, що він створив нежиттєздатну схему

Безпека

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

Обмеження доступу

Будь корпоративна база даних містить систему обмеження доступу до даних окремих осіб і їх груп Гранулярність таких правил може варіюватися від звичайного обмеження доступу до визначення привілеїв на створення, вилучення, оновлення і видалення обєктів

Додаткова Система безпеки SQL Server 2005, яка може бути досить склад-інформація ної, описана в главі 40

Інформація про власників

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

Додаткова Сумісність з законом Сарбанеса-Окслі вимагає не тільки захисту даних, інформація а й документування будь-яких змін власників даних або обмежень: доступу

Журнал аудиту

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

Додаткова У главі 24 ми розглянемо методи створення журналів аудиту

інформація

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*