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

MS SQL Server е клиент-сървър архитектура. Процесът на MS SQL Server започва с клиентското приложение, изпращащо заявка. SQL Server приема, обработва и отговаря на заявката с обработени данни. Нека обсъдим подробно цялата архитектура, показана по-долу:

Както е показано на диаграмата по-долу, SQL Server има три основни компонента Archiтекстура:

1. Протоколен слой
2. Релационна машина
3. Двигател за съхранение

Протоколен слой – SNI

Протоколният слой на SQL Server, известен още като Server Network Interface (SNI), поддържа три типа клиент-сървър архитектура. Всеки протокол обслужва различен мрежов сценарий. Разбирането на тези протоколи е от съществено значение, преди да се проучи как заявките се обработват вътрешно.

Споделена памет

Да разгледаме сценарий за разговор рано сутрин. Том и майка му са на едно и също логично място – в дома си. Том иска кафе, а мама го сервира директно. По подобен начин SQL Server предоставя протокола за споделена памет (Shared Memory), когато клиентът и сървърът работят на една и съща машина. И двамата комуникират чрез споделена памет без никакви мрежови разходи.

Аналогия: Том се свързва с Клиента, Мама се свързва със SQL Server, Домът се свързва с Машината, а вербалната комуникация се свързва с протокола за споделена памет.

Бележки за конфигурацията: In SQL Management Studio, опцията „Име на сървър“ за локална връзка може да бъде „.“, „localhost“, „127.0.0.1“ или „Machine\Instance“.

TCP / IP

Сега да предположим, че Том иска кафе от магазин, разположен на 10 км. Том е у дома, а кафенето е на оживен пазар. Те комуникират чрез клетъчна мрежа. По подобен начин SQL Server предоставя TCP / IP протокол когато клиентът и SQL Server са на отделни машини, свързани през мрежа.

Аналогия: Том се свързва с Клиента, кафенето се свързва със SQL Server, домът и пазарът се свързват с отдалечени местоположения, а клетъчната мрежа се свързва с TCP/IP протокола.

Бележки за конфигурацията: В SQL Management Studio опцията „Име на сървъра“ за TCP/IP връзка трябва да бъде „Машина\Екземпляр на сървъра“. SQL Server използва порт 1433 по подразбиране за TCP/IP връзки.

Именувани тръби

Накрая Том иска зелен чай от съседката си Сиера. Те са на едно и също физическо място, съседи са и комуникират чрез вътрешна мрежа. По подобен начин SQL Server предоставя протокола Named Pipe, когато клиентът и сървърът са свързани чрез локална мрежа (LAN).

Аналогия: Tom се свързва с клиента, Sierra се свързва със SQL Server, being neighbors се свързва с LAN, а intra-network се свързва с протокола Named Pipe.

Бележки за конфигурацията: Именуваните канали са деактивирани по подразбиране и трябва да бъдат активирани чрез SQL Configuration Manager.

Какво е TDS?

След като трите типа клиент-сървър архитектура са ясни, ето един поглед към TDS:

• TDS означава Табличен поток от данни.
• И трите протокола използват TDS пакети.
• TDS е капсулиран в мрежови пакети, което позволява прехвърляне на данни от клиентската машина към сървърната машина.
• TDS е разработен първоначално от Sybase и сега е собственост на Microsoft.

Следната таблица сравнява трите протокола за свързване на SQL Server:

Особеност	Споделена памет	TCP / IP	Именувани тръби
Обхват на мрежата	Същата машина	Отдалечено (WAN/Интернет)	Само локална мрежа
Порт по подразбиране	N / A	1433	445
Изпълнение	Най-бърз (без мрежови разходи)	Добро (оптимизирано за WAN)	Добър (оптимизиран за LAN)
Активирано по подразбиране	Да	Да	Не
Най-добър случай на употреба	Локално развитие и тестване	Отдалечен достъп до продукцията	Надеждни LAN среди

Тъй като протоколният слой обработва мрежовата комуникация, следващата стъпка в архитектурата на SQL Server е обработката на самата заявка. Тук релационният енджин поема контрола.

Релационна машина

Релационният енджин е известен още като процесор за заявки. Той съдържа компонентите на SQL Server, които определят какво трябва да направи една заявка и как може да бъде изпълнена най-ефективно. Той е отговорен за изпълнението на потребителски заявки, като изисква данни от енджин за съхранение и обработва върнатите резултати.

Както е показано на архитектурната диаграма, има три основни компонента на релационния енджин:

CMD анализатор

Данните, получени от протоколния слой, се предават на релационния енджин. CMD парсерът е първият компонент, който получава данните от заявката. Основната му задача е да провери заявката за синтактични и семантични грешки и след това да генерира дърво на заявките.

Синтактична проверка: Както всеки друг език за програмиране, SQL Server има предварително дефиниран набор от ключови думи и граматически правила. SELECT, INSERT, UPDATE и много други принадлежат към списъка с предварително дефинирани ключови думи. CMD Parser проверява дали входните данни следват тези правила. Ако входните данни на потребителя се отклоняват от очаквания синтаксис, парсерът връща грешка.

Пример: Да предположим, че руснак влиза в японски ресторант и поръчва на руски. Сервитьорът разбира само японски и не може да обработи поръчката. По подобен начин, ако потребител въведе „SELECR“ вместо „SELECT“, CMD Parser връща грешка, защото не разпознава ключовата дума.

Семантична проверка: Това се извършва от Нормализатора. Той проверява дали имената на колоните, имената на таблиците и другите обекти, към които се отправят заявки, действително съществуват в схемата. Ако съществуват, Нормализаторът ги свързва със заявката. Този процес е известен още като Обвързване (Binding). Когато потребителските заявки съдържат VIEW, Нормализаторът го замества с вътрешно съхранената дефиниция на изгледа.

Пример: Работещи SELECT * from USER_ID би накарало парсера да издаде грешка по време на семантичната проверка, ако таблицата USER_ID не съществува в базата данни.

Създаване на дърво на заявката: Тази стъпка генерира различни дървета на изпълнение, представляващи различните начини, по които може да се изпълни заявка. Всички дървета произвеждат един и същ желан резултат.

Optimizer

Оптимизаторът създава план за изпълнение на заявката на потребителя. Този план определя как ще бъде изпълнена заявката. Не всички заявки са оптимизирани. Оптимизацията се прилага за DML (език за модифициране на данни) команди като SELECT, INSERT, DELETE и UPDATE. DDL команди като CREATE и ALTER не са оптимизирани, а се компилират във вътрешна форма.

Цената на заявката се изчислява въз основа на фактори като използване на процесора, използване на паметта и нужди от входно/изходни данни. Ролята на оптимизатора е да намери най-евтиния и рентабилен план за изпълнение, а не непременно най-добрия.

Пример: Представете си, че искате да отворите онлайн банкова сметка. Отварянето на сметка в една банка отнема максимум 2 дни. Имате и списък с 20 други банки, които може да отнемат по-малко време, а може и да не отнемат. Търсенето във всичките 20 банки може да не намери по-бърз вариант, а самото търсене струва време. Би било по-добре да изберете първата банка. По подобен начин, SQL оптимизаторът използва изчерпателни и евристични алгоритми, за да минимизира времето за изпълнение на заявката.

Оптимизаторът търси в три фази:

Фаза 0: Търсене на тривиален план

Това е етапът преди оптимизация. За някои заявки съществува само един практичен план, известен като тривиален план. Няма нужда да се търси допълнително, защото всяко допълнително търсене би довело до същия план за изпълнение, но с допълнителни разходи.

Фаза 1: Търсене на планове за обработка на транзакции

Това включва търсене както на прости, така и на сложни планове. Търсенето на прост план използва статистически анализ на данни от колони и индекси, обикновено ограничен до един индекс на таблица. Ако не се намери прост план, се извършва по-сложно търсене, включващо множество индекси на таблица.

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

Ако предишните стратегии не доведат до адекватен план, оптимизаторът търси възможности за паралелна обработка въз основа на възможностите за обработка на машината. Ако паралелната обработка не е възможна, започва финална фаза на оптимизация, която използва всички останали опции, за да намери най-добрия възможен план за изпълнение.

Изпълнител на заявки

Изпълнителят на заявки извиква метода за достъп (Access Method) в Storage Engine. Той предоставя план за изпълнение, съдържащ логиката за извличане на данни, необходима за изпълнението. След като данните бъдат получени от Storage Engine, резултатът се публикува на протоколния слой (Text Layer) и се изпраща на крайния потребител.

След като релационният енджин определи как да изпълни заявка, енджинът за съхранение обработва физическите операции с данни. Този слой управлява как данните се съхраняват, кешират и извличат от диска.

Двигател за съхранение

Storage Engine е отговорен за съхраняването на данни в система за съхранение, като диск или SAN, и извличането им, когато е необходимо. Преди да разгледаме компонентите на Storage Engine, е важно да разберем как данните се съхраняват физически.

Файлове с данни и екстенти

Файловете с данни физически съхраняват данни под формата на страници с данни, като всяка страница е с размер 8KB. Това е най-малката единица за съхранение в SQL ServerСтраниците с данни са логически групирани в екстенти. На никой обект не е присвоена директно отделна страница; вместо това поддръжката се извършва чрез екстенти. Всяка страница има заглавка на страница (96 байта), съдържаща метаданни като тип страница, номер на страница, използвано пространство, свободно пространство и указатели към следващата и предишната страница.

Типове файлове

Основен файл: Всяка база данни съдържа един основен файл. Той съхранява всички важни данни, свързани с таблици, изгледи, тригери и други обекти. Разширението обикновено е .mdf, но може да бъде всяко друго.

Вторичен файл: Базата данни може да съдържа или да не съдържа множество вторични файлове. Те са незадължителни и съдържат специфични за потребителя данни. Разширението обикновено е .ndf, но може да бъде всяко друго.

Лог файл: Известни също като регистрационни файлове за предварително записване. Разширението е .ldf. Регистрационните файлове се използват за управление на транзакции, възстановяване от нежелани случаи и извършване на връщане назад на неизвършени транзакции.

Системата за съхранение има три основни компонента. Всеки от тях играе специфична роля в управлението на достъпа до данни и целостта им.

Метод за достъп

Методът за достъп действа като интерфейс между изпълнителя на заявки и Buffer Мениджър или регистрационни файлове на транзакции. Той не извършва самото изпълнение, а определя типа на заявката:

• Ако заявката е SELECT оператор (DML), то се предава на Buffer Мениджър за по-нататъшна обработка.
• Ако заявката е Не-SELECT оператор (DDL и DML), той се предава на мениджъра на транзакции. Това включва най-вече оператори UPDATE, INSERT и DELETE.

Buffer Мениджър

- Buffer Мениджърът управлява основните функции за кеш на плана, парсинг на данни и обработка на „мръсни“ страници.

Кеш план

Съществуващ план за заявки: - Buffer Мениджърът проверява дали планът за изпълнение съществува в съхранения кеш на плановете. Ако е така, кешираният план на заявката и свързаният с него кеш на данни се използват директно.

План за първоначално кеширане: Ако планът за изпълнение на заявка за първи път е сложен, той се съхранява в кеша на плановете. Това осигурява по-бърза наличност следващия път, когато SQL Server получи същата заявка.

Разбор на данни: Buffer Кеш и съхранение на данни

- Buffer Мениджърът предоставя достъп до необходимите данни. Възможни са два подхода в зависимост от това дали в кеша съществуват данни:

Buffer Кеш – Софт парсинг

- Buffer Мениджърът търси данни в Buffer Кеш. Ако данните са налични, изпълнителят на заявки ги използва директно. Това подобрява производителността, защото извличането на данни от кеша изисква по-малко входно-изходни операции в сравнение с извличането от дисково хранилище.

Съхранение на данни – твърд парсинг

Ако данните не са налични в Buffer Кеш, необходимите данни се търсят в хранилището за данни на диска. След това данните също се съхраняват в кеша за бъдеща употреба.

Мениджър на транзакции

Мениджърът на транзакции се извиква, когато методът за достъп определи, че заявката е оператор, различен от SELECT. Той осигурява съгласуваност и дълготрайност на данните чрез няколко подкомпонента:

Мениджър на регистрационни файлове

Мениджърът на дневници съхранява track от всички актуализации, извършени в системата, чрез регистрационни файлове, съхранявани в регистрационни файлове за транзакции. Всеки запис в регистрационния файл съдържа пореден номер на регистрационния файл, заедно с идентификатора на транзакцията и записа за промяна на данни. Този механизъм tracks извършени и отменени транзакции.

Диспечер на заключване

По време на транзакция, свързаните данни в хранилището влизат в заключено състояние. Мениджърът на заключванията управлява този процес, като осигурява съгласуваност и изолация на данните. Тези свойства са известни още като ACID (Atomградус, последователност, изолация, издръжливост).

Процес на изпълнение

Процесът на изпълнение следва следните стъпки:

1. Мениджърът на регистрационни файлове започва регистрирането, а мениджърът на заключванията заключва свързаните данни.
2. Копие на данните се съхранява в Buffer Кеш.
3. Копие от данните, които ще бъдат актуализирани, се поддържа в дневника. Bufferи всички събития актуализират данните в Data Buffer.
4. Страниците, които съхраняват модифицирани данни, са известни като Мръсни страници.

Контролни точки и предварително записване в регистри

Процесът на контролна точка се изпълнява приблизително веднъж в минута и маркира всички „нечисти“ страници за запис на диск. Страницата обаче първо се изпраща към страницата с данни на лог файла от Buffer Регистриране. Този механизъм е известен като регистриране с предварително записване. Неактуалните страници остават в кеша дори след като бъдат записани на диска.

Мързелив Writer

Когато SQL Server наблюдава голямо натоварване и е необходима буферна памет за нови транзакции, той освобождава „мръсни“ страници от кеша. Writer работи по алгоритъма LRU (Най-малко използвани), за да почиства страниците от буферния пул на диска.

Как SQL Server обработва заявка от край до край

Разбирането на всеки слой поотделно е ценно, но виждането как работят заедно изяснява цялостната картина. Когато клиентско приложение изпрати SQL заявка, се случва следната последователност:

- Протоколен слой получава заявката чрез споделена памет, TCP/IP или именувани канали и я опакова в TDS пакет. Релационна машина след това поема контрола: CMD Parser проверява синтаксиса и семантиката, оптимизаторът генерира най-евтиния план за изпълнение и Query Executor започва извличането на данни.

Изпълнителят на заявки извиква Двигатели за съхранение Метод за достъп, който насочва SELECT заявки към Buffer Мениджър и заявки за модификация към Мениджъра на транзакции. Buffer Мениджърът проверява кеша на плана и Buffer Първо кеширане (мек парсинг). Ако данните не са кеширани, се извършва четене от диска (твърд парсинг). За операции по запис, Transaction Manager координира Log Manager, Lock Manager и процеса на контролни точки, за да осигури съответствие с ACID.

След като Storage Engine върне заявените данни, Relational Engine форматира резултатния набор и Protocol Layer го доставя обратно на клиентското приложение чрез същия TDS протокол.

Как да изберете правилния протокол за SQL Server връзки

Изборът на правилния протокол зависи от физическата връзка между клиента и сървъра, както и от изискванията за производителност.

Използване на споделена памет когато клиентското приложение работи на същата машина като SQL Server. Това е най-бързият вариант, защото елиминира всички мрежови разходи. Идеален е за локална разработка, тестване и внедряване на една машина.

Използвайте TCP/IP когато клиентът и сървърът са на различни машини, свързани през WAN или интернет. Това е най-често използваният протокол в производствени среди. SQL Server слуша на порт 1433 по подразбиране и този протокол поддържа криптирани връзки чрез TLS.

Използвайте именувани канали когато клиентът и сървърът са в една и съща надеждна локална мрежа и производителността във вътрешните мрежи е приоритет. Named Pipes е деактивиран по подразбиране и трябва да бъде активиран чрез SQL Server Configuration Manager. Той е по-рядко срещан в съвременните внедрявания, но остава полезен за по-стари интранет приложения.

Въпроси и Отговори