SQL Server Architecture (förklarad)

MS SQL Server är en klient-server-arkitektur. MS SQL Server-processen börjar med att klientapplikationen skickar en begäran. SQL-servern accepterar, bearbetar och svarar på begäran med bearbetade data. Låt oss diskutera i detalj hela arkitekturen som visas nedan:

Som diagrammet nedan visar finns det tre huvudkomponenter i SQL Server Architecture:

Protokolllager
Relationsmotor
Förvaringsmotor

Protokolllager – SNI

MS SQL SERVER PROTOCOL LAYER stöder 3 typer av klientserver Architecture. Vi börjar med "Tre typer av klientserver Architecture” som MS SQL Server stöder.

Delat minne

Låt oss ompröva ett samtalsscenario tidigt på morgonen.

MAMMA och TOM – Här befann sig Tom och hans mamma på samma logiska ställe, dvs hemma hos sig. Tom kunde be om kaffe och mamma kunde servera det varmt.

MS SQL SERVER – Här MSSQL server tillhandahåller PROTOKOLL FÖR DELAT MINNE. Här KLIENT och MSSQL servern körs på samma maskin. Båda kan kommunicera via Shared Memory-protokoll.

Analogi: Låter kartlägga enheter i ovanstående två scenarier. Vi kan enkelt mappa Tom till klient, mamma till SQL-server, hem till maskin och verbal kommunikation till delat minnesprotokoll.

Från skrivbordet för konfiguration och installation:

För anslutning till lokal DB – In SQL Management Studio, Alternativet "Servernamn" kan vara

"."

"lokal värd"

"127.0.0.1"

"Maskin\instans"

TCP / IP-

Tänk nu på kvällen, Tom är på festhumör. Han vill ha en kaffe beställd från en välkänd Coffee Shop. Kaféet ligger 10 km från hans hem.

Här är Tom och Starbuck på olika fysiska platser. Tom hemma och Starbucks på den livliga marknadsplatsen. De kommunicerar via mobilnätet. På samma sätt ger MS SQL SERVER möjligheten att interagera via TCP / IP-protokoll, där CLIENT och MS SQL Server är fjärranslutna till varandra och installerade på en separat dator.

Analogi: Låter kartlägga enheter i ovanstående två scenarier. Vi kan enkelt mappa Tom till klient, Starbuck till SQL-server, hem-/marknadsplatsen till fjärrplats och slutligen mobilnät till TCP/IP-protokoll.

Anteckningar från skrivbordet för konfiguration/installation:

I SQL Management Studio – För anslutning via TCP\IP måste alternativet "Servernamn" vara "Maskin\instans av servern."
SQL-servern använder port 1433 i TCP/IP.

Namngivna rör

Nu, äntligen på natten, ville Tom ha ett ljusgrönt te som hennes granne, Sierra förbereder mycket väl.

Här Tom och hans Granne, Sierra, är i samma fysisk plats, att vara varandras granne. De kommunicerar via Intranätverk. På liknande sätt MS SQL SERVER ger möjlighet att interagera via Döpt till Pipe protokoll. Här KUNDEN och MS SQL SERVER är i anslutning via LAN.

Analogi: Låter kartlägga enheter i ovanstående två scenarier. Vi kan enkelt mappa Tom till klient, Sierra till SQL-server, Neighbor till LAN och slutligen intranät till Named Pipe Protocol.

Anteckningar från skrivbordet för konfiguration/installation:

För anslutning via Named Pipe. Det här alternativet är inaktiverat som standard och måste aktiveras av SQL Configuration Manager.

Vad är TDS?

Nu när vi vet att det finns tre typer av klient-server Architecture, låter oss ta en titt på TDS:

TDS står för Tabular Data Stream.
Alla 3 protokoll använder TDS-paket. TDS är inkapslat i nätverkspaket. Detta möjliggör dataöverföring från klientmaskinen till servermaskinen.
TDS utvecklades först av Sybase och ägs nu av Microsoft

Relationsmotor

Relationsmotorn är också känd som frågeprocessorn. Den har SQL Server komponenter som avgör exakt vad en fråga behöver göra och hur den kan göras bäst. Den ansvarar för utförandet av användarförfrågningar genom att begära data från lagringsmotorn och bearbeta resultaten som returneras.

Som avbildas i Archidet finns ett tekniskt diagram 3 huvudkomponenter av relationsmotorn. Låt oss studera komponenterna i detalj:

CMD Parser

När data väl mottagits från Protocol Layer skickas sedan till Relational Engine. "CMD Parser" är den första komponenten i Relational Engine som tar emot frågedata. Den huvudsakliga uppgiften för CMD Parser är att kontrollera frågan för Syntaktiska och semantiska fel. Slutligen, det genererar ett frågeträd. Låt oss diskutera i detalj.

Syntaktisk kontroll:

Precis som alla andra programmeringsspråk har MS SQL också den fördefinierade uppsättningen nyckelord. SQL Server har också sin egen grammatik som SQL Server förstår.
SELECT, INSERT, UPDATE och många andra tillhör MS SQL fördefinierade nyckelordslistor.
CMD Parser gör syntaktisk kontroll. Om användarnas inmatning inte följer dessa språksyntax eller grammatikregler, är det returnerar ett fel.

Exempelvis: Låt oss säga att en ryss gick till en japansk restaurang. Han beställer snabbmat på ryska språket. Tyvärr förstår servitören bara japanska. Vilket skulle vara det mest uppenbara resultatet?

Svaret är - servitören kan inte behandla beställningen ytterligare.

Det bör inte finnas någon avvikelse i grammatik eller språk som SQL-servern accepterar. Om det finns kan SQL-servern inte bearbeta det och kommer därför att returnera ett felmeddelande.

Vi kommer att lära oss mer om MS SQL-frågan i kommande handledningar. Ändå, överväg nedan den mest grundläggande frågesyntaxen som

SELECT * from <TABLE_NAME>;

För att få en uppfattning om vad syntaktisk gör, säg om användaren kör den grundläggande frågan enligt nedan:

SELECR * from <TABLE_NAME>

Observera att i stället för "SELECT" skrev användaren "SELECR."

Resultat: CMD Parser kommer att analysera detta uttalande och skickar felmeddelandet. Eftersom "SELECR" inte följer det fördefinierade nyckelordets namn och grammatik. Här väntade CMD Parser "SELECT."

Semantisk kontroll:

Detta utförs av normaliserare.
I sin enklaste form kontrollerar den om kolumnnamn, tabellnamn som efterfrågas finns i Schema. Och om den finns, bind den till Query. Detta är också känt som Bindning.
Komplexiteten ökar när användarfrågor innehåller VIEW. Normalizer utför ersättningen med den internt lagrade vydefinitionen och mycket mer.

Låt oss förstå detta med hjälp av exemplet nedan -

SELECT * from USER_ID

Resultat: CMD Parser kommer att analysera detta uttalande för semantisk kontroll. Parsern kommer att skicka ett felmeddelande eftersom Normalizer inte hittar den begärda tabellen (USER_ID) eftersom den inte finns.

Skapa frågeträd:

Detta steg genererar ett annat exekveringsträd där frågan kan köras.
Observera att alla olika träd har samma önskade resultat.

Optimizer

Optimerarens arbete är att skapa en exekveringsplan för användarens fråga. Detta är planen som kommer att avgöra hur användarfrågan kommer att exekveras.

Observera att inte alla frågor är optimerade. Optimering görs för DML-kommandon (Data Modification Language) som SELECT, INSERT, DELETE och UPDATE. Sådana frågor markeras först och skickas sedan till optimeraren. DDL-kommandon som CREATE och ALTER är inte optimerade, utan de kompileras istället till en intern form. Frågekostnaden beräknas baserat på faktorer som CPU-användning, minnesanvändning och input/output-behov.

Optimizers roll är att hitta billigaste, inte den bästa, kostnadseffektiva genomförandeplanen.

Innan vi går in på mer tekniska detaljer om Optimizer, överväg nedanstående exempel från verkligheten:

Exempelvis:

Låt oss säga att du vill öppna ett bankkonto online. Du känner redan till en bank som tar högst 2 dagar att öppna ett konto. Men du har också en lista med 20 andra banker, som kan ta mindre än 2 dagar eller inte. Du kan börja kontakta dessa banker för att avgöra vilka banker som tar mindre än två dagar. Nu kanske du inte hittar en bank som tar mindre än 2 dagar, och det går förlorad ytterligare tid på grund av själva sökaktiviteten. Det hade varit bättre att öppna ett konto hos den första banken själv.

Slutsats: Det är viktigare att välja klokt. För att vara exakt, välj vilken alternativet är bäst, inte det billigaste.

På liknande sätt har MS SQL Optimizer fungerar på inbyggda uttömmande/heuristiska algoritmer. Målet är att minimera söktiden. Alla Optimizer-algoritmer är anständigheten av Microsoft och en hemlighet. Även, nedan är stegen på hög nivå som utförs av MS SQL Optimizer. Sökningar av optimering följer tre faser som visas i diagrammet nedan:

Fas 0: Sök efter trivial plan:

Detta är också känt som Föroptimeringsstadiet.
I vissa fall kan det bara finnas en praktisk, genomförbar plan, känd som en trivial plan. Det finns inget behov av att skapa en optimerad plan. Anledningen är att sökningar mer skulle resultera i att hitta samma körtidsplan. Det också med den extra kostnaden för att söka efter optimerad plan som inte alls krävdes.
Om ingen trivial plan hittas, då 1^st Fasen startar.

Fas 1: Sök efter transaktionshanteringsplaner

Detta inkluderar sökningen efter Enkel och komplex plan.
Enkel plansökning: Tidigare data för kolumn och index som är involverade i fråga kommer att användas för statistisk analys. Detta består vanligtvis men inte begränsat till ett index per tabell.
Ändå, om den enkla planen inte hittas, söks mer komplex plan. Det innebär flera index per tabell.

Fas 2: Parallell bearbetning och optimering.

Om ingen av ovanstående strategier fungerar, söker Optimizer efter möjligheter för parallell bearbetning. Detta beror på maskinens bearbetningsmöjligheter och konfiguration.
Om det fortfarande inte är möjligt startar den sista optimeringsfasen. Nu är det slutliga optimeringsmålet att hitta alla andra möjliga alternativ för att utföra frågan på bästa sätt. Slutlig optimeringsfas Algorithms är Microsoft Anständighet.

Frågeexekutor

Fråga executer anrop Åtkomstmetod. Den tillhandahåller en exekveringsplan för datahämtningslogik som krävs för exekvering. När data väl har tagits emot från Storage Engine publiceras resultatet till protokolllagret. Slutligen skickas data till slutanvändaren.

Förvaringsmotor

Storage Engines arbete är att lagra data i ett lagringssystem som Disk eller SAN och hämta data när det behövs. Innan vi djupdyker in i Storage-motorn, låt oss ta en titt på hur data lagras i Databas och typ av tillgängliga filer.

Datafil och omfattning:

Datafil, lagrar fysiskt data i form av datasidor, där varje datasida har en storlek på 8KB, vilket utgör den minsta lagringsenheten i SQL Server. Dessa datasidor är logiskt grupperade för att bilda omfattningar. Inget objekt tilldelas en sida i SQL Server.

Underhållet av objektet sker via omfattningar. Sidan har en sektion som kallas sidhuvudet med en storlek på 96 byte, som bär metadatainformationen om sidan som sidtyp, sidnummer, storlek på använt utrymme, storlek på ledigt utrymme och pekare till nästa sida och föregående sida , etc.

filtyper

Primär fil

Varje databas innehåller en primär fil.
Detta lagrar all viktig data relaterad till tabeller, vyer, utlösare, etc.
Förlängning är .MDF vanligtvis men kan ha vilken förlängning som helst.

Sekundär fil

Databasen kan innehålla flera sekundära filer eller inte.
Detta är valfritt och innehåller användarspecifika data.
Förlängning är .NDF vanligtvis men kan ha vilken förlängning som helst.

Loggfil

Även känd som Write ahead-loggar.
Förlängning är .LDF
Används för transaktionshantering.
Detta används för att återställa från alla oönskade instanser. Utför viktig uppgift att återställa till icke-engagerade transaktioner.

Storage Engine har 3 komponenter; låt oss titta närmare på dem.

Åtkomstmetod

Det fungerar som ett gränssnitt mellan query executor och Buffer Manager/Transaktionsloggar.

Åtkomstmetoden i sig gör ingen exekvering.

Den första åtgärden är att avgöra om frågan är:

Välj uttalande (DDL)
Non-Select Statement (DDL & DML)

Beroende på resultatet tar åtkomstmetoden följande steg:

Om frågan är DDL, SELECT-satsen, skickas frågan till Buffer chef för vidare bearbetning.
Och om fråga om DDL, NON-SELECT-sats, skickas frågan till Transaction Manager. Detta inkluderar oftast UPDATE-satsen.

Buffer chef

Buffer manager hanterar kärnfunktioner för modulerna nedan:

Planera cache
Dataanalys: Buffer cache & datalagring
Smutsig sida

Vi kommer att lära oss Plan, Buffer och Datacache i det här avsnittet. Vi kommer att täcka smutsiga sidor i avsnittet Transaktioner.

Planera cache

Befintlig frågeplan: Bufferthanteraren kontrollerar om exekveringsplanen finns i den lagrade plancachen. Om Ja, används frågeplanscache och dess associerade datacache.
Första gången cacheplan: Var kommer befintlig Plan-cache ifrån? Om planen för förstagångsförfrågningskörning körs och är komplex, är det vettigt att lagra den i Plane-cachen. Detta kommer att säkerställa snabbare tillgänglighet nästa gång SQL-servern får samma fråga. Så det är inget annat än själva frågan vilken Plan-exekvering som lagras om den körs för första gången.

Dataanalys: Buffer cache och datalagring

Buffer manager ger tillgång till de uppgifter som krävs. Nedan två metoder är möjliga beroende på om data finns i datacachen eller inte:

Buffer Cache – Soft Parsing:

Buffer Manager letar efter Data i Buffer i datacache. Om sådan finns används denna data av Query Executor. Detta förbättrar prestandan eftersom antalet I/O-operationer minskas vid hämtning av data från cachen jämfört med hämtning av data från datalagring.

Datalagring – hård analys:

Om data inte finns i Buffer Manager än krävs Data söks i datalagring. If lagrar även data i datacchen för framtida användning.

Smutsig sida

Den lagras som en bearbetningslogik för Transaction Manager. Vi kommer att lära oss i detalj i avsnittet Transaction Manager.

Transaktionsansvarig

Transaktionshanteraren anropas när åtkomstmetoden bestämmer att Query är en Non-Select-sats.

Logghanterare

Log Manager håller reda på alla uppdateringar som görs i systemet via loggar i Transaktionsloggar.
Loggar har Loggar sekvensnummer med transaktions-ID och dataändringspost.
Detta används för att hålla reda på Transaktion begången och återställning av transaktion.

Låshanterare

Under transaktionen är tillhörande data i datalagring i låst tillstånd. Denna process hanteras av Lock Manager.
Denna process säkerställer datakonsistens och isolering. Även känd som ACID-egenskaper.

Utförandeprocess

Log Manager börjar logga och Lock Manager låser tillhörande data.
Datas kopia bevaras i Buffer cache.
Kopia av data som ska uppdateras bevaras i loggbuffert och alla händelser uppdaterar data i databuffert.
Sidor som lagrar data kallas också Smutsiga sidor.
Checkpoint och Write-Ahead-loggning: Denna process körs och markerar hela sidan från Dirty Pages till Disk, men sidan finns kvar i cachen. Frekvensen är cirka 1 körning per minut. Men sidan skjuts först till Datasidan för loggfilen från Buffer logga. Detta är känt som Skriv framåt loggning.
Lat författare: Den smutsiga sidan kan finnas kvar i minnet. När SQL-servern observerar en enorm belastning och Buffer minne behövs för en ny transaktion, det frigör Dirty Pages från cachen. Den verkar på LRU – Senast använda algoritm för att rensa sida från buffertpool till disk.

Sammanfattning

Tre typer av klientserver ArchiTecture existerar: 1) Delat minne 2) TCP/IP 3) Namngivna rör
TDS, utvecklat av Sybase och nu ägt av Microsoft, är ett paket som är inkapslat i nätverkspaket för dataöverföring från klientmaskinen till servermaskinen.
Relationsmotorn innehåller tre huvudkomponenter:CMD Parser: Detta är ansvarigt för syntaktiska och semantiska fel och genererar slutligen ett frågeträd.Optimerare: Optimerarens roll är att hitta den billigaste, inte den bästa, kostnadseffektiva genomförandeplanen.
Frågeexekutor: Query executer anropar Access Method och tillhandahåller exekveringsplan för datahämtningslogik som krävs för exekvering.
Det finns tre typer av filer Primär fil, Sekundär fil och Loggfiler.
Lagringsmotor: Har följande viktiga komponenterÅtkomstmetod: Den här komponenten Bestäm om frågan är Select eller Non-Select Statement. Åberopar Buffer och Transfer Manager i enlighet därmed.Buffer Manager: Buffer manager hanterar kärnfunktioner för Plan Cache, Data Parsing & Dirty Page.
Transaktionshanterare: It manager Non-Select Transaction med hjälp av logg- och låshanterare. Underlättar också viktig implementering av Write Ahead-loggning och Lazy writers.