SQL Server-arkitektur forklaret: Navngivne rør, Optimizer, Buffer Manager

Indholdsfortegnelse:

Anonim

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

Som nedenstående diagram viser, er der tre hovedkomponenter i SQL Server Architecture:

  1. Protokollag
  2. Relationel motor
  3. Opbevaringsmotor
SQL Server-arkitekturdiagram

Lad os diskutere detaljeret om alle de tre ovenstående hovedmoduler. I denne vejledning lærer du.

  • Protokollag - SNI
    • Delt hukommelse
    • TCP / IP
    • Navngivne rør
    • Hvad er TDS?
  • Relationel motor
    • CMD-parser
    • Optimizer
    • Forespørgselseksekutør
  • Opbevaringsmotor
    • Filtyper
    • Adgangsmetode
    • Buffer Manager
    • Planlæg cache
    • Dataparsering: Buffercache og datalagring
    • Transaktionschef

Protokollag - SNI

MS SQL SERVER PROTOCOL LAYER understøtter 3 Type Client Server Architecture. Vi starter med " Three Type of Client Server Architecture", som MS SQL Server understøtter.

Delt hukommelse

Lad os genoverveje et tidligt morgenkonversationsscenarie.

MOM og TOM - Her var Tom og hans mor på det samme logiske sted, dvs. hjemme hos dem. Tom var i stand til at bede om kaffe, og mor var i stand til at servere den varm.

MS SQL SERVER - Her leverer MS SQL server SHARED MEMORY PROTOCOL . Her kører CLIENT og MS SQL server på samme maskine. Begge kan kommunikere via Shared Memory-protokollen.

Analogi: Gør det muligt at kortlægge enheder i ovenstående to scenarier. Vi kan nemt kortlægge Tom til klient, mor til SQL-server, hjem til maskine og verbal kommunikation til delt hukommelsesprotokol.

Fra skrivebordet med konfiguration og installation:

For forbindelse til lokal DB - I SQL Management Studio kan "Servernavn" være

"."

"localhost"

"127.0.0.1"

"Maskine \ Instans"

TCP / IP

Overvej nu om aftenen, Tom er i feststemning. Han vil have en kaffe bestilt fra en velkendt kaffebar. Kaffebaren ligger 10 km væk fra hans hjem.

Her er Tom og Starbuck forskellige fysiske steder. Tom derhjemme og Starbucks på den travle markedsplads. De kommunikerer via mobilnetværk. Tilsvarende giver MS SQL SERVER mulighed for at interagere via TCP / IP-protokol, hvor CLIENT og MS SQL Server er fjerntliggende til hinanden og installeret på en separat maskine.

Analogi: Gør det muligt at kortlægge enheder i ovenstående to scenarier. Vi kan nemt kortlægge Tom til klient, Starbuck til SQL-server, hjemmet / markedspladsen til ekstern placering og til sidst mobilnetværk til TCP / IP-protokol.

Noter fra skrivebordet til konfiguration / installation:

  • I SQL Management Studio - For forbindelse via TCP \ IP skal "Servernavn" være "Machine \ Instance of the server."
  • SQL-server bruger port 1433 i TCP / IP.

Navngivne rør

Nu endelig om natten ønskede Tom at have en lysegrøn te, som hendes nabo, Sierra, forberedte meget godt.

Her er Tom og hans nabo , Sierra, på samme fysiske sted og er hinandens nabo. De kommunikerer via Intra-netværk. Tilsvarende giver MS SQL SERVER muligheden for at interagere via Named Pipe- protokollen. Her er CLIENT og MS SQL SERVER i forbindelse via LAN .

Analogi: Gør det muligt at kortlægge enheder i ovenstående to scenarier. Vi kan nemt kortlægge Tom til klient, Sierra til SQL-server, Neighbor til LAN og endelig Intra-netværk til Named Pipe Protocol.

Noter fra skrivebordet til konfiguration / installation:

  • Til forbindelse via navngivet rør. Denne indstilling er som standard deaktiveret og skal aktiveres af SQL Configuration Manager.

Hvad er TDS?

Nu hvor vi ved, at der er tre typer klient-serverarkitektur, kan vi se på TDS:

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

Relationel motor

Relational Engine er også kendt som Query Processor. Det har SQL Server-komponenter, der bestemmer, hvad en forespørgsel skal gøre, og hvordan det kan gøres bedst. Det er ansvarligt for udførelsen af ​​brugerforespørgsler ved at anmode om data fra lagermotoren og behandle de resultater, der returneres.

Som afbildet i det arkitektoniske diagram er der 3 hovedkomponenter i Relational Engine. Lad os studere komponenterne detaljeret:

CMD-parser

Data, der en gang er modtaget fra Protocol Layer, sendes derefter til Relational Engine. "CMD Parser" er den første komponent i Relational Engine, der modtager forespørgselsdataene. CMD Parsers hovedopgave er at kontrollere forespørgslen for syntaktisk og semantisk fejl. Endelig genererer det et forespørgselstræ . Lad os diskutere detaljeret.

Syntaktisk kontrol:

  • Som alle andre programmeringssprog har MS SQL også det foruddefinerede sæt nøgleord. SQL Server har også sin egen grammatik, som SQL-serveren forstår.
  • SELECT, INSERT, UPDATE og mange andre tilhører MS SQL foruddefinerede søgeordslister.
  • CMD Parser udfører syntaktisk kontrol. Hvis brugernes input ikke følger disse sproglige syntaks- eller grammatikregler, returnerer den en fejl.

Eksempel: Lad os sige, at en russer gik til en japansk restaurant. Han bestiller fastfood på russisk. Desværre forstår tjeneren kun japansk. Hvad ville være det mest oplagte resultat?

Svaret er - tjeneren kan ikke behandle ordren yderligere.

Der bør ikke være nogen afvigelse i grammatik eller sprog, som SQL-server accepterer. Hvis det er tilfældet, kan SQL-server ikke behandle det og returnerer derfor en fejlmeddelelse.

Vi lærer mere om MS SQL-forespørgsel i kommende tutorials. Overvej alligevel nedenstående mest basale forespørgselssyntaks som 

SELECT * from ;

For at få opfattelsen af, hvad syntaktisk gør, skal du sige, om brugeren kører den grundlæggende forespørgsel som nedenfor:

SELECR * from

Bemærk, at i stedet for 'VÆLG' skrev brugeren "SELECR."

Resultat: CMD-parseren analyserer denne erklæring og kaster fejlmeddelelsen. Da "SELECR" ikke følger det foruddefinerede søgeordsnavn og grammatik. Her forventede CMD Parser "SELECT".

Semantisk kontrol:

  • Dette udføres af Normalizer .
  • I sin enkleste form kontrollerer den, om der findes et kolonnenavn, det tabelnavn, der er spurgt i, i skemaet. Og hvis den findes, skal du binde den til forespørgsel. Dette er også kendt som Binding .
  • Kompleksiteten øges, når brugerforespørgsler indeholder VIEW. Normalizer udfører udskiftningen med den internt gemte visningsdefinition og meget mere.

Lad os forstå dette ved hjælp af nedenstående eksempel -

SELECT * from USER_ID

Resultat: CMD Parser analyserer denne erklæring til semantisk kontrol. Parseren kaster en fejlmeddelelse, da Normalizer ikke finder den ønskede tabel (USER_ID), da den ikke findes.

Opret forespørgselstræ:

  • Dette trin genererer forskellige eksekveringstræ, hvor forespørgsel kan køres.
  • Bemærk, at alle de forskellige træer har det samme ønskede output.

Optimizer

Optimizerens arbejde er at oprette en eksekveringsplan for brugerens forespørgsel. Dette er planen, der bestemmer, hvordan brugerforespørgslen udføres.

Bemærk, at ikke alle forespørgsler er optimeret. Optimering udføres for DML-kommandoer (Data Modification Language) som SELECT, INSERT, DELETE og UPDATE. Sådanne forespørgsler markeres først og sendes derefter til optimeringsprogrammet. DDL-kommandoer som CREATE og ALTER er ikke optimeret, men de kompileres i stedet til en intern form. Forespørgselsomkostningerne beregnes ud fra faktorer som CPU-forbrug, hukommelsesforbrug og behov for input / output.

Optimizer's rolle er at finde den billigste, ikke den bedste, omkostningseffektive udførelsesplan.

Inden vi springer ind i mere tekniske detaljer af Optimizer, skal du overveje nedenstående eksempel på virkeligheden:

Eksempel:

Lad os sige, at du vil åbne en online bankkonto. Du kender allerede til en bank, der maksimalt tager 2 dage at åbne en konto. Men du har også en liste over 20 andre banker, som måske eller måske ikke tager mindre end 2 dage. Du kan begynde at samarbejde med disse banker for at bestemme, hvilke banker der tager mindre end 2 dage. Nu kan du muligvis ikke finde en bank, der tager mindre end to dage, og der er yderligere tabt tid på grund af selve søgeaktiviteten. Det ville have været bedre at åbne en konto i den første bank selv.

Konklusion: Det er vigtigere at vælge klogt. For at være præcis skal du vælge, hvilken mulighed der er bedst, ikke den billigste.

Tilsvarende fungerer MS SQL Optimizer på indbyggede udtømmende / heuristiske algoritmer. Målet er at minimere forespørgselens kørselstid. Alle Optimizer-algoritmerne er Microsoft og en hemmelighed. Selvom , nedenfor er de højt niveau trin, der udføres af MS SQL Optimizer. Søgninger efter optimering følger tre faser som vist i nedenstående diagram:

Fase 0: Søg efter Trivial Plan:

  • Dette er også kendt som præoptimeringsfasen .
  • I nogle tilfælde kunne der kun være en praktisk, brugbar plan, kendt som en triviel plan. Der er ikke behov for at oprette en optimeret plan. Årsagen er, at søgning efter mere ville resultere i at finde den samme udførelsesplan for kørselstiden. Det også med de ekstra omkostninger ved at søge efter en optimeret plan, som slet ikke var påkrævet.
  • Hvis der ikke Trivial planen fundet, derefter 1 st Phase starter.

Fase 1: Søg efter transaktionsbehandlingsplaner

  • Dette inkluderer søgningen efter enkel og kompleks plan .
  • Enkel plansøgning: Tidligere data for kolonne og indeks involveret i forespørgsel vil blive brugt til statistisk analyse. Dette består normalt, men ikke begrænset til en indeks pr. Tabel.
  • Hvis den enkle plan ikke findes, søges der stadig i mere kompleks plan. Det involverer flere indeks pr. Tabel.

Fase 2: Parallel behandling og optimering.

  • Hvis ingen af ​​ovenstående strategier virker, søger Optimizer efter parallelle behandlingsmuligheder. Dette afhænger af maskinens behandlingsfunktioner og konfiguration.
  • Hvis det stadig ikke er muligt, starter den sidste optimeringsfase. Nu er det endelige optimeringsmål at finde alle andre mulige muligheder for at udføre forespørgslen på den bedste måde. Den endelige optimeringsfase Algoritmer er Microsoft Propriety.

Forespørgselseksekutør

Forespørgselsekspertopkald Adgangsmetode . Det giver en eksekveringsplan for datahentningslogik, der kræves til udførelse. Når data er modtaget fra Storage Engine, bliver resultatet offentliggjort i protokollaget. Endelig sendes data til slutbrugeren.

Opbevaringsmotor

Arbejdet med Storage Engine er at gemme data i et lagersystem som Disk eller SAN og hente dataene efter behov. Før vi dybt dykker ned i lagringsmotoren, skal vi se på, hvordan data lagres i databasen og den tilgængelige filtype.

Datafil og omfang:

Datafil gemmer data fysisk i form af datasider, hvor hver dataside har en størrelse på 8 KB og udgør den mindste lagerenhed i SQL Server. Disse datasider er logisk grupperet for at danne omfang. Intet objekt tildeles en side i SQL Server.

Vedligeholdelsen af ​​objektet sker via udstrækninger. Siden har et afsnit kaldet sidehoved med en størrelse på 96 byte, der bærer metadataoplysningerne om siden som sidetype, sidetal, størrelse på brugt plads, størrelse på ledig plads og markør til næste side og forrige side , etc.

Filtyper

  1. Primær fil
  • Hver database indeholder en primær fil.
  • Denne gemmer alle vigtige data relateret til tabeller, visninger, udløsere osv.
  • Udvidelse er. mdf normalt men kan være af enhver udvidelse.
  1. Sekundær fil
  • Databasen indeholder måske eller måske ikke flere sekundære filer.
  • Dette er valgfrit og indeholder brugerspecifikke data.
  • Udvidelse er. ndf normalt men kan være af enhver udvidelse.
  1. Logfil
  • Også kendt som Skriv forud-logfiler.
  • Udvidelse er. ldf
  • Bruges til transaktionsstyring.
  • Dette bruges til at komme sig efter uønskede forekomster. Udfør en vigtig opgave med tilbageførsel til ikke-forpligtede transaktioner.

Storage Engine har 3 komponenter; lad os se nærmere på dem.

Adgangsmetode

Det fungerer som en grænseflade mellem forespørgselseksekutor og Buffer Manager / Transaction Logs.

Selve adgangsmetoden udfører ikke nogen udførelse.

Den første handling er at afgøre, om forespørgslen er:

  1. Vælg erklæring (DDL)
  2. Ikke-vælg erklæring (DDL & DML)

Afhængigt af resultatet tager adgangsmetoden følgende trin:

  1. Hvis forespørgslen er DDL , SELECT-sætning, sendes forespørgslen til Buffer Manager til yderligere behandling.
  2. Og hvis forespørgsel om DDL, NON-SELECT-sætning , sendes forespørgslen til Transaction Manager. Dette inkluderer for det meste UPDATE-erklæringen.

Buffer Manager

Buffer manager administrerer kernefunktioner for nedenstående moduler:

  • Planlæg cache
  • Dataparsering: Buffercache og datalagring
  • Beskidt side

Vi lærer plan-, buffer- og datacache i dette afsnit. Vi vil dække beskidte sider i afsnittet Transaktion.

Planlæg cache

  • Eksisterende forespørgselsplan: Buffertadministratoren kontrollerer, om udførelsesplanen er der i den lagrede Plan Cache. Hvis ja, anvendes forespørgselscache og dens tilknyttede datacache.
  • Første gang Cache-plan: Hvor kommer eksisterende Plan-cache fra?

    Hvis den første gangs udførelsesplan for forespørgsler køres og er kompleks, er det fornuftigt at gemme den i planens cache. Dette vil sikre hurtigere tilgængelighed, når næste gang SQL-server får den samme forespørgsel. Så det er ikke andet end selve forespørgslen, hvilken planudførelse der gemmes, hvis den køres for første gang.

Dataparsering: Buffercache og datalagring

Buffer manager giver adgang til de krævede data. Nedenfor er to tilgange mulige, afhængigt af om der findes data i datacachen eller ej:

Buffercache - blød parsing:

Buffer Manager leder efter data i buffer i datacache. Hvis de er til stede, bruges disse data af Query Executor. Dette forbedrer ydeevnen, da antallet af I / O-operationer reduceres, når data hentes fra cachen sammenlignet med hentning af data fra datalagring.

Datalagring - hård parsing:

Hvis der ikke findes data i Buffer Manager end krævet, søges der data i datalagring. Hvis også gemmer data i datacachen til fremtidig brug.

Beskidt side

Det gemmes som en behandlingslogik fra Transaction Manager. Vi lærer detaljeret i afsnittet Transaction Manager.

Transaktionschef

Transaction Manager påkaldes, når adgangsmetoden bestemmer, at Query er en ikke-Select-sætning.

Log Manager

  • Log Manager holder styr på alle opdateringer, der er foretaget i systemet via logfiler i Transaktionslogfiler.
  • Logs har logs sekvensnummer med transaktions-id og datamodifikationsregistrering .
  • Dette bruges til at holde styr på forpligtet transaktion og tilbageførsel af transaktion .

Låsemanager

  • Under transaktion er de tilknyttede data i datalagring i tilstanden Lås. Denne proces håndteres af Lock Manager.
  • Denne proces sikrer datakonsistens og isolering . Også kendt som ACID-egenskaber.

Udførelsesproces

  • Log Manager starter logning og Lock Manager låser de tilknyttede data.
  • Datakopien vedligeholdes i buffercachen.
  • Kopi af data, der skal opdateres, opretholdes i Logbuffer, og alle begivenheder opdaterer data i Databuffer.
  • Sider, der gemmer dataene, er også kendt som Dirty Pages .
  • Kontrol- og skrivningslogging: Denne proces kører og markerer hele siden fra beskidte sider til disk, men siden forbliver i cachen. Frekvensen er ca. 1 kørsel pr. Minut, men siden skubbes først til datasiden i logfilen fra bufferloggen. Dette er kendt som Write Ahead Logging.
  • Lazy Writer: Den beskidte side kan forblive i hukommelsen. Når SQL-server observerer en enorm belastning, og der er behov for bufferhukommelse til en ny transaktion, frigør den beskidte sider fra cachen. Det fungerer på LRU - Mindst brugt algoritme til rengøring af side fra bufferpool til disk.

Resumé:

  • Der findes tre typer klientserverarkitektur: 1) Delt hukommelse 2) TCP / IP 3) Navngivne rør
  • TDS, udviklet af Sybase og nu ejet af Microsoft, er en pakke, der er indkapslet i netværkspakker til dataoverførsel fra klientmaskinen til servermaskinen.
  • Relational Engine indeholder tre hovedkomponenter:

    CMD Parser: Dette er ansvarlig for syntaktisk og semantisk fejl og genererer endelig et forespørgselstræ.

    Optimizer: Optimizer-rollen er at finde den billigste, ikke den bedste, omkostningseffektive udførelsesplan.

    Forespørgselseksekutør: Forespørgselsekspert kalder adgangsmetode og giver udførelsesplan for datahentningslogik, der kræves til udførelse.

  • Der findes tre typer filer Primær fil, sekundær fil og logfiler.
  • Opbevaringsmotor: Har følgende vigtige komponenter

    Adgangsmetode: Denne komponent Bestem, om forespørgslen er Select eller Non-Select Statement. Påkalder buffer- og overførselsansvarlig i overensstemmelse hermed.

    Buffer Manager: Buffer manager administrerer kernefunktioner til Plan Cache, Data Parsing & Dirty Page.

    Transaction Manager: It manager Non-Select Transaction med hjælp fra Log and Lock Managers. Letter også vigtig implementering af Write Ahead-logning og Lazy forfattere.