SQL Server Architecture (vysvětleno)

MS SQL Server je architektura klient-server. Proces MS SQL Server začíná odesláním požadavku klientskou aplikací. SQL Server přijímá, zpracovává a odpovídá na požadavek se zpracovanými daty. Pojďme si podrobně probrat celou níže zobrazenou architekturu:

Jak ukazuje níže uvedený diagram, SQL Server má tři hlavní součásti Archistruktura:

Protokolová vrstva
Relační motor
Storage Engine

Protokolová vrstva – SNI

MS SQL SERVER PROTOCOL LAYER podporuje 3 typy klientského serveru Architecture. Začneme s „Tři typy klientského serveru Architecture” které MS SQL Server podporuje.

Sdílená paměť

Pojďme znovu zvážit scénář ranní konverzace.

MOM a TOM – Tady Tom a jeho máma byli na stejném logickém místě, tedy u nich doma. Tom byl schopen požádat o kávu a máma ji dokázala podávat horkou.

MS SQL SERVER – Zde MS SQL server poskytuje PROTOKOL SDÍLENÉ PAMĚTI. Tady KLIENT si MS SQL server běží na stejném stroji. Oba mohou komunikovat prostřednictvím protokolu sdílené paměti.

Analogie: Umožňuje mapovat entity ve dvou výše uvedených scénářích. Můžeme snadno mapovat Toma na klienta, mámu na SQL server, domov na stroj a verbální komunikaci na protokol sdílené paměti.

Ze stolu konfigurace a instalace:

Pro připojení k místní DB – In SQL Management Studio, Možnost „Název serveru“ může být

"."

“místní hostitel”

"127.0.0.1"

"Stroj\Instance"

TCP / IP

A teď si představte večer, Tom je večírkové náladě. Chce kávu objednanou ve známé kavárně. Kavárna se nachází 10 km od jeho domova.

Zde jsou Tom a Starbuck na různých fyzických místech. Tom doma a Starbucks na rušném tržišti. Komunikují prostřednictvím mobilní sítě. Podobně MS SQL SERVER poskytuje možnost interakce prostřednictvím Protokol TCP / IP, kde jsou KLIENT a MS SQL Server navzájem vzdálené a nainstalované na samostatném počítači.

Analogie: Umožňuje mapovat entity ve dvou výše uvedených scénářích. Můžeme snadno namapovat Toma na klienta, Starbuck na SQL server, domov/tržiště na vzdálené umístění a nakonec celulární síť na protokol TCP/IP.

Poznámky ze stolu konfigurace/instalace:

V SQL Management Studio – pro připojení přes TCP\IP musí být možnost „Název serveru“ „Machine\Instance serveru“.
SQL server používá port 1433 v TCP/IP.

Pojmenované Pipes

Teď konečně v noci si Tom chtěl dát světle zelený čaj, který její sousedka Sierra velmi dobře připravuje.

Zde Tomáš a jeho Soused, Sierra, jsou na tom stejně fyzikální umístění, být si navzájem sousedem. Komunikují přes Vnitrosíť. Podobně, MS SQL SERVER poskytuje možnost interakce prostřednictvím S názvem Pipe protokol. Zde KLIENT a MS SQL SERVER jsou ve spojení přes LAN.

Analogie: Umožňuje mapovat entity ve dvou výše uvedených scénářích. Můžeme snadno namapovat Toma na klienta, Sierru na SQL server, Neighbor na LAN a nakonec Intra síť na Named Pipe Protocol.

Poznámky ze stolu konfigurace/instalace:

Pro připojení přes Named Pipe. Tato možnost je ve výchozím nastavení zakázána a musí být povolena správcem konfigurace SQL.

Co je TDS?

Nyní, když víme, že existují tři typy klient-server Architecture, nám umožní podívat se na TDS:

TDS je zkratka pro Tabular Data Stream.
Všechny 3 protokoly používají pakety TDS. TDS je zapouzdřeno v síťových paketech. To umožňuje přenos dat z klientského počítače na serverový stroj.
TDS byl poprvé vyvinut společností Sybase a nyní je vlastněn Microsoft

Relační motor

Relační stroj je také známý jako Query Processor. To má SQL Server komponenty, které určují, co přesně dotaz musí udělat a jak jej lze nejlépe provést. Je odpovědný za provádění uživatelských dotazů tím, že požaduje data z úložiště a zpracovává výsledky, které jsou vráceny.

Jak je znázorněno v Archiexistuje technický diagram 3 hlavní komponenty relačního motoru. Pojďme si komponenty podrobně prostudovat:

CMD Parser

Data jednou přijatá z Protocol Layer jsou poté předána do Relational Engine. "CMD Parser" je první komponentou Relational Engine, která přijímá data Query. Hlavním úkolem CMD Parser je zkontrolovat dotaz Syntaktická a sémantická chyba. Konečně to vygeneruje strom dotazů. Pojďme diskutovat podrobně.

Syntaktická kontrola:

Jako každý jiný programovací jazyk má i MS SQL předdefinovanou sadu klíčových slov. SQL Server má také svou vlastní gramatiku, které SQL server rozumí.
SELECT, INSERT, UPDATE a mnoho dalších patří do předdefinovaných seznamů klíčových slov v MS SQL.
CMD Parser provádí syntaktickou kontrolu. Pokud vstup uživatelů neodpovídá těmto pravidlům syntaxe nebo gramatiky jazyka, je to vrátí chybu.

Příklad: Řekněme, že Rus šel do japonské restaurace. Objednává rychlé občerstvení v ruském jazyce. Bohužel číšník rozumí pouze japonsky. Jaký by byl nejzřetelnější výsledek?

Odpověď zní – číšník nemůže objednávku dále zpracovat.

Neměly by existovat žádné odchylky v gramatice nebo jazyce, které SQL server akceptuje. Pokud existují, SQL server je nemůže zpracovat, a proto vrátí chybovou zprávu.

Více se o MS SQL dotazu dozvíme v nadcházejících tutoriálech. Přesto zvažte níže nejzákladnější syntaxi dotazu jako

SELECT * from <TABLE_NAME>;

Nyní, abyste získali představu o tom, co dělá syntaktika, řekněte, zda uživatel spustí základní dotaz, jak je uvedeno níže:

SELECR * from <TABLE_NAME>

Všimněte si, že místo „SELECT“ uživatel zadal „SELECR“.

Výsledek: CMD Parser analyzuje tento příkaz a vyvolá chybovou zprávu. Protože „SELECR“ se neřídí předdefinovaným názvem klíčového slova a gramatikou. Zde CMD Parser očekával „SELECT“.

Sémantická kontrola:

Toto provádí Normalizátor.
Ve své nejjednodušší podobě zkontroluje, zda ve schématu existuje název sloupce, dotazovaný název tabulky. A pokud existuje, svažte jej s Query. Toto je také známé jako Vazba.
Složitost se zvyšuje, když uživatelské dotazy obsahují VIEW. Normalizer provádí nahrazení interně uloženou definicí pohledu a mnohem více.

Pojďme to pochopit pomocí níže uvedeného příkladu -

SELECT * from USER_ID

Výsledek: CMD Parser analyzuje tento příkaz pro sémantickou kontrolu. Analyzátor vyvolá chybovou zprávu, protože Normalizer nenalezne požadovanou tabulku (USER_ID), protože neexistuje.

Vytvořit strom dotazů:

Tento krok vygeneruje jiný prováděcí strom, ve kterém lze spustit dotaz.
Všimněte si, že všechny různé stromy mají stejný požadovaný výstup.

Optimalizátor

Úkolem optimalizátoru je vytvořit plán provádění pro dotaz uživatele. Toto je plán, který určí, jak bude dotaz uživatele proveden.

Všimněte si, že ne všechny dotazy jsou optimalizovány. Optimalizace se provádí pro příkazy DML (Data Modification Language), jako jsou SELECT, INSERT, DELETE a UPDATE. Takové dotazy jsou nejprve označeny a poté odeslány do optimalizátoru. Příkazy DDL jako CREATE a ALTER nejsou optimalizovány, ale jsou kompilovány do interní formy. Cena dotazu se vypočítává na základě faktorů, jako je využití procesoru, využití paměti a potřeby vstupu/výstupu.

Úlohou optimalizátoru je najít nejlevnější, ne nejlepší, nákladově efektivní plán realizace.

Než přejdeme k dalším technickým detailům Optimalizátoru, zvažte níže příklad ze skutečného života:

Příklad:

Řekněme, že si chcete otevřít online bankovní účet. Již víte o jedné bance, které trvá otevření účtu maximálně 2 dny. Ale máte také seznam 20 dalších bank, což může nebo nemusí trvat méně než 2 dny. Můžete začít jednat s těmito bankami, abyste zjistili, kterým bankám to trvá méně než 2 dny. Nyní nemusíte najít banku, která trvá méně než 2 dny, a navíc dochází ke ztrátě času kvůli samotné vyhledávací aktivitě. Bylo by lepší otevřít si účet u první banky samotné.

Závěr: Důležitější je vybírat moudře. Abychom byli přesní, vyberte jaké varianta je nejlepší, ne nejlevnější.

Podobně čs SQL Optimizer pracuje na vestavěných vyčerpávajících/heuristických algoritmech. Cílem je minimalizovat dobu běhu dotazu. Všechny optimalizační algoritmy jsou vhodnost Microsoft a tajemství. Ačkoli, níže jsou kroky na vysoké úrovni provedené nástrojem MS SQL Optimizer. Hledání optimalizace probíhá ve třech fázích, jak ukazuje níže uvedený diagram:

Fáze 0: Hledání triviálního plánu:

Toto je také známé jako Předoptimalizační fáze.
V některých případech mohl existovat pouze jeden praktický, proveditelný plán, známý jako triviální plán. Není potřeba vytvářet optimalizovaný plán. Důvodem je, že další hledání by vedlo k nalezení stejného plánu spuštění. To také s dodatečnými náklady na vyhledávání optimalizovaného plánu, které nebyly vůbec vyžadovány.
Pokud nebyl nalezen žádný triviální plán, pak 1^st Fáze začíná.

Fáze 1: Hledání plánů zpracování transakcí

To zahrnuje hledání Jednoduchý a komplexní plán.
Jednoduché vyhledávání plánu: Minulá data sloupce a indexu zapojených do dotazu budou použita pro statistickou analýzu. To se obvykle skládá, ale není omezeno na jeden index na tabulku.
Přesto, pokud není nalezen jednoduchý plán, pak se hledá složitější plán. Zahrnuje více indexů na tabulku.

Fáze 2: Paralelní zpracování a optimalizace.

Pokud žádná z výše uvedených strategií nefunguje, Optimalizátor hledá možnosti paralelního zpracování. To závisí na schopnostech zpracování a konfiguraci stroje.
Pokud to stále není možné, pak začíná finální fáze optimalizace. Nyní je konečným cílem optimalizace nalezení všech dalších možných možností pro provedení dotazu nejlepším způsobem. Finální fáze optimalizace Algorithms jsou Microsoft Slušnost.

Vykonavatel dotazu

Volání spouštěče dotazu Metoda přístupu. Poskytuje plán provádění pro logiku načítání dat potřebnou pro provádění. Jakmile jsou data přijata z Storage Engine, je výsledek publikován na vrstvě protokolu. Nakonec jsou data odeslána koncovému uživateli.

Storage Engine

Úkolem Storage Engine je ukládat data do úložného systému, jako je Disk nebo SAN, a v případě potřeby je načítat. Než se hlouběji ponoříme do Storage Engine, podívejme se, jak jsou data uložena Databáze si typ dostupných souborů.

Datový soubor a rozsah:

Data File, fyzicky ukládá data ve formě datových stránek, přičemž každá datová stránka má velikost 8 KB, což tvoří nejmenší úložnou jednotku na SQL Serveru. Tyto datové stránky jsou logicky seskupeny do oblastí. Na serveru SQL Server není přiřazena stránka žádnému objektu.

Údržba objektu se provádí přes rozsahy. Stránka má sekci nazvanou Záhlaví stránky o velikosti 96 bajtů, která obsahuje informace o metadatech o stránce, jako je Typ stránky, Číslo stránky, Velikost použitého prostoru, Velikost volného místa a Ukazatel na další stránku a předchozí stránku. , atd.

Typy souborů

Primární soubor

Každá databáze obsahuje jeden primární soubor.
Zde se ukládají všechna důležitá data související s tabulkami, pohledy, spouštěči atd.
Rozšíření je .MDF obvykle, ale může mít jakékoli rozšíření.

Sekundární soubor

Databáze může nebo nemusí obsahovat více sekundárních souborů.
Toto je volitelné a obsahuje data specifická pro uživatele.
Rozšíření je .naf obvykle, ale může mít jakékoli rozšíření.

Log soubor

Také známý jako Zápis předem protokolů.
Rozšíření je .ldf
Používá se pro správu transakcí.
To se používá k zotavení z jakýchkoli nežádoucích instancí. Proveďte důležitý úkol vrácení zpět k nesvěřeným transakcím.

Storage Engine má 3 komponenty; podívejme se na ně podrobně.

Způsob přístupu

Funguje jako rozhraní mezi vykonavatelem dotazu a Buffer Správce/Protokoly transakcí.

Samotná Access Method neprovádí žádné spuštění.

První akcí je určit, zda je dotaz:

Vybrat výpis (DDL)
Non-select Statement (DDL a DML)

V závislosti na výsledku metoda přístupu provede následující kroky:

Pokud je dotaz DDL, příkaz SELECT, dotaz je předán Buffer Manažer k dalšímu zpracování.
A na dotaz jestli DDL, příkaz NON-SELECT, je dotaz předán do Správce transakcí. To většinou zahrnuje příkaz UPDATE.

Buffer Manažer

Buffer manažer spravuje základní funkce pro níže uvedené moduly:

Plán Cache
Analýza dat: Buffer mezipaměť a úložiště dat
Špinavá stránka

Naučíme se plánovat, Buffer a Datová mezipaměť v této části. Špinavé stránky pokryjeme v sekci Transakce.

Plán Cache

Stávající plán dotazů: Správce vyrovnávací paměti zkontroluje, zda je plán provádění v uložené mezipaměti plánů. Pokud Ano, použije se mezipaměť plánu dotazů a její přidružená mezipaměť dat.
Plán první mezipaměti: Odkud pochází existující mezipaměť plánu? Pokud je plán provádění prvního dotazu spuštěn a je složitý, má smysl jej uložit do mezipaměti Plane. To zajistí rychlejší dostupnost, až SQL server příště dostane stejný dotaz. Není to tedy nic jiného než samotný dotaz, který se ukládá provádění plánu, pokud je spuštěn poprvé.

Analýza dat: Buffer mezipaměť a úložiště dat

Buffer správce poskytuje přístup k požadovaným údajům. Níže jsou možné dva přístupy v závislosti na tom, zda data existují v mezipaměti dat nebo ne:

Buffer Cache – Měkká analýza:

Buffer Manažer hledá data v Buffer v mezipaměti dat. Pokud jsou k dispozici, pak tato data používá Query Executor. To zlepšuje výkon, protože se snižuje počet I/O operací při načítání dat z mezipaměti ve srovnání s načítáním dat z datového úložiště.

Úložiště dat – tvrdá analýza:

Pokud data nejsou přítomna v Buffer Správce, než je požadováno Data jsou vyhledávána v Úložišti dat. If také ukládá data do mezipaměti dat pro budoucí použití.

Špinavá stránka

Je uložena jako logika zpracování Správce transakcí. Podrobně se naučíme v sekci Transaction Manager.

Správce transakcí

Správce transakcí se vyvolá, když metoda přístupu určí, že Query je příkaz Non-Select.

Správce protokolů

Správce protokolů uchovává záznamy o všech aktualizacích provedených v systému prostřednictvím protokolů v protokolech transakcí.
Logy mají Zaznamenává pořadové číslo s ID transakce a záznamem o úpravě dat.
To se používá pro sledování Transaction Committed and Transaction Rollback.

Správce zámku

Během transakce jsou přidružená data v úložišti dat ve stavu Lock. Tento proces zajišťuje Správce zámků.
Tento proces zajišťuje konzistence a izolace dat. Také známé jako ACID vlastnosti.

Proces provádění

Log Manager spustí protokolování a Lock Manager uzamkne související data.
Kopie dat je udržována v Buffer mezipaměti.
Kopie dat, která mají být aktualizována, je udržována v Log bufferu a všechny události aktualizují data v Data bufferu.
Stránky, které ukládají data, jsou také známé jako Špinavé stránky.
Protokolování kontrolního bodu a zápisu předem: Tento proces se spustí a označí všechny stránky od Dirty Pages na Disk, ale stránka zůstane v mezipaměti. Frekvence je přibližně 1 běh za minutu. Ale stránka je nejprve přesunuta na datovou stránku souboru protokolu ze Buffer log. Toto je známé jako Napište předem protokolování.
Líný spisovatel: Špinavá stránka může zůstat v paměti. Když SQL server zaznamená velké zatížení a Buffer paměť potřebuje pro novou transakci, uvolní špinavé stránky z mezipaměti. Funguje na LRU – Nejméně nedávno použitý algoritmus pro čištění stránky z fondu vyrovnávacích pamětí na disk.

Shrnutí

Tři typy klientského serveru Archiexistují: 1) Sdílená paměť 2) TCP/IP 3) Pojmenovaná propojení
TDS, vyvinutý společností Sybase a nyní vlastněný společností Microsoft, je paket, který je zapouzdřen do síťových paketů pro přenos dat z klientského počítače na serverový stroj.
Relational Engine obsahuje tři hlavní součásti:CMD Parser: To je zodpovědné za syntaktickou a sémantickou chybu a nakonec vygeneruje strom dotazů.Optimalizátor: Úlohou optimalizátora je najít nejlevnější, nikoli nejlepší, nákladově efektivní plán realizace.
Vykonavatel dotazu: Prováděcí program dotazu volá Access Method a poskytuje plán provádění pro logiku načítání dat potřebnou pro spuštění.
Existují tři typy souborů Primární soubor, Sekundární soubor a Soubory protokolu.
Storage Engine: Má následující důležité součástiMetoda přístupu: Tato komponenta Určuje, zda je dotaz příkazem Select nebo Non-Select. Vyvolá Buffer a podle toho Manažer převodu.Buffer Manažer: Buffer manažer spravuje základní funkce pro mezipaměť plánu, analýzu dat a špinavou stránku.
Správce transakcí: Spravuje Non-Select Transaction s pomocí Log a Lock Managers. Také usnadňuje důležitou implementaci protokolování Write Ahead a Lazy Writer.