![]() |
![]() | ||||||||||||||||||||
TPC-A
V předchozích dílech databázové abecedy jsme uvedli řadu pojmů týkajících se paralelního zpracování transakcí. Lze tušit, že odhadnout výkon transakčního zpracování je obtížné. V průběhu času, kdy transakční systémy dospěly od naivních řešení k pokročilejším, se objevila řada testovacích systémů (benchmarks), které dovolují uživateli porovnat transakční systémy od různých výrobců. Pod termínem benchmark si můžeme představit jistý etalon umožňující nějaké porovnání. V software jde o předpis množiny měření, které je nutné provést, aby mohla být vyhodnocena nějaká vlastnost software, obvykle výkon. Existují tedy nejen testovací systémy pro měření transakčního pracování, ale např. i pro zpracování dotazů a další. Jim Gray, tvůrce příručky věnující se testovacím systémům (The Benchmark Handbook) z r. 1991, doporučuje aby testovací systém:
Nejslavnější takový systém ve světě databází je označován jako TPC-A. TPC-A je test standardizovaný Konsorciem TPC (Transaction Processing Performance Council), které zahrnuje cca 50 výrobců (v roce 1992 mezi ně patřily firmy jako např. IBM, ORACLE, INGRES). Původně šlo o test Debit/Credit publikovaný v časopise Datamation v r. 1985. Konsorcium definovalo ještě další testovací systémy TPC A, TPC B, TPC C a TPC-D pokrývající mnoho různých případů hardwarových konfigurací, typů transakcí atd. Pomocí těchto systémů se měří výkon v počtu transakcí za sekundu (t/s), resp. za hodinu (u TPC-D ale i poměr cena/výkon a další parametry). Je zřejmé, že žádný ze současných výrobců transakčního software nepouští na trh systém, bez publikace výsledků provedení příslušného testu. Test TPC-A modeluje jednoduché bankovní transakce pomocí čtyřech tabulek (viz Tab. 1). Obecně lze pomocí TPC-A testovat i nerelační systémy, tj. místo tabulek může jít o soubory, nicméně předpokládá se splnění vlastností ACID a tedy takto nelze testovat každý jednoduchý systém pro zpracování souborů.
Velikosti tabulek jsou uzpůsobeny předpokládanému zatížení provozu do 100 t/s. Transakce jsou všechny identické - předpokládá se přičtení částky Delta (záporné číslo) k účtu v dané pobočce pro danou pokladnu. Jde vlastně o UPDATE atributu ZŮSTATEK po výběru peněz a to ve třech tabulkách - Účet, Pokladna, Pobočka, takže se jedná o 3 aktualizace. Dále se aktualizuje Historie přidáním záznamu, který dokumentuje pohybu na účtu. Takovou transakci budeme dále nazývat VÝBĚR. Vznik transakce se předpokládá na terminálu se vstupem 100 Byte (hodnoty pro Číslo_účtu, ID_pokladny, ID_pobočky, Delta). Hodnoty vstupu a rovněž tak i řádky v tabulkách jsou generovány náhodně. V testu se potom zkouší paralelní provoz takových transakcí. Další testy se týkají garance vlastností ACID. Např. test na izolaci transakce vychází ze spuštění transakce VÝBĚR, před COMMIT se spustí druhá taková transakce a podle jistého scénáře se testuje, zdali správně probíhá čekání a je-li korektní výsledek. Testy na trvanlivost zase simulují různé chyby a ověřují, zdali se změny správně promítají do deníku transakcí atd. Zaměřme se na chvíli podrobněji na výkonový test. Předpokládá se, že mezi dvěma uživatelskými požadavky na jednom terminálu uplyne v průměru 10 s. Tento cyklus se skládá z doby odezvy a času na přemýšlení uživatele. Je-li jeden uživatel, pak doba odezvy je mnohem menší než 1 s, nicméně se zvyšujícím se počtem uživatelů se provoz zpomaluje. Prakticky test vypadá tak, že se začne s jistým počtem terminálů (samozřejmě jejich simulací), každých 10 s se generuje další transakce. Pak se zvyšuje počet uživatelů až se dosáhne doby odezvy ne větší než 2s u 90% z nich. Toto pravidlo se nazývá kritérium pro dobu odezvy u TPC-A. Při měření se pak musí dosáhnout jakéhosi vyváženého stavu, kdy je toto kritérium při daném počtu paralelních uživatelů splněno. Trvání odpovídajícího časového intervalu je minimálně 15 min. a ne více než 1 hodina. Na základě TPC-A je možné odhalit “úzká hrdla” transakčního systému především ve třech oblastech:
Např. uzamykání stránek (a ne řádků tabulek), tak jak je obvyklé u řady databází, značně snižuje výkon transakčního systému pod TPC-A. Může zapříčit, že výkon je řádově pouze několik desítek TPS. Co se týče zápisů do deníku transakcí, problém je s přístupem na disk, který je omezen, řekněme v průměru 40 I/O operacemi za s. Protože s každým COMMIT transakce musí být proveden zápis do deníku, zdálo by se, že nemůže být provedeno více než 40 t/s. Řešením je, že deníkový buffer obsahuje záznamy pro více transakcí. Ukládání populárních stránek do vnitřní paměti může také podstatně zvýšit výkon transakčního provozu. Představme si pod populární stránkou stránku z disku s dostatečně malým intervalem mezi dvěma přístupy uživatelů. Jim Gray a Franco Putzolu v r. 1987 dospěli k závěru, že tento dostatečně malý interval je 5 min. Tedy je-li doba mezi dvojím použitím jedné stránky větší než 5 min., je možné ji odeslat na disk a naopak. Na jedné straně můžeme zvyšovat vnitřní paměť pro použití jako buffery pro populární stránky, na druhé straně můžeme požadovat více disků pro paralelní čtení stránek do vnitřní paměti (zvýší se počet I/O operací za sekundu). Je zřejmé, že rozhodování o velikostech bufferů pak souvisí s cenami obou typů pamětí. Pravidlo 5 minut lze zdůvodnit výpočty, které vyvažují cenu potřebné vnitřní a vnější paměti. Na základě počtu t/s (v anglických textech se uvádí TPS) se také počítají další ukazatelé, jako např.$COST/TPS. Jde o podíl pětileté ceny celého systému (software a hardware včetně údržby) na jednu transakci. Zatímco test TPC B jen o něco vylepšuje TPC-A (přidává k TPC-A transakci jeden výběr dat na základě podmínky výběru), s TPC C se dostaneme do realističtějšího prostředí. Test obsahuje on-line i dávkové transakce, dále realistické prvky jako jsou rušení transakcí, fronty transakcí. TPC-C již vůbec nesouvisí s TPC-A. Transakce jsou 10x složitější než v TPC A, tj. jsou 10x pomalejší na stejném hardware. Jeho databáze se skládá z 9 tabulek a složitostí transakcí se snaží simulovat složitý OLTP systém. TPC C byl podobně jako TPC-A zlepšen na standard Jeho výsledky se již uvádějí v počtu transakcí za minutu, t./min. V roce 1995 v březnu se objevil TPC-D pojednávající o počtu transakcí za hodinu, který je určen pro provoz na škálovaných databázích (30 GByte, 100 GByte, 300 GByte, ...) Připomeňme, že zmíněné TPC A a B vycházejí z typických jednoduchých bankovních transakcí. Důvod je historický - první transakční systémy byly vyvinuty právě pro bankovní aplikace. Řada dalších použití transakčních systémů oficiálními testy je nepokryta, testování je součástí kuchyně jednotlivých výrobců a je pro různé případy stěží porovnatelné. Případně jsou použity sice známé testy, ale nestandardizované. Patří mezi ně např. tzv. Wiskonsin benchmark (má pevnou množinu 32 dotazů pro měření výkonu dotazovacího režimu), CITY benchmark pro měření transakčního zpracování na velkých databázích, AS3AP a další. Veškeré údaje o TPS a poměru cena/výkon je proto nutné brát s rezervou a klást si otázku, za jakých podmínek skutečně platí.
<seznam dílů seriálu> <COMPUTERWORLD> |