SQL Server Architecture (forklart)
MS SQL Server er en klient-server-arkitektur. MS SQL Server-prosessen starter med at klientapplikasjonen sender en forespørsel. SQL Server aksepterer, behandler og svarer på forespørselen med behandlede data. La oss diskutere i detalj hele arkitekturen vist nedenfor:
Som diagrammet nedenfor viser, er det tre hovedkomponenter i SQL Server Archilære:
- Protokollag
- Relasjonsmotor
- Lagringsmotor
Protokolllag – SNI
MS SQL SERVER PROTOCOL LAYER støtter 3 typer klientserver Architecture. Vi starter med "Tre typer klientserver Architecture" som MS SQL Server støtter.
Delt minne
La oss revurdere et samtalescenario tidlig om morgenen.
MAMMA og TOM – Her var Tom og moren hans på samme logiske sted, altså hjemme hos dem. Tom var i stand til å be om kaffe, og mamma kunne servere den varm.
MS SQL SERVER – Her MS SQL server gir PROTOKOLL FOR DELT MINNE. Her KLIENT og MS SQL server kjøres på samme maskin. Begge kan kommunisere via delt minneprotokoll.
Analogi: Lar kartlegge enheter i de to scenariene ovenfor. Vi kan enkelt kartlegge Tom til klient, mor til SQL-server, hjem til maskin og verbal kommunikasjon til delt minneprotokoll.
Fra skrivebordet for konfigurasjon og installasjon:
For tilkobling til lokal DB – Inn SQL Management Studio, "Server Name" Alternativet kan være
"."
"lokal vert"
"127.0.0.1"
"Machine\Instance"
TCP / IP
Tenk nå på kvelden, Tom er i festhumør. Han vil ha en kaffe bestilt fra en kjent kaffebar. Kaffebaren ligger 10 km unna hjemmet hans.
Her er Tom og Starbuck på forskjellige fysiske steder. Tom hjemme og Starbucks på den travle markedsplassen. De kommuniserer via mobilnettverk. Tilsvarende gir MS SQL SERVER muligheten til å samhandle via TCP / IP-protokoll, hvor CLIENT og MS SQL Server er fjerntliggende til hverandre og installert på en separat maskin.
Analogi: Lar kartlegge enheter i de to scenariene ovenfor. Vi kan enkelt kartlegge Tom til klient, Starbuck til SQL-server, hjemme-/markedsplassen til ekstern plassering og til slutt mobilnettverk til TCP/IP-protokollen.
Merknader fra skrivebordet for konfigurasjon/installasjon:
- I SQL Management Studio – For tilkobling via TCP\IP må alternativet "Server Name" være "Machine\Instance of the server."
- SQL-serveren bruker port 1433 i TCP/IP.
Navngitte rør
Nå, endelig om natten, ønsket Tom å ha en lysegrønn te som naboen hennes, Sierra tilbereder veldig godt.
Her Tom og hans Nabo, Sierra, er i samme fysisk plassering, å være hverandres nabo. De kommuniserer via Intranettverk. Tilsvarende MS SQL SERVER gir muligheten til å samhandle via kalt Pipe protokoll. Her KLIENT og MS SQL SERVER er i forbindelse via LAN.
Analogi: Lar kartlegge enheter i de to scenariene ovenfor. Vi kan enkelt kartlegge Tom til Client, Sierra til SQL-server, Neighbor til LAN og til slutt Intranettverk til Named Pipe Protocol.
Merknader fra skrivebordet for konfigurasjon/installasjon:
- For tilkobling via navngitt rør. Dette alternativet er deaktivert som standard og må aktiveres av SQL Configuration Manager.
Hva er TDS?
Nå som vi vet at det finnes tre typer klient-server Architecture, la oss ta et blikk på TDS:
- TDS står for Tabular Data Stream.
- Alle 3 protokollene bruker TDS-pakker. TDS er innkapslet i nettverkspakker. Dette muliggjør dataoverføring fra klientmaskinen til servermaskinen.
- TDS ble først utviklet av Sybase og eies nå av Microsoft
Relasjonsmotor
Relasjonsmotoren er også kjent som spørringsprosessoren. Den har SQL Server komponenter som bestemmer nøyaktig hva en spørring må gjøre og hvordan den kan gjøres best mulig. Den er ansvarlig for å utføre brukerforespørsler ved å be om data fra lagringsmotoren og behandle resultatene som returneres.
Som avbildet i Architekturdiagram som finnes 3 hovedkomponenter av relasjonsmotoren. La oss studere komponentene i detalj:
CMD Parser
Når data er mottatt fra Protocol Layer, sendes deretter til Relational Engine. "CMD Parser" er den første komponenten i Relational Engine som mottar spørringsdataene. Hovedoppgaven til CMD Parser er å sjekke spørringen etter Syntaktisk og semantisk feil. Til slutt, det genererer et spørringstre. La oss diskutere i detalj.
Syntaktisk sjekk:
- Som alle andre programmeringsspråk har MS SQL også det forhåndsdefinerte settet med nøkkelord. SQL Server har også sin egen grammatikk som SQL-serveren forstår.
- SELECT, INSERT, UPDATE og mange andre tilhører MS SQL forhåndsdefinerte nøkkelordlister.
- CMD Parser utfører syntaktisk sjekk. Hvis brukernes input ikke følger disse språksyntaks- eller grammatikkreglene, vil det returnerer en feil.
Eksempel: La oss si at en russer dro til en japansk restaurant. Han bestiller hurtigmat på russisk. Dessverre forstår servitøren bare japansk. Hva ville være det mest åpenbare resultatet?
Svaret er - servitøren kan ikke behandle bestillingen videre.
Det skal ikke være noen avvik i grammatikk eller språk som SQL-serveren aksepterer. Hvis det er det, kan ikke SQL-serveren behandle den og vil derfor returnere en feilmelding.
Vi vil lære mer om MS SQL-spørringer i kommende opplæringsprogrammer. Likevel, vurder nedenfor mest grunnleggende spørringssyntaks som
SELECT * from <TABLE_NAME>;
Nå, for å få en oppfatning av hva syntaktisk gjør, si om brukeren kjører den grunnleggende spørringen som nedenfor:
SELECR * from <TABLE_NAME>
Merk at i stedet for 'SELECT' skrev brukeren "SELECR."
Resultat: CMD-parseren vil analysere denne setningen og sende feilmeldingen. Siden "SELECR" ikke følger det forhåndsdefinerte nøkkelordnavnet og grammatikken. Her ventet CMD Parser "SELECT."
Semantisk sjekk:
- Dette utføres av Normalisering.
- I sin enkleste form sjekker den om kolonnenavn, tabellnavn som spørres om finnes i skjema. Og hvis den eksisterer, bind den til Query. Dette er også kjent som Bindende.
- Kompleksiteten øker når brukerforespørsler inneholder VIEW. Normalizer utfører erstatningen med den internt lagrede visningsdefinisjonen og mye mer.
La oss forstå dette ved hjelp av eksemplet nedenfor -
SELECT * from USER_ID
Resultat: CMD Parser vil analysere denne setningen for semantisk sjekk. Parseren vil sende en feilmelding da Normalizer ikke finner den forespurte tabellen (USER_ID) siden den ikke eksisterer.
Opprett spørringstre:
- Dette trinnet genererer et annet utførelsestre der spørringen kan kjøres.
- Merk at alle de forskjellige trærne har samme ønskede utgang.
Optimizer
Optimalisatorens arbeid er å lage en utførelsesplan for brukerens spørring. Dette er planen som vil bestemme hvordan brukerspørringen skal utføres.
Merk at ikke alle søk er optimalisert. Optimalisering gjøres for DML-kommandoer (Data Modification Language) som SELECT, INSERT, DELETE og UPDATE. Slike forespørsler merkes først og sendes deretter til optimalisereren. DDL-kommandoer som CREATE og ALTER er ikke optimalisert, men de er i stedet kompilert til en intern form. Spørringskostnaden beregnes basert på faktorer som CPU-bruk, minnebruk og input/output-behov.
Optimizers rolle er å finne billigste, ikke den beste, kostnadseffektive utførelsesplanen.
Før vi går inn i mer tekniske detaljer om Optimizer, bør du vurdere nedenfor virkelige eksempel:
Eksempel:
La oss si at du vil åpne en nettbankkonto. Du vet allerede om en bank som tar maksimalt 2 dager å åpne en konto. Men du har også en liste over 20 andre banker, som kan ta mindre enn 2 dager eller ikke. Du kan begynne å snakke med disse bankene for å finne ut hvilke banker som tar mindre enn 2 dager. Nå kan det hende du ikke finner en bank som tar mindre enn 2 dager, og det går tapt ekstra tid på grunn av selve søkeaktiviteten. Det hadde vært bedre å åpne en konto i den første banken selv.
Konklusjon: Det er viktigere å velge med omhu. For å være presis, velg hvilken alternativet er best, ikke det billigste.
Tilsvarende MS SQL Optimizer fungerer på innebygde uttømmende/heuristiske algoritmer. Målet er å minimere kjøretiden for spørringen. Alle Optimizer-algoritmene er forsvarlighet av Microsoft og en hemmelighet. Selv, nedenfor er trinnene på høyt nivå utført av MS SQL Optimizer. Søk etter optimalisering følger tre faser som vist i diagrammet nedenfor:
Fase 0: Søk etter trivialplan:
- Dette er også kjent som Forhåndsoptimeringsstadiet.
- For noen tilfeller kan det bare være én praktisk, gjennomførbar plan, kjent som en triviell plan. Det er ikke nødvendig å lage en optimalisert plan. Årsaken er at å søke mer ville resultere i å finne den samme kjøretidsutførelsesplanen. Det også med den ekstra kostnaden ved å søke etter optimalisert plan som ikke var nødvendig i det hele tatt.
- Hvis ingen triviell plan funnet, så 1st Fasen starter.
Fase 1: Søk etter transaksjonsbehandlingsplaner
- Dette inkluderer søket etter Enkel og kompleks plan.
- Enkelt plansøk: Tidligere data for kolonne og indeks som er involvert i spørringen, vil bli brukt for statistisk analyse. Dette består vanligvis, men ikke begrenset til, én indeks per tabell.
- Likevel, hvis den enkle planen ikke blir funnet, søkes mer kompleks plan. Det involverer flere indekser per tabell.
Fase 2: Parallell prosessering og optimalisering.
- Hvis ingen av de ovennevnte strategiene fungerer, søker Optimizer etter parallellbehandlingsmuligheter. Dette avhenger av maskinens prosesseringsevne og konfigurasjon.
- Hvis det fortsatt ikke er mulig, starter den siste optimaliseringsfasen. Nå er det endelige optimaliseringsmålet å finne alle andre mulige alternativer for å utføre spørringen på den beste måten. Endelig optimaliseringsfase Algorithms er Microsoft Anstendighet.
Forespørselsutøver
Spørringsutføreranrop Tilgangsmetode. Den gir en utførelsesplan for datahentingslogikk som kreves for utførelse. Når data er mottatt fra Storage Engine, publiseres resultatet til protokolllaget. Til slutt sendes data til sluttbrukeren.
Lagringsmotor
Arbeidet til Storage Engine er å lagre data i et lagringssystem som Disk eller SAN og hente dataene når det er nødvendig. Før vi går dypt inn i Storage-motoren, la oss se på hvordan data lagres i Database og type filer tilgjengelig.
Datafil og omfang:
Datafil, lagrer data fysisk i form av datasider, der hver dataside har en størrelse på 8KB, og danner den minste lagringsenheten i SQL Server. Disse datasidene er logisk gruppert for å danne omfang. Ingen objekter er tilordnet en side i SQL Server.
Vedlikeholdet av objektet gjøres via utstrekninger. Siden har en seksjon kalt Sideoverskriften med en størrelse på 96 byte, som fører metadatainformasjonen om siden som sidetype, sidenummer, størrelse på brukt plass, størrelse på ledig plass og peker til neste side og forrige side , osv.
Filtyper
- Primær fil
- Hver database inneholder én primærfil.
- Dette lagrer alle viktige data relatert til tabeller, visninger, utløsere, etc.
- Utvidelse er .mdf vanligvis, men kan ha en hvilken som helst utvidelse.
- Sekundær fil
- Databasen inneholder kanskje eller ikke inneholder flere sekundære filer.
- Dette er valgfritt og inneholder brukerspesifikke data.
- Utvidelse er .naf vanligvis, men kan ha en hvilken som helst utvidelse.
- Loggfil
- Også kjent som Write ahead-logger.
- Utvidelse er .ldf
- Brukes til transaksjonshåndtering.
- Dette brukes til å gjenopprette fra eventuelle uønskede tilfeller. Utfør viktig oppgave med tilbakeføring til ikke-forpliktede transaksjoner.
Storage Engine har 3 komponenter; la oss se nærmere på dem.
Tilgangsmetode
Den fungerer som et grensesnitt mellom spørringsutfører og Buffer Manager/transaksjonslogger.
Access Method i seg selv utfører ingen kjøring.
Den første handlingen er å finne ut om spørringen er:
- Velg erklæring (DDL)
- Ikke-valgt erklæring (DDL og DML)
Avhengig av resultatet tar tilgangsmetoden følgende trinn:
- Hvis spørringen er DDL, SELECT-setning, sendes spørringen til Buffer Leder for videre behandling.
- Og hvis du spør om DDL, NON-SELECT-setning, sendes spørringen til Transaction Manager. Dette inkluderer for det meste UPDATE-setningen.
Buffer Leder
Buffer leder administrerer kjernefunksjoner for modulene nedenfor:
- Plan cache
- Dataanalyse: Buffer cache og datalagring
- Skitten side
Vi skal lære Plan, Buffer og databuffer i denne delen. Vi vil dekke skitne sider i transaksjonsdelen.
Plan cache
- Eksisterende søkeplan: Buffermanageren sjekker om utførelsesplanen er der i den lagrede planbufferen. Hvis Ja, brukes spørreplanbuffer og tilhørende databuffer.
- Førstegangsbufferplan: Hvor kommer eksisterende Plan-cache fra? Hvis planen for utførelse av førstegangsspørringer kjøres og er kompleks, er det fornuftig å lagre den i Plane-bufferen. Dette vil sikre raskere tilgjengelighet neste gang SQL-serveren får samme spørring. Så det er ikke noe annet enn selve spørringen hvilken planutførelse som lagres hvis den kjøres for første gang.
Dataanalyse: Buffer cache og datalagring
Buffer leder gir tilgang til nødvendige data. Nedenfor er to tilnærminger mulige avhengig av om data finnes i databufferen eller ikke:
Buffer Cache – myk parsing:
Buffer Leder ser etter data i Buffer i databuffer. Hvis tilstede, brukes disse dataene av Query Executor. Dette forbedrer ytelsen ettersom antall I/O-operasjoner reduseres når data hentes fra hurtigbufferen sammenlignet med henting av data fra datalagring.
Datalagring – Hard Parsing:
Hvis data ikke er til stede i Buffer Manager enn nødvendig Data søkes i datalagring. If lagrer også data i databufferen for fremtidig bruk.
Skitten side
Den er lagret som en behandlingslogikk til Transaction Manager. Vi vil lære i detalj i Transaction Manager-delen.
Transaksjonsleder
Transaksjonsbehandling påkalles når tilgangsmetoden bestemmer at Query er en Non-Select-setning.
Loggbehandler
- Log Manager holder oversikt over alle oppdateringer som gjøres i systemet via logger i Transaksjonslogger.
- Logger har Logger sekvensnummer med transaksjons-ID og dataendringspost.
- Denne brukes for å holde styr på Transaksjon forpliktet og tilbakeføring av transaksjon.
Låsbehandler
- Under transaksjonen er de tilknyttede dataene i datalagring i låst tilstand. Denne prosessen håndteres av Lock Manager.
- Denne prosessen sikrer datakonsistens og isolasjon. Også kjent som ACID-egenskaper.
Utførelsesprosess
- Log Manager starter logging og Lock Manager låser de tilknyttede dataene.
- Dataens kopi oppbevares i Buffer cache.
- Kopi av data som skal oppdateres opprettholdes i loggbuffer og alle hendelsene oppdaterer data i databuffer.
- Sider som lagrer data er også kjent som Skitne sider.
- Sjekkpunkt og fremskrivningslogging: Denne prosessen kjører og merker hele siden fra Dirty Pages til Disk, men siden forblir i hurtigbufferen. Frekvensen er omtrent 1 løp per minutt. Men siden skyves først til Data-siden til loggfilen fra Buffer logg. Dette er kjent som Skriv fremover logging.
- lat forfatter: Dirty-siden kan forbli i minnet. Når SQL server observerer en stor belastning og Buffer minne er nødvendig for en ny transaksjon, frigjør det Dirty Pages fra cachen. Den opererer LRU – Minst nylig brukte algoritme for rengjøring av side fra bufferbasseng til disk.
Oppsummering
- Tre typer klientserver Architecture eksisterer: 1) Delt minne 2) TCP/IP 3) Navngitte rør
- TDS, utviklet av Sybase og nå eid av Microsoft, er en pakke som er innkapslet i nettverkspakker for dataoverføring fra klientmaskinen til servermaskinen.
- Relasjonsmotoren inneholder tre hovedkomponenter:CMD-parser: Dette er ansvarlig for syntaktiske og semantiske feil og genererer til slutt et spørringstre.Optimizer: Optimalisatorens rolle er å finne den billigste, ikke den beste, kostnadseffektive utførelsesplanen.
Spørringsutøver: Query executer kaller Access Method og gir en utførelsesplan for datahentingslogikk som kreves for utførelse.
- Det finnes tre typer filer Primærfil, Sekundærfil og Loggfiler.
- Lagringsmotor: Har følgende viktige komponenterTilgangsmetode: Denne komponenten Bestem om spørringen er Velg eller Ikke-valgt uttalelse. Påkaller Buffer og Transfer Manager deretter.Buffer manager: Buffer manager administrerer kjernefunksjoner for Plan Cache, Data Parsing & Dirty Page.
Transaksjonsleder: It manager Non-Select Transaction ved hjelp av Log and Lock Managers. Forenkler også viktig implementering av Write Ahead-logging og Lazy writers.