Теорія оптимізації і масштабованість

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

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

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

Масштабування платформи

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

■ Виділіть для SQL Server окремий компютер Не використовуйте цей сервер як файловий, сервер друку, поштовий або IIS

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

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

Недоліком SAN є те, що її дисковий простір варто в 40-50 разів більше простору локального диска, і її досить складно конфігурувати і налаштовувати Тому допоможіть адміністратору SAN сконцентруватися на вимогах бази даних і ретельно конфігурувати бази даних, щоб вони не загубилася в масі файлових потоків організації Це завдання може виявитися досить важкою, особливо якщо потоки бази даних і файлового сервера скомбіновані в одній і тій же S AN

■ Використовуйте доставку журналу або реплікацію для створення доступної тільки для читання бази даних звітності

Додаткова Про реплікації см в главі 39, а про доставку журналу і дзеркальному відображенні інформація бази даних – у главі 52

■ Подумайте про використання окремого резидентного диска для бази tempdb або файлу підкачки Windows

Масштабованість і бізнес-процеси

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

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

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

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

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

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

■ При виборі приводів в першу чергу звертайте увагу на пропускну здатність В даний час пристрої Ultra 320 SCSI пропонують найбільшу пропускну здатність, на пяти їм наступають пристрої SATA 2, і вже існують деякі цікаві контролери SATA RAED Швидкість обертання приводу являє собою ще один ключовий фактор пропускної здатності Існує пряма залежність між швидкістю обертання приводу і обсягом даних, які можуть бути лічені або записані за одну мілісекунди В даний час на вершині знаходяться пристрої зі швидкістю обертання 15000 об / хв

■ SQL Server оптимізований для послідовного читання і запису в дискової підсистемі як файлів даних, так і журналу транзакцій Тому я використовую масив RAID 1 (дзеркальний), який також оптимізований для послідовних операцій, а не RAID 5, який краще себе проявляє у випадковому доступі

■ Основною метою дискової підсистеми є не використання як можна більш ємного диска, а використання якомога більшої кількості приводів Використання двох пристроїв ємністю 73 Гбайт набагато краще, ніж одного, ємністю 146 Гбайт

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

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

■ Оптимізатор запитів SQL Server 2005 надає сильне навантаження на базу tempdb Краща дискова оптимізація полягає у виділенні для tempdb окремого DAS, і ще одного – для журналу транзакцій цієї бази даних Ще одним хорошим рішенням є приміщення tempdb в різні файли, розміщені в різних дискових підсистемах DAS

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

■ Щоб узагальнити рекомендації щодо масштабування дискової підсистеми, відмінної від SAN, в табл 531 описана одна з можливих конфігурацій

Таблиця 531 Масштабування дискової підсистеми, відмінної від SAN

Логічний диск

Призначення

С:

Система Windows і виконувані файли SQL Server

D:

Файл підкачки Windows

Е:

Файл даних TempDB

F:

Журнал транзакцій TempDB

G:

Файл даних

Н:

Журнал транзакцій

I:, ..

Додаткові файли даних

Додаткова Практика показує, що продуктивність SAN приблизно в чотири рази інформація вище, ніж у дискової підсистеми DAS Водночас, скориставшись дослідженнями доктора Джима Грея (Jim Gray), служба Microsoft Consulting Services створила сховище даних ємністю 24 Тбайт, використовуючи 48 приводів SATA, і досягла загальної пропускної здатності, рівний SAN (2,2 Гбайт при

послідовному читанні і 2,0 Гбайт при послідовній запису), приблизно за сорокову частину вартості SAN Більш докладно про це ви можете прочитати за адресою:

wwwsqlmagcom/Article/ArticleID/49557/sql_server_49557html

Природно, ще одним варіантом масштабування є перехід з редакції Standard Edition на редакцію Enterprise Edition, щоб використовувати більше процесорів, або перейти на 64-розрядну редакцію SQL Server 2005

Масштабування рішень

У вершині піраміди теорії оптимізації знаходиться налаштування розширеного масштабування SQL Server 2005 Вона пропонує кілька технологій і засобів масштабування рівня бази даних для підвищення продуктивності

■ Брокер служб може буферізіровать запити, підвищуючи масштабованість під час пікових навантажень (Про брокера служб см в розділі 28)

■ Рівень ізоляції Read Commited Snapshot дозволяє виконувати високопродуктивні операції читання без конфліктів конкуренції з операціями запису (Про ізоляції Snapshot см в главі 51)

Редакція Enterprise Edition додає наступні потенційні ресурси масштабування

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

■ Індексовані уявлення дозволяють створювати Групові індекси в уявленнях, які ефективно денормалізуют матеріалізовані уявлення

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

У цьому розділі ми зосередимо увагу на функціях масштабування редакції Enterprise Edition

Джерело: Нільсен, Пол 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>

*

*