Навигация по сайту

Популярные статьи

Теорія оптимізації і SQL Server

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

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

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

модель схеми

Моєю головною стратегією підвищення продуктивності є ретельна розробка схеми. Хороша схема дозволить застосовувати пакетні запити і полегшить планування індексів.

Щоб створити ефективну схему, дотримуйтесь наступних порад:

? уникайте надмірної складності;

? ретельно вибирайте ключі;

? стежте за необов'язковими даними;

? використовуйте деякий рівень абстракції.

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

В результаті базу даних можна вважати мертвонародженою

Мал. 1.3. Теорія оптимізації говорить, що кожна стратегія залежить від іншої і активізується нею

запити

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

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

Таблиця 1.4. методи програмування

завдання

Найкраще рішення

Складна бізнес-логіка

Запити, підзапити, сте

Динамічне генерування DDL Курсори

перебудова списку

Змінні або курсор

перехресна таблиця

Запит з пропозицією pivot або case

Проходження по ієрархії

Користувацька функція або сте

Накопичувальні суми

курсор

Додаткова У главі 20 ви дізнаєтеся, як суттєво підвищити продуктивність, преоб- | інформація разу складні логічні курсори в пакетні запити.

Індексація

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

Додаткова Створення кластеризованих, некластерізованних і інших індексів детально інформація описано в главі 50.

конкуренція

Блокування - це більш складна проблема, ніж думають більшість розробників, і більшість адміністраторів баз даних змушені вирішувати її шляхом зниження рівня ізоляції транзакцій до no lock, що дуже небезпечно.

Конкуренцію можна порівняти з джерелом води. Якщо люди, вальяжно прогулюючись, очікують своєї черги наповнити стаканчики, ситуація стабільна. Установка параметра nolock рівносильна заклику: "Все кидайтеся до джерела!" Природно, в цьому випадку ситуація вийде з-під контролю і тиснява неминуча. У такій ситуації краще послідовно наливати воду в стаканчики, при цьому скорочуючи час свого перебування у джерела. Аналогічна ситуація і в базах даних: краще обмежитися невеликими запитами або скоротити час виконання транзакцій. А для створення ефективних транзакцій потрібно розробити ефективну схему, використовувати пакетний код і індекси.

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

розширена масштабованість

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

? ізоляцією миттєвих знімків;

? поділом таблиць;

? індексованими уявленнями;

? брокером служб.

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

Теорія оптимізації, в якій розкрито залежності між різними технологіями оптимізації, є революційною концепцією. Найсвіжішу інформацію про теорію оптимізації, а також мої презентації рішень підвищення продуктивності ви знайдете на сайті www. SQLServer Bible. com.

резюме

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

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

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

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