SQL Server architektúra magyarázata: Elnevezett csövek, optimalizáló, pufferkezelő

Tartalomjegyzék:

Anonim

Az MS SQL Server egy kliens-szerver architektúra. Az MS SQL Server folyamata azzal kezdődik, hogy az ügyfélalkalmazás kérelmet küld. Az SQL Server feldolgozott adatokkal fogadja el, dolgozza fel és válaszolja meg a kérést. Beszéljük meg részletesen az alább látható teljes architektúrát:

Ahogy az alábbi ábra mutatja, az SQL Server Architecture három fő összetevője van:

  1. Protokoll réteg
  2. Relációs motor
  3. Tároló motor
SQL Server architektúra diagram

Beszéljünk részletesen a fenti három fő modulról. Ebben az oktatóanyagban megtanulja.

  • Protokoll réteg - SNI
    • Megosztott memória
    • TCP / IP
    • Elnevezett csövek
    • Mi az a TDS?
  • Relációs motor
    • CMD elemző
    • Optimalizáló
    • Lekérdezés végrehajtó
  • Tároló motor
    • Fájl típusok
    • Hozzáférési módszer
    • Pufferkezelő
    • Terv gyorsítótár
    • Adatok elemzése: puffer gyorsítótár és adattárolás
    • Tranzakciókezelő

Protokoll réteg - SNI

Az MS SQL Server kiszolgálóprotokoll-réteg 3 típusú ügyfélkiszolgáló-architektúrát támogat. Kezdjük a " Három típusú ügyfélkiszolgáló-architektúrával", amelyet az MS SQL Server támogat.

Megosztott memória

Gondoljuk át a kora reggeli beszélgetés forgatókönyvét.

Anya és TOM - Itt Tom és az anyja ugyanabban a logikus helyen voltak, azaz otthonukban. Tom kérhetett kávét, anya pedig forrón tálalhatta.

MS SQL SERVER - Itt az MS SQL szerver biztosítja a MEGOSZTOTT MEMÓRIA JEGYZŐKÖNYVET . Itt a CLIENT és az MS SQL szerver ugyanazon a gépen fut. Mindkettő kommunikálhat megosztott memória protokollon keresztül.

Analógia: Lehetővé teszi az entitások feltérképezését a fenti két forgatókönyvben. Könnyen hozzárendelhetjük Tomot az Ügyfélhöz, az Anyát az SQL szerverhez, az Otthon géphez és a verbális kommunikációt a megosztott memória protokollhoz.

A konfigurálás és telepítés asztaláról:

Helyi DB-hez való csatlakozáshoz - Az SQL Management Studio alkalmazásban a "Kiszolgáló neve" opció lehet

""

"helyi kiszolgáló"

"127.0.0.1"

"Machine \ instance"

TCP / IP

Most fontold meg este, Tom bulizós hangulatban van. Kávét akar egy jól ismert kávézóból. A kávézó 10 km-re található otthonától.

Itt Tom és Starbuck különböző fizikai helyen vannak. Tom otthon és a Starbucks a forgalmas piacon. Cellular hálózaton keresztül kommunikálnak. Hasonlóképpen, az MS SQL SERVER lehetőséget nyújt a TCP / IP protokollon keresztüli interakcióra, ahol az ÜGYFÉL és az MS SQL Server egymástól távol vannak, és külön gépre vannak telepítve.

Analógia: Lehetővé teszi az entitások feltérképezését a fenti két forgatókönyvben. Könnyen hozzárendelhetjük Tomot az Ügyfélhöz, a Starbuckot az SQL szerverhez, az Otthon / Piactéret a Távoli helyhez és végül a Cellular network -t a TCP / IP protokollhoz.

Megjegyzések a Konfiguráció / telepítés asztaláról:

  • Az SQL Management Studio alkalmazásban - TCP \ IP kapcsolaton keresztül történő kapcsolódáshoz a "Kiszolgáló neve" beállításnak a "Gép \ a kiszolgáló példánya" értéknek kell lennie.
  • Az SQL szerver az 1433-as portot használja a TCP / IP-ben.

Elnevezett csövek

Most végül éjjel Tom egy világos zöld teát szeretett volna inni, amelyet szomszédja, Sierra nagyon jól elkészített.

Itt Tom és szomszédja , Sierra ugyanabban a fizikai helyen vannak, egymás szomszédjai. Intra hálózaton keresztül kommunikálnak . Hasonlóképpen, az MS SQL SERVER lehetőséget nyújt a Named Pipe protokollon keresztüli interakcióra . Itt az ÜGYFÉL és az MS SQL SZERVER LAN- on keresztül csatlakozik .

Analógia: Lehetővé teszi az entitások feltérképezését a fenti két forgatókönyvben. Könnyen hozzárendelhetjük Tomot az Ügyfélhöz, a Sierrát SQL szerverhez, a Szomszédot a LAN-hoz és végül az Intra hálózatot a Named Pipe Protocol-hoz.

Megjegyzések a Konfiguráció / telepítés asztaláról:

  • Csatlakozáshoz elnevezett csövön keresztül. Ez az opció alapértelmezés szerint le van tiltva, és az SQL Configuration Manager-nek engedélyeznie kell.

Mi az a TDS?

Most, hogy tudjuk, hogy az ügyfél-kiszolgáló architektúrának három típusa létezik, bepillanthatunk a TDS-be:

  • A TDS a táblázatos adatfolyamot jelenti.
  • Mind a 3 protokoll TDS csomagokat használ. A TDS hálózati csomagokba van beágyazva. Ez lehetővé teszi az adatátvitelt az ügyfélgépről a kiszolgáló gépre.
  • A TDS-t először a Sybase fejlesztette ki, és jelenleg a Microsoft tulajdonosa

Relációs motor

A Relációs motor Query Processor néven is ismert. Az SQL Server összetevői határozzák meg, hogy pontosan mit kell tennie egy lekérdezésnek, és hogyan lehet a legjobban végrehajtani. Felelős a felhasználói lekérdezések végrehajtásáért azáltal, hogy adatokat kér a tárolómotortól és feldolgozza a visszaküldött eredményeket.

Amint azt az Építészeti Diagram mutatja , a Relációs motor 3 fő alkotóeleme van. Tanulmányozzuk részletesen az összetevőket:

CMD elemző

A Protokollrétegtől kapott adatokat ezután továbbítják a Relational Engine-nek. A "CMD elemző" a Relational Engine első összetevője, amely megkapja a lekérdezés adatait. A CMD elemző fő feladata a szintaktikai és szemantikai hibák lekérdezésének ellenőrzése . Végül létrehoz egy lekérdezési fát . Beszéljünk részletesen.

Szintaktikus ellenőrzés:

  • Mint minden más programozási nyelv, az MS SQL is rendelkezik előre definiált kulcsszavakkal. Ezenkívül az SQL Server saját nyelvtanral rendelkezik, amelyet az SQL szerver megért.
  • A SELECT, INSERT, UPDATE és még sokan mások az MS SQL előre definiált kulcsszólistákhoz tartoznak.
  • A CMD elemző szintaktikai ellenőrzést végez. Ha a felhasználók bevitele nem követi ezeket a nyelvi szintaxis vagy nyelvtani szabályokat, akkor hibát ad vissza.

Példa: Tegyük fel, hogy egy orosz japán étterembe ment. Gyorsétkezést rendel orosz nyelven. Sajnos a pincér csak japánul ért. Mi lenne a legkézenfekvőbb eredmény?

A válasz: a pincér nem tudja tovább feldolgozni a megrendelést.

Nem lehet semmilyen eltérés a nyelvtanban vagy a nyelvben, amelyet az SQL szerver elfogad. Ha vannak ilyenek, az SQL szerver nem tudja feldolgozni, ezért hibaüzenetet küld.

Az MS SQL lekérdezésről többet megtudhatunk a következő oktatóanyagokban. Az alábbiakban vegyük figyelembe a legalapvetőbb Lekérdezési szintaxist 

SELECT * from ;

Most, hogy megértsük, mit csinál a szintaktika, mondjuk, ha a felhasználó az alábbi lekérdezést futtatja:

SELECR * from

Vegye figyelembe, hogy a „SELECT” helyett a felhasználó beírta a „SELECR” szót.

Eredmény: A CMD elemző elemzi ezt az állítást, és elküldi a hibaüzenetet. Mivel a "SELECR" nem követi az előre meghatározott kulcsszó nevét és nyelvtanát. Itt a CMD elemző a "SELECT" -re számított.

Szemantikus ellenőrzés:

  • Ezt a Normalizer végzi .
  • A legegyszerűbb formájában ellenőrzi, hogy létezik-e a sémában a lekérdezett oszlopnév, táblázatnév. És ha létezik, kösse be a Query-hez. Ez más néven Binding .
  • A komplexitás növekszik, ha a felhasználói lekérdezések VIEW-t tartalmaznak. A Normalizer elvégzi a cserét a belső tárolt nézetdefinícióval és még sok mással.

Értsük meg ezt az alábbi példa segítségével -

SELECT * from USER_ID

Eredmény: A CMD elemző elemzi ezt az állítást szemantikai ellenőrzés céljából. Az elemző hibaüzenetet küld, mivel a Normalizer nem találja a kért táblát (USER_ID), mivel nem létezik.

Lekérdezőfa létrehozása:

  • Ez a lépés különböző végrehajtási fát generál, amelyben a lekérdezés futtatható.
  • Vegye figyelembe, hogy az összes fának ugyanaz a kívánt teljesítménye.

Optimalizáló

Az optimalizáló feladata végrehajtási terv készítése a felhasználói lekérdezéshez. Ez a terv határozza meg a felhasználói lekérdezés végrehajtásának módját.

Ne feledje, hogy nem minden lekérdezés optimalizált. Az optimalizálás olyan DML (Data Modification Language) parancsokra történik, mint a SELECT, INSERT, DELETE és UPDATE. Az ilyen lekérdezéseket először megjelöli, majd elküldi az optimalizálónak. Az olyan DDL parancsok, mint a CREATE és az ALTER, nincsenek optimalizálva, hanem egy belső formába vannak fordítva. A lekérdezés költségét olyan tényezők alapján számítják ki, mint a processzorhasználat, a memóriahasználat, valamint a bemeneti / kimeneti igények.

Az optimalizáló feladata a legolcsóbb, és nem a legjobb, költséghatékony végrehajtási terv megtalálása.

Mielőtt áttekintenénk az Optimizer technikai részleteit, vegyük figyelembe az alábbiakban a valós példákat:

Példa:

Tegyük fel, hogy online bankszámlát akar nyitni. Ön már ismer egy bankot, amelynek legfeljebb 2 napja szükséges a számla megnyitásához. De van még egy listája 20 másik bankról, amelyek 2 napnál kevesebbet vehetnek igénybe. Kezdheti kapcsolatba lépni ezekkel a bankokkal annak meghatározása érdekében, hogy melyik bankok vesznek igénybe kevesebb mint 2 napot. Most előfordulhat, hogy nem talál olyan bankot, amely kevesebb, mint 2 napot vesz igénybe, és maga a keresési tevékenység miatt több időt veszít. Jobb lett volna az első banknál számlát nyitni.

Következtetés: Fontosabb az okos kiválasztás. Hogy pontos legyünk, válassza ki, melyik a legjobb, és nem a legolcsóbb.

Hasonlóképpen, az MS SQL Optimizer beépített kimerítő / heurisztikus algoritmusokon is működik. A cél a lekérdezés futási idejének minimalizálása. Az Optimizer összes algoritmusa a Microsoft megfelelősége és titok. Bár , alábbiakban a magas szintű által végrehajtott lépéseket MS SQL optimalizáló. Az optimalizálás keresései három fázist követnek, az alábbi ábra szerint:

0. fázis: Triviális terv keresése:

  • Ez más néven Pre-optimalization szakasz .
  • Bizonyos esetekben csak egy praktikus, működőképes terv létezhet, amelyet triviális tervnek neveznek. Nincs szükség optimalizált terv készítésére. Ennek oka, hogy ha többet keres, ugyanaz a futási idő végrehajtási terv megtalálható. Ez az optimalizált terv keresésének többletköltségével is, amelyre egyáltalán nem volt szükség.
  • Ha nem triviális terv talált, akkor 1 -jén fázis kezdődik.

1. fázis: Keresse meg a tranzakciófeldolgozási terveket

  • Ez magában foglalja az egyszerű és összetett terv keresését .
  • Egyszerű tervkeresés: A lekérdezésben érintett oszlop és index múltbeli adatait felhasználjuk a statisztikai elemzéshez. Ez általában táblázatonként egy indexet tartalmaz, de nem korlátozódik erre.
  • Mégis, ha az egyszerű terv nem található, akkor a bonyolultabb tervet keresik. Több indexet tartalmaz táblánként.

2. fázis: Párhuzamos feldolgozás és optimalizálás.

  • Ha a fenti stratégiák egyike sem működik, az Optimizer párhuzamos feldolgozási lehetőségeket keres. Ez a Gép feldolgozási képességeitől és konfigurációjától függ.
  • Ha ez még mindig nem lehetséges, akkor megkezdődik az utolsó optimalizálási szakasz. Most a végső optimalizálási cél az összes többi lehetőség megtalálása a lekérdezés legjobb végrehajtásához. A végső optimalizálási szakasz algoritmusai a Microsoft Propriety.

Lekérdezés végrehajtó

Végrehajtó hívások lekérdezése Hozzáférési módszer. Végrehajtási tervet nyújt a végrehajtáshoz szükséges adatletöltési logikához. Miután az adatokat megkapta a Storage Engine-től, az eredmény közzétételre kerül a Protocol rétegben. Végül az adatokat elküldik a végfelhasználónak.

Tároló motor

A Storage Engine feladata, hogy adatokat tároljon egy olyan tárolórendszerben, mint például a Lemez vagy a SAN, és szükség esetén visszakeresje az adatokat. Mielőtt elmélyülnénk a Storage motorban, nézzük meg, hogyan tárolják az adatokat az adatbázisban, és hogy milyen típusú fájlok állnak rendelkezésre.

Adatfájl és kiterjedés:

Az Adatfájl fizikailag tárolja az adatokat adatlapok formájában, mindegyik adatlap mérete 8KB, és ez képezi az SQL Server legkisebb tárolóegységét. Ezeket az adatlapokat logikusan csoportosítva alakítják ki. Nincs objektum hozzárendelve egy oldalhoz az SQL Server szolgáltatásban.

Az objektum karbantartása terjedelmeken keresztül történik. Az oldal rendelkezik egy Fejléc nevű szakaszsal, amelynek mérete 96 bájt, és amely az oldal metaadatainak információit tartalmazza, mint például az Oldal típusa, Oldalszám, Használt terület mérete, Szabad terület mérete és Mutató a következő oldalra és az előző oldalra. stb.

Fájl típusok

  1. Elsődleges fájl
  • Minden adatbázis egy Elsődleges fájlt tartalmaz.
  • Ez a táblákkal, nézetekkel, triggerekkel stb. Kapcsolatos összes fontos adatot tárolja.
  • A kiterjesztés az. Az mdf általában, de bármilyen kiterjesztésű lehet.
  1. Másodlagos fájl
  • Az adatbázis több másodlagos fájlt is tartalmazhat, vagy nem.
  • Ez nem kötelező, és felhasználóspecifikus adatokat tartalmaz.
  • A kiterjesztés az. Az ndf általában, de bármilyen kiterjesztésű lehet.
  1. Log fájl
  • Más néven írási naplók.
  • A kiterjesztés az. ldf
  • Tranzakciók kezelésére használják.
  • Ezt a nem kívánt példányok helyreállítására használják. Végezze el a nem kötelező tranzakciók visszagörgetésének fontos feladatát.

A Storage Engine 3 komponensű; nézzük meg őket részletesen.

Hozzáférési módszer

Interfészként működik a lekérdezés végrehajtója és a pufferkezelő / tranzakciós naplók között.

Maga az Access Method nem hajt végre semmilyen végrehajtást.

Az első lépés annak meghatározása, hogy a lekérdezés:

  1. Nyilatkozat kiválasztása (DDL)
  2. Nem kiválasztott nyilatkozat (DDL és DML)

Az eredménytől függően az Access Method a következő lépéseket teszi:

  1. Ha a lekérdezés DDL , SELECT utasítás, akkor a lekérdezés továbbításra kerül a Pufferkezelőhöz további feldolgozás céljából.
  2. És ha lekérdezi, ha DDL, NON-SELECT utasítás , akkor a lekérdezést továbbítja a Transaction Manager-nek. Ez többnyire magában foglalja az UPDATE utasítást.

Pufferkezelő

A pufferkezelő az alábbi modulok alapvető funkcióit kezeli:

  • Terv gyorsítótár
  • Adatok elemzése: puffer gyorsítótár és adattárolás
  • Piszkos oldal

Ebben a szakaszban megtanuljuk a Terv, Puffer és Adat gyorsítótárat. A Piszkos oldalakról a Tranzakció részben foglalkozunk.

Terv gyorsítótár

  • Meglévő lekérdezési terv: A pufferkezelő ellenőrzi, hogy a végrehajtási terv szerepel-e a tárolt tervgyorsítótárban. Ha Igen, akkor a lekérdezési terv gyorsítótárát és a hozzá tartozó adatgyorsítótárat használja.
  • Első alkalommal gyorsítótár-terv: Honnan származik a meglévő terv-gyorsítótár?

    Ha az első lekérdezés-futtatási terv fut és összetett, akkor célszerű a Plane gyorsítótárban tárolni. Ez biztosítja a gyorsabb elérhetőséget, amikor az SQL szerver legközelebb ugyanazt a lekérdezést kapja meg. Tehát nem más, mint maga a lekérdezés, amelyet a Plan végrehajtása tárol, ha azt először futtatják.

Adatok elemzése: puffer gyorsítótár és adattárolás

A pufferkezelő hozzáférést biztosít a szükséges adatokhoz. Kétféle megközelítés lehetséges, attól függően, hogy vannak-e adatok az adat-gyorsítótárban, vagy sem:

Puffer gyorsítótár - puha elemzés:

A Pufferkezelő az Adatokat a pufferben keresi az Adat gyorsítótárban. Ha vannak, akkor ezeket az adatokat a Query Executor használja. Ez javítja a teljesítményt, mivel az I / O műveletek száma csökken az adatok gyorsítótárból történő lekérésekor, összehasonlítva az adatok Adattárolóból történő lekérésével.

Adattárolás - kemény elemzés:

Ha az adatok nincsenek a Buffer Manager alkalmazásban, akkor a szükséges adatokra az Adattárolóban keresnek. Az If is tárolja az adatokat az adatgyorsítótárban későbbi felhasználás céljából.

Piszkos oldal

A Transaction Manager feldolgozási logikájaként tárolódik. Részletesen megtanuljuk a Transaction Manager részben.

Tranzakciókezelő

A Transaction Manager akkor hívódik meg, amikor a hozzáférési módszer megállapítja, hogy a Query egy Non-Select utasítás.

Naplókezelő

  • A Log Manager a Tranzakciónaplókban található naplók segítségével nyomon követi a rendszerben végrehajtott összes frissítést.
  • A naplók tartalmazzák a Napló sorszámát a tranzakcióazonosítóval és az adatmódosítási rekorddal .
  • Ez a végrehajtott tranzakciók és a tranzakciók visszagörgetésének nyomon követésére szolgál .

Lock Manager

  • Tranzakció során az adattárolóban a kapcsolódó adatok zárolt állapotban vannak. Ezt a folyamatot a Lock Manager kezeli.
  • Ez a folyamat biztosítja az adatok konzisztenciáját és elkülönítését . Más néven ACID tulajdonságok.

Végrehajtási folyamat

  • A Log Manager elindítja a naplózást, és a Lock Manager zárolja a társított adatokat.
  • Az adatok másolatát a Buffer cache tárolja.
  • Az állítólag frissítendő adatok másolata a Napló pufferben van, az összes esemény pedig az Adat pufferben frissíti az adatokat.
  • Az adatokat tároló oldalak Dirty Pages néven is ismertek .
  • Ellenőrzőpont és írás előtti naplózás: Ez a folyamat lefuttatja és megjelöli az összes oldalt a Piszkos oldalaktól a Lemezig, de az oldal a gyorsítótárban marad. A gyakoriság körülbelül 1 futtatás percenként. De az oldal először a naplófájl Adatlapjára kerül a puffernaplóból. Ez az úgynevezett Write Ahead Logging.
  • Lusta író: A Dirty oldal a memóriában maradhat. Ha az SQL szerver hatalmas terhelést figyel meg, és puffermemóriára van szükség egy új tranzakcióhoz, akkor a Dirty Pages felszabadul a gyorsítótárból. Az LRU-n működik - a legkevésbé használt algoritmus az oldal puffertárról lemezre történő tisztításához.

Összegzés:

  • Három típusú ügyfélkiszolgáló-architektúra létezik: 1) megosztott memória 2) TCP / IP 3) elnevezett csövek
  • A Sybase által kifejlesztett és a Microsoft tulajdonában lévő TDS egy olyan csomag, amelyet hálózati csomagokba foglalnak, hogy az ügyfélgépről a kiszolgálóra továbbítsák az adatokat.
  • A Relational Engine három fő összetevőt tartalmaz:

    CMD elemző: Ez felelős a szintaktikai és szemantikai hibákért, és végül létrehoz egy lekérdezési fát.

    Optimalizáló: Az optimalizáló szerepe a legolcsóbb, és nem a legjobb, költséghatékony végrehajtási terv megtalálása.

    Lekérdezés végrehajtó: Lekérdezés végrehajtó hívja az Access metódust, és végrehajtási tervet nyújt a végrehajtáshoz szükséges adatletöltési logikához.

  • Három típusú fájl létezik: Elsődleges fájl, Másodlagos fájl és Naplófájlok.
  • Tároló motor: A következő fontos alkatrészekkel rendelkezik

    Hozzáférési módszer: Ez az összetevő határozza meg, hogy a lekérdezés Select vagy Non-Select utasítás legyen. Ennek megfelelően meghívja a Puffert és a Transzferkezelőt.

    Pufferkezelő: A pufferkezelő kezeli a Terv gyorsítótár, az adatelemzés és a piszkos oldal alapvető funkcióit.

    Tranzakciókezelő: A Nem kiválasztott tranzakció kezelése a Napló és a Zároláskezelők segítségével. Ez megkönnyíti az Write Ahead naplózás és a Lusta írók fontos megvalósítását is.