MS SQL Server ir klienta-servera arhitektūra. MS SQL Server process sākas ar klienta lietojumprogrammas nosūtīšanu pieprasījumu. SQL Server pieņem, apstrādā un uz pieprasījumu atbild ar apstrādātiem datiem. Detalizēti apspriedīsim visu tālāk parādīto arhitektūru:
Kā parādīts šajā diagrammā, SQL Server arhitektūrā ir trīs galvenie komponenti:
- Protokola slānis
- Relāciju dzinējs
- Uzglabāšanas dzinējs
Detalizēti apspriedīsim visus trīs iepriekš minētos galvenos moduļus. Šajā apmācībā jūs uzzināsiet.
- Protokola slānis - SNI
- Dalīta atmiņa
- TCP / IP
- Nosauktas caurules
- Kas ir TDS?
- Relāciju dzinējs
- CMD parsētājs
- Optimizētājs
- Vaicājumu izpildītājs
- Uzglabāšanas dzinējs
- Failu tipi
- Piekļuves metode
- Bufera pārvaldnieks
- Plānojiet kešatmiņu
- Datu parsēšana: bufera kešatmiņa un datu glabāšana
- Darījumu vadītājs
Protokola slānis - SNI
MS SQL Server servera protokola slānis atbalsta 3 veidu klienta servera arhitektūru. Mēs sāksim ar " Trīs veidu klienta servera arhitektūru", kuru atbalsta MS SQL Server.
Dalīta atmiņa
Pārskatīsim agra rīta sarunu scenāriju.
MAMMA un TOMA - šeit Toms un viņa mamma atradās tajā pašā loģiskajā vietā, ti, savās mājās. Toms varēja lūgt kafiju, bet mamma - to pasniegt karstu.
MS SQL SERVER - Šeit MS SQL serveris nodrošina KOPĪGAS ATMIŅAS PROTOKOLU . Šeit KLIENTS un MS SQL serveris darbojas vienā un tajā pašā mašīnā. Abi var sazināties, izmantojot koplietotās atmiņas protokolu.
Analogija: ļauj kartēt entītijas iepriekš minētajos divos scenārijos. Mēs varam viegli piesaistīt Tomu klientam, mammu SQL serverim, mājas mašīnai un verbālo saziņu koplietotās atmiņas protokolam.
No konfigurācijas un instalācijas galda:
Savienojumam ar lokālo DB - SQL Management Studio var būt opcija "Servera nosaukums"
"."
"localhost"
"127.0.0.1"
"Machine \ instance"
TCP / IP
Tagad apsveriet vakarā, Toms ir ballītes noskaņojumā. Viņš vēlas kafiju, kas pasūtīta labi zināmā kafijas veikalā. Kafejnīca atrodas 10 km attālumā no viņa mājām.
Šeit Toms un Starbuks atrodas dažādās fiziskās vietās. Toms mājās un Starbucks rosīgajā tirgū. Viņi sazinās, izmantojot mobilo tīklu. Līdzīgi MS SQL SERVER nodrošina iespēju mijiedarboties, izmantojot TCP / IP protokolu, kur KLIENTS un MS SQL Server atrodas attālināti viens no otra un instalēti atsevišķā mašīnā.
Analogija: ļauj kartēt entītijas iepriekš minētajos divos scenārijos. Mēs varam viegli piesaistīt Tomu klientam, Starbuck SQL serverim, mājas / tirgus vietu attālinātai atrašanās vietai un visbeidzot mobilo tīklu TCP / IP protokolam.
Piezīmes no konfigurācijas / instalācijas galda:
- SQL Management Studio - lai izveidotu savienojumu, izmantojot TCP \ IP, opcijai "Servera nosaukums" ir jābūt "Servera mašīna \ eksemplārs".
- SQL serveris TCP / IP izmanto 1433. portu.
Nosauktas caurules
Tagad beidzot naktī Toms vēlējās iedzert gaiši zaļu tēju, kuru viņas kaimiņiene Sjerra ļoti labi pagatavoja.
Šeit Toms un viņa Kaimiņš Sjerra atrodas vienā fiziskā vietā, būdami viens otra kaimiņi. Viņi sazinās, izmantojot intra tīklu. Līdzīgi MS SQL Server nodrošina iespēju mijiedarboties, izmantojot Named Pipe protokolu. Šeit KLIENTS un MS SQL SERVER ir savienoti, izmantojot LAN .
Analogija: ļauj kartēt entītijas iepriekš minētajos divos scenārijos. Mēs varam viegli piesaistīt Tomu klientam, Sierra SQL serverim, kaimiņu LAN un visbeidzot intra tīklu Named Pipe Protocol.
Piezīmes no konfigurācijas / instalācijas galda:
- Savienojumam caur nosaukto cauruli. Šī opcija pēc noklusējuma ir atspējota, un tā ir jāiespējo SQL Configuration Manager.
Kas ir TDS?
Tagad, kad mēs zinām, ka pastāv trīs klienta-servera arhitektūras veidi, ļaujiet mums ieskatīties TDS:
- TDS nozīmē Tabular Data Stream.
- Visos 3 protokolos tiek izmantotas TDS paketes. TDS ir iekapsulēts tīkla paketēs. Tas ļauj datus pārsūtīt no klienta datora uz servera mašīnu.
- TDS pirmo reizi izstrādāja Sybase, un tagad tā pieder Microsoft
Relāciju dzinējs
Relāciju dzinējs ir pazīstams arī kā vaicājumu procesors. Tam ir SQL Server komponenti, kas nosaka, kas tieši jāveic vaicājumam un kā to var izdarīt vislabāk. Tas ir atbildīgs par lietotāju vaicājumu izpildi, pieprasot datus no krātuves dzinēja un apstrādājot atgrieztos rezultātus.
Kā attēlots Arhitektūras diagrammā, ir 3 galvenie Relāciju dzinēja komponenti . Detalizēti izpētīsim komponentus:
CMD parsētājs
Pēc protokola slāņa saņemtie dati tiek pārsūtīti uz Relational Engine. "CMD Parser" ir pirmā Relational Engine sastāvdaļa, kas saņem vaicājuma datus. CMD parsētāja galvenais uzdevums ir pārbaudīt vaicājumu par sintaktiskām un semantiskām kļūdām. Visbeidzot, tas ģenerē vaicājumu koku . Apspriedīsimies sīkāk.
Sintaktiskā pārbaude:
- Tāpat kā visās citās programmēšanas valodās, arī MS SQL ir iepriekš definēts Atslēgvārdu kopums. Arī SQL Server ir sava gramatika, kuru SQL serveris saprot.
- SELECT, INSERT, UPDATE un daudzi citi pieder MS SQL iepriekš definētiem atslēgvārdu sarakstiem.
- CMD parsētājs veic sintaktisko pārbaudi. Ja lietotāju ievade neievēro šīs valodas sintakses vai gramatikas kārtulas, tiek parādīta kļūda.
Piemērs: Pieņemsim, ka krievs devās uz japāņu restorānu. Viņš pasūta ātrās uzkodas krievu valodā. Diemžēl viesmīlis saprot tikai japāņu valodu. Kāds būtu visredzamākais rezultāts?
Atbilde ir - viesmīlis nespēj apstrādāt pasūtījumu tālāk.
Gramatikā vai valodā, kuru pieņem SQL serveris, nedrīkst būt noviržu. Ja tādi ir, SQL serveris to nevar apstrādāt un tādējādi atgriezīs kļūdas ziņojumu.
Par MS SQL vaicājumu vairāk uzzināsim gaidāmajās apmācībās. Tomēr apsveriet zemāk pamata vaicājumu sintaksi kā
SELECT * from;
Tagad, lai iegūtu priekšstatu par sintaktisko darbību, sakiet, vai lietotājs izpilda pamata vaicājumu, kā norādīts zemāk:
SELECR * from
Ņemiet vērā, ka “SELECT” vietā lietotājs ierakstīja “SELECR”.
Rezultāts: CMD parsētājs parsēs šo paziņojumu un iemetīs kļūdas ziņojumu. Tā kā "SELECR" neievēro iepriekš definēto atslēgvārda vārdu un gramatiku. Šeit CMD parsētājs gaidīja “SELECT”.
Semantiskā pārbaude:
- To veic Normalizer .
- Vienkāršākajā formā tas pārbauda, vai shēmā ir kolonnas nosaukums un tabulas nosaukums, par kuru tiek pieprasīts. Un, ja tas pastāv, piesaistiet to vaicājumam. Tas ir pazīstams arī kā saistošs .
- Sarežģītība palielinās, ja lietotāju vaicājumos ir VIEW. Normalizētājs veic nomaiņu ar iekšēji saglabātu skata definīciju un daudz ko citu.
Sapratīsim to, izmantojot tālāk sniegto piemēru -
SELECT * from USER_ID
Rezultāts: CMD parsētājs parsēs šo paziņojumu semantiskai pārbaudei. Parsētājs iemetīs kļūdas ziņojumu, jo Normalizer neatradīs pieprasīto tabulu (USER_ID), jo tās nav.
Izveidot vaicājumu koku:
- Šis solis ģenerē dažādu izpildes koku, kurā var izpildīt vaicājumu.
- Ņemiet vērā, ka visiem dažādajiem kokiem ir vienāda vēlamā izeja.
Optimizētājs
Optimizētāja uzdevums ir izveidot izpildes plānu lietotāja vaicājumam. Šis ir plāns, kas noteiks, kā tiks izpildīts lietotāja vaicājums.
Ņemiet vērā, ka ne visi vaicājumi ir optimizēti. Optimizācija tiek veikta komandām DML (Data Modification Language), piemēram, SELECT, INSERT, DELETE un UPDATE. Šādi vaicājumi vispirms tiek atzīmēti un pēc tam nosūtīti optimizatoram. DDL komandas, piemēram, CREATE un ALTER, netiek optimizētas, bet tās tiek apkopotas iekšējā formā. Vaicājuma izmaksas tiek aprēķinātas, pamatojoties uz tādiem faktoriem kā CPU izmantošana, Atmiņas izmantošana un Ievades / izvades vajadzības.
Optimizētāja uzdevums ir atrast lētāko, nevis labāko, rentablu izpildes plānu.
Pirms mēs pievērsīsimies optimizētāja tehniskākai detaļai, apsveriet tālāk sniegto piemēru reālajā dzīvē:
Piemērs:
Pieņemsim, ka vēlaties atvērt tiešsaistes bankas kontu. Jūs jau zināt par vienu banku, kuras konta atvēršana aizņem ne vairāk kā 2 dienas. Bet jums ir arī 20 citu banku saraksts, kas var aizņemt mazāk nekā 2 dienas. Jūs varat sākt sadarboties ar šīm bankām, lai noteiktu, kurām bankām nepieciešams mazāk nekā 2 dienas. Tagad jūs, iespējams, neatradīsit banku, kas aizņem mazāk nekā 2 dienas, un pašas meklēšanas darbības dēļ tiek zaudēts papildu laiks. Labāk būtu bijis atvērt kontu pašā pirmajā bankā.
Secinājums: svarīgāk ir izvēlēties saprātīgi. Precīzāk sakot, izvēlieties labāko variantu, nevis lētāko.
Līdzīgi MS SQL Optimizer darbojas ar iebūvētiem izsmeļošiem / heiristiskiem algoritmiem. Mērķis ir samazināt vaicājuma izpildes laiku. Visi optimizētāja algoritmi ir Microsoft pareizība un noslēpums. Kaut gan , turpmāk ir augsta līmeņa pasākumi, MS SQL optimizētājs veic. Optimizācijas meklēšana notiek trīs posmos, kā parādīts zemāk redzamajā diagrammā:
0. fāze: Trivial plāna meklēšana:
- To sauc arī par pirmsoptimizācijas posmu .
- Dažos gadījumos varētu būt tikai viens praktisks un praktiski izpildāms plāns, kas pazīstams kā niecīgs plāns. Optimizēta plāna izveide nav nepieciešama. Iemesls ir tāds, ka, meklējot vairāk, tiktu atrasts tas pats izpildes laika izpildes plāns. Tas arī ar papildu izmaksām par optimizēta plāna meklēšanu, kas nemaz nebija nepieciešama.
- Ja nē Trivial plāns atrasts, tad 1 st fāze sākas.
1. fāze: Darījumu apstrādes plānu meklēšana
- Tas ietver vienkārša un sarežģīta plāna meklēšanu .
- Vienkārša plāna meklēšana: statistikas analīzei tiks izmantoti vaicājumā iesaistīto sleju un rādītāju iepriekšējie dati. Parasti tas sastāv, bet neaprobežojas ar vienu indeksu katrā tabulā.
- Tomēr, ja vienkāršais plāns nav atrasts, tiek meklēts sarežģītāks plāns. Tas ietver vairākus indeksus katrā tabulā.
2. fāze: paralēla apstrāde un optimizācija.
- Ja neviena no iepriekš minētajām stratēģijām nedarbojas, optimizētājs meklē paralēlās apstrādes iespējas. Tas ir atkarīgs no Iekārtas apstrādes iespējām un konfigurācijas.
- Ja tas joprojām nav iespējams, sākas pēdējais optimizācijas posms. Tagad pēdējais optimizācijas mērķis ir atrast visas citas iespējamās iespējas vaicājuma izpildei vislabākajā veidā. Galīgās optimizācijas fāzes algoritmi ir Microsoft Propriety.
Vaicājumu izpildītājs
Vaicājuma izpildītāja zvanu piekļuves metode. Tas nodrošina izpildes plānu datu iegūšanas loģikai, kas nepieciešama izpildei. Kad dati tiek saņemti no Storage Engine, rezultāts tiek publicēts protokola slānī. Visbeidzot, dati tiek nosūtīti galalietotājam.
Uzglabāšanas dzinējs
Storage Engine uzdevums ir uzglabāt datus glabāšanas sistēmā, piemēram, Disk vai SAN, un pēc nepieciešamības iegūt datus. Pirms padziļināti ienirstam Storage engine, apskatīsim, kā dati tiek glabāti datu bāzē, un pieejamo failu tipu.
Datu fails un apjoms:
Datu fails fiziski uzglabā datus datu lapu veidā, katrai datu lapai 8KB lielumā veidojot mazāko SQL Server atmiņas vienību. Šīs datu lapas ir loģiski sagrupētas, veidojot apjomus. SQL Server nav piešķirts neviens objekts.
Objekta uzturēšana tiek veikta, izmantojot apjomus. Lapai ir sadaļa, kuras nosaukums ir Lapas galvene un kuras lielums ir 96 baiti, un tajā ir metadatu informācija par lapu, piemēram, Lapas tips, Lapas numurs, Izmantotās vietas lielums, Brīvās vietas lielums un Rādītājs uz nākamo un iepriekšējo lapu utt.
Failu tipi
- Primārais fails
- Katrā datu bāzē ir viens primārais fails.
- Šajā glabā visus svarīgos datus, kas saistīti ar tabulām, skatiem, aktivizētājiem utt.
- Pagarinājums ir. mdf parasti, bet var būt jebkura paplašinājuma.
- Sekundārais fails
- Datu bāzē var būt vai nav vairāki sekundārie faili.
- Tas nav obligāts un satur lietotājam specifiskus datus.
- Pagarinājums ir. ndf parasti, bet var būt jebkura paplašinājuma.
- Žurnāla fails
- Pazīstams arī kā Rakstīt žurnālus.
- Pagarinājums ir. ldf
- Izmanto darījumu pārvaldībai.
- To izmanto, lai atkoptu visus nevēlamos gadījumus. Veiciet svarīgu neatgriezenisku darījumu atcelšanas uzdevumu.
Uzglabāšanas motoram ir 3 komponenti; apskatīsim tos detalizēti.
Piekļuves metode
Tas darbojas kā saskarne starp vaicājuma izpildītāju un bufera pārvaldnieku / darījumu žurnāliem.
Piekļuves metode pati neveic nekādu izpildi.
Pirmā darbība ir noteikt, vai vaicājums ir:
- Atlasīt paziņojumu (DDL)
- Neatlasīt paziņojumu (DDL un DML)
Atkarībā no rezultāta piekļuves metode veic šādas darbības:
- Ja vaicājums ir DDL , SELECT priekšraksts, vaicājums tiek nodots Bufera pārvaldniekam tālākai apstrādei.
- Un, ja vaicājums ir DDL, NON-SELECT priekšraksts , vaicājums tiek nodots Transaction Manager. Tas galvenokārt ietver paziņojumu UPDATE.
Bufera pārvaldnieks
Bufera pārvaldnieks pārvalda tālāk minēto moduļu pamatfunkcijas:
- Plānojiet kešatmiņu
- Datu parsēšana: bufera kešatmiņa un datu glabāšana
- Netīra lapa
Šajā sadaļā mēs uzzināsim plānu, buferi un datu kešatmiņu. Mēs aplūkosim netīrās lapas sadaļā Darījums.
Plānojiet kešatmiņu
- Esošais vaicājumu plāns: Bufera pārvaldnieks pārbauda, vai izpildes plāns ir saglabātajā plāna kešatmiņā. Ja jā, tad tiek izmantota vaicājuma plāna kešatmiņa un ar to saistītā datu kešatmiņa.
- Pirmo reizi kešatmiņas plāns: no kurienes nāk esošā plāna kešatmiņa?
Ja vaicājuma izpildes plāns tiek palaists pirmo reizi un ir sarežģīts, ir lietderīgi to glabāt Plane kešatmiņā. Tas nodrošinās ātrāku pieejamību, kad nākamreiz, kad SQL serveris saņem to pašu vaicājumu. Tātad, tas nav nekas cits kā pats vaicājums, kurš plāna izpildījums tiek saglabāts, ja tas tiek palaists pirmo reizi.
Datu parsēšana: bufera kešatmiņa un datu glabāšana
Bufera pārvaldnieks nodrošina piekļuvi nepieciešamajiem datiem. Zemāk ir pieejamas divas pieejas atkarībā no tā, vai dati ir vai nav datu kešatmiņā:
Bufera kešatmiņa - mīksta parsēšana:
Bufera pārvaldnieks meklē datus buferī datu kešatmiņā. Ja šie dati ir, vaicājumu izpildītājs izmanto šos datus. Tas uzlabo veiktspēju, jo, ienesot datus no kešatmiņas, I / O darbību skaits tiek samazināts, salīdzinot ar datu ienešanu no datu krātuves.
Datu glabāšana - cietā parsēšana:
Ja bufera pārvaldniekā nav datu, datu krātuvē tiek meklēti nepieciešamie dati. If arī saglabā datus datu kešatmiņā turpmākai izmantošanai.
Netīra lapa
Tas tiek saglabāts kā Transaction Manager apstrādes loģika. Mēs detalizēti uzzināsim sadaļā Transaction Manager.
Darījumu vadītājs
Darījumu pārvaldnieks tiek izsaukts, kad piekļuves metode nosaka, ka vaicājums ir paziņojums Neatlasīt.
Žurnālu pārvaldnieks
- Žurnālu pārvaldnieks uzskaita visus sistēmā veiktos atjauninājumus, izmantojot žurnālus Darījumu žurnālos.
- Žurnāliem ir žurnālu kārtas numurs ar darījuma ID un datu modifikācijas ierakstu .
- To izmanto, lai sekotu līdzi izdarītajam darījumam un darījuma atcelšanai .
Slēdzenes pārvaldnieks
- Darījuma laikā saistītie dati datu krātuvē ir bloķēšanas stāvoklī. Šo procesu veic Lock Manager.
- Šis process nodrošina datu konsekvenci un izolāciju . Pazīstams arī kā ACID īpašības.
Izpildes process
- Log Manager sāk reģistrēt un Lock Manager bloķē saistītos datus.
- Datu kopija tiek saglabāta bufera kešatmiņā.
- Datu kopija, kas ir jāatjaunina, tiek saglabāta žurnāla buferī, un visi notikumi atjaunina datus datu buferī.
- Lapas, kurās tiek glabāti dati, tiek dēvētas arī par Dirty Pages .
- Kontrolpunkta un ierakstīšanas uz priekšu reģistrēšana: Šis process tiek palaists un atzīmēts visas lapas no Netīras lapas līdz Diskam, bet lapa paliek kešatmiņā. Biežums ir aptuveni 1 palaišana minūtē. Bet lapa vispirms tiek pārvietota uz žurnāla faila datu lapu no bufera žurnāla. Tas ir pazīstams kā rakstīšana uz priekšu.
- Slinks rakstnieks: Dirty lapa var palikt atmiņā. Kad SQL serveris novēro milzīgu slodzi un bufera atmiņa ir nepieciešama jaunam darījumam, tas atbrīvo Dirty Pages no kešatmiņas. Tas darbojas ar LRU - vismazāk izmantotais algoritms lapas tīrīšanai no bufera kopas uz disku.
Kopsavilkums:
- Pastāv trīs klienta servera arhitektūras veidi: 1) koplietotā atmiņa 2) TCP / IP 3) nosauktās caurules
- TBS, kuru izstrādājusi Sybase un kas tagad pieder Microsoft, ir pakete, kas ir iekapsulēta tīkla paketēs datu pārsūtīšanai no klienta datora uz servera mašīnu.
- Relāciju dzinējs satur trīs galvenos komponentus:
CMD parsētājs: Tas ir atbildīgs par sintaktiskām un semantiskām kļūdām un visbeidzot ģenerē vaicājumu koku.
Optimizētājs: Optimizētāja uzdevums ir atrast lētāko, nevis labāko, rentablu izpildes plānu.
Vaicājuma izpildītājs: vaicājuma izpildītājs izsauc piekļuves metodi un nodrošina izpildes plānu nepieciešamo datu iegūšanas loģikai.
- Pastāv trīs veidu faili: primārais fails, sekundārais fails un žurnāla faili.
- Uzglabāšanas dzinējs: ir šādi svarīgi komponenti
Piekļuves metode: Šis komponents nosaka, vai vaicājums ir paziņojums Atlasīt vai Neatlasīt. Attiecīgi izsauc buferi un pārsūtīšanas pārvaldnieku.
Bufera pārvaldnieks: Bufera pārvaldnieks pārvalda plāna kešatmiņas, datu parsēšanas un netīras lapas pamatfunkcijas.
Transaction Manager: Tas pārvalda Non-Select Transaction ar žurnālu un bloķēšanas pārvaldnieku palīdzību. Turklāt tas atvieglo nozīmīgu rakstīšanas un sagatavošanas “Lazy” rakstītāju ieviešanu.