SQL Server -arkkitehtuuri selitetty: Nimetyt putket, optimoija, puskurin hallinta

Sisällysluettelo:

Anonim

MS SQL Server on asiakas-palvelinarkkitehtuuri. MS SQL Server -prosessi alkaa asiakassovelluksesta, joka lähettää pyynnön. SQL Server hyväksyy, käsittelee ja vastaa pyyntöön käsitellyillä tiedoilla. Keskustellaan yksityiskohtaisesti koko alla esitetystä arkkitehtuurista:

Kuten alla oleva kaavio kuvaa, SQL Server -arkkitehtuurissa on kolme pääkomponenttia:

  1. Protokollakerros
  2. Suhteellinen moottori
  3. Varastointi Moottori
SQL Server -arkkitehtuurikaavio

Keskustellaan yksityiskohtaisesti kaikista kolmesta yllä olevasta päämoduulista. Tässä opetusohjelmassa opit.

  • Protokollakerros - SNI
    • Jaettu muisti
    • TCP / IP
    • Nimetty putki
    • Mikä on TDS?
  • Suhteellinen moottori
    • CMD-jäsennin
    • Optimoija
    • Kyselyn toteuttaja
  • Varastointi Moottori
    • Tiedostotyypit
    • Käyttömenetelmä
    • Puskuripäällikkö
    • Suunnittele välimuisti
    • Tietojen jäsentäminen: Puskurin välimuisti ja tietojen tallennus
    • Transaction Manager

Protokollakerros - SNI

MS SQL Server -protokollakerros tukee 3-tyyppistä asiakaspalvelinarkkitehtuuria. Aloitamme " Three Type of Client Server Architecture" -työkalulla, jota MS SQL Server tukee.

Jaettu muisti

Tarkastellaan uudelleen aikaisin aamulla käydyn keskustelun skenaariota.

ÄITI ja TOM - Täällä Tom ja hänen äitinsä olivat samassa loogisessa paikassa eli kotonaan. Tom pystyi pyytämään kahvia ja äiti pystyi tarjoilemaan sitä kuumana.

MS SQL SERVER - Tässä MS SQL -palvelin tarjoaa JAETUN MUISTIPROTOKOLLIN . Tässä ASIAKAS ja MS SQL- palvelin toimivat samalla koneella. Molemmat voivat kommunikoida jaetun muistin protokollan kautta.

Analogia: Antaa karttakokonaisuuden kahdessa yllä olevassa skenaariossa. Voimme helposti yhdistää Tomin asiakkaalle, äidin SQL-palvelimelle, kodin koneelle ja sanallisen viestinnän jaetun muistin protokollalle.

Kokoonpanon ja asennuksen työpöydältä:

Yhteys paikalliseen tietokantaan - SQL Management Studiossa "Palvelimen nimi" -vaihtoehto voi olla

"."

"paikallinen isäntä"

"127.0.0.1"

"Machine \ instance"

TCP / IP

Harkitse nyt illalla, Tom on juhlatunnelmassa. Hän haluaa kahvin, joka on tilattu tunnetusta kahvilasta. Kahvila sijaitsee 10 km: n päässä hänen kodistaan.

Täällä Tom ja Starbuck ovat eri fyysisessä paikassa. Tom kotona ja Starbucks vilkkaalla torilla. He kommunikoivat matkapuhelinverkon kautta. Vastaavasti MS SQL SERVER tarjoaa mahdollisuuden olla vuorovaikutuksessa TCP / IP-protokollan kautta, jolloin ASIAKAS ja MS SQL Server ovat etäällä toisistaan ​​ja asennettuna erilliseen koneeseen.

Analogia: Antaa karttakokonaisuuden kahdessa yllä olevassa skenaariossa. Voimme helposti yhdistää Tomin asiakkaaseen, Starbuckin SQL-palvelimeen, Koti / kauppapaikka etäsijaintiin ja lopuksi matkapuhelinverkon TCP / IP-protokollaan.

Huomautuksia kokoonpanon / asennuksen työpöydältä:

  • SQL Management Studiossa - TCP \ IP-yhteyden kautta tapahtuvaa yhteyttä varten "Palvelimen nimi" -vaihtoehdon on oltava "Palvelimen kone \ ilmentymä".
  • SQL-palvelin käyttää porttia 1433 TCP / IP: ssä.

Nimetty putki

Nyt vihdoin illalla, Tom halusi saada vaalean vihreää teetä, jonka hänen naapurinsa, Sierra, valmisti erittäin hyvin.

Täällä Tom ja hänen naapurinsa , Sierra, ovat samassa fyysisessä sijainnissa toistensa naapureina. He kommunikoivat sisäisen verkon kautta . Samoin MS SQL SERVER tarjoaa mahdollisuuden olla vuorovaikutuksessa Named Pipe -protokollan kautta. Tässä ASIAKAS ja MS SQL -PALVELIN ovat yhteydessä lähiverkon kautta .

Analogia: Antaa karttakokonaisuuden kahdessa yllä olevassa skenaariossa. Voimme helposti yhdistää Tomin asiakkaaseen, Sierran SQL-palvelimeen, naapurin lähiverkkoon ja lopuksi sisäisen verkon Named Pipe Protocoliin.

Huomautuksia kokoonpanon / asennuksen työpöydältä:

  • Yhdistämistä varten nimetty putki. Tämä vaihtoehto on oletusarvoisesti poissa käytöstä, ja SQL Configuration Managerin on otettava se käyttöön.

Mikä on TDS?

Nyt kun tiedämme, että Client-Server-arkkitehtuuria on kolme tyyppiä, voimme vilkaista TDS: tä:

  • TDS tarkoittaa taulukkotietovirtaa.
  • Kaikki 3 protokollaa käyttävät TDS-paketteja. TDS on kapseloitu verkkopaketteihin. Tämä mahdollistaa tiedonsiirron asiakaskoneelta palvelinkoneelle.
  • TDS: n kehitti ensin Sybase, ja sen omistaa nyt Microsoft

Suhteellinen moottori

Relaatiomoottori tunnetaan myös nimellä kyselyprosessori. Siinä on SQL Server -komponentit, jotka määrittävät, mitä kyselyn on tehtävä ja miten se voidaan tehdä parhaiten. Se vastaa käyttäjien kyselyjen suorittamisesta pyytämällä tietoja tallennusmoottorilta ja käsittelemällä palautetut tulokset.

Kuten arkkitehtuurikaaviossa on esitetty, relaatiomoottorissa on 3 pääkomponenttia . Tutkitaan komponentit yksityiskohtaisesti:

CMD-jäsennin

Kerran Protokollakerrokselta saadut tiedot siirretään sitten Relational Engineen. "CMD-jäsennin" on Relational Enginen ensimmäinen komponentti, joka vastaanottaa kyselytiedot. CMD-jäsentimen päätehtävä on tarkistaa syntaktisten ja semanttisten virheiden kysely . Lopuksi se luo kyselypuun . Keskustellaan yksityiskohtaisesti.

Syntaktinen tarkistus:

  • Kuten kaikilla muilla ohjelmointikielillä, MS SQL: llä on myös ennalta määritetty avainsanaryhmä. SQL Serverillä on myös oma kielioppi, jonka SQL-palvelin ymmärtää.
  • SELECT, INSERT, UPDATE ja monet muut kuuluvat MS SQL: n ennalta määritettyihin avainsanaluetteloihin.
  • CMD-jäsennin tarkistaa syntaktisen tarkistuksen. Jos käyttäjien syöttö ei noudata näitä kielen syntaksia tai kielioppisääntöjä, se palauttaa virheen.

Esimerkki: Oletetaan, että venäläinen kävi japanilaisessa ravintolassa. Hän tilaa pikaruokaa venäjän kielellä. Valitettavasti tarjoilija ymmärtää vain japanin. Mikä olisi ilmeisin tulos?

Vastaus on - tarjoilija ei pysty käsittelemään tilausta edelleen.

Kieliopissa tai kielessä ei saisi olla poikkeamia, jonka SQL-palvelin hyväksyy. Jos sellaisia ​​on, SQL-palvelin ei voi käsitellä sitä ja palauttaa siten virheilmoituksen.

Opimme MS SQL-kyselystä lisää tulevissa opetusohjelmissa. Harkitse kuitenkin alapuolella olevaa peruskyselyn syntaksia nimellä 

SELECT * from ;

Nyt saadaksesi käsityksen syntaktisesta toiminnasta, sano jos käyttäjä suorittaa peruskyselyn seuraavasti:

SELECR * from

Huomaa, että käyttäjä kirjoitti 'SELECT' -toiminnon sijaan "SELECR".

Tulos: CMD-jäsennin jäsentää tämän lauseen ja heittää virhesanoman. Koska "SELECR" ei noudata ennalta määritettyä avainsanan nimeä ja kielioppia. Tässä CMD-jäsennin odotti "SELECT" -toimintoa.

Semanttinen tarkistus:

  • Tämän suorittaa Normalizer .
  • Yksinkertaisimmassa muodossaan se tarkistaa, onko sarakkeessa sarakkeen nimi, kysyttävän taulukon nimi. Ja jos se on olemassa, sido se kyselyyn. Tätä kutsutaan myös sitomiseksi .
  • Monimutkaisuus kasvaa, kun käyttäjien kyselyt sisältävät VIEW. Normalizer korvaa sisäisesti tallennetun näkymän määritelmän ja paljon muuta.

Ymmärretään tämä alla olevan esimerkin avulla -

SELECT * from USER_ID

Tulos: CMD-jäsennin jäsentää tämän lausekkeen semanttista tarkistusta varten. Jäsennys heittää virheilmoituksen, koska Normalizer ei löydä pyydettyä taulukkoa (USER_ID), koska sitä ei ole olemassa.

Luo kyselypuu:

  • Tämä vaihe luo erilaisen suorituspuun, jossa kysely voidaan suorittaa.
  • Huomaa, että kaikilla eri puilla on sama haluttu tuotos.

Optimoija

Optimoijan tehtävänä on luoda toteutussuunnitelma käyttäjän kyselylle. Tämä on suunnitelma, joka määrittää, miten käyttäjän kysely suoritetaan.

Huomaa, että kaikkia kyselyjä ei ole optimoitu. Optimointi tehdään DML (Data Modification Language) -komennoille, kuten SELECT, INSERT, DELETE ja UPDATE. Tällaiset kyselyt merkitään ensin ja lähetetään sitten optimoijalle. DDL-komentoja, kuten CREATE ja ALTER, ei optimoida, mutta ne kootaan sen sijaan sisäiseen muotoon. Kyselyn hinta lasketaan tekijöiden, kuten suorittimen käytön, muistin käytön ja syöttö- ja lähtötehtävien perusteella.

Optimizerin tehtävänä on löytää halvin, ei paras, kustannustehokas toteutussuunnitelma.

Ennen kuin ryhdymme optimoijan teknisempiin yksityiskohtiin, harkitse alla olevaa tosielämän esimerkkiä:

Esimerkki:

Oletetaan, että haluat avata verkkopankkitilin. Tiedät jo yhdestä pankista, jonka avaaminen kestää enintään 2 päivää. Mutta sinulla on myös luettelo 20 muusta pankista, jotka voivat kestää tai olla ottamatta alle 2 päivää. Voit aloittaa yhteydenoton näiden pankkien kanssa selvittääkseen, mitkä pankit vievät alle 2 päivää. Et ehkä löydä pankkia, joka vie alle 2 päivää, ja ylimääräinen aika menetetään itse hakutoiminnan vuoksi. Olisi ollut parempi avata tili ensimmäisessä pankissa.

Johtopäätös: On tärkeämpää valita viisaasti. Jos haluat olla tarkka, valitse mikä vaihtoehto on paras, ei halvin.

Samoin MS SQL Optimizer toimii sisäänrakennetuilla tyhjentävillä / heuristisilla algoritmeilla. Tavoitteena on minimoida kyselyn ajoaika. Kaikki Optimizer-algoritmit ovat Microsoftin omaisuutta ja salaisuus. Vaikka , Alla on korkean tason suorittamat vaiheet MS SQL Optimizer. Optimoinnin haut seuraavat kolmea vaihetta alla olevan kaavion mukaisesti:

Vaihe 0: Trivial-suunnitelman haku:

  • Tämä tunnetaan myös nimellä Pre-optimointivaihe .
  • Joissakin tapauksissa voi olla vain yksi käytännöllinen ja toimiva suunnitelma, joka tunnetaan triviaalina suunnitelmana. Optimoitua suunnitelmaa ei tarvitse luoda. Syynä on, että enemmän etsiminen johtaisi saman ajoajan suoritussuunnitelman löytämiseen. Myös tämä optimoidun suunnitelman etsinnän lisäkustannuksilla, joita ei tarvittu ollenkaan.
  • Jos ei Trivial suunnitelmaa löytyy, 1 kpl alkaa.

Vaihe 1: Etsi tapahtumien käsittelysuunnitelmia

  • Tähän sisältyy yksinkertaisen ja monimutkaisen suunnitelman haku .
  • Yksinkertainen suunnitelmahaku: Kyselyyn osallistuvien sarakkeiden ja hakemistojen aiempia tietoja käytetään tilastolliseen analyysiin. Tämä koostuu yleensä, mutta ei rajoittuen yhteen Indeksi per taulukko.
  • Silti, jos yksinkertaista suunnitelmaa ei löydy, etsitään monimutkaisempaa suunnitelmaa. Se sisältää useita indeksejä taulukkoa kohti.

Vaihe 2: Rinnakkaisprosessointi ja optimointi.

  • Jos mikään yllä olevista strategioista ei toimi, Optimizer etsii rinnakkaiskäsittelymahdollisuuksia. Tämä riippuu koneen käsittelyominaisuuksista ja kokoonpanosta.
  • Jos se ei vieläkään ole mahdollista, lopullinen optimointivaihe alkaa. Lopullinen optimointitavoite on nyt löytää kaikki muut mahdolliset vaihtoehdot kyselyn suorittamiseksi parhaalla mahdollisella tavalla. Viimeisen optimointivaiheen algoritmit ovat Microsoft Propriety.

Kyselyn toteuttaja

Kysy suorituspuheluiden käyttömenetelmä . Se tarjoaa suoritussuunnitelman suorituksen edellyttämälle tiedonhakulogiikalle. Kun tiedot on vastaanotettu Storage Engine -palvelusta, tulos julkaistaan ​​Protokollakerroksessa. Lopuksi tiedot lähetetään loppukäyttäjälle.

Varastointi Moottori

Tallennusmoottorin tehtävänä on tallentaa tietoja tallennusjärjestelmään, kuten Levy tai SAN, ja hakea tietoja tarvittaessa. Ennen kuin sukelamme syvälle Storage-moottoriin, katsotaanpa, miten tiedot tallennetaan tietokantaan ja käytettävissä olevien tiedostotyyppien.

Datatiedosto ja laajuus:

Data File tallentaa fyysisesti tiedot datasivujen muodossa, ja jokaisen datasivun koko on 8 kt, muodostaen SQL Serverin pienimmän tallennusyksikön. Nämä tietosivut on ryhmitelty loogisesti muodoksi. Objektille ei ole määritetty sivua SQL Serverissä.

Kohteen huolto tapahtuu laajuuksien kautta. Sivulla on Sivuotsikko-osio, jonka koko on 96 tavua ja joka sisältää sivun metatiedot, kuten sivutyyppi, sivunumero, käytetyn tilan koko, vapaan tilan koko ja osoitin seuraavalle ja edelliselle sivulle , jne.

Tiedostotyypit

  1. Ensisijainen tiedosto
  • Jokainen tietokanta sisältää yhden ensisijaisen tiedoston.
  • Tämä tallentaa kaikki tärkeät tiedot, jotka liittyvät taulukoihin, näkymiin, triggereihin jne.
  • Laajennus on. mdf yleensä, mutta voi olla mikä tahansa laajennus.
  1. Toissijainen tiedosto
  • Tietokanta voi sisältää useita toissijaisia ​​tiedostoja tai ei.
  • Tämä on valinnainen ja sisältää käyttäjäkohtaisia ​​tietoja.
  • Laajennus on. ndf yleensä, mutta voi olla mikä tahansa laajennus.
  1. Loki tiedosto
  • Tunnetaan myös nimellä Kirjoita eteenpäin lokit.
  • Laajennus on. ldf
  • Käytetään tapahtumien hallintaan.
  • Tätä käytetään palautumiseen kaikista ei-toivotuista tapauksista. Suorita tärkeä tehtävä palauttamattomille tapahtumille.

Varastomoottorissa on 3 komponenttia; tarkastellaan niitä yksityiskohtaisesti.

Käyttömenetelmä

Se toimii käyttöliittymänä kyselyn suorittajan ja puskurinhallinta / tapahtumalokien välillä.

Pääsymenetelmä itsessään ei tee mitään suoritusta.

Ensimmäinen toimenpide on selvittää, onko kysely:

  1. Valitse lause (DDL)
  2. Ei-valittava lausunto (DDL ja DML)

Tuloksesta riippuen käyttömenetelmä suorittaa seuraavat vaiheet:

  1. Jos kysely on DDL , SELECT-käsky, kysely välitetään Buffer Managerille jatkokäsittelyä varten.
  2. Ja jos kysytään jos DDL, NON-SELECT-käsky , kysely välitetään Transaction Managerille. Tähän sisältyy enimmäkseen UPDATE-käsky.

Puskuripäällikkö

Puskuripäällikkö hallinnoi alla olevien moduulien ydintoimintoja:

  • Suunnittele välimuisti
  • Tietojen jäsentäminen: Puskurin välimuisti ja tietojen tallennus
  • Likainen sivu

Opimme Suunnittelu-, Puskuri- ja Data-välimuistin tässä osiossa. Käsittelemme likaiset sivut Tapahtumat-osiossa.

Suunnittele välimuisti

  • Olemassa oleva kyselysuunnitelma: Puskurinhallinta tarkistaa, onko suoritussuunnitelma tallennetussa suunnitelman välimuistissa. Jos Kyllä, käytetään kyselysuunnitelman välimuistia ja siihen liittyvää välimuistia.
  • Ensimmäisen kerran välimuistisuunnitelma: Mistä nykyinen Plan-välimuisti tulee?

    Jos kyselyn ensimmäistä kertaa suoritettava suunnitelma on monimutkainen, on järkevää tallentaa se Plane-välimuistiin. Tämä varmistaa nopeamman saatavuuden, kun seuraavan kerran SQL-palvelin saa saman kyselyn. Joten, se ei ole mitään muuta kuin itse kysely, joka Suunnitelman toteutus tallennetaan, jos sitä ajetaan ensimmäistä kertaa.

Tietojen jäsentäminen: Puskurin välimuisti ja tietojen tallennus

Puskurin hallinta tarjoaa pääsyn tarvittaviin tietoihin. Alle kaksi lähestymistapaa ovat mahdollisia riippuen siitä, onko dataa välimuistissa vai ei:

Puskurimuisti - pehmeä jäsentäminen:

Puskurin hallinta etsii dataa välimuistissa olevasta puskurista. Jos tietoja on, Query Executor käyttää näitä tietoja. Tämä parantaa suorituskykyä, kun I / O-operaatioiden määrä vähenee, kun tietoja haetaan välimuistista, verrattuna tietojen hakemiseen datamuistista.

Tietojen tallennus - vaikea jäsentäminen:

Jos tietoja ei ole Buffer Manager -ohjelmassa, tietoja haetaan Data Storage -palvelusta. If myös tallentaa dataa välimuistiin tulevaa käyttöä varten.

Likainen sivu

Se on tallennettu Transaction Managerin käsittelylogiikaksi. Opimme yksityiskohtaisesti Transaction Manager -osiossa.

Transaction Manager

Transaction Manager käynnistetään, kun käyttömenetelmä määrittää, että Query on Ei-Valitse-käsky.

Lokien hallinta

  • Lokien hallinta seuraa kaikkia järjestelmässä tehtyjä päivityksiä tapahtumalokien lokien kautta.
  • Lokeissa on lokien järjestysnumero, jossa on tapahtuman tunnus ja tietomuutosrekisteri .
  • Tätä käytetään tapahtumien seuraamiseen ja tapahtumien palauttamiseen .

Lukituksen hallinta

  • Tapahtuman aikana tietovarastossa olevat tiedot ovat lukitustilassa. Tätä prosessia hoitaa Lock Manager.
  • Tämä prosessi varmistaa tietojen yhdenmukaisuuden ja eristämisen . Tunnetaan myös nimellä ACID-ominaisuudet.

Suoritusprosessi

  • Lokien hallinta alkaa kirjata ja Lukitse hallinta lukitsee niihin liittyvät tiedot.
  • Datan kopio säilytetään puskurimuistissa.
  • Kopio päivitettävistä tiedoista pidetään lokipuskurissa ja kaikki tapahtumat päivittävät datapuskurissa.
  • Tiedot tallentavat sivut tunnetaan myös nimellä Dirty Pages .
  • Tarkistuskohdan ja kirjoituspäivän kirjaus: Tämä prosessi suorittaa ja merkitsee kaikki sivut likaisista sivuista levylle, mutta sivu pysyy välimuistissa. Taajuus on noin 1 ajo minuutissa, mutta sivu työnnetään ensin lokitiedoston Data-sivulle puskurilokista. Tämä tunnetaan nimellä kirjoita eteenpäin kirjaaminen.
  • Laiska kirjoittaja: Dirty-sivu voi jäädä muistiin. Kun SQL-palvelin havaitsee valtavan kuormituksen ja uudelle tapahtumalle tarvitaan puskurimuistia, se vapauttaa Dirty Pages -välimuistista. Se toimii LRU: lla - viimeisimmin käytetty algoritmi sivun puhdistamiseen puskurivarastosta levylle.

Yhteenveto:

  • Kolme asiakaspalvelinarkkitehtuurityyppiä on: 1) Jaettu muisti 2) TCP / IP 3) Nimetyt putket
  • Sybasen kehittämä ja nyt Microsoftin omistama TDS on paketti, joka on kapseloitu verkkopaketteihin tiedonsiirtoa varten asiakaskoneelta palvelinkoneelle.
  • Relational Engine sisältää kolme pääkomponenttia:

    CMD-jäsennin: Tämä on vastuussa syntaktisista ja semanttisista virheistä ja lopulta luo kyselypuun.

    Optimoija: Optimoijan tehtävänä on löytää halvin, ei paras, kustannustehokas toteutussuunnitelma.

    Kyselyn toteuttaja: Kysy suorittajalta kutsuja Access Method ja tarjoaa toteutussuunnitelman suorituksen edellyttämälle tiedonhakulogiikalle.

  • Kolme tiedostotyyppiä on ensisijainen tiedosto, toissijainen tiedosto ja lokitiedostot.
  • Varastomoottori: Sisältää seuraavat tärkeät komponentit

    Saantitapa: Tämä komponentti määrittää, onko kysely valinta- tai ei-valinta-lause. Käynnistää puskurin ja siirtohallinnan vastaavasti.

    Puskurin hallinta: Puskurin hallinta hallitsee Plan Cache-, Data Parsing- ja Dirty Page -palvelun ydintoimintoja.

    Transaction Manager: Se hallinnoi Ei-Valitse-tapahtumaa Loki- ja Lukitushallintojen avulla. Helpottaa myös Write Ahead -lokien ja laiskojen kirjoittajien tärkeää toteutusta.