Výkonnost databázových aplikací (2)

V dnešní části seriálu se budu věnovat výkonnosti databázových

strojů. Zmíním se o:



- způsobu porovnání výkonnosti databázových serverů; tak jak se

tyto nástroje stávají více a více standardizovanými, je totiž

jejich výkonnost jedním z hlavních rozlišovacích faktorů



- některých fyzických charakteristikách databázových strojů,

které ovlivňují výkonnost databázové aplikace i přístup k jejímu

návrhu



Porovnávání výkonnosti



V případě databázových serverů se podobně jako v případě jiných

technologických nástrojů používají pro vzájemné srovnání tzv.

benchmark testy. Výkonnostní benchmark testy představují sadu

úkolů, které jsou používány pro kvantifikování výkonnosti

systému. Sada úkolů je nezbytná proto, že jeden ze systémů může

být nejefektivnější vzhledem k jednomu úkolu a jiný vzhledem

k jinému.



Sérii benchmark standardů pro databázové systémy definovala

americká organizace Transaction Processing Performance Council

(TPC) a tyto standardy jsou zaměřeny na obě největší třídy

dnešních databázových aplikací: online transaction processing

(OLTP) a decision support (včetně online analytical processing –

OLAP). Obě tyto třídy úloh mají odlišné požadavky. Vysoký stupeň

sdíleného přístupu a chytré techniky pro urychlení procesu

komitování jsou na jedné straně požadovány u systémů s vysokým

stupněm aktualizačních transakcí (OLTP). Na straně druhé systémy

pro podporu rozhodování vyžadují dobré algoritmy vyhodnocení a

optimalizace dotazu. Architektura určitých databázových systémů

byla laděna pro transakční zpracování, jiných zas spíše pro

podporu rozhodování. Někteří dodavatelé se snaží balancovat mezi

oběma typy úloh.



Aplikace typicky zahrnují požadavky obou typů úloh – jak

transakčního zpracování, tak i podpory rozhodování. O tom, který

databázový stroj je lepší pro tu kterou aplikaci, tedy rozhoduje

vzájemný poměr obou typů požadavků.



Některé fyzické charakteristiky databázových strojů ve vztahu k výkonnosti



Databázové soubory



Kromě otevřeného vlastního databázového souboru může relační

databázový stroj (SŘBD) potřebovat pro svoji práci otevřít

zejména následující typy souborů:



- log soubory (transaction log files)



- dočasné soubory



- soubor chyb







Log soubory (transaction log files)



Log soubor obsahuje části databáze před a po změně a dále pak

tzv. log záznamy pro řízení transakcí. Jde o zaznamenání, kdy

transakce začala a jak skončila. Log soubory mají trojí význam:



1. rollback – soubory obsahují data nezbytná pro rollback

transakce



2. Crash recovery – soubory obsahují data nezbytná pro

zpětné uvedení databáze do konzistentního stavu po zhroucení

databáze z důvodu výpadku elektrického proudu nebo chyby

operátora (např. neregulérní „shození“ serveru)



3. Media recovery – log soubory, pakliže jsou zálohovány

spolu s databázovými, obsahují data nezbytná pro obnovení

databáze v případě poškození paměťového média



Log soubory pomáhají zabezpečit konzistenci dat. Pokud se

transakce řádně neukončí, nebo v případě chyby systému či média,

užívá SŘBD log soubory k obnově databáze do jejího původního

stavu.



SŘBD vytváří log soubor v okamžiku prvního připojení se

k databázi. Tak jak dochází ke změnám, přibývají log záznamy

dokumentující tyto změny. V okamžiku, kdy aktuální log soubor

dosáhne určené maximální velikosti, SŘBD vytváří log soubor

nový. Interně log soubory obsahují časové značky a další hodnoty

sloužící pro to, aby je SŘBD byl schopen identifikovat ve

správném pořadí. Vytvořené log soubory jsou SŘBD automaticky

uvolňovány v okamžiku, kdy již nejsou potřeba.



Z hlediska výkonnosti má značný význam umístění log

souborů, a to zejména vzhledem k vlastnímu databázovému souboru.

Defaultně jsou tyto dva typy souborů ukládány na stejný disk.

Přesměrování umístění log souborů může přispět ke zlepšení

výkonnosti (možnost paralelních I/O operací). Kromě toho se

obvykle provádí s cílem zvýšit diskovou kapacitu pro log soubory

a zvýšit odolnost systému (je málo pravděpodobné, že v jeden

okamžik zhavarují dva disky).



Dalším aspektem ovlivňujícím výkonnost je velikost log

souboru – tu lze měnit a pohybuje se řádově ve stovkách

kilobytů, resp. v několika megabytech. Velký log soubor zlepšuje

výkonnost databáze, jelikož není třeba tak často vytvářet nové

logy. Je-li však log soubor příliš veliký, zatěžuje to diskovou

kapacitu.



Dočasné soubory



V průběhu své činnosti může SŘBD vytvářet několik typů dočasných

souborů, a to zejména:



- třídicí soubory



- soubory k obecnému použití



Obecně platí, že vytváření těchto dočasných souborů opět

zpomaluje zpracování. Je proto velmi dobré, aby správce databáze

průběžně sledoval a analyzoval výskyt takovýchto souborů.







Třídicí soubory



Třídicí soubory obsahují konečný result set třídění

definovaného klauzulí DISTINCT, ORDER BY, GROUP BY nebo CREATE

INDEX. Pro každou třídicí klauzuli vytváří SŘBD obvykle jeden

třídicí soubor.



Obecně použitelné soubory



Tyto soubory obsahují result sety, dočasné tabulky, dočasné

indexy používané při zpracování joinu.



Databázové stránky



Stránka je základní datová struktura databázového souboru a

jednotka fyzického ukládaní v databázi. Databázový soubor se

skládá z řady stránek různého typu, ale stejné velikosti.

Typická velikost stránky se pohybuje v řádu několika kilobytů

(např. 2KB), resp. jejich násobků.



Obecně lze typy databázových stránek rozdělit v zásadě do třech

kategorií:



- datové stránky, obsahující vlastní data



- indexní stránky, obsahující informace pro přímý přístup k datům



- řídící stránky, na nichž si SŘBD ukládá interní informace,

které se využívají např. pro alokaci nových databázových

stránek, řízení logování transakcí, apod.



Pakliže se opět zaměříme na výkonnost databázové aplikace, je

možné konstatovat, že obecně mají na výkonnost negativní vliv

takové databázové stránky, které představují dodatečné požadavky

na operace čtení a zápisu. Patří sem zejména stránky pro

uchovávání tzv. dlouhých dat, tj. dat, jež mají ve fyzickém

návrhu přiřazen datový typ LONG (LONGCHAR, LONGVARCHAR). Dále

sem patří i tzv. rozšiřující stránky používané v případě, že se

určitá řádka tabulky nevejde na jednu datovou stránku. Oba

uvedené případy mají jedno společné: řádka tabulky je uložena na

více než jedné datové stránce. Je velmi pravděpodobné, že

stránky obsahující data jedné řádky nebudou uloženy ve stejném

fyzickém bloku, a tudíž pro načtení celé řádky bude zapotřebí

více operací čtení.



Cílem by tedy měla být minimalizace počtu rozšiřujících stránek.

Nástrojem pro realizaci tohoto cíle je pravidelná reorganizace

databáze, či v případě tabulek, u nichž se předpokládá

rozšiřování řádek vlivem aktualizace, je nutno nastavit větší

rezervovanou oblast pro rozšiřování (PCTFREE). Dále by v

případě, že se průměrná velikost řádky blíží použitelné

velikosti stránky, mělo dojít k rozdělení databázové tabulky na

dvě.



V případě stránek obsahujících „dlouhá“ data by měla být

popsaná fakta respektována a aplikační programy by se měly

vyvarovat dotazů typu SELECT *, kdy jsou na klienta přenášena

všechna data.







Databázová cache



Pro optimalizaci databázového vstupu a výstupu užívá SŘBD cache

paměť. Jde o část hlavní paměti počítače na stroji databázového

serveru, jež obsahuje kopie , které uživatel čte a zapisuje do

nich.



V okamžiku, kdy uživatel čte nebo zapisuje řádku či

index, SŘBD zjišťuje, zda stránka, v níž se příslušný řádek či

index nachází, je v cache či nikoliv. Pakliže tomu tak není,

zkopíruje ji do cache. Pokud stránka v cache již je, server

použije tuto kopii. Tento proces redukuje diskové I/O operace.



Při implicitním či explicitním komitu SŘBD zapisuje

záznam o komitu do log souboru. Nicméně databázové stránky v

cache paměti se zapisují zpět do databázového souboru na základě

LRU (least-recently used) algoritmu. Informace v log souboru

jsou dostačující k aktualizaci databáze v případě jejího

zhroucení, takže není nezbytně nutné stránku ukládat na disk

bezprostředně po komitu.



Aby se minimalizovala doba, po niž je třeba provádět

crash recovery, používají SŘBD obvykle mechanismus tzv. fuzzy

checkpointingu. Tento pojem znamená, že změněné databázové

stránky jsou v cache paměti během jednoho kontrolního okamžiku

(checkpoint) označeny a během dalšího pak zapsány na disk,

pakliže se tak již nestalo v rámci běžné správy cache paměti. V

závislosti na typu klientské aplikace mohou operace prováděné v

kontrolních bodech silně ovlivňovat výkonnost. V okamžiku, kdy k

tomu dochází, je možné zvýšit interval mezi jednotlivými

kontrolními body.



(Příště: Řízení sdíleného přístupu a indexování)