Обяснена архитектура на SQL Server: Именувани тръби, оптимизатор, мениджър на буфери

Съдържание:

Anonim

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

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

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

Нека обсъдим подробно за трите по-горе основни модула. В този урок ще научите.

  • Протоколен слой - SNI
    • Споделена памет
    • TCP / IP
    • Наречени тръби
    • Какво е TDS?
  • Релационен двигател
    • CMD парсер
    • Оптимизатор
    • Изпълнител на заявки
  • Двигател за съхранение
    • Типове файлове
    • Метод за достъп
    • Мениджър на буфери
    • Кеш за планиране
    • Анализиране на данни: Буферен кеш и съхранение на данни
    • Мениджър на транзакции

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

MS SQL SERVER PROTOCOL LAYER поддържа 3 типа архитектура на клиентския сървър. Ще започнем с " Архитектура на три типа клиентски сървър", която MS SQL Server поддържа.

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

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

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

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

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

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

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

"."

"localhost"

„127.0.0.1“

"Machine \ Instance"

TCP / IP

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

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

Аналогия: Нека картографира обекти в горните два сценария. Лесно можем да картографираме Том към клиент, Starbuck към SQL сървър, Начало / Пазар към Отдалечено местоположение и накрая Клетъчната мрежа към TCP / IP протокол.

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

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

Наречени тръби

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

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

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

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

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

Какво е TDS?

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

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

Релационен двигател

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

Както е изобразено в Архитектурната диаграма, има 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 ;

Сега, за да разберете какво прави синтактиката, кажете дали потребителят изпълнява основната заявка, както е показано по-долу:

SELECR * from

Имайте предвид, че вместо „SELECT“ потребителят е въвел „SELECR“.

Резултат: Парсерът CMD ще анализира това изявление и ще изведе съобщението за грешка. Тъй като "SELECR" не следва предварително дефинираното име на ключова дума и граматика. Тук CMD Parser очакваше „SELECT“.

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

  • Това се извършва от Normalizer .
  • В най-простата си форма той проверява дали име на колона, име на таблица, което се заявява, съществува в Schema. И ако съществува, свържете го с Query. Това е известно още като Обвързване .
  • Сложността се увеличава, когато потребителските заявки съдържат VIEW. Normalizer извършва замяната с вътрешно съхранената дефиниция на изгледа и много повече.

Нека разберем това с помощта на долния пример -

SELECT * from USER_ID

Резултат: Парсерът CMD ще анализира това изявление за семантична проверка. Анализаторът ще изведе съобщение за грешка, тъй като Normalizer няма да намери исканата таблица (USER_ID), тъй като не съществува.

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

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

Оптимизатор

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

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

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

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

Пример:

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

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

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

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

  • Това е известно още като етап на предварителна оптимизация .
  • В някои случаи може да има само един практичен, работещ план, известен като тривиален план. Няма нужда от създаване на оптимизиран план. Причината е, че търсенето на повече би довело до намирането на същия план за изпълнение на времето за изпълнение. Това също с допълнителните разходи за търсене на оптимизиран план, които изобщо не бяха необходими.
  • Ако не е намерен тривиален план, тогава започва 1- ва фаза.

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

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

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

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

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

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

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

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

Файл с данни и обхват:

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

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

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

  1. Основен файл
  • Всяка база данни съдържа един първичен файл.
  • Това съхранява всички важни данни, свързани с таблици, изгледи, задействания и т.н.
  • Удължаването е. mdf обикновено, но може да бъде с всяко разширение.
  1. Вторичен файл
  • Базата данни може или не може да съдържа множество вторични файлове.
  • Това не е задължително и съдържа специфични за потребителя данни.
  • Удължаването е. ndf обикновено, но може да бъде с всяко разширение.
  1. Регистрационен файл
  • Известни също като дневници за записване напред.
  • Удължаването е. ldf
  • Използва се за управление на транзакции.
  • Това се използва за възстановяване от нежелани случаи. Изпълнявайте важна задача на Rollback към неангажирани транзакции.

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

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

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

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

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

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

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

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

Мениджър на буфери

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

  • Кеш за планиране
  • Анализиране на данни: Буферен кеш и съхранение на данни
  • Мръсна страница

В този раздел ще научим кеш за план, буфер и данни. Ще покрием Мръсни страници в раздела Транзакция.

Кеш за планиране

  • Съществуващ план за заявки: Мениджърът на буфера проверява дали планът за изпълнение е в съхранения кеш на плана. Ако да, тогава се използва кеш на плана за заявки и свързаният с него кеш за данни.
  • План за първи път на кеш: Откъде идва съществуващия кеш на плана?

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

Анализиране на данни: Буферен кеш и съхранение на данни

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

Буферен кеш - меко анализиране:

Buffer Manager търси данни в буфера в кеша за данни. Ако присъстват, тези данни се използват от Изпълнителя на заявки. Това подобрява производителността, тъй като броят на операциите за вход / изход е намален при извличане на данни от кеша в сравнение с извличането на данни от съхранение на данни.

Съхранение на данни - Труден анализ:

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

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

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

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

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

Log Manager

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

Lock Manager

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

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

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

Резюме:

  • Съществуват три типа архитектура на клиентския сървър: 1) споделена памет 2) TCP / IP 3) именувани тръби
  • TDS, разработен от Sybase и сега притежаван от Microsoft, е пакет, който е капсулиран в мрежови пакети за трансфер на данни от клиентската машина към сървърната машина.
  • Релационният двигател съдържа три основни компонента:

    CMD Parser: Това е отговорно за синтактичната и семантичната грешка и накрая генерира дърво за заявки.

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

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

  • Съществуват три типа файлове Първичен файл, Вторичен файл и Регистрационни файлове.
  • Storage Engine: Има следните важни компоненти

    Метод за достъп: Този компонент Определя дали заявката е Изявление или Неизбиране. Извиква съответно буфера и мениджъра на трансфери.

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

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