SQL Server Architecture (selitys)

MS SQL Server on asiakas-palvelin-arkkitehtuuri. MS SQL Server -prosessi alkaa asiakassovelluksen lähettämällä pyynnöllä. SQL Server hyväksyy, käsittelee ja vastaa pyyntöön käsitellyillä tiedoilla. Käydään läpi koko arkkitehtuuri yksityiskohtaisesti alla:

Kuten alla oleva kaavio osoittaa, SQL Serverissä on kolme pääkomponenttia Archirakenne:

1. Protokollakerros
2. Relaatiomoottori
3. Varastointi Moottori

Protokollakerros – SNI

SQL Serverin protokollakerros, joka tunnetaan myös nimellä Server Network Interface (SNI), tukee kolmenlaisia ​​asiakas-palvelin-arkkitehtuureja. Jokainen protokolla palvelee erilaista verkkoskenaariota. Näiden protokollien ymmärtäminen on olennaista ennen kuin tutkitaan, miten kyselyitä käsitellään sisäisesti.

Jaettu muisti

Tarkastellaan aamuvarhaisen keskustelun tilannetta. Tom ja hänen äitinsä ovat samassa loogisessa paikassa, kotonaan. Tom pyytää kahvia ja äiti tarjoilee sen suoraan. Samoin SQL Server tarjoaa jaetun muistin protokollan, kun asiakas ja palvelin toimivat samalla koneella. Molemmat kommunikoivat jaetun muistin kautta ilman verkon lisäkuormitusta.

Analogia: Tom yhdistää asiakkaan (Client), äiti (Mom) SQL Serverin, koti (Home) koneen (Machine) ja verbaalinen kommunikaatio jaetun muistin protokollaan.

Kokoonpanohuomautuksia: In SQL Management Studiopaikallisen yhteyden ”Palvelimen nimi” -vaihtoehto voi olla ”.”, ”localhost”, ”127.0.0.1” tai ”Kone\Instanssi”.

TCP / IP

Oletetaan nyt, että Tom haluaa kahvia kaupasta, joka sijaitsee 10 km päässä. Tom on kotona ja kahvila on vilkkaalla torilla. He kommunikoivat matkapuhelinverkon kautta. Samoin SQL Server tarjoaa TCP / IP-protokolla kun asiakas ja SQL Server ovat eri koneilla, jotka ovat yhteydessä toisiinsa verkon kautta.

Analogia: Tom yhdistetään asiakkaaseen, kahvila SQL Serveriin, koti ja markkinapaikka etäsijainteihin ja matkapuhelinverkko TCP/IP-protokollaan.

Kokoonpanohuomautuksia: SQL Management Studiossa TCP/IP-yhteyden ”Palvelimen nimi” -vaihtoehdon on oltava ”Palvelimen kone\instanssi”. SQL Server käyttää TCP/IP-yhteyksille oletusarvoisesti porttia 1433.

Nimetyt putket

Lopuksi Tom haluaa vihreää teetä naapuriltaan Sierralta. He ovat samassa fyysisessä paikassa, naapureita, ja kommunikoivat sisäisen verkon kautta. Samoin SQL Server tarjoaa Named Pipe -protokollan, kun asiakas ja palvelin ovat yhteydessä toisiinsa lähiverkon (LAN) kautta.

Analogia: Tom kartoittaa asiakkaaseen, Sierra kartoittaa SQL Serveriin, naapurit kartoittavat lähiverkkoon ja verkon sisäinen kartoittaa nimetyn putken protokollaan.

Kokoonpanohuomautuksia: Nimetyt putket ovat oletusarvoisesti poissa käytöstä, ja ne on otettava käyttöön SQL Configuration Managerin kautta.

Mikä on TDS?

Nyt kun kolme asiakas-palvelinarkkitehtuurityyppiä ovat selvät, tässä katsaus TDS:ään:

• TDS on lyhenne sanoista Tabular Data Stream.
• Kaikki kolme protokollaa käyttävät TDS-paketteja.
• TDS on kapseloitu verkkopaketteihin, mikä mahdollistaa tiedonsiirron asiakaskoneelta palvelinkoneelle.
• TDS:n kehitti alun perin Sybase, ja sen omistaa nyt Microsoft.

Seuraavassa taulukossa vertaillaan kolmea SQL Server -yhteysprotokollaa:

Ominaisuus	Jaettu muisti	TCP / IP	Nimetyt putket
Verkon laajuus	Sama kone	Etäkäyttö (WAN/Internet)	Vain lähiverkko
Oletusportti	N / A	1433	445
Suorituskyky	Nopein (ei verkon ylikuormitusta)	Hyvä (optimoitu WAN-verkkoon)	Hyvä (optimoitu lähiverkolle)
Oletusarvoisesti käytössä	Kyllä	Kyllä	Ei
Paras käyttökotelo	Paikallinen kehitys ja testaus	Tuotannon etäkäyttö	Luotettavat lähiverkkoympäristöt

Koska protokollakerros käsittelee verkkoliikennettä, seuraava vaihe SQL Server -arkkitehtuurissa on itse kyselyn käsittely. Tässä kohtaa relaatiomoottori ottaa ohjat käsiinsä.

Relaatiomoottori

Relaatiomoottori tunnetaan myös kyselyprosessorina. Se sisältää SQL Server -komponentit, jotka määrittävät, mitä kyselyn on tehtävä ja miten se voidaan suorittaa tehokkaimmin. Se vastaa käyttäjien kyselyiden suorittamisesta pyytämällä tietoja tallennusmoottorilta ja käsittelemällä palautetut tulokset.

Kuten arkkitehtuurikaaviossa on esitetty, relaatiomoottorissa on kolme pääkomponenttia:

CMD jäsentäjä

Protokollakerrokselta vastaanotettu data välitetään relaatiomoottorille. CMD-jäsennin on ensimmäinen komponentti, joka vastaanottaa kyselydatan. Sen päätehtävänä on tarkistaa kysely syntaktisten ja semanttisten virheiden varalta ja luoda sitten kyselypuu.

Syntaktinen tarkistus: Kuten kaikilla muillakin ohjelmointikielillä, SQL Serverillä on ennalta määritetty joukko avainsanoja ja kielioppisääntöjä. SELECT, INSERT, UPDATE ja monet muut kuuluvat ennalta määritettyyn avainsanaluetteloon. CMD-jäsennin varmistaa, että syöte noudattaa näitä sääntöjä. Jos käyttäjän syöte poikkeaa odotetusta syntaksista, jäsennin palauttaa virheen.

Esimerkiksi: Kuvitellaan venäläinen, joka kävelee japanilaiseen ravintolaan ja tilaa ruokaa venäjäksi. Tarjoilija ymmärtää vain japania eikä pysty käsittelemään tilausta. Vastaavasti, jos käyttäjä kirjoittaa ”SELECR” ”SELECT”:n sijaan, CMD-jäsennin palauttaa virheen, koska se ei tunnista avainsanaa.

Semanttinen tarkistus: Normalisoija suorittaa tämän. Se tarkistaa, ovatko kyselyn kohteena olevat sarakenimet, taulukoiden nimet ja muut objektit todella olemassa kaavassa. Jos ne ovat olemassa, normalisoija sitoo ne kyselyyn. Tätä prosessia kutsutaan myös sidonnaksi. Kun käyttäjän kyselyt sisältävät VIEW-näkymän, normalisoija korvaa sen sisäisesti tallennetulla näkymämäärityksellä.

Esimerkiksi: Running SELECT * from USER_ID aiheuttaisi jäsentimen heittävän virheen semanttisen tarkistuksen aikana, jos taulukkoa USER_ID ei ole tietokannassa.

Luo kyselypuu: Tässä vaiheessa luodaan erilaisia ​​suorituspuita, jotka edustavat kyselyn eri suoritustapoja. Kaikki puut tuottavat saman halutun tulosteen.

Optimizer

Optimoija luo käyttäjän kyselylle suoritussuunnitelman. Tämä suunnitelma määrittää, miten kysely suoritetaan. Kaikkia kyselyitä ei ole optimoitu. Optimointi koskee DML (Data Modification Language) -komentoja, kuten SELECT, INSERT, DELETE ja UPDATE. DDL-komentoja, kuten CREATE ja ALTER, ei ole optimoitu, vaan ne käännetään sisäiseen lomakkeeseen.

Kyselyn hinta lasketaan tekijöiden, kuten suorittimen käytön, muistin käytön ja syöte-/tulostustarpeiden, perusteella. Optimoijan tehtävänä on löytää halvin ja kustannustehokkain suoritussuunnitelma, ei välttämättä ehdottomasti paras.

Esimerkiksi: Kuvittele, että haluat avata verkkopankkitilin. Yhden pankin kysely kestää korkeintaan kaksi päivää. Sinulla on myös lista 20 muusta pankista, joiden kyselyn suorittaminen voi kestää lyhyemmän ajan. Kaikkien 20 pankin läpi hakeminen ei välttämättä tarjoa nopeampaa vaihtoehtoa, ja itse haku vie aikaa. Olisi ollut parempi valita ensimmäinen pankki. Samoin SQL-optimoija käyttää kattavia ja heuristisia algoritmeja kyselyn suoritusajan minimoimiseksi.

Optimoija etsii kolmessa vaiheessa:

Vaihe 0: Triviaalin suunnitelman etsintä

Tämä on optimointia edeltävä vaihe. Joillekin kyselyille on olemassa vain yksi käytännöllinen suunnitelma, joka tunnetaan triviaalisuunnitelmana. Lisähakuja ei tarvitse tehdä, koska mikä tahansa lisähaku löytäisi saman suoritussuunnitelman lisäkustannuksilla.

Vaihe 1: Transaktioiden käsittelysuunnitelmien etsiminen

Tämä sisältää sekä yksinkertaisten että monimutkaisten suunnitelmien haun. Yksinkertaisen suunnitelman haku käyttää sarake- ja indeksitietojen tilastollista analyysia, ja se on tyypillisesti rajoitettu yhteen indeksiin taulukkoa kohden. Jos yksinkertaista suunnitelmaa ei löydy, suoritetaan monimutkaisempi haku, johon sisältyy useita indeksejä taulukkoa kohden.

Vaihe 2: Rinnakkaiskäsittely ja optimointi

Jos edelliset strategiat eivät tuota riittävää suunnitelmaa, optimoija etsii rinnakkaiskäsittelymahdollisuuksia koneen käsittelyominaisuuksien perusteella. Jos rinnakkaiskäsittely ei ole mahdollista, alkaa viimeinen optimointivaihe, jossa käytetään kaikkia jäljellä olevia vaihtoehtoja parhaan mahdollisen suoritussuunnitelman löytämiseksi.

Kyselyn suorittaja

Kyselyiden suorittaja kutsuu tallennusmoottorin Access Methodia. Se tarjoaa suoritussuunnitelman, joka sisältää suorittamiseen tarvittavan tiedonhakulogiikan. Kun tiedot on vastaanotettu tallennusmoottorista, tulos julkaistaan ​​protokollakerrokselle ja lähetetään loppukäyttäjälle.

Kun relaatiomoottori on määrittänyt kyselyn suoritustavan, tallennusmoottori käsittelee fyysiset dataoperaatiot. Tämä kerros hallinnoi, miten tiedot tallennetaan, tallennetaan välimuistiin ja noudetaan levyltä.

Varastointi Moottori

Tallennusmoottori vastaa datan tallentamisesta tallennusjärjestelmään, kuten levylle tai SAN-järjestelmään, ja sen hakemisesta tarvittaessa. Ennen tallennusmoottorin komponenttien tarkastelua on tärkeää ymmärtää, miten data fyysisesti tallennetaan.

Tiedostot ja niiden laajuus

Datatiedostot tallentavat tiedot fyysisesti datasivujen muodossa, joiden jokaisen sivun koko on 8 kt. Tämä on pienin tallennusyksikkö tiedostoissa. SQL ServerTietosivut on loogisesti ryhmitelty laajennuksiin (extents). Yhdellekään objektille ei ole suoraan määritetty yksittäistä sivua; sen sijaan ylläpito tehdään laajennusten kautta. Jokaisella sivulla on sivun otsikko (96 tavua), joka sisältää metatietoja, kuten sivutyypin, sivunumeron, käytetyn tilan, vapaan tilan sekä osoittimet seuraavalle ja edelliselle sivulle.

tiedostotyypit

Ensisijainen tiedosto: Jokaisessa tietokannassa on yksi päätiedosto. Se tallentaa kaikki tärkeät tiedot, jotka liittyvät taulukoihin, näkymiin, triggereihin ja muihin objekteihin. Tiedostopääte on tyypillisesti .mdf, mutta se voi olla mikä tahansa tiedostopääte.

Toissijainen tiedosto: Tietokanta voi sisältää useita toissijaisia ​​tiedostoja tai olla sisältämättä niitä. Nämä ovat valinnaisia ​​ja sisältävät käyttäjäkohtaisia ​​tietoja. Tiedostopääte on tyypillisesti .ndf, mutta se voi olla mikä tahansa tiedostopääte.

Lokitiedosto: Tunnetaan myös nimellä Write-Ahead Logs. Tiedostopääte on .ldf. Lokitiedostoja käytetään tapahtumien hallintaan, ei-toivotuista instansseista palautumiseen ja vahvistamattomien tapahtumien peruutukseen.

Tallennusmoottorissa on kolme pääkomponenttia. Jokaisella on oma roolinsa tiedonsaannin ja eheyden hallinnassa.

Käyttömenetelmä

Access Method toimii rajapintana kyselyn suorittajan ja Buffer Manager tai tapahtumalokit. Se ei itse suorita kyselyä, mutta määrittää sen tyypin:

• Jos kysely on SELECT-lauseke (DML), se välitetään Buffer Jatkokäsittelyn päällikkö.
• Jos kysely on Ei-SELECT-lauseke (DDL ja DML), se välitetään tapahtumien hallinnalle. Tämä sisältää enimmäkseen UPDATE-, INSERT- ja DELETE-lausekkeita.

Buffer Johtaja

Buffer Manager hallitsee ydintoimintoja, kuten suunnitelmavälimuistia, tietojen jäsennystä ja virheellisten sivujen käsittelyä.

Suunnitelman välimuisti

Nykyinen kyselysuunnitelma: Buffer Hallinta tarkistaa, onko suoritussuunnitelma tallennetussa suunnitelmavälimuistissa. Jos on, välimuistissa olevaa kyselysuunnitelmaa ja siihen liittyvää datavälimuistia käytetään suoraan.

Ensimmäisen käyttökerran välimuistisuunnitelma: Jos ensimmäisen kyselyn suoritussuunnitelma on monimutkainen, se tallennetaan suunnitelman välimuistiin. Tämä varmistaa nopeamman saatavuuden, kun SQL Server vastaanottaa saman kyselyn seuraavan kerran.

Tietojen jäsentäminen: Buffer Välimuisti ja datan tallennus

Buffer Pääkäyttäjä tarjoaa pääsyn tarvittaviin tietoihin. Kaksi mahdollista lähestymistapaa riippuen siitä, onko välimuistissa tietoja:

Buffer Välimuisti – pehmeä jäsennys

Buffer Johtaja etsii tietoja Buffer Välimuisti. Jos tiedot ovat olemassa, kyselyn suorittaja käyttää niitä suoraan. Tämä parantaa suorituskykyä, koska tietojen hakeminen välimuistista vaatii vähemmän I/O-toimintoja verrattuna tiedon hakemiseen levyltä.

Tietojen tallennus – kova jäsentäminen

Jos tietoja ei ole kohdassa Buffer Välimuisti, tarvittavat tiedot haetaan levyllä olevasta tallennustilasta. Tiedot tallennetaan sitten myös välimuistiin myöhempää käyttöä varten.

Tapahtuman johtaja

Transaktionhallintaa kutsutaan, kun käyttötapa määrittää, että kysely ei ole SELECT-lauseke. Se varmistaa datan yhtenäisyyden ja kestävyyden useiden alikomponenttien avulla:

Lokien hallinta

Lokinhallinta pitää track kaikista järjestelmässä suoritetuista päivityksistä tapahtumalokeihin tallennettujen lokien kautta. Jokainen lokimerkintä sisältää lokin järjestysnumeron sekä tapahtumatunnuksen ja tietojen muokkaustietueen. Tämä mekanismi tracks vahvistettuja ja peruutettuja tapahtumia.

Lukon hallinta

Transaktion aikana tallennustilassa olevat tiedot siirtyvät lukittuun tilaan. Lukituksenhallinta käsittelee tätä prosessia varmistaen tietojen yhtenäisyyden ja eristäytymisen. Näitä ominaisuuksia kutsutaan myös nimellä ACID (Atomjääisyys, johdonmukaisuus, eristys, kestävyys).

Toteutusprosessi

Toteutusprosessi seuraa seuraavia vaiheita:

1. Lokinhallinta aloittaa lokin kirjaamisen ja Lukinhallinta lukitsee siihen liittyvät tiedot.
2. Tiedoista säilytetään kopio Buffer Välimuisti.
3. Päivitettävien tietojen kopio säilytetään lokissa. Buffer, ja kaikki tapahtumat päivittävät tiedot Data-osiossa Buffer.
4. Sivut, jotka tallentavat muokattua tietoa, tunnetaan nimellä Likaiset sivut.

Tarkistuspisteiden ja ennakkoon kirjoitettavien lokien tallennus

Tarkistuspisteprosessi suoritetaan noin kerran minuutissa ja merkitsee kaikki likaiset sivut levylle kirjoitettavaksi. Sivu kuitenkin lähetetään ensin lokitiedoston datasivulle Buffer Loki. Tätä mekanismia kutsutaan ennakkokirjaukseksi. Likaiset sivut pysyvät välimuistissa, vaikka ne olisi kirjoitettu levylle.

laiska Writer

Kun SQL Server havaitsee suuren kuormituksen ja uusille tapahtumille tarvitaan puskurimuistia, se vapauttaa likaiset sivut välimuistista. Lazy Writer toimii LRU (Least Recently Used) -algoritmilla puhdistaakseen sivuja puskurialtaasta levylle.

Kuinka SQL Server käsittelee kyselyn päästä päähän

Kunkin kerroksen ymmärtäminen erikseen on arvokasta, mutta kokonaiskuvan selventäminen tapahtuu, kun tarkastellaan niiden yhteistoimintaa. Kun asiakassovellus lähettää SQL-kyselyn, tapahtuu seuraava sarja:

Protokollakerros vastaanottaa pyynnön jaetun muistin, TCP/IP:n tai nimettyjen putkien kautta ja käärii sen TDS-pakettiin. Relaatiomoottori sitten ottaa ohjat: CMD-jäsennin tarkistaa syntaksin ja semantiikan, optimoija luo halvimman suoritussuunnitelman ja kyselyn suorittaja aloittaa tiedonhaun.

Kyselyn suorittaja kutsuu Tallennusmoottorin Käyttötapa, joka reitittää SELECT-kyselyt Buffer Manager ja muokkauskyselyt Transaction Managerille. Buffer Esimies tarkistaa suunnitelmavälimuistin ja Buffer Välimuisti ensin (pehmeä jäsennys). Jos tietoja ei ole välimuistissa, se suorittaa levyn lukemisen (kova jäsennys). Kirjoitustoimintoja varten tapahtumienhallinta koordinoi lokinhallintaa, lukitusnhallintaa ja tarkistuspisteprosessia varmistaakseen ACID-yhteensopivuuden.

Kun tallennusmoduuli palauttaa pyydetyt tiedot, relaatiomoduuli muotoilee tulosjoukon ja protokollakerros toimittaa sen takaisin asiakassovellukselle saman TDS-protokollan kautta.

Kuinka valita oikea protokolla SQL Server -yhteyksille

Oikean protokollan valinta riippuu asiakkaan ja palvelimen välisestä fyysisestä suhteesta sekä suorituskykyvaatimuksista.

Käytä jaettua muistia kun asiakassovellus toimii samassa koneessa kuin SQL Server. Tämä on nopein vaihtoehto, koska se poistaa kaiken verkon ylimääräisen kuormituksen. Se sopii erinomaisesti paikalliseen kehitykseen, testaukseen ja yhden koneen käyttöönottoihin.

Käytä TCP/IP-protokollaa kun asiakas ja palvelin ovat eri koneilla, jotka on yhdistetty WAN-verkon tai internetin kautta. Tämä on yleisimmin käytetty protokolla tuotantoympäristöissä. SQL Server kuuntelee oletusarvoisesti porttia 1433, ja tämä protokolla tukee salattuja yhteyksiä TLS:n kautta.

Käytä nimettyjä putkia kun asiakas ja palvelin ovat samassa luotettavassa lähiverkossa ja suorituskyky sisäisissä verkoissa on etusijalla. Nimetyt putket ovat oletusarvoisesti poissa käytöstä ja ne on otettava käyttöön SQL Server Configuration Managerin kautta. Se on harvinaisempi nykyaikaisissa käyttöönotoissa, mutta on edelleen hyödyllinen vanhoissa intranet-sovelluksissa.

UKK