Výkonnost databázových aplikací III

Rád bych navázal na poznámky z minulého čísla a věnoval se
dalším fyzickým charakteristikám nebo, chcete-li, vlastnostem
SŘBD, které přímo souvisejí s výkonností aplikací pracujících
nad daným SŘBD, resp. databází.

Řízení sdíleného přístupu

Mechanismy řízení sdíleného přístupu slouží pro realizaci
víceuživatelského prostředí databázových aplikací. Základním
problém je řešení paralelního přístupu více uživatelů k témže
řádkám určité databázové tabulky. Řízení sdíleného přístupu má
dva hlavní cíle:

- zabezpečení realizace transakcí, tj. mechanismu, kdy buď
všechny změny jedné transakce budou promítnuty do databáze, nebo
nebudou promítnuty do žádné

- zabezpečení vzájemné neovlivnitelnosti transakcí

Již z definice těchto cílů vyplývá, že základní pracovní
jednotkou zmíněných mechanismů jsou transakce. Provádění
transakcí má dva základní dopady:

- dopad na data prováděním příkazů INSERT, UPDATE, DELETE

- dopad na jiné transakce, pakliže tyto načetly data zapsané
danou transakcí

První z dopadů - přímý dopad na data lze eliminovat provedením
operace ROLLBACK s využitím záznamů v log souborech (viz minulá
část seriálu). Eliminace druhého dopadu na jiné transakce je
realizována databázovými zámky. Zámky jsou mechanismy
zabezpečující synchronizaci provádění transakcí v tom smyslu, že
lze jednu transakci ukončit příkazem ROLLBACK bez vlivu na
integritu jiných transakcí, které by jinak pracovaly s daty
vytvořenými nezakomitovanou transakcí.

Pakliže není zabezpečeno dostatečné řízení sdíleného přístupu
(zejména synchronizace transakcí), může to vést k řadě
problémům. Mezi nejčastější patří:

ignorace operace ROLLBACK - abych blíže popsal tento problém,
uvedu časově uspořádané zpracování dvou transakcí:



ztracené aktualizace: k tomuto problému dojde v okamžiku, kdy
dvě či více transakcí přistoupí ke stejným řádkám databáze a
provedou úspěšnou aktualizaci těchto řádek. V případě, že nejsou
k dispozici mechanismy zámků, mohou transakce přepsat poslední
modifikace, aniž se vůbec dozvědí, že k nějakým došlo.

problém nezakomitované závislosti: pokud jedna transakce provede
ROLLBACK, může to (opět v případě, že nejsou k dispozici
mechanismy zámků) způsobit ztrátu změn provedených jinou
transakcí. Problém lze vysvětlit na následujícím příkladu: řádka
je aktualizovaná jednou transakcí, ale tato aktualizace není
zakomitovaná. Poté je aktualizována i druhou transakcí, opět bez
provedení operace COMMIT. Pakliže následně první transakce
provede operaci ROLLBACK, dojde tak ke zrušení i aktualizačních
změn provedených druhou transakcí.

Zámky

SŘBD používají dva vzájemně se vylučující typy zámků: sdílené
zámky (shared locks, S-zámky) a exkluzívní zámky ( exclusive
locks, X-zámky). Dále je obvykle využíván jeden typ dočasných
zámků, tzv. update zámky (U-zámky). Jednotlivé SŘBD se liší
podle toho, na jaké úrovni zámky nastavují - zda na úrovni
databázových stránek či na úrovni jednotlivých řádek. Diskuse o
tom, který z těchto přístupů je lepší, není dosud uzavřena a dle
mého názoru nemá jednoznačný závěr.

Všechny zámky jsou nastavovány implicitně (tj. bez speciálního
požadavku transakce) SŘBD jako reakce na různé DML příkazy
transakce. Jedinou výjimkou je klauzule FOR UPDATE OF příkazu
SELECT, která způsobí explicitní nastavení U-zámku a předpokládá
následnou aktualizaci uzamčených řádek. Možnou koexistenci
jednotlivých typů zámků nad jedinou stránkou, resp. řádkou,
ukazuje následující tabulka:



Pro realizaci uzamykacích operací používají SŘBD protokoly
nazývané izolační úrovně . Tyto protokoly definují, jak dlouho
budou zámky nad danou stránkou, resp. řádkou, nastaveny a jakým
způsobem budou zpřístupňována data pomocí message bufferů.
Izolační úroveň volí transakce v okamžiku otevření prvního
kurzoru a zůstává v platnosti po celou dobu trvání transakce.
Izolační úroveň platí pro všechny kurzory používané transakcí.
Změna izolační úrovně uprostřed transakce způsobí vygenerování
implicitního COMMITu a spuštění nové transakce s novou úrovní
izolace.

Standard SQL-92 definuje následující izolační úrovně:

- serializable (S) - je to defaultní úroveň

- repeatable read (RR) - úroveň povoluje číst pouze komitované
záznamy a dále požaduje, že mezi dvěma čteními záznamu transakcí
nemá žádná další povoleno aktualizovat tato data. Nicméně
transakce nemusí být serializovaná vzhledem k ostatním
transakcím. Např. při hledání záznamů splňujících určité
podmínky může transakce nalézt některé záznamy vložené
komitovanou transakcí, ale nemusí nalézt jiné (dosud
nekomitované)

- read committed (RC) - Úroveň umožňuje číst jen komitované
záznamy, ale nevyžaduje repeatable reads. Např. mezi dvěma
operacemi čtení záznamu jednou transakcí může záznam
aktualizovat jiná komitovaná transakce

- read uncommitted (RU) - umožňuje číst i nezakomitované
záznamy. Je to nejnižší úroveň konzistence povolená standardem
SQL-92

Při návrhu víceuživatelských databázových aplikací je třeba
zvažovat dva protichůdné faktory ovlivňující výběr izolační
úrovně:

- konzistence dat

- sdílený přístup více uživatelů (potažmo i doba odezvy)

Vyšší stupeň konzistence dat je zpravidla zabezpečen na úkor
nižšího stupně sdíleného přístupu a tedy i delší doby odezvy
transakcí. Vztah jednotlivých protokolů k těmto dvěma kritickým
faktorům ukazuje následující schéma:



Indexování

Indexy jako vyhledávací technika nejsou nic nového. Nedávné
archeologické průzkumy dokonce naznačují, že v jisté podobě je
využíval již člověk neandrtálský. V oblasti výpočetní techniky
se zavedly jako prostředek pro snížení počtu diskových I/O
operací (a tedy zkrácení doby odezvy) a byly používány v
několika souborových systémech ještě před nástupem relačních
databází.

Primárním důvodem (ne však jediným) pro vytváření indexu je
zlepšení výkonnosti. Druhý důvod má co do činění s dosažením
unikátnosti mezi řádkami uloženými v databázové tabulce. Tabulky
v relační databázi jsou zpravidla navrženy s primárním klíčem.
Pakliže je do tabulky definované s primárním klíčem vložena nová
řádka, je na SŘBD, aby zajistil, že hodnota primárního klíče pro
tuto řádku je unikátní. V případě, že by SŘBD musela pokaždé,
když se vkládá nový řádek procházet celou tabulku, byla by
výkonnost velmi špatná. Vhodným řešením proto je vytvořit
unikátní index nad primárním klíčem a nechat jej, aby ho SŘBD
využívala jako donucovacího mechanismu pro zajištění unikátnosti
řádek.

Kdy vytvořit a kdy nevytvořit index

Zatímco je takřka povinností vytvořit unikátní index nad
primárním klíčem tabulky, existují i jiné situace, kdy je
použití indexu vhodné. Je ho možné např. využít nad cizím
klíčem. Jelikož je cizí klíč vždy joinován s primárním klíčem
druhé tabulky, bylo by sice možné pro urychlení operace join
využít unikátní index nad primárním klíčem druhé tabulky,
nicméně z důvodů výkonnosti a sdíleného přístupu je vhodné dát
SŘBD možnost použití indexu nad cizím klíčem, a to i v případě,
kdy již existuje index nad primárním klíčem v referenční
tabulce. V praxi se totiž hodnoty cizího klíče objevují jako
omezovací kritéria ve WHERE klauzuli, takže lze využít i
příslušný index.

Index by se dále měl použít i tehdy, když se některé sloupce
často vyskytují ve WHERE klauzuli, a to i v případě, že nejsou
součástí primárního ani cizího klíče. Čím více indexovaných
sloupců ve WHERE klauzuli je, tím více je i pravděpodobné, že
SŘBD bude schopná využít indexy pro zrychlení výkonnosti dotazu.

Existuje tu však i nevýhoda a jakési pravidlo: malý počet indexů
způsobuje pomalé zpracování dotazu, velký počet indexů na druhou
stranu způsobuje pomalé změny v databázi. To je cena, jakou je
třeba za indexy platit: zvýšený overhead, spojený s údržbou
indexů během provádění operací INSERT, UPDATE a DELETE. Cílem
tedy je najít "zlatou" střední cestu mezi oběma extrémy.

Jednou z možností, jak toho dosáhnout, je vyjít ze situací, ve
kterých by se indexy vytvářet neměly.

V první řadě by se neměly vytvářet nad malými tabulkami. Pakliže
jen několik málo diskových operací čtení dokáže prohledat celou
tabulku, pak index vlastně zpomalí celé zpracování, jelikož
vyžaduje minimálně jeden až dvě operace čtení navíc. Co se ale
považuje za malou tabulku? Velikostní limit se liší v závislosti
na hardwaru, operačním systému, SŘBD a velikosti řádky, nicméně
každá tabulka s méně jak 100 řádkami je vhodným kandidátem.

Za druhé, indexy by se neměly vytvářet nad sloupci, které
nabývají jen několika málo hodnot (mají malý definiční obor).
Nejlepším kandidátem pro vytvoření indexu jsou sloupce s
unikátními hodnotami. Naopak sloupce, jež nabývají jen několika
málo hodnot (např. "pohlaví") jsou kandidátem nejhorším. Pro
SŘBD je totiž daleko efektivnější v těchto případech projít
celou tabulku než použít index k nalezení 50 procent řádek.

Dále je třeba si uvědomit, že sloupce obsahující tzv. binary
large object (BLOB - také známé pod označením "long" nebo "raw"
sloupce) nelze indexovat, a že pro to existuje velmi pádný
důvod. Index nad takovým sloupcem by zabral daleko více
diskového prostoru než samotná tabulka a výkonnost by se tudíž
značně snížila. Efektivní přístup k BLOB datům je předmětem
intenzivního výzkumu.