SQL Server Archiтектура (пояснення)

Примітки зі столу конфігурації/встановлення:

• Для підключення через іменований канал. Цей параметр вимкнено за замовчуванням, і його потрібно ввімкнути диспетчером конфігурації SQL.

Що таке TDS?

Тепер ми знаємо, що існує три типи клієнт-сервер Architecture, дозволяє нам поглянути на TDS:

• TDS означає потік табличних даних.
• Усі 3 протоколи використовують пакети TDS. TDS інкапсульовано в мережевих пакетах. Це дозволяє передавати дані з клієнтської машини на серверну.
• TDS спочатку був розроблений Sybase і зараз належить Microsoft

Реляційний механізм

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

Як зображено на Archiтектурна діаграма є 3 основні компоненти реляційного механізму. Вивчимо компоненти докладніше:

Парсер CMD

Дані, отримані від рівня протоколу, потім передаються до Relational Engine. «CMD Parser» є першим компонентом Relational Engine, який отримує дані запиту. Основне завдання CMD Parser — перевірити запит Синтаксична та семантична помилка. Нарешті, це створює дерево запитів. Давайте обговоримо детально.

Синтаксична перевірка:

• Як і будь-яка інша мова програмування, MS SQL також має попередньо визначений набір ключових слів. Крім того, SQL Server має власну граматику, яку розуміє SQL-сервер.
• SELECT, INSERT, UPDATE та багато інших належать до попередньо визначених списків ключових слів MS SQL.
• CMD Parser виконує синтаксичну перевірку. Якщо введення користувачами не відповідає синтаксису мови чи граматичним правилам, воно повертає помилку.

приклад: Припустимо, росіянин зайшов в японський ресторан. Замовляє фастфуд російською мовою. На жаль, офіціант розуміє тільки японську. Яким буде найбільш очевидний результат?

Відповідь – офіціант не може обробити замовлення далі.

Не повинно бути жодних відхилень у граматиці чи мові, яку приймає SQL-сервер. Якщо вони є, SQL-сервер не може його обробити, а отже, поверне повідомлення про помилку.

Ми дізнаємося більше про запити MS SQL у наступних уроках. Проте розглянемо нижче найпростіший синтаксис запиту

SELECT * from <TABLE_NAME>;

Тепер, щоб отримати уявлення про те, що робить синтаксис, скажімо, якщо користувач виконує базовий запит, як показано нижче:

SELECR * from <TABLE_NAME>

Зауважте, що замість «SELECT» користувач ввів «SELECR».

Результат: Синтаксичний аналізатор CMD розбере цей оператор і видасть повідомлення про помилку. Оскільки «SELECR» не відповідає попередньо визначеній назві ключового слова та граматиці. Тут CMD Parser очікував «SELECT».

Семантична перевірка:

• Це виконує Нормалізатор.
• У своїй найпростішій формі він перевіряє, чи існує в схемі ім’я стовпця та ім’я таблиці, що запитується. І якщо він існує, прив’яжіть його до Query. Це також відомо як Обов'язковий.
• Складність зростає, коли запити користувача містять VIEW. Нормалізатор виконує заміну на внутрішньо збережене визначення перегляду та багато іншого.

Давайте зрозуміємо це за допомогою прикладу нижче –

SELECT * from USER_ID

Результат: Синтаксичний аналізатор CMD розбере цей оператор для семантичної перевірки. Синтаксичний аналізатор видасть повідомлення про помилку, оскільки нормалізатор не знайде запитану таблицю (USER_ID), оскільки вона не існує.

Створити дерево запитів:

• Цей крок генерує інше дерево виконання, у якому можна виконувати запит.
• Зауважте, що всі різні дерева мають однаковий бажаний результат.

Оптимізатор

Робота оптимізатора полягає у створенні плану виконання для запиту користувача. Це план, який визначатиме, як буде виконано запит користувача.

Зауважте, що не всі запити оптимізовані. Оптимізовано такі команди DML (мова модифікації даних), як SELECT, INSERT, DELETE та UPDATE. Такі запити спочатку позначаються, а потім надсилаються в оптимізатор. Такі команди DDL, як CREATE і ALTER, не оптимізовані, а натомість компілюються у внутрішню форму. Вартість запиту розраховується на основі таких факторів, як використання процесора, використання пам’яті та потреби введення/виведення.

Роль оптимізатора полягає в тому, щоб знайти найдешевший, а не найкращий, економічно ефективний план виконання.

Перш ніж перейти до більш технічних деталей оптимізатора, розглянемо наведений нижче приклад із реального життя:

приклад:

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

Висновок: Важливіше вибирати з розумом. Якщо бути точним, вибирайте який варіант найкращий, не найдешевший.

Так само MS Оптимізатор SQL працює на основі вбудованих вичерпних/евристичних алгоритмів. Мета полягає в тому, щоб мінімізувати час виконання запиту. Усі алгоритми оптимізатора є належність Microsoft і секрет. хоча, Нижче наведено кроки високого рівня, які виконує MS SQL Optimizer. Пошук оптимізації складається з трьох етапів, як показано на діаграмі нижче:

Фаза 0: Пошук тривіального плану:

• Це також відомо як Етап попередньої оптимізації.
• Для деяких випадків може існувати лише один практичний, дієвий план, відомий як тривіальний план. Немає необхідності створювати оптимізований план. Причина полягає в тому, що пошук більше призведе до знаходження того самого плану виконання під час виконання. Це також з додатковими витратами на пошук оптимізованого плану, який взагалі не був потрібним.
• Якщо тривіальний план не знайдено, тоді 1^st Починається фаза.

Етап 1: пошук планів обробки транзакцій

• Це включає в себе пошук Простий і складний план.
• Простий пошук за планом: минулі дані стовпця та індексу, які беруть участь у запиті, використовуватимуться для статистичного аналізу. Зазвичай це складається, але не обмежується одним індексом на таблицю.
• Проте, якщо простий план не знайдено, то шукають більш складний план. Він передбачає кілька індексів на таблицю.

Фаза 2: Паралельна обробка та оптимізація.

• Якщо жодна з наведених вище стратегій не працює, оптимізатор шукає можливості паралельної обробки. Це залежить від можливостей обробки та конфігурації машини.
• Якщо це все ще неможливо, починається заключний етап оптимізації. Тепер кінцевою метою оптимізації є пошук усіх інших можливих варіантів для виконання запиту найкращим чином. Фінальний етап оптимізації Algorithms він має Microsoft Пристойність.

Виконавець запитів

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

Система зберігання

Робота Storage Engine полягає в тому, щоб зберігати дані в системі зберігання, як-от Disk або SAN, і отримувати дані за потреби. Перш ніж ми глибоко зануримося в систему зберігання, давайте подивимося, як зберігаються дані Database та тип доступних файлів.

Файл даних і екстент:

Файл даних фізично зберігає дані у формі сторінок даних, причому кожна сторінка даних має розмір 8 КБ, утворюючи найменшу одиницю зберігання в SQL Server. Ці сторінки даних логічно згруповані для формування екстентів. У SQL Server жодному об’єкту не призначено сторінку.

Обслуговування об'єкта здійснюється через екстенти. Сторінка має розділ під назвою «Заголовок сторінки» розміром 96 байт, який містить інформацію про метадані сторінки, як-от тип сторінки, номер сторінки, розмір використаного простору, розмір вільного простору та вказівник на наступну та попередню сторінки. і т.д.

Типи файлів

1. Первинний файл

• Кожна база даних містить один основний файл.
• Тут зберігаються всі важливі дані, пов’язані з таблицями, представленнями, тригерами тощо.
• Розширення є .MdF зазвичай, але може мати будь-яке розширення.

2. Вторинний файл

• База даних може містити або не містити кілька вторинних файлів.
• Це необов’язково та містить дані користувача.
• Розширення є .наф зазвичай, але може мати будь-яке розширення.

3. Файл журналу

• Також відомий як журнали попереднього запису.
• Розширення є .ldf
• Використовується для керування транзакціями.
• Це використовується для відновлення після будь-яких небажаних випадків. Виконайте важливе завдання відкату до незафіксованих транзакцій.

Система зберігання даних складається з 3 компонентів; розглянемо їх докладніше.

Метод доступу

Він діє як інтерфейс між виконавцем запиту та Buffer Менеджер/Журнали транзакцій.

Сам метод доступу не виконує жодних завдань.

Перша дія полягає в тому, щоб визначити, чи є запит:

1. Select Statement (DDL)
2. Інструкція Non-Select (DDL & DML)

Залежно від результату метод доступу виконує такі дії:

1. Якщо запит є DDL, оператор SELECT, запит передається до Buffer менеджер для подальшої обробки.
2. І якщо запит, якщо DDL, оператор NON-SELECT, запит передається до диспетчера транзакцій. Здебільшого це стосується оператора UPDATE.

Buffer менеджер

Buffer менеджер керує основними функціями для модулів нижче:

• Кеш плану
• Розбір даних: Buffer кеш і зберігання даних
• Брудна сторінка

Ми навчимося планувати, Buffer і Кеш даних у цьому розділі. Ми розглянемо Брудні сторінки в розділі Транзакції.

Кеш плану

• Існуючий план запиту: Менеджер буферів перевіряє, чи є план виконання в збереженому кеші планів. Якщо так, то використовується кеш плану запиту та пов’язаний з ним кеш даних.
• Перший план кешу: Звідки береться наявний кеш плану? Якщо план виконання першого запиту виконується та є складним, має сенс зберігати його в кеші плану. Це забезпечить швидшу доступність, коли наступного разу SQL-сервер отримає той самий запит. Отже, це не що інше, як сам запит, який план виконання зберігається, якщо він запускається вперше.

Розбір даних: Buffer кеш і зберігання даних

Buffer менеджер надає доступ до необхідних даних. Залежно від того, чи існують дані в кеші даних, можливі два підходи:

Buffer Кеш – м’який аналіз:

Buffer Менеджер шукає дані Buffer в кеші даних. Якщо вони присутні, ці дані використовуються програмою Query Executor. Це покращує продуктивність, оскільки кількість операцій вводу/виводу зменшується під час отримання даних із кешу порівняно з отриманням даних із сховища даних.

Зберігання даних – жорсткий аналіз:

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

Брудна сторінка

Він зберігається як логіка обробки Transaction Manager. Детально дізнаємося в розділі Transaction Manager.

Менеджер транзакцій

Менеджер транзакцій викликається, коли метод доступу визначає, що Query є оператором Non-Select.

Менеджер журналів

• Менеджер журналів відстежує всі оновлення, зроблені в системі, за допомогою журналів у журналах транзакцій.
• Колоди мають Реєструє порядковий номер журналу з ідентифікатором транзакції та записом про зміну даних.
• Це використовується для відстеження Здійснена транзакція та відкат транзакції.

Менеджер блокувань

• Під час транзакції пов’язані дані в сховищі даних перебувають у стані блокування. Цей процес обробляється диспетчером блокувань.
• Цей процес забезпечує узгодженість та ізоляція даних. Також відомий як властивості КИСЛОТИ.

Процес виконання

• Менеджер журналів починає реєстрацію, а Менеджер блокувань блокує пов’язані дані.
• Копія даних зберігається в Buffer кеш-пам'ять
• Копія даних, які мають бути оновлені, зберігається в буфері журналу, а всі події оновлюють дані в буфері даних.
• Сторінки, які зберігають дані, також відомі як Брудні сторінки.
• Реєстрація контрольної точки та попереднього запису: Цей процес запускається та позначає всю сторінку з брудних сторінок на диск, але сторінка залишається в кеші. Частота становить приблизно 1 пробіжку за хвилину. Але сторінка спочатку надсилається на сторінку даних файлу журналу з Buffer журнал. Це відомо як Попереднє ведення журналу.
• Лінивий письменник: Брудна сторінка може залишитися в пам'яті. Коли SQL сервер спостерігає величезне навантаження і Buffer пам'ять потрібна для нової транзакції, це звільняє брудні сторінки з кешу. Він діє на LRU – Алгоритм очищення сторінки з пулу буферів на диск використовувався останнім часом.

Підсумки

• Три типи клієнт-сервера ArchiІснує структура: 1) Спільна пам'ять 2) TCP/IP 3) Іменовані канали
• TDS, розроблений Sybase і зараз належить Microsoft, це пакет, інкапсульований у мережевих пакетах для передачі даних від клієнтської машини до серверної.
• Relational Engine містить три основні компоненти:Парсер CMD: Це відповідає за синтаксичну та семантичну помилку та, нарешті, створює дерево запитів.оптимізатор: Роль оптимізатора полягає в тому, щоб знайти найдешевший, а не найкращий економічно ефективний план виконання.

  Виконавець запиту: Виконавець запиту викликає метод доступу та надає план виконання для логіки отримання даних, необхідної для виконання.

• Існує три типи файлів: основний файл, вторинний файл і файли журналу.
• Механізм зберігання: має такі важливі компонентиМетод доступу: Цей компонент визначає, чи є запит оператором Select чи Non-Select. Викликає Buffer і менеджера переказів відповідно.Buffer Менеджер: Buffer менеджер керує основними функціями для кешу плану, аналізу даних і брудної сторінки.

  Менеджер транзакцій: Це керує транзакціями без вибору за допомогою диспетчерів журналів і блокувань. Крім того, полегшує важливу реалізацію протоколювання Write Ahead і Lazy writers.