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