Објашњена архитектура СКЛ сервера: Именоване цеви, оптимизатор, Менаџер бафера

Преглед садржаја:

Anonim

МС СКЛ Сервер је архитектура клијент-сервер. Процес МС СКЛ Сервер започиње тако што клијентска апликација шаље захтев. СКЛ Сервер прихвата, обрађује и одговара на захтев обрађеним подацима. Размотримо детаљно целокупну архитектуру приказану у наставку:

Као што доњи дијаграм приказује, постоје три главне компоненте у СКЛ Сервер Арцхитецтуре:

  1. Слој протокола
  2. Релациони мотор
  3. Стораге Енгине
Дијаграм архитектуре СКЛ сервера

Размотримо детаљно о ​​сва три горе наведена главна модула. У овом упутству ћете научити.

  • Слој протокола - СНИ
    • Заједничка меморија
    • ТЦП / ИП
    • Именоване цеви
    • Шта је ТДС?
  • Релациони мотор
    • ЦМД Парсер
    • Оптимизер
    • Извршитељ упита
  • Стораге Енгине
    • Типови фајлова
    • Начин приступа
    • Менаџер бафера
    • Планирај кеш
    • Рашчлањивање података: предмеморија међуспремника и складиштење података
    • Трансацтион Манагер

Слој протокола - СНИ

МС СКЛ СЕРВЕР ПРОТОЦОЛ ЛАИЕР подржава 3 типа архитектуре клијентског сервера. Почећемо са „ Архитектуром три типа клијентског сервера“ коју МС СКЛ Сервер подржава.

Заједничка меморија

Преиспитајмо ранојутарњи сценарио разговора.

МАМА и ТОМ - Овде су Том и његова мама били на истом логичном месту, односно у свом дому. Том је могао да затражи кафу, а мама је послужила врућу.

МС СКЛ СЕРВЕР - Овде МС СКЛ сервер пружа ПРОТОКОЛ ПОДЕЛЕНЕ ПАМЋЕЊЕ . Овде КЛИЈЕНТ и МС СКЛ сервер раде на истој машини. Обоје могу да комуницирају путем протокола заједничке меморије.

Аналогија: Омогућимо мапирање ентитета у горња два сценарија. Тома можемо лако повезати са клијентом, маму са СКЛ сервером, од куће до машине и вербалну комуникацију са протоколом заједничке меморије.

Са стола за конфигурацију и инсталацију:

За везу са локалним ДБ-ом - у СКЛ Манагемент Студиу може бити опција „Име сервера“

"."

"локални домаћин"

"127.0.0.1"

„Мацхине \ Инстанце“

ТЦП / ИП

Сад размислите увече, Том је расположен за забаву. Жели кафу наручену из познате кафетерије. Кафић се налази на 10 км од његове куће.

Том и Старбуцк су овде на различитим физичким локацијама. Том код куће и Старбуцкс на прометној пијаци. Комуницирају путем мобилне мреже. Слично томе, МС СКЛ СЕРВЕР пружа могућност интеракције путем ТЦП / ИП протокола, где су ЦЛИЕНТ и МС СКЛ Сервер удаљени једни од других и инсталирани на посебном рачунару.

Аналогија: Омогућимо мапирање ентитета у горња два сценарија. Тома можемо лако пресликати на клијента, Старбуцк на СКЛ сервер, дом / тржиште на удаљену локацију и на крају целуларну мрежу на ТЦП / ИП протокол.

Белешке са деск-а за конфигурацију / инсталацију:

  • У програму СКЛ Манагемент Студио - За повезивање путем ТЦП \ ИП, опција „Име сервера“ мора бити „Мацхине \ Инстанце оф тхе сервер“.
  • СКЛ сервер користи порт 1433 у ТЦП / ИП.

Именоване цеви

Сад напокон ноћу, Том је желео да попије светло зелени чај који је њена комшиница Сиерра врло добро припремила.

Овде Томе и његов комшија , Сијера, су у истој физичке локације, као један другом комшија. Комуницирају путем Интра мреже. Слично томе, МС СКЛ СЕРВЕР пружа могућност интеракције путем протокола Намед Пипе . Овде су КЛИЈЕНТ и МС СКЛ СЕРВЕР повезани преко ЛАН-а .

Аналогија: Омогућимо мапирање ентитета у горња два сценарија. Тома можемо лако пресликати на клијента, Сиерру на СКЛ сервер, суседа на ЛАН и коначно Интра мрежу на Намед Пипе Протоцол.

Белешке са деск-а за конфигурацију / инсталацију:

  • За везу преко именоване цеви. Ова опција је подразумевано онемогућена и мора је омогућити СКЛ Цонфигуратион Манагер.

Шта је ТДС?

Сад кад знамо да постоје три врсте архитектуре клијент-сервер, омогућава нам да погледамо ТДС:

  • ТДС је скраћеница од Табеларни ток података.
  • Сва 3 протокола користе ТДС пакете. ТДС је енкапсулиран у мрежне пакете. Ово омогућава пренос података са клијентске машине на серверску машину.
  • ТДС је први пут развио Сибасе, а сада га има Мицрософт

Релациони мотор

Релациони механизам познат је и као процесор упита. Садржи компоненте СКЛ Сервера које одређују шта тачно упит треба да уради и како то најбоље може да се уради. Одговорна је за извршавање корисничких упита тако што захтева податке из механизма за складиштење и обрађује резултате који се враћају.

Као што је приказано на Архитектонском дијаграму, постоје 3 главне компоненте релационог мотора. Проучимо компоненте детаљно:

ЦМД Парсер

Подаци једном примљени из слоја протокола се затим прослеђују у релациони механизам. „ЦМД парсер“ је прва компонента релационог механизма која прима податке упита. Основни посао ЦМД Парсера је да провери упит за синтаксичку и семантичку грешку. Коначно, генерише стабло упита . Хајде да разговарамо детаљно.

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

  • Као и сваки други програмски језик, и МС СКЛ има унапред дефинисани скуп кључних речи. Такође, СКЛ Сервер има своју граматику коју СКЛ сервер разуме.
  • СЕЛЕЦТ, ИНСЕРТ, УПДАТЕ и многи други припадају МС СКЛ унапред дефинисаним листама кључних речи.
  • ЦМД Парсер врши синтаксичку проверу. Ако се унос корисника не придржава ових синтакса језика или граматичких правила, враћа грешку.

Пример: Рецимо да је Рус отишао у јапански ресторан. Наручује брзу храну на руском језику. На несрећу, конобар разуме само јапански. Који би био најочигледнији резултат?

Одговор је - конобар не може даље да обрађује поруџбину.

Не би требало да буде одступања у граматици или језику који СКЛ сервер прихвата. Ако постоје, СКЛ сервер га не може обрадити и стога ће вратити поруку о грешци.

О МС СКЛ упиту сазнаћемо више у наредним водичима. Ипак, узмите у обзир најосновнију синтаксу упита као

SELECT * from ;

Сада, да бисте стекли перцепцију шта синтаксика ради, реците да ли корисник покреће основни упит као у наставку:

SELECR * from 

Имајте на уму да је уместо „СЕЛЕЦТ“ корисник откуцао „СЕЛЕЦР.“

Резултат: ЦМД парсер ће рашчланити ову изјаву и избацити поруку о грешци. Како „СЕЛЕЦР“ не следи унапред дефинисано име и граматику кључне речи. Овде је ЦМД Парсер очекивао „СЕЛЕЦТ“.

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

  • Ово изводи Нормализер .
  • У свом најједноставнијем облику проверава да ли назив колоне и назив табеле који се испитују постоје у шеми. А ако постоји, вежите га за Куери. Ово је такође познато као везивање .
  • Сложеност се повећава када кориснички упити садрже ВИЕВ. Нормализер врши замену са интерно ускладиштеном дефиницијом погледа и много више.

Да схватимо ово уз помоћ доњег примера -

SELECT * from USER_ID

Резултат: ЦМД парсер ће рашчланити ову изјаву за семантичку проверу. Анализатор ће послати поруку о грешци јер Нормализер неће пронаћи тражену табелу (УСЕР_ИД) јер не постоји.

Направите стабло упита:

  • Овај корак генерише различито стабло извршења у којем се упит може покренути.
  • Имајте на уму да сва различита стабла имају исти жељени излаз.

Оптимизер

Посао оптимизатора је стварање плана извршења за корисников упит. Ово је план који ће одредити како ће се извршавати кориснички упит.

Имајте на уму да нису сви упити оптимизовани. Оптимизација се врши за ДМЛ (Дата Модифицатион Лангуаге) наредбе попут СЕЛЕЦТ, ИНСЕРТ, ДЕЛЕТЕ и УПДАТЕ. Такви упити се прво обележавају, а затим шаљу оптимизатору. ДДЛ наредбе попут ЦРЕАТЕ и АЛТЕР нису оптимизоване, али се умјесто тога компајлирају у интерни образац. Трошкови упита израчунавају се на основу фактора као што су коришћење процесора, коришћење меморије и потребе за улазом / излазом.

Улога оптимизатора је да пронађе најјефтинији, а не најбољи, исплатив план извршења.

Пре него што уђемо у техничке детаље Оптимизер-а, размотрите доњи пример из стварног живота:

Пример:

Рецимо, желите да отворите мрежни рачун у банци. Већ знате за једну банку којој треба највише 2 дана да отвори рачун. Али, такође имате листу са 20 других банака, што може или не мора трајати мање од 2 дана. Можете започети интеракцију са овим банкама да бисте утврдили којим банкама треба мање од 2 дана. Сада можда нећете пронаћи банку која траје мање од 2 дана, а додатно је изгубљено време због саме активности претраживања. Било би боље да отворите рачун код прве банке.

Закључак: Важније је одабрати паметно. Да будемо прецизни, одаберите која је опција најбоља, а не најјефтинија.

Слично томе, МС СКЛ Оптимизер ради на уграђеним исцрпним / хеуристичким алгоритмима. Циљ је минимизирање времена извођења упита. Сви алгоритми за оптимизацију су својство Мицрософта и тајна. Мада , у наставку су кораци на високом нивоу обављају МС СКЛ Оптимизер. Претраге оптимизације прате три фазе како је приказано на доњем дијаграму:

Фаза 0: Потрага за тривијалним планом:

  • Ово је такође познато као фаза пре-оптимизације .
  • У неким случајевима може постојати само један практичан, изводљив план, познат као тривијалан план. Нема потребе за стварањем оптимизованог плана. Разлог је тај што би тражење више резултирало проналажење истог плана извршења. И то уз додатне трошкове тражења оптимизованог плана који уопште нису били потребни.
  • Ако није пронађен тривијални план, започиње 1. фаза.

Фаза 1: Претрага планова обраде трансакција

  • То укључује потрагу за једноставним и сложеним планом .
  • Једноставно претраживање плана: Претходни подаци колоне и индекса који су укључени у упит, користиће се за статистичку анализу. Ово се обично састоји, али није ограничено на један индекс по табели.
  • Ипак, ако једноставни план није пронађен, претражује се сложенији план. Укључује вишеструки индекс по табели.

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

  • Ако ниједна од горе наведених стратегија не успе, Оптимизер тражи могућности паралелне обраде. Ово зависи од могућности обраде машине и конфигурације.
  • Ако то и даље није могуће, започиње завршна фаза оптимизације. Сада је коначни циљ оптимизације проналажење свих осталих могућих опција за извршавање упита на најбољи начин. Алгоритми фазе завршне оптимизације су Мицрософт Проприети.

Извршитељ упита

Извршитељ упита позива метод приступа. Пружа план извршења за логику преузимања података потребну за извршење. Једном када се подаци приме из Стораге Енгине-а, резултат се објављује на слоју Протоцол. Коначно, подаци се шаљу крајњем кориснику.

Стораге Енгине

Посао Стораге Енгине-а је чување података у систему за складиштење попут Диска или САН-а и преузимање података по потреби. Пре него што дубље заронимо у Стораге енгине, погледајмо како се подаци чувају у бази података и врста доступних датотека.

Датотека података и обим:

Датотека података физички складишти податке у облику страница података, при чему свака страница података има величину од 8 КБ, што чини најмању јединицу за складиштење у СКЛ серверу. Ове странице са подацима логички су груписане да би формирале екстензије. Ниједном објекту није додељена страница у СКЛ Сервер-у.

Одржавање објекта се врши путем екстензија. Страница има одељак под називом Заглавље странице, величине 96 бајтова, који садржи податке о метаподацима о страници, као што су Тип странице, Број странице, Величина заузетог простора, Величина слободног простора и Показивач на следећу страницу и претходну страницу итд.

Типови фајлова

  1. Примарна датотека
  • Свака база података садржи једну примарну датотеку.
  • Ово чува све важне податке који се односе на табеле, погледе, окидаче итд.
  • Продужетак је. мдф обично, али може бити било ког продужетка.
  1. Секундарна датотека
  • База података може или не мора садржавати више секундарних датотека.
  • Ово није обавезно и садржи податке специфичне за корисника.
  • Продужетак је. ндф обично, али може бити било ког продужетка.
  1. Лог фајл
  • Познати и као Записи напред.
  • Продужетак је. лдф
  • Користи се за управљање трансакцијама.
  • Ово се користи за опоравак од нежељених случајева. Извршите важан задатак враћања на необрађене трансакције.

Стораге Енгине има 3 компоненте; размотримо их детаљно.

Начин приступа

Делује као интерфејс између извршиоца упита и Менаџера бафера / Дневника трансакција.

Начин приступа сам по себи не извршава.

Прва радња је утврђивање да ли је упит:

  1. Изаберите изјаву (ДДЛ)
  2. Избор који није изабран (ДДЛ и ДМЛ)

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

  1. Ако је упит ДДЛ , СЕЛЕЦТ израз, упит се прослеђује Менаџеру међуспремника на даљу обраду.
  2. А ако је упит ДДЛ, израз НОН-СЕЛЕЦТ , упит се прослеђује Трансацтион Манагер-у. Ово углавном укључује УПДАТЕ израз.

Менаџер бафера

Менаџер бафера управља основним функцијама за модуле испод:

  • Планирај кеш
  • Рашчлањивање података: Међуспремник и предмеморија
  • Прљава страница

У овом одељку ћемо научити план, бафер и кеш података. Покриваћемо Прљаве странице у одељку Трансакција.

Планирај кеш

  • Постојећи план упита: Менаџер ме успремника проверава да ли се план извршавања налази у ускладиштеној предмеморији плана. Ако је одговор да, тада се користи кеш плана упита и придружена кеш меморија података.
  • Први пут кеш плана: Одакле потиче постојећи кеш плана?

    Ако се први пут извршава план упита и који је сложен, има смисла да га похраните у Плане цацхе. Ово ће осигурати бржу доступност када следећи пут СКЛ сервер добије исти упит. Дакле, то није ништа друго него сам упит које извршење плана се чува ако се изводи први пут.

Рашчлањивање података: предмеморија међуспремника и складиштење података

Менаџер бафера омогућава приступ потребним подацима. У зависности од тога постоје ли подаци у кеш меморији података могућа су два приступа:

Међуспремник - Меко рашчлањивање:

Менаџер бафера тражи податке у баферу у кешу података. Ако су присутни, извршитељ упита користи ове податке. Ово побољшава перформансе јер се број И / О операција смањује приликом преузимања података из кеш меморије у поређењу са дохватањем података из складишта података.

Складиштење података - тешко рашчлањивање:

Ако подаци нису присутни у програму Буффер Манагер него што је потребно, подаци се претражују у складишту података. Ако такође чува податке у кешу података за будућу употребу.

Прљава страница

Чува се као логика обраде Трансацтион Манагер-а. Детаљно ћемо научити у одељку Трансацтион Манагер.

Трансацтион Манагер

Трансацтион Манагер се позива када метода приступа утврди да је Куери изјава која није изабрана.

Лог Манагер

  • Лог Манагер води евиденцију свих ажурирања извршених у систему путем дневника у дневницима трансакција.
  • Евиденције имају редни број евиденције са ИД-ом трансакције и записом о модификацији података .
  • Ово се користи за праћење извршених трансакција и враћања трансакција .

Лоцк Манагер

  • Током трансакције повезани подаци у складишту података су у стању закључавања. Овим процесом управља Лоцк Манагер.
  • Овај поступак осигурава доследност и изолацију података . Такође позната као АЦИД својства.

Процес извршења

  • Лог Манагер започиње евидентирање и Лоцк Манагер закључава повезане податке.
  • Копија података се чува у предмеморији ме успремника.
  • Копија података која треба да се ажурира чува се у међуспремнику дневника, а сви догађаји ажурирају податке у међуспремнику података.
  • Странице које чувају податке познате су и под називом Прљаве странице .
  • Контролна тачка и бележење унапред: Овај процес се покреће и означава сву страницу од Прљавих страница до Диска, али страница остаје у кешу. Фреквенција је приближно 1 покретање у минути. Али страница се прво пребацује на страницу података датотеке дневника из дневника бафера. Ово је познато као Записивање унапред.
  • Лази Вритер: Прљава страница може остати у меморији. Када СКЛ сервер примети велико оптерећење и када је за нову трансакцију потребна меморија међуспремника, ослобађа Прљаве странице из кеш меморије. Функционише на ЛРУ - Најмање недавно коришћен алгоритам за чишћење странице од спремишта ме успремника до диска.

Резиме:

  • Постоје три врсте архитектуре клијентског сервера: 1) заједничка меморија 2) ТЦП / ИП 3) именоване цеви
  • ТДС, који је развио Сибасе, а сада је у власништву Мицрософта, пакет је који је енкапсулиран у мрежне пакете за пренос података са клијентске машине на серверску машину.
  • Релацијски мотор садржи три главне компоненте:

    ЦМД парсер: Ово је одговорно за синтаксичку и семантичку грешку и коначно генерише стабло упита.

    Оптимизер: Улога оптимизатора је да пронађе најјефтинији, а не најбољи, исплатив план извршења.

    Извршитељ упита: Извршитељ упита позива приступни метод и пружа план извршења за логику преузимања података потребну за извршење.

  • Постоје три врсте датотека Примарна датотека, Секундарна датотека и Дневници.
  • Стораге Енгине: Садржи следеће важне компоненте

    Начин приступа: Ова компонента Одредите да ли је упит Избор или Избор који није изабран. Призива ме успремник и менаџера трансфера.

    Менаџер бафера: Менаџер бафера управља основним функцијама за предмеморију плана, рашчлањивање података и прљаву страницу.

    Трансацтион Манагер: Управља трансакцијама које нису одабране уз помоћ менаџера дневника и закључавања. Такође, олакшава важну примену евидентирања Врите Ахеад и Лази Вритерс.