Výkonnost databázových aplikací 1

"Navrhnout databázi a doufat, že navždy zůstane neměnnou,
konstantní, je velmi naivní pohled. Ani sebelepší fyzický návrh
nemůže pro stále se měnící databázi poskytnout konstantně dobrou
výkonnost, a to i přes samo-reorganizační vlastnosti některých
SŘBD."
Shaku Atre, Data Base: Structured Techniques for Design,
Performance and Management, 1980

Dnes je všeobecně znám fakt, že nebyla přesná představa 70. let
(ve kterých kapacity počítačů ve většině oblastí přesahovaly
poptávku), kdy by vývoj v oblasti hardwaru postupně zcela vyřešil
rostoucí požadavky na počítačové systémy a o výkonnost nebude
třeba se více starat. Pokroky v oblasti hardwaru sice umožňují
realizovat nová sofistikovanější softwarová řešení, značnou
pozornost je však třeba věnovat odpovídající konfiguraci celého
systému a zejména pak jeho výkonnosti.
Problematice výkonnosti je věnován i tento seriál článků,
v němž bych rád poukázal na některé podstatné problémy, jež
souvisejí s tímto pojmem. Celý seriál je rozčleněn do tří částí:

1. první část se bude obecně zabývat pojmem výkonnost, poukazuje na přístupy zohledňování výkonnostních požadavků v dnešních softwarových aplikacích a stručně se dotýká i měření výkonnosti;

2. druhá část je zaměřena již na konkrétní typ softwaru, a sice na databázové aplikace typu klient/server, které představují dnes nejobvyklejší architekturu řešení aplikačního softwaru;

3. třetí část je věnována databázovým serverům, klíčové komponentě databázových aplikací a některým jejich možnostem řízení výkonnosti.

Na úvod se vraťme obecně k pojmu výkonnost . Tato
problematika je podstatným, často však zanedbávaným aspektem
vývoje softwaru. U klasických informačních systémů jsou úvahy
o výkonnosti často spojovány s pojmy jako doba odezvy
uživatelských transakcí, u systémů pracujících v reálném čase
(tzv. reaktivních systémů) pak spíše s přesností a spolehlivostí
systému. Tvůrci každého systému usilují (ať to již deklarují či
nikoliv) o dosažení tzv. výkonnostní rovnováhy . Systém je
z hlediska výkonnosti vybalancovaný, jestliže požadavky na zdroje
odpovídají kapacitě počítače a zároveň pokud systém splňuje
výkonnostní požadavky.
Již z výše uvedeného bude pochopitelné, že se
v souvislosti s výkonností rozvíjí další oblast informatiky,
která se nazývá výkonnostní inženýrství (Performance
Engineering). Jejím úkolem je definovat nástroje, které umožní
vývojářům dosáhnout výkonnostních požadavků uživatelů, a to
nikoliv na úkor požadavků jiných. Výkonnostní inženýrství
zahrnuje dvě základní disciplíny:

a) metody vývoje softwarového systému, zohledňující výkonnostní
požadavky

b) řízení výkonnosti implementovaného systému


ad a) Dnes je již neoddiskutovatelným faktem, že výkonnost je
záležitostí celého životního cyklu projektu. V současné době lze
rozlišit dvě hlavní skupiny přístupů k vývoji softwaru z hlediska
výkonnosti:

- Tradiční metody vývoje softwaru, které se soustředí zejména na
přesnost a spolehlivost, otázku výkonnosti odkládají až na
pozdější fáze životního cyklu (tj. zavádění a testování).
Jestliže se v těchto fázích objeví problémy s výkonností, řeší se
nákupem dodatečného hardwaru nebo "tuningem" softwaru. Tento
přístup byl akceptovatelný v 70. letech, ale v 80. letech se již
významně zvýšila poptávka po počítačových zdrojích. Zvýšila se
komplexnost systémů, zatímco se proporcionálně snížil počet
vývojářů se schopností řídit výkonnost. To mělo nepříjemné
následky, z nichž mnohé nemohly být řešeny dodatečným hardwarem
(platformy s požadovaným výkonem ještě neexistovaly), ani
tuningem (opravy vyžadovaly podstatné zásahy do návrhu a tím
reimplementaci). Jejich řešení v pozdějších fázích životního
cyklu mělo za následek zvýšení nákladů na vývoj, zpoždění
realizace, nebo nepříznivě ovlivnilo jiné požadavky na systém,
jako srozumitelnost, udržovatelnost, univerzálnost.

- Metody podporující techniky, které lze využít pro ohodnocení
a srovnávání výkonnostních charakteristik návrhu. Mezi tyto
techniky patří:

- modely sítí front
- Petriho sítě
- kvantitativní modely
- CASE nástroje; některé z těchto nástrojů (CardTools) mají
funkce pro analýzu výkonnosti či nabízejí interface k simulátorům
výkonnosti (Teamwork -> ADAS)
- formální metody založené na matematických postupech
a notacích (neumožňují navrhnout, jak splnit určité požadavky)

Přístupy v této oblasti lze rozlišit na:

- přístupy orientované na operační systém
- přístupy zaměřené na alokaci zdrojů
- softwarově orientované přístupy

a vyznačují se snahou určitým způsobem řidit výkonnost již během
vývoje systému. Příkladem softwarově orientovaného přístupu je
Software Performance Engineering (SPE).

ad b)

Řízení výkonnosti lze rozdělit do tří disciplin:

- odhady výkonnosti,
- měření výkonnosti (monitoring)
- zlepšování výkonnosti (tuning).

Cílem řízení výkonnosti je poskytnout uživatelům nejrychlejší
možný přístup k datům, která potřebují, při využití dostupných
zdrojů co nejúčinněji a nejefektivněji. Tyto zdroje zahrnují
prostor pro zpracování, čas zpracování a lidský čas. Prostor pro
zpracování představuje vnitřní paměť a diskový prostor, čas
zpracování zahrnuje dobu zpracování na CPU a dobu pro realizaci
I/O operací, lidský čas odpovídá reálné době odezvy pro koncového
uživatele.
Většina aplikačního softwaru (a obraťme se již zde přímo
na databázové aplikace) - bez ohledu na to, jak dobře je navržen
- je náchylná k špatné výkonnosti na té či oné úrovni. Příčinou
je entropie. Entropie se popisuje jako tendence k chaosu. Tato
tendence se dříve či později projeví v každé databázi, která není
soustavně ošetřována z hlediska výkonnosti. Příkladem může být
vkládání lineárních klíčových hodnot do nevybalancované stromové
struktury: Jedna větev stromu neustále roste, zatímco ostatní
nerostou, nebo se dokonce zkracují; výsledkem je kosá stromová
struktura a velmi špatná výkonnost. Dalším příkladem jsou
hashované či klusterované indexy, které přerostou do dlouhých
overflow řetězců, jež zvyšují soupeření při zamykání databázových
stránek; nebo změny v uložených informacích, velké objemy nových
informací, nové přístupové cesty k uloženým datům nebo změny
v typickém chování koncových uživatelů.
Samozřejmě že výkonnost významně ovlivňuje vedle entropie
několik dalších faktorů. Patří mezi ně např. to, jak a kde je
SŘBD (Systém Řízení Báze Dat) instalovaná, jak je databázový
server konfigurován, jak a kde se provádějí logovací a zamykací
funkce, a - ze všeho nejdůležitější - návrh databáze a databázové
aplikace.
V tomto dílu bych se nejprve krátce zastavil u problematiky tuningu , ke které se později vrátíme. Tento pojem obecně znamená "ladění" a nejčastěji je využíván ve smyslu optimalizace výkonnostních charakteristik již implementovaného
systému. V tomto smyslu jej dále chápu i já. Proces tuningu je
možné definovat jako iterativní proces identifikace slabého místa
a změny příslušných výkonnostních charakteristik změnou způsobu
provádění dané aktivity. Takto lze tuning chápat i jako jakési
"nouzové" řešení, snižující univerzálnost, transparentnost
a udržovatelnost systému. Při realizaci tuningu se totiž
zpravidla objeví řešení, které by bylo efektnější, ale jehož
realizace se již nevyplatí.
Tuning je iterativní proces vylepšování výkonnostních
charakteristik implementovaného systému na základě následujícího
postupu:

1. identifikace slabého místa
2. pokus o vylepšení výkonnostních charakteristik tak, že se
mění to, jak daná komponenta realizuje přidělenou operaci

Tuning je možné provádět v zásadě ve třech oblastech:

- hardware
- základní software
- aplikační software.

Pro případ databázových aplikací je možné tyto tři základní
oblasti ještě modifikovat na:

- hardware a operační systém,
- SŘBD
- aplikační software.

Ve světě panuje značná nejednotnost ohledně přesného
postupu tuningu, tj. zda se má nejprve optimalizovat aplikační
nebo základní software. Dodavatelé databází doporučují nejprve
ladit aplikaci a databázi, pak teprve operační systém. Systémoví
programátoři se zas naopak kloní nejprve k ladění operačního
systému. Tento spor je způsoben mimo jiné i tím, že dnes je
k dispozici řada nástrojů pro optimalizaci jednotlivých komponent
systému, tj. SŘBD, operačního systému i vlastní aplikace, bohužel
však tyto nástroje pracují do značné míry autonomně a není
k dispozici nástroj, který by realizoval optimalizaci komplexně.
Podle mého názoru je třeba před tím, než se začne optimalizovat
SŘBD a aplikace, mít dobře nakonfigurován hardware
a optimalizován operační systém. Těmto dvěma komponentám
výpočetního systému se však v našem seriálu věnovat nebudeme
a zaměříme se na SŘBD a aplikační software.

V případě SŘBD lze ladění provádět

- na úrovni hardwaru: přidání disků, užití RAID systémů
(v případě problémů s diskovými I/O operacemi), přidáním paměti
(v případě problémů s buffery), výměna CPU (v případě problémů
s využitím CPU)
- na úrovni parametrů databázového systému: velikost
bufferů, interval checkpointů
- na úrovni návrhu (nejvyšší úroveň): definice databázového
schématu (normalizace jen do určité úrovně, či denormalizace)
a transakcí (optimalizace dotazu, užití uložených procedur,
zkrácení aktualizačních transakcí), definice indexů (je-li slabým
místem dotaz, je možná třeba přidat index, je-li slabým místem
aktualizace, je možná třeba index ubrat, volba typu indexu
- B-tree, hashovaný, klusterovaný)

Všechny tři úrovně spolu spolupracují. Je třeba je zvažovat
najednou. Např. tuning na nejvyšší úrovni může způsobit problémy
v oblasti HW.

V oblasti aplikačního softwaru je nutno se zaměřit zejména
na:
- efektivnost algoritmu zapsaného ve zdrojovém kódu;
v dalších částech seriálu efektivnost předpokládám a nebudu se jí
z důvodu rozsahu dále věnovat, je však třeba vědět, že se jedná
o nezanedbatelnou součást
- formulaci dotazů, což do značné míry souvisí
i s optimalizéry databázových serverů
- metodám přístupu k datovým zdrojům