SQL Server Architecture (forklaret)

MS SQL Server er en klient-server-arkitektur. MS SQL Server-processen starter med, at klientapplikationen sender en anmodning. SQL Server accepterer, behandler og besvarer anmodningen med behandlede data. Lad os diskutere hele arkitekturen vist nedenfor i detaljer:

Som diagrammet nedenfor viser, er der tre hovedkomponenter i SQL Server Archilære:

1. Protokollag
2. Relationel motor
3. Opbevaringsmotor

Protokollag – SNI

SQL Server Protocol Layer, også kendt som Server Network Interface (SNI), understøtter tre typer klient-server-arkitekturer. Hver protokol betjener et forskelligt netværksscenarie. Det er vigtigt at forstå disse protokoller, før man undersøger, hvordan forespørgsler behandles internt.

Delt hukommelse

Forestil dig en samtale tidligt om morgenen. Tom og hans mor er på det samme logiske sted, deres hjem. Tom beder om kaffe, og mor serverer den direkte. På samme måde leverer SQL Server Shared Memory-protokollen, når klienten og serveren kører på den samme maskine. Begge kommunikerer via delt hukommelse uden netværksoverhead.

Analogi: Tom knytter til klienten, mor knytter til SQL Server, hjemme knytter til maskinen, og verbal kommunikation knytter til delt hukommelsesprotokoll.

Konfigurationsnoter: In SQL Management Studio, kan indstillingen "Servernavn" for en lokal forbindelse være ".", "localhost", "127.0.0.1" eller "Maskine\Instans".

TCP / IP

Forestil dig nu, at Tom vil have kaffe fra en butik, der ligger 10 km væk. Tom er hjemme, og kaffebaren ligger på en travl markedsplads. De kommunikerer via et mobilnetværk. På samme måde leverer SQL Server TCP / IP-protokol når klienten og SQL Server er på separate maskiner, der er forbundet via et netværk.

Analogi: Tom knytter til klienten, caféen knytter til SQL Server, hjemmet og markedspladsen knytter til fjerntliggende placeringer, og mobilnetværket knytter til TCP/IP-protokollen.

Konfigurationsnoter: I SQL Management Studio skal indstillingen "Servernavn" for en TCP/IP-forbindelse være "Maskine\Instans af serveren". SQL Server bruger port 1433 som standard til TCP/IP-forbindelser.

Navngivne rør

Endelig vil Tom have grøn te fra sin nabo Sierra. De er på samme fysiske placering, da de er naboer, og kommunikerer via et intranetværk. På samme måde leverer SQL Server Named Pipe-protokollen, når klienten og serveren er forbundet via et lokalnetværk (LAN).

Analogi: Tom knytter til klienten, Sierra knytter til SQL Server, mens naboer knytter til LAN, og det interne netværk knytter til Named Pipe-protokollen.

Konfigurationsnoter: Navngivne piper er som standard deaktiveret og skal aktiveres via SQL Configuration Manager.

Hvad er TDS?

Nu hvor de tre typer klient-server-arkitektur er klare, er her et kig på TDS:

• TDS står for Tabular Data Stream.
• Alle tre protokoller bruger TDS-pakker.
• TDS er indkapslet i netværkspakker, hvilket muliggør dataoverførsel fra klientmaskinen til servermaskinen.
• TDS blev først udviklet af Sybase og ejes nu af Microsoft.

Følgende tabel sammenligner de tre SQL Server-forbindelsesprotokoller:

Feature	Delt hukommelse	TCP / IP	Navngivne rør
Netværksomfang	Samme maskine	Fjernbetjening (WAN/Internet)	Kun LAN
Standard port	N / A	1433	445
Ydeevne	Hurtigst (ingen netværksoverhead)	God (optimeret til WAN)	God (optimeret til LAN)
Aktiveret som standard	Ja	Ja	Ingen
Bedste Use Case	Lokal udvikling og testning	Fjernadgang til produktion	Pålidelige LAN-miljøer

Da protokollaget håndterer netværkskommunikation, er det næste trin i SQL Server-arkitekturen behandlingen af ​​selve forespørgslen. Det er her, relationsmotoren tager over.

Relationel motor

Relationsmotoren er også kendt som forespørgselsprocessoren. Den indeholder SQL Server-komponenterne, der bestemmer, hvad en forespørgsel skal gøre, og hvordan den kan udføres mest effektivt. Den er ansvarlig for at udføre brugerforespørgsler ved at anmode om data fra lagringsmotoren og behandle de returnerede resultater.

Som vist i arkitekturdiagrammet er der tre hovedkomponenter i den relationelle motor:

CMD Parser

Data modtaget fra protokollaget sendes til relationsmotoren. CMD-parseren er den første komponent, der modtager forespørgselsdataene. Dens primære opgave er at kontrollere forespørgslen for syntaktiske og semantiske fejl og derefter generere et forespørgselstræ.

Syntaktisk kontrol: Ligesom alle andre programmeringssprog har SQL Server et foruddefineret sæt af nøgleord og grammatikregler. SELECT, INSERT, UPDATE og mange andre tilhører den foruddefinerede nøgleordsliste. CMD-parseren verificerer, at inputtet følger disse regler. Hvis brugerens input afviger fra den forventede syntaks, returnerer parseren en fejl.

Eksempel: Forestil dig en russer, der går ind på en japansk restaurant og bestiller på russisk. Tjeneren forstår kun japansk og kan ikke behandle ordren. Hvis en bruger skriver "SELECR" i stedet for "SELECT", returnerer CMD-parseren ligeledes en fejl, fordi den ikke genkender nøgleordet.

Semantisk kontrol: Dette udføres af normaliseringsværktøjet. Det kontrollerer, om kolonnenavnene, tabelnavnene og andre objekter, der forespørges på, faktisk findes i skemaet. Hvis de findes, binder normaliseringsværktøjet dem til forespørgslen. Denne proces kaldes også binding. Når brugerforespørgsler indeholder en VIEW, erstatter normaliseringsværktøjet den med den internt lagrede viewdefinition.

Eksempel: Løb SELECT * from USER_ID ville få parseren til at kaste en fejl under den semantiske kontrol, hvis tabellen USER_ID ikke findes i databasen.

Opret forespørgselstræ: Dette trin genererer forskellige udførelsestræer, der repræsenterer de forskellige måder, en forespørgsel kan køres på. Alle træer producerer det samme ønskede output.

Optimizer

Optimeringsværktøjet opretter en udførelsesplan for brugerens forespørgsel. Denne plan bestemmer, hvordan forespørgslen skal udføres. Ikke alle forespørgsler er optimerede. Optimering gælder for DML (Data Modification Language)-kommandoer som SELECT, INSERT, DELETE og UPDATE. DDL-kommandoer som CREATE og ALTER er ikke optimerede, men kompileres til en intern formular.

Forespørgselsomkostningerne beregnes ud fra faktorer som CPU-forbrug, hukommelsesforbrug og input/output-behov. Optimeringsværktøjets rolle er at finde den billigste og omkostningseffektive udførelsesplan, ikke nødvendigvis den absolut bedste.

Eksempel: Forestil dig, at du vil åbne en online bankkonto. Én bank tager maksimalt 2 dage. Du har også en liste med 20 andre banker, som måske eller måske ikke tager kortere tid. Hvis du søger i alle 20 banker, finder du muligvis ikke en hurtigere løsning, og selve søgningen koster tid. Det ville have været bedre at vælge den første bank. Tilsvarende bruger SQL Optimizer udtømmende og heuristiske algoritmer til at minimere forespørgselskørselstiden.

Optimeringsværktøjet søger i tre faser:

Fase 0: Søg efter Trivial Plan

Dette er præoptimeringsfasen. For nogle forespørgsler findes der kun én praktisk plan, kendt som en triviel plan. Der er ikke behov for at søge yderligere, da enhver yderligere søgning ville finde den samme udførelsesplan med ekstra omkostninger.

Fase 1: Søg efter transaktionsbehandlingsplaner

Dette inkluderer søgning efter både simple og komplekse planer. Den simple plansøgning bruger statistisk analyse af kolonne- og indeksdata, typisk begrænset til ét indeks pr. tabel. Hvis der ikke findes en simpel plan, udføres en mere kompleks søgning, der involverer flere indeks pr. tabel.

Fase 2: Parallel behandling og optimering

Hvis de tidligere strategier ikke resulterer i en tilstrækkelig plan, søger optimeringsværktøjet efter muligheder for parallel behandling baseret på maskinens behandlingskapacitet. Hvis parallel behandling ikke er mulig, begynder en afsluttende optimeringsfase, der bruger alle resterende muligheder til at finde den bedst mulige udførelsesplan.

Forespørgselsudøver

Forespørgselseksekutoren kalder adgangsmetoden i lagringsmotoren. Den leverer en udførelsesplan, der indeholder den datahentningslogik, der kræves til udførelse. Når data er modtaget fra lagringsmotoren, publiceres resultatet til protokollaget og sendes til slutbrugeren.

Når relationsmotoren har fastlagt, hvordan en forespørgsel skal udføres, håndterer lagringsmotoren de fysiske dataoperationer. Dette lag styrer, hvordan data gemmes, caches og hentes fra disken.

Opbevaringsmotor

Storage Engine er ansvarlig for at lagre data i et lagringssystem som en disk eller et SAN og hente dem, når det er nødvendigt. Før man undersøger Storage Engine-komponenterne, er det vigtigt at forstå, hvordan data fysisk lagres.

Datafiler og -omfang

Datafiler lagrer fysisk data i form af datasider, hvor hver side har en størrelse på 8 KB. Dette er den mindste lagerenhed i SQL ServerDatasider er logisk grupperet i extents. Intet objekt er direkte tildelt en individuel side; i stedet udføres vedligeholdelse via extents. Hver side har en sidehoved (96 bytes), der indeholder metadata såsom sidetype, sidetal, brugt plads, ledig plads og henvisninger til den næste og forrige side.

Filtyper

Primær fil: Hver database indeholder én primær fil. Den gemmer alle vigtige data relateret til tabeller, visninger, triggere og andre objekter. Filtypen er typisk .mdf, men kan være en hvilken som helst filtype.

Sekundær fil: En database kan indeholde flere sekundære filer, men kan ikke indeholde dem. Disse er valgfrie og indeholder brugerspecifikke data. Filtypenavnet er typisk .ndf, men det kan være et hvilket som helst filtypenavn.

Logfil: Også kendt som Write-Ahead Logs. Filtypenavnet er .ldf. Logfiler bruges til transaktionsstyring, gendannelse fra uønskede instanser og udførelse af rollback af ikke-committede transaktioner.

Storage Engine har tre hovedkomponenter. Hver af dem spiller en specifik rolle i styringen af ​​dataadgang og -integritet.

Adgangsmetode

Access-metoden fungerer som en grænseflade mellem forespørgselsudføreren og Buffer Manager eller transaktionslogge. Den udfører ikke selv udførelsen, men bestemmer typen af ​​forespørgsel:

• Hvis forespørgslen er en SELECT-sætning (DML), den videregives til Buffer Leder til videre behandling.
• Hvis forespørgslen er en Ikke-SELECT-sætning (DDL og DML), sendes den til Transaktionsadministratoren. Dette omfatter primært UPDATE-, INSERT- og DELETE-sætninger.

Buffer Manager

Buffer Manager administrerer kernefunktioner for plancache, dataparsing og håndtering af dirty page.

Plan cache

Eksisterende forespørgselsplan: Buffer Manager kontrollerer, om udførelsesplanen findes i den gemte plancache. Hvis den gør, bruges den cachelagrede forespørgselsplan og dens tilhørende datacache direkte.

Førstegangs cacheplan: Hvis en førstegangsforespørgselsplan er kompleks, gemmes den i plancachen. Dette sikrer hurtigere tilgængelighed næste gang SQL Server modtager den samme forespørgsel.

Dataparsing: Buffer Cache og datalagring

Buffer Manageren giver adgang til de nødvendige data. Der er to mulige tilgange afhængigt af om der findes data i cachen:

Buffer Cache – Blød parsing

Buffer Lederen søger efter data i Buffer Cache. Hvis dataene er til stede, bruger Query Executor dem direkte. Dette forbedrer ydeevnen, fordi hentning af data fra cachen kræver færre I/O-operationer sammenlignet med hentning fra disklager.

Datalagring – Hård parsing

Hvis data ikke er til stede i Buffer Cache, de nødvendige data søges i datalageret på disken. Dataene gemmes derefter også i datacachen til senere brug.

Transaktionsleder

Transaktionshåndteringen kaldes, når adgangsmetoden bestemmer, at en forespørgsel er en ikke-SELECT-sætning. Den sikrer datakonsistens og holdbarhed gennem flere underkomponenter:

Log Manager

Logadministratoren gemmer track af alle opdateringer udført i systemet via logfiler gemt i transaktionslogge. Hver logpost indeholder et logsekvensnummer sammen med transaktions-ID'et og dataændringsposten. Denne mekanisme tracks committede og tilbageførte transaktioner.

Låsemanager

Under en transaktion går de tilknyttede data i lageret i en låst tilstand. Låseadministratoren håndterer denne proces og sikrer datakonsistens og -isolering. Disse egenskaber er også kendt som ACID (Atomicity, konsistens, isolation, holdbarhed).

Udførelsesproces

Udførelsesprocessen følger disse trin:

1. Logadministratoren starter logføring, og Låseadministratoren låser de tilhørende data.
2. En kopi af dataene opbevares i Buffer cache.
3. En kopi af data, der skal opdateres, gemmes i loggen Buffer, og alle hændelser opdaterer data i Data Buffer.
4. Sider, der gemmer ændrede data, kaldes Beskidte sider.

Checkpoint- og forhåndslogning

Kontrolpunktsprocessen kører cirka én gang i minuttet og markerer alle snavsede sider til skrivning til disk. Siden skubbes dog først til datasiden i logfilen fra Buffer Log. Denne mekanisme er kendt som Write-Ahead Logging. De snavsede sider forbliver i cachen, selv efter de er blevet skrevet til disken.

Lazy Writer

Når SQL Server observerer en høj belastning, og der er behov for bufferhukommelse til nye transaktioner, frigør den snavsede sider fra cachen. The Lazy Writer bruger LRU-algoritmen (Mindst Nyligt Brugte) til at rense sider fra bufferpuljen til disken.

Sådan behandler SQL Server en forespørgsel fra ende til anden

Det er værdifuldt at forstå hvert lag individuelt, men at se, hvordan de fungerer sammen, klargør det samlede billede. Når en klientapplikation sender en SQL-forespørgsel, sker følgende sekvens:

Protokollag modtager anmodningen via delt hukommelse, TCP/IP eller navngivne pipes og pakker den ind i en TDS-pakke. Relationel motor derefter tager over: CMD-parseren kontrollerer syntaks og semantik, optimizeren genererer den billigste udførelsesplan, og forespørgselseksekutoren begynder datahentning.

Forespørgselsudføreren kalder Lagringsmotorens Adgangsmetode, som sender SELECT-forespørgsler til Buffer Manager og ændringsforespørgsler til Transaktionsadministratoren. Buffer Manager tjekker plancache og Buffer Cache først (blød parsing). Hvis data ikke caches, udføres en disklæsning (hård parsing). Ved skriveoperationer koordinerer Transaktionshåndtering Loghåndtering, Låsehåndtering og kontrolpunktsprocessen for at sikre ACID-overholdelse.

Når Storage Engine returnerer de anmodede data, formaterer Relational Engine resultatsættet, og protokollaget leverer det tilbage til klientapplikationen via den samme TDS-protokol.

Sådan vælger du den rigtige protokol til SQL Server-forbindelser

Valg af den korrekte protokol afhænger af det fysiske forhold mellem klienten og serveren, samt krav til ydeevne.

Brug delt hukommelse når klientapplikationen kører på den samme maskine som SQL Server. Dette er den hurtigste mulighed, fordi den eliminerer al netværksoverhead. Den er ideel til lokal udvikling, test og implementeringer på én maskine.

Brug TCP/IP når klienten og serveren er på forskellige maskiner, der er forbundet via et WAN eller internettet. Dette er den mest almindeligt anvendte protokol i produktionsmiljøer. SQL Server lytter som standard på port 1433, og denne protokol understøtter krypterede forbindelser via TLS.

Brug navngivne pipes når klienten og serveren er på det samme betroede LAN, og ydeevne på interne netværk er en prioritet. Named Pipes er som standard deaktiveret og skal aktiveres via SQL Server Configuration Manager. Det er mindre almindeligt i moderne implementeringer, men er stadig nyttigt til ældre intranetapplikationer.

Ofte Stillede Spørgsmål