Оптимізація запитів
Для реляційних систем оптимізація є як проблемою, і можливістю підвищення продуктивності.
Проблема оптимізації у тому, деякі системи задля досягнення певного рівня продуктивності вимагають оптимізації. Оптимізація дозволяє поліпшити роботу системи, оскільки однією з сильних сторін реляційного підходу є те, що застосування оптимізації до реляційного виразу переводить цей вислів більш ефективний семантичний рівень.
З іншого боку, в нереляційних системах, в яких запити користувача виражаються на нижчому семантичному рівні, будь-яка оптимізація повинна виконуватися програмістом вручну.
У таких системах програміст, а чи не система, визначає, які операції низького рівня мають бути виконані й у якій послідовності. І якщо програміст ухвалив неправильне рішення, то система ніяк не зможе виправити становище.
Перевага автоматичної оптимізації полягає в тому, що користувач або програміст може не здогадуватися над найкращим способом висловлення своїх запитів, тобто над тим, як сформулювати запит краще, ніж програміст, з наступних причин:
хороший оптимізатор має достатню кількість інформації, якої користувач може не мати. Оптимізатор повинен володіти деякими статистичними даними, такими як: координальна кількість відношення, кількість значень для кожного атрибуту відношення, кількість значень кожного значення даного атрибута. Завдяки наявності даних оптимізатор здатний більш точно оцінювати ефективність будь-якої стратегії, реалізації конкретного запиту і вибрати найкращу стратегію.
Якщо з часом статистика бази даних значно зміниться, наприклад, в результаті їїреорганізації, то реалізації запиту може знадобитися зовсім інша стратегія, ніж до реорганізації. Іншими словами, може знадобитися повторна оптимізація. У реляційних системах процес повторної оптимізації досить тривіальний. Це просто повторне оброблення вихідного запиту системним оптимізатором. У нереляційних системах повторна оптимізація вимагає переписування програми, а деяких випадках взагалі не здійсненна.
Оптимізатор здатний розглядати сотні різних стратегій реалізації запиту, тоді як програміст, як правило, вивчає лише три-чотири. Призначення оптимізатора полягає у виборі ефективної стратегії реалізації запитів. Насправді оптимізованою стратегією зазвичай вважається та, яка є деяким поліпшенням вихідної стратегії виконання запиту.
Стадії процесу оптимізації запитів
Перетворення запиту на внутрішню форму.
Перетворення запиту на канонічну форму.
Вибір потенційних низькорівневих процедур.
Генерація планів виконання запиту та вибір плану з мінімальними витратами.
На першій стадії виконується перетворення запиту на деяке внутрішнє уявлення, зручніше для маніпуляцій. Незалежно від того, який спосіб формалізації обраний, він повинен бути достатньо повним, щоб подати будь-які запити, які можуть бути визначені мовою системи.
Крім того, обраний спосіб оптимізації має бути достатньо нейтральним, щоб не визначати подальших оптимізаційних рішень.
Зазвичай, внутрішнє подання запиту є певною модифікацією дерева запитів.
На другій стадії виконується кілька операцій оптимізації, про які наперед відомо, що вони збільшують продуктивність запитунезалежно від реальних даних, що зберігаються в базі даних та шляхів доступу до них.
Усі запити, крім найпростіших, реляційні мови зазвичай дозволяють висловити декількома різними способами.
Продуктивність обчислення запиту повинна залежати від форми запису, яку вибрав користувач.
Тому наступний етап обробки запиту переводить їх у деяку канонічну форму. Метою цього перетворення є виключення зовнішніх відмінностей в еквівалентних уявленнях запиту та пошук більш ефективного, порівняно з вихідним, уявлення запиту.
На третій стадії після перетворення внутрішньої форми запиту на канонічну форму необхідно вирішити, як виконувати запит, представлений у канонічній формі. На цій стадії береться до уваги наявність індексів, розподіл значень даних, що зберігаються, фізична кластеризація збережених даних і т.д.
Основна стратегія полягає в тому, щоб розглянути запит як серію низькорівневих операцій з'єднання, вибірки тощо, які певною мірою залежні один від одного. Для кожної низькорівневої операції існує набір низькорівневих процедур реалізації, наприклад, набір процедур реалізації операції вибірки включає операції для вибірки з умовою рівності, визначення значення потенційного ключа, операцію для індексованого атрибута, за яким визначається вибірка і операцію для неіндексованого атрибута.
p align="justify"> З кожною процедурою пов'язана також вартісна формула, яка вказує так звану вартість виконання процедури, тобто. рівень необхідних витрат за її виконання.
Зазвичай вартість нараховується в контексті операцій введення/виводу з диска, але деякі системи враховують час використання процесора та інші фактори.
Далі здопомогою інформації з каталогу стан бази даних, тобто. про наявність індексів, кількість записів у таблиці тощо. оптимізатор вибирає одну або кілька операцій у запиті.
На останній четвертій стадії процесу оптимізації конструюються потенційні плани виконання запитів, після чого їх вибирається кращий, тобто. найменш дорогий.
Кожен план виконання будується як поєднання набору процедур реалізації. У цьому кожної низькорівневої операції у запиті відповідає одна процедура.
Для вибору плану з найменшою вартістю рекомендується використовувати евристичні алгоритми досить обмеженому наборі планів запиту.
Поняття досить обмеженого набору означає, що необхідно зменшити простір пошуку до діапазону, що піддається аналізу та управлінню.