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

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

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

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

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

MS SQL SERVER PROTOCOL LAYER поддържа 3 типа клиентски сървър Archiтекстура. Ще започнем с „Три типа клиентски сървър Archiтекстура” които MS SQL Server поддържа.

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

Нека преразгледаме сценария за сутрешен разговор.

МАМА и ТОМ – Тук Том и неговата майка бяха на едно и също логично място, т.е. в дома си. Том успя да поиска кафе, а мама успя да го сервира горещо.

MS SQL СЪРВЪР – Тук MS SQL сървърът предоставя ПРОТОКОЛ ЗА СПОДЕЛЕНА ПАМЕТ, тук КЛИЕНТИ намлява MS SQL сървър, работещ на същата машина. И двете могат да комуникират чрез протокол за споделена памет.

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

От бюрото за конфигуриране и инсталиране:

За връзка с локална база данни – In SQL Management Studio, опцията „Име на сървъра“ може да бъде

„.“

„localhost“

"127.0.0.1"

„Машина\Екземпляр“

TCP / IP

Сега помислете вечерта, Том е в настроение за купон. Той иска кафе, поръчано от известно кафене. Кафенето се намира на 10 км от дома му.

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

Аналогия: Нека картографираме обекти в горните два сценария. Можем лесно да съпоставим Tom към Client, Starbuck към SQL сървър, Home/Market place към Remote location и накрая Cellular мрежа към TCP/IP протокол.

Бележки от бюрото за конфигурация/инсталация:

• В SQL Management Studio – За връзка чрез TCP\IP, опцията „Име на сървъра“ трябва да бъде „Машина\Екземпляр на сървъра“.
• SQL сървърът използва порт 1433 в TCP/IP.

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

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

Тук Том и неговата Съсед, Сиера, са в същото физически местоположение, тъй като са съседи един на друг. Те комуникират чрез Вътрешна мрежа. По същия начин, MS SQL СЪРВЪР осигурява възможност за взаимодействие чрез Наименована тръба протокол. Тук КЛИЕНТЪТ и MS SQL СЪРВЪР са във връзка чрез LAN.

Аналогия: Нека картографираме обекти в горните два сценария. Можем лесно да съпоставим Tom към Client, Sierra към SQL сървър, Neighbor към LAN и накрая Intra network към Named Pipe Protocol.

Бележки от бюрото за конфигурация/инсталация:

• За свързване чрез Named Pipe. Тази опция е деактивирана по подразбиране и трябва да бъде активирана от SQL Configuration Manager.

Какво е TDS?

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

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

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

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

Както е показано в Archiтектурна диаграма има 3 основни компонента на релационния двигател. Нека да проучим компонентите подробно:

CMD анализатор

Данните, веднъж получени от протоколния слой, след това се предават на Relational Engine. „CMD анализатор“ е първият компонент на 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 анализаторът ще анализира това изявление за семантична проверка. Анализаторът ще изведе съобщение за грешка, тъй като Normalizer няма да намери исканата таблица (USER_ID), тъй като тя не съществува.

Създаване на дърво на заявката:

• Тази стъпка генерира различно дърво за изпълнение, в което може да се изпълни заявка.
• Имайте предвид, че всички различни дървета имат еднакъв желан изход.

Optimizer

Работата на оптимизатора е да създаде план за изпълнение на заявката на потребителя. Това е планът, който ще определи как ще бъде изпълнена потребителската заявка.

Имайте предвид, че не всички заявки са оптимизирани. Оптимизацията се извършва за DML (Език за модифициране на данни) команди като SELECT, INSERT, DELETE и UPDATE. Такива заявки първо се маркират, след което се изпращат на оптимизатора. DDL команди като CREATE и ALTER не са оптимизирани, но вместо това се компилират във вътрешна форма. Цената на заявката се изчислява въз основа на фактори като използване на процесора, използване на памет и нужди от вход/изход.

Ролята на оптимизатора е да намери най-евтиният, не най-добрият, рентабилен план за изпълнение.

Преди да преминем към повече технически подробности за оптимизатора, разгледайте примера от реалния живот по-долу:

Пример:

Да речем, че искате да отворите онлайн банкова сметка. Вече знаете за една банка, която отнема максимум 2 дни за откриване на сметка. Но имате и списък с 20 други банки, което може или не може да отнеме по-малко от 2 дни. Можете да започнете да се ангажирате с тези банки, за да определите кои банки отнемат по-малко от 2 дни. Сега може да не намерите банка, която отнема по-малко от 2 дни, и има допълнителна загуба на време поради самата дейност по търсене. По-добре да си отвориш сметка в първата банка.

Заключение: По-важно е да изберете разумно. За да бъдем точни, изберете кое вариантът е най-добрият, не най-евтиният.

По същия начин MS SQL Optimizer работи с вградени изчерпателни/евристични алгоритми. Целта е да се минимизира времето за изпълнение на заявката. Всички алгоритми на оптимизатора са уместност на Microsoft и тайна. Въпреки че, по-долу са стъпките на високо ниво, изпълнявани от MS SQL Optimizer. Търсенето на оптимизация следва три фази, както е показано на диаграмата по-долу:

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

• Това е известно още като Етап на предоптимизация.
• За някои случаи може да има само един практичен, работещ план, известен като тривиален план. Няма нужда от създаване на оптимизиран план. Причината е, че търсенето на повече ще доведе до намирането на същия план за изпълнение по време на изпълнение. Това също с допълнителните разходи за търсене на оптимизиран план, който изобщо не беше необходим.
• Ако не бъде намерен тривиален план, тогава 1^st Фазата започва.

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

• Това включва търсенето на Прост и сложен план.
• Обикновено планово търсене: Минали данни на колона и индекс, включени в заявката, ще бъдат използвани за статистически анализ. Това обикновено се състои, но не се ограничава до един индекс на таблица.
• И все пак, ако простият план не бъде намерен, тогава се търси по-сложен план. Той включва множество индекси на таблица.

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

• Ако нито една от горните стратегии не работи, Optimizer търси възможности за паралелна обработка. Това зависи от възможностите за обработка и конфигурацията на машината.
• Ако това все още не е възможно, тогава започва последната фаза на оптимизация. Сега крайната цел на оптимизацията е намирането на всички други възможни опции за изпълнение на заявката по най-добрия начин. Последна фаза на оптимизация Algorithms сте Microsoft Коректност.

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

Извиквания на изпълнителя на заявки Метод за достъп. Той предоставя план за изпълнение за логиката за извличане на данни, необходима за изпълнение. След като данните бъдат получени от Storage Engine, резултатът се публикува в протоколния слой. Накрая данните се изпращат до крайния потребител.

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

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

Файл с данни и степен:

Файл с данни, физически съхранява данни под формата на страници с данни, като всяка страница с данни има размер от 8KB, образувайки най-малката единица за съхранение в SQL Server. Тези страници с данни са логически групирани, за да образуват екстенти. На нито един обект не е присвоена страница в SQL Server.

Поддръжката на обекта се извършва чрез екстенти. Страницата има раздел, наречен Заглавен колонтитул на страницата, с размер 96 байта, носещ информацията за метаданните за страницата като тип на страницата, номер на страница, размер на използваното пространство, размер на свободното пространство и указател към следващата и предишната страница и т.н.

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

1. Основен файл

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

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

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

3. Лог файл

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

Storage Engine има 3 компонента; нека ги разгледаме подробно.

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

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

Самият метод на достъп не извършва никакво изпълнение.

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

1. Избор на извлечение (DDL)
2. Изявление без избор (DDL и DML)

В зависимост от резултата, методът за достъп предприема следните стъпки:

1. Ако запитването е DDL, оператор SELECT, заявката се предава към Buffer Мениджър за по-нататъшна обработка.
2. И ако запитване ако DDL, NON-SELECT оператор, заявката се предава на Transaction Manager. Това включва най-вече оператора UPDATE.

Buffer Мениджър

Buffer мениджърът управлява основните функции за модулите по-долу:

• Кеш план
• Разбор на данни: Buffer кеш и съхранение на данни
• Мръсна страница

Ще научим план, Buffer и Кеш на данни в този раздел. Ще разгледаме Мръсните страници в раздела Транзакции.

Кеш план

• Съществуващ план за заявка: Буферният мениджър проверява дали планът за изпълнение е там в съхранения кеш на плановете. Ако Да, тогава се използва кешът на плана за заявка и свързаният с него кеш на данни.
• Кеш план за първи път: Откъде идва съществуващият кеш на план? Ако планът за изпълнение на заявка за първи път се изпълнява и е сложен, има смисъл да го съхранявате в кеша на план. Това ще осигури по-бърза наличност, когато следващия път SQL сървърът получи същата заявка. Така че не е нищо друго освен самата заявка кое изпълнение на плана се съхранява, ако се изпълнява за първи път.

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

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

Buffer Кеш – Soft Parsing:

Buffer Мениджърът търси данни в Buffer в кеша за данни. Ако присъства, тогава тези данни се използват от Query Executor. Това подобрява производителността, тъй като броят на I/O операциите е намален при извличане на данни от кеша в сравнение с извличането на данни от хранилището на данни.

Съхранение на данни – Твърд анализ:

Ако данните не присъстват в Buffer Мениджър от необходимото Данните се търсят в Data Storage. Ако също така съхранява данни в кеша за данни за бъдеща употреба.

Мръсна страница

Той се съхранява като логика за обработка на Transaction Manager. Ще научим подробно в секцията Transaction Manager.

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

Мениджърът на транзакции се извиква, когато методът за достъп определи, че Query е оператор Non-Select.

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

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

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

• По време на транзакция свързаните данни в Data Storage са в състояние Lock. Този процес се управлява от Lock Manager.
• Този процес гарантира последователност и изолация на данните. Известен също като свойства на КИСЕЛИНА.

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

• Log Manager започва регистриране и Lock Manager заключва свързаните данни.
• Копието на данните се поддържа в Buffer кеш.
• Копието на данните, които трябва да бъдат актуализирани, се поддържа в буфера на регистрационния файл и всички събития актуализират данните в буфера на данните.
• Страниците, които съхраняват данните, са известни още като Мръсни страници.
• Регистриране на контролна точка и предварително записване: Този процес се изпълнява и маркира цялата страница от Dirty Pages на Disk, но страницата остава в кеша. Честотата е приблизително 1 движение в минута. Но страницата първо се насочва към страницата с данни на регистрационния файл от Buffer дневник. Това е известно като Предварително записване.
• Мързелив писател: Мръсната страница може да остане в паметта. Когато SQL сървърът наблюдава огромно натоварване и Buffer паметта е необходима за нова транзакция, тя освобождава Dirty Pages от кеша. Действа върху LRU – Най-скоро използван алгоритъм за почистване на страница от буферен пул към диск.

Oбобщение

• Три вида клиентски сървър ArchiСъществува структура: 1) Споделена памет 2) TCP/IP 3) Именувани канали
• TDS, разработен от Sybase и сега притежаван от Microsoft, е пакет, който е капсулиран в мрежови пакети за пренос на данни от клиентската машина към сървърната машина.
• Relational Engine съдържа три основни компонента:CMD анализатор: Това е отговорно за синтактичната и семантична грешка и накрая генерира дърво на заявката.Оптимизатор: Ролята на оптимизатора е да намери най-евтиния, а не най-добрия, икономически ефективен план за изпълнение.

  Изпълнител на заявка: Изпълнителят на заявка извиква метода за достъп и предоставя план за изпълнение за логиката за извличане на данни, необходима за изпълнение.

• Съществуват три вида файлове: първичен файл, вторичен файл и регистрационни файлове.
• Механизъм за съхранение: Има следните важни компонентиНачин на достъп: Този компонент Определя дали заявката е Select или Non-Select Statement. Извиква Buffer и съответно Transfer Manager.Buffer Мениджър: Buffer мениджърът управлява основните функции за план кеш, анализ на данни и мръсна страница.

  Мениджър на транзакции: Той управлява Non-Select Transaction с помощта на Log and Lock Managers. Също така улеснява важното внедряване на Write Ahead logging и Lazy writers.