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í)