SQL Server Archistruktura (objašnjeno)

MS SQL Server je klijent-poslužiteljska arhitektura. MS SQL Server proces počinje tako što klijentska aplikacija šalje zahtjev. SQL Server prihvaća, obrađuje i odgovara na zahtjev s obrađenim podacima. Razmotrimo detaljno cijelu arhitekturu prikazanu u nastavku:

Kao što donji dijagram prikazuje, postoje tri glavne komponente u SQL Serveru Architekstura:

1. Sloj protokola
2. Relacijski motor
3. Motor za pohranu podataka

Sloj protokola – SNI

SLOJ PROTOKOLA MS SQL POSLUŽITELJA podržava 3 vrste klijentskog poslužitelja Architektura. Počet ćemo s “Tri vrste poslužitelja klijenta Architekstura” koje MS SQL Server podržava.

Zajedničko sjećanje

Razmotrimo scenarij ranog jutarnjeg razgovora.

MAMA i TOM – Ovdje su Tom i njegova mama, bili na istom logičnom mjestu, tj. kod njih doma. Tom je mogao zatražiti kavu, a mama ju je mogla poslužiti vruću.

MS SQL POSLUŽITELJ – Ovdje MS SQL pruža poslužitelj PROTOKOL DIJELJENE MEMORIJE, Ovdje KUPAC i MS SQL poslužitelj radi na istom stroju. Oba mogu komunicirati putem protokola zajedničke memorije.

Analogija: Omogućava mapiranje entiteta u gornja dva scenarija. Lako možemo preslikati Toma u klijenta, mamu u SQL poslužitelj, kuću u stroj i verbalnu komunikaciju u protokol zajedničke memorije.

Sa stola konfiguracije i instalacije:

Za povezivanje s lokalnom bazom podataka – In SQL Management Studio, opcija "Naziv poslužitelja" može biti

"."

“localhost”

"127.0.0.1"

“Stroj\instanca”

TCP / IP

Sada razmislite o večeri, Tom je raspoložen za zabavu. Želi naručenu kavu iz poznatog kafića. Kafić se nalazi 10 km od njegove kuće.

Ovdje su Tom i Starbuck na različitim fizičkim lokacijama. Tom kod kuće i Starbucks na užurbanoj tržnici. Komuniciraju putem mobilne mreže. Slično tome, MS SQL SERVER pruža mogućnost interakcije putem TCP / IP protokol, gdje su KLIJENT i MS SQL Server međusobno udaljeni i instalirani na zasebnom računalu.

Analogija: Omogućava mapiranje entiteta u gornja dva scenarija. Lako možemo preslikati Toma na klijenta, Starbuck na SQL poslužitelj, početnu/tržišnu lokaciju na udaljenu lokaciju i konačno mobilnu mrežu na TCP/IP protokol.

Bilješke sa stola za konfiguraciju/instalaciju:

• U SQL Management Studio – za povezivanje putem TCP\IP, opcija "Naziv poslužitelja" mora biti "Stroj\Instanca poslužitelja."
• SQL poslužitelj koristi port 1433 u TCP/IP-u.

Nazvane cijevi

Sada je konačno noću Tom želio popiti svijetlozeleni čaj koji je njezina susjeda Sierra jako dobro pripremila.

Ovdje mužjak nekih malih životinja i njegov Susjed, Sierra, nalaze se u istom fizički mjesto, biti susjedi jedni drugima. Komuniciraju putem Intra mreža. Slično tome, MS SQL POSLUŽITELJ pruža mogućnost interakcije putem Pod nazivom Pipe protokol. Ovdje KLIJENT i MS SQL POSLUŽITELJ su u vezi preko LAN.

Analogija: Omogućava mapiranje entiteta u gornja dva scenarija. Lako možemo preslikati Tom na klijenta, Sierru na SQL poslužitelj, susjed na LAN i na kraju unutarnju mrežu u Named Pipe Protocol.

Bilješke sa stola za konfiguraciju/instalaciju:

• Za spajanje putem imenovane cijevi. Ova je opcija prema zadanim postavkama onemogućena i treba je omogućiti SQL Configuration Manager.

Što je TDS?

Sada kada znamo da postoje tri vrste klijent-poslužitelj Architeksture, omogućuje nam da bacimo pogled na TDS:

• TDS je kratica za Tabular Data Stream.
• Sva 3 protokola koriste TDS pakete. TDS je enkapsuliran u mrežnim paketima. To omogućuje prijenos podataka s klijentskog stroja na poslužiteljski stroj.
• TDS je prvi razvio Sybase i sada je u vlasništvu Microsoft

Relacijski motor

Relacijski mehanizam je također poznat kao procesor upita. Ima SQL Server komponente koje određuju što točno upit treba učiniti i kako se to najbolje može učiniti. Odgovoran je za izvršavanje korisničkih upita traženjem podataka od mehanizma za pohranu i obradom rezultata koji se vraćaju.

Kao što je prikazano u Archipostoje tekstualni dijagrami 3 glavne komponente relacijskog motora. Proučimo detaljno komponente:

CMD parser

Jednom primljeni podaci od sloja protokola prosljeđuju se relacijskom mehanizmu. “CMD parser” je prva komponenta Relational Enginea koja prima podatke upita. Glavni posao CMD parsera je provjera upita za Sintaktička i semantička pogreška. Konačno, to generira stablo upita. Raspravljajmo detaljno.

Sintaktička provjera:

• Kao i svaki drugi programski jezik, MS SQL također ima unaprijed definiran skup ključnih riječi. Također, SQL Server ima vlastitu gramatiku koju SQL poslužitelj razumije.
• SELECT, INSERT, UPDATE i mnogi drugi pripadaju MS SQL unaprijed definiranim popisima ključnih riječi.
• CMD Parser radi sintaktičku provjeru. Ako unos korisnika ne slijedi sintaksu jezika ili pravila gramatike, vraća grešku.

Primjer: Recimo da je Rus otišao u japanski restoran. Naručuje brzu hranu na ruskom jeziku. Nažalost, konobar razumije samo japanski. Koji bi bio najočitiji rezultat?

Odgovor je – konobar nije u mogućnosti dalje obraditi narudžbu.

Ne bi trebalo biti nikakvih odstupanja u gramatici ili jeziku koji SQL poslužitelj prihvaća. Ako postoje, SQL poslužitelj ih ne može obraditi i stoga će vratiti poruku o pogrešci.

Naučit ćemo više o MS SQL upitu u nadolazećim tutorijalima. Ipak, u nastavku razmotrite najosnovniju sintaksu upita kao

SELECT * from <TABLE_NAME>;

Sada, da biste dobili percepciju o tome što radi sintaktika, recimo ako korisnik pokrene osnovni upit kao u nastavku:

SELECR * from <TABLE_NAME>

Imajte na umu da je umjesto 'SELECT' korisnik upisao "SELECR."

Rezultat: CMD Parser analizirat će ovu izjavu i izbacit će poruku o pogrešci. Kako “SELECR” ne slijedi unaprijed definirani naziv ključne riječi i gramatiku. Ovdje je CMD Parser očekivao "SELECT".

Semantička provjera:

• Ovo izvodi Normalizator.
• U svom najjednostavnijem obliku, provjerava postoje li u shemi naziv stupca, naziv tablice koji se ispituje. I ako postoji, povežite ga s upitom. Ovo je također poznato kao Vezivanje.
• Složenost se povećava kada korisnički upiti sadrže VIEW. Normalizator izvodi zamjenu s interno pohranjenom definicijom pogleda i još mnogo toga.

Shvatimo ovo uz pomoć donjeg primjera –

SELECT * from USER_ID

Rezultat: CMD parser analizirat će ovu izjavu za semantičku provjeru. Parser će izbaciti poruku o pogrešci jer Normalizator neće pronaći traženu tablicu (USER_ID) jer ne postoji.

Napravi stablo upita:

• Ovaj korak generira različito stablo izvršenja u kojem se može pokrenuti upit.
• Imajte na umu da sva različita stabla imaju isti željeni izlaz.

optimizaciju

Rad optimizatora je stvoriti plan izvršenja za korisnički upit. Ovo je plan koji će odrediti kako će se korisnički upit izvršiti.

Imajte na umu da nisu svi upiti optimizirani. Optimizacija se vrši za DML (jezik za modificiranje podataka) naredbe kao što su SELECT, INSERT, DELETE i UPDATE. Takvi se upiti prvo označavaju, a zatim šalju optimizatoru. DDL naredbe poput CREATE i ALTER nisu optimizirane, već se umjesto toga prevode u interni obrazac. Cijena upita izračunava se na temelju čimbenika kao što su upotreba CPU-a, upotreba memorije i potrebe za ulazom/izlazom.

Uloga optimizatora je pronaći najjeftiniji, a ne najbolji, isplativ plan izvršenja.

Prije nego što pređemo na tehničke pojedinosti alata za optimizaciju, razmotrite donji primjer iz stvarnog života:

Primjer:

Recimo, želite otvoriti online bankovni račun. Već znate za jednu banku kojoj je potrebno najviše 2 dana da otvori račun. No, također imate popis od 20 drugih banaka, što može, ali i ne mora potrajati manje od 2 dana. Možete započeti suradnju s tim bankama kako biste utvrdili kojim bankama treba manje od 2 dana. Sada možda nećete pronaći banku za što je potrebno manje od 2 dana, a gubi se dodatno vrijeme zbog same aktivnosti pretraživanja. Bilo bi bolje da sam otvorio račun kod prve banke.

Zaključak: Važnije je mudro odabrati. Točnije, odaberite koji opcija je najbolja, a ne najjeftinija.

Slično, MS SQL Optimizer radi na ugrađenim iscrpnim/heurističkim algoritmima. Cilj je minimalizirati vrijeme izvođenja upita. Svi algoritmi optimizatora su ispravnost od Microsoft i tajna. Iako, ispod su koraci visoke razine koje izvodi MS SQL Optimizer. Pretraživanje optimizacije slijedi tri faze kao što je prikazano na donjem dijagramu:

Faza 0: Potraga za trivijalnim planom:

• Ovo je također poznato kao Faza predoptimizacije.
• Za neke slučajeve može postojati samo jedan praktičan, izvediv plan, poznat kao trivijalni plan. Nema potrebe za izradom optimiziranog plana. Razlog je što bi više pretraživanja rezultiralo pronalaženjem istog plana izvršenja vremena izvođenja. To također uz dodatne troškove traženja optimiziranog plana koji uopće nije bio potreban.
• Ako nije pronađen trivijalni plan, tada 1^st Faza počinje.

Faza 1: Potražite planove obrade transakcija

• To uključuje traženje Jednostavan i složen plan.
• Jednostavno plansko pretraživanje: prošli podaci stupca i indeksa koji su uključeni u upit koristit će se za statističku analizu. To se obično sastoji, ali nije ograničeno na jedan indeks po tablici.
• Ipak, ako se jednostavni plan ne pronađe, onda se traži složeniji plan. Uključuje više indeksa po tablici.

Faza 2: Paralelna obrada i optimizacija.

• Ako nijedna od gore navedenih strategija ne uspije, Optimizer traži mogućnosti paralelne obrade. To ovisi o mogućnostima obrade i konfiguraciji Stroja.
• Ako to još uvijek nije moguće, tada počinje zadnja faza optimizacije. Sada je konačni cilj optimizacije pronalaženje svih drugih mogućih opcija za izvršenje upita na najbolji način. Završna faza optimizacije Algorithms ima Microsoft Pristojnost.

Izvršitelj upita

Pozivi izvršitelja upita Metoda pristupa. Pruža plan izvršenja za logiku dohvaćanja podataka potrebnu za izvršenje. Nakon što se podaci prime iz Storage Enginea, rezultat se objavljuje na sloju protokola. Na kraju se podaci šalju krajnjem korisniku.

Motor za pohranu podataka

Rad Storage Enginea je pohranjivanje podataka u sustav za pohranjivanje kao što je Disk ili SAN i dohvaćanje podataka kada su potrebni. Prije nego što duboko zaronimo u Storage engine, pogledajmo kako se podaci pohranjuju Baza podataka i vrste dostupnih datoteka.

Podatkovna datoteka i opseg:

Podatkovna datoteka, fizički pohranjuje podatke u obliku podatkovnih stranica, pri čemu svaka podatkovna stranica ima veličinu od 8 KB, čineći najmanju jedinicu za pohranu u SQL Serveru. Ove podatkovne stranice su logično grupirane u obliku ekstenti. Nijednom objektu nije dodijeljena stranica u SQL Serveru.

Održavanje objekta vrši se preko ekstenata. Stranica ima odjeljak pod nazivom Zaglavlje stranice veličine 96 bajtova, koji sadrži informacije o metapodacima o stranici kao što su vrsta stranice, broj stranice, veličina iskorištenog prostora, veličina slobodnog prostora i pokazivač na sljedeću i prethodnu stranicu itd.

Vrste datoteka

1. Primarna datoteka

• Svaka baza podataka sadrži jednu primarnu datoteku.
• Ovo pohranjuje sve važne podatke koji se odnose na tablice, prikaze, okidače itd.
• Ekstenzija je .MDF obično, ali može imati bilo koje proširenje.

2. Sekundarna datoteka

• Baza podataka može ali ne mora sadržavati više sekundarnih datoteka.
• Ovo nije obavezno i ​​sadrži podatke specifične za korisnika.
• Ekstenzija je .naf obično, ali može imati bilo koje proširenje.

3. Log datoteka

• Također poznat kao dnevnici pisanja unaprijed.
• Ekstenzija je .LDF
• Koristi se za upravljanje transakcijama.
• Ovo se koristi za oporavak od svih neželjenih instanci. Izvršite važan zadatak vraćanja na neizvršene transakcije.

Storage Engine ima 3 komponente; pogledajmo ih detaljno.

Način pristupa

Djeluje kao sučelje između izvršitelja upita i Buffer Upravitelj/Dnevnici transakcija.

Sama metoda pristupa ne izvršava nikakvo izvršenje.

Prva radnja je utvrditi je li upit:

1. Odaberite izjavu (DDL)
2. Izjava bez odabira (DDL i DML)

Ovisno o rezultatu, Metoda pristupa poduzima sljedeće korake:

1. Ako je upit DDL, SELECT izjava, upit se prosljeđuje na Buffer Voditelj za daljnju obradu.
2. I ako upit ako DDL, NON-SELECT izjava, upit se prosljeđuje upravitelju transakcija. To uglavnom uključuje naredbu UPDATE.

Buffer Voditelj

Buffer upravitelj upravlja temeljnim funkcijama za module ispod:

• Predmemorija plana
• Raščlanjivanje podataka: Buffer predmemorija i pohrana podataka
• Prljava stranica

Naučit ćemo planirati, Buffer i Predmemorija podataka u ovom odjeljku. Prljave stranice obradit ćemo u odjeljku Transakcije.

Predmemorija plana

• Postojeći plan upita: Upravitelj međuspremnika provjerava postoji li plan izvršenja u pohranjenoj predmemorije plana. Ako je Da, koristi se predmemorija plana upita i pridružena predmemorija podataka.
• Prvi plan predmemorije: Odakle dolazi postojeća predmemorija plana? Ako se izvodi prvi plan izvršenja upita i složen je, ima smisla pohraniti ga u predmemoriju plana. Ovo će osigurati bržu dostupnost kada sljedeći put SQL poslužitelj dobije isti upit. Dakle, nije ništa drugo nego sam upit koje se izvršenje plana pohranjuje ako se pokreće prvi put.

Raščlanjivanje podataka: Buffer predmemorija i pohrana podataka

Buffer upravitelj omogućuje pristup potrebnim podacima. Sljedeća dva pristupa moguća su ovisno o tome postoje li podaci u predmemoriji podataka ili ne:

Buffer Predmemorija – meko analiziranje:

Buffer Upravitelj traži podatke Buffer u predmemoriji podataka. Ako su prisutni, tada ove podatke koristi Izvršitelj upita. Ovo poboljšava izvedbu jer se smanjuje broj I/O operacija prilikom dohvaćanja podataka iz predmemorije u usporedbi s dohvaćanjem podataka iz pohrane podataka.

Pohranjivanje podataka – teško analiziranje:

Ako podaci nisu prisutni u Buffer Upravitelj od potrebnog Podaci se pretražuju u Pohrani podataka. If također pohranjuje podatke u predmemoriju podataka za buduću upotrebu.

Prljava stranica

Pohranjuje se kao logika obrade Transaction Managera. Detaljno ćemo naučiti u odjeljku Transaction Manager.

Upravitelj transakcija

Transaction Manager se poziva kada pristupna metoda utvrdi da je Query iskaz Non-Select.

Log Manager

• Log Manager prati sva ažuriranja izvršena u sustavu putem zapisa u zapisima transakcija.
• Dnevnici imaju Zapisuje redni broj s ID-om transakcije i zapisom izmjene podataka.
• Ovo se koristi za praćenje Preuzeta transakcija i vraćanje transakcije.

Upravitelj zaključavanja

• Tijekom transakcije, pridruženi podaci u pohrani podataka su u zaključanom stanju. Ovim procesom upravlja Lock Manager.
• Ovaj proces osigurava dosljednost i izolacija podataka. Poznato i kao svojstva KISELINE.

Proces izvršenja

• Log Manager započinje bilježenje, a Lock Manager zaključava povezane podatke.
• Kopija podataka čuva se u Buffer predmemorija.
• Kopija podataka koja se treba ažurirati održava se u međuspremniku dnevnika, a svi događaji ažuriraju podatke u međuspremniku podataka.
• Stranice koje pohranjuju podatke poznate su i kao Prljave stranice.
• Kontrolna točka i bilježenje unaprijed: Ovaj proces se pokreće i označava sve stranice od prljavih stranica do diska, ali stranica ostaje u predmemorij. Frekvencija je otprilike 1 trčanje u minuti. Ali stranica se prvo gura na stranicu podataka datoteke dnevnika iz Buffer log. Ovo je poznato kao Zapisivanje unaprijed.
• Lijeni pisac: Prljava stranica može ostati u sjećanju. Kada SQL poslužitelj primijeti veliko opterećenje i Buffer memorija je potrebna za novu transakciju, oslobađa Dirty Pages iz predmemorije. Djeluje na LRU – Zadnji korišteni algoritam za čišćenje stranice iz međuspremnika na disk.

rezime

• Tri vrste klijentskog poslužitelja Archipostoji struktura: 1) dijeljena memorija 2) TCP/IP 3) imenovane cijevi
• TDS, koji je razvio Sybase i sada je u vlasništvu Microsoft, je paket koji je enkapsuliran u mrežnim paketima za prijenos podataka s klijentskog stroja na poslužiteljski stroj.
• Relacijski motor sadrži tri glavne komponente:CMD parser: Ovo je odgovorno za sintaktičku i semantičku pogrešku i konačno generira stablo upita.Optimizator: Uloga optimizatora je pronaći najjeftiniji, a ne najbolji, troškovno učinkovit plan izvršenja.

  Izvršitelj upita: Izvršitelj upita poziva metodu pristupa i daje plan izvršenja za logiku dohvaćanja podataka potrebnu za izvršenje.

• Postoje tri vrste datoteka: primarna datoteka, sekundarna datoteka i zapisnici.
• Storage Engine: ima sljedeće važne komponenteNačin pristupa: Ova komponenta utvrđuje je li upit izjava Odabir ili Ne-Odabir. Priziva Buffer i Transfer Manager sukladno tome.Buffer Menadžer: Buffer upravitelj upravlja temeljnim funkcijama za predmemoriju plana, analizu podataka i prljavu stranicu.

  Upravitelj transakcija: Upravlja transakcijama bez odabira uz pomoć upravitelja zapisnika i zaključavanja. Također, olakšava važnu implementaciju zapisivanja Write Ahead i Lazy writers.