LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> Transakční test TPC-B - popis

Podíváme se podrobněji na databázové testy TPC-A a TPC-B.

27.9.2010 00:00 | Radim Kolář | Články autora | přečteno 5038×

TPC-A/B databázové schema

Při popisu TPC-A/B testu začneme u databázového schema. To je velmi jednoduché a tvoří ho 4 tabulky.

Schema simuluje banku s pobočkami (branch), účty (account), pokladnami (teller) a záznamy o trasakcích (history). Každá pobočka má 10 pokladen, 100 000 účtů a 10 terminálů (terminály jsou pouze u TPC-A). U TPC-B jsou transakce inicializovány driverem, zato v TPC-A jsou inicializovány z terminálů. U transakcí inicializovaných z terminálů je definován minimální střední čas mezi transakcemi 10 sekund a výsledné tps (počet transakcí za sekundu) musí být maximálně 1/10 na terminál. U TPC-B musí dosažené tps maximálně rovno počtu simulovaných poboček. Toto pravidlo platí i v případě TPC-A, ale tam je výsledné tps limitováno mnohem více počtem připojených terminálů, protože na jednu transakci je časové okno 10 sekund. Doba zpracování transakce není neomezená, 90% transakcí musí být provedeno do 2 sekund.

Struktura tabulek je jednoduchá:

BRANCHES (BID PRIMARY KEY, BALANCE NUMERIC(10)
TELLERS  (TID PRIMARY KEY, BID REFERENCES BRANCHES, TBALANCE NUMERIC(10))
ACCOUNTS (AID PRIMARY KEY, BID REFERENCES BRANCHES, ABALANCE NUMERIC(10))
HISTORY  (BID REFERENCES BRANCHES, TID REFERENCES TELLERS,
             AID REFERENCES ACCOUNTS, DELTA NUMERIC(10), TIME TIMESTAMP)

Velikost datových typů u položek není specifikována až na BALANCE a DELTA, které musí mít alespoň 10 číslic a TIME, který musí mít rozlišovací schopnost minimálně 0,1 sekundy. Velikost primárních klíčů musíme stanovit tak abychom byli schopni uložit specifikací požadované množství řádků. Největší tabulka je ACCOUNTS, kde nám bude primární klíč AID stačit pro domácí testování ve velikosti INT4.

Scale up

Počty záznamů a terminálů musí udržovat odpovídající poměr. Pokud použijeme 200 terminálů tak musíme mít také 200 pokladen (poměr mezi terminály a pokladnami je 1:1) a 20 poboček (poměr mezi pobočkami a pokladnami je 1:10). S tímto nastavením můžeme dosáhnout maximálně 20 tps, protože jsme omezeni jednak počtem poboček a jednak deseti sekundami mezi transakcemi na terminál. U TPC-B se na desetisekundový rozestup transakcí nehraje, takže naměřit sice můžeme i výrazně více, ale transakce nad 20 nebudou uznány z důvodů nedodržení předepsaného počtu záznamů v tabulkách. Výsledek testu se zveřejňuje v jednotkách s písmenem označující příslušný test tpsA nebo tpsB. Jak jsem již napsal minule, jedná se o rozdílné, ačkoliv velmi podobné, testy a nelze výsledky zaměňovat. Publikované hodnoty musí být dosažené v plně doloženém testu, publikace interpolovaných hodnot není povolena.

Protože rozdílné databáze ukládají data různě, byla specifikována minimální velikost řádky a zakázána komprese. Minimální velikost řádky v tabulkách BRANCHES, TELLERS a ACCOUNTS je 100 bajtů a v tabulce HISTORY 50 bajtů. Velikost řádky se obvykle zarovnává přidáním sloupce FILL typu CHARACTER. Prostor v řádce s nespecifikovanou hodnoutou je možné použít pro index nebo pro řídící struktury databáze. Pravidlo o zarovnávání řádků na požadovanou délku lze tedy shrnout jednoduše: tabulka ACCOUNTS se 10M záznamy musí na disku zabírat minimálně 1GB.

Testovací transakce

TPC-A/B testy vykonávají transakce které vypadají takto:

BEGIN TRANSACTION
Update Account where Account_ID = Aid:
Set Account_Balance = Account_Balance + Delta
Read Account_Balance from Account
Write Account_Balance to Account

Write to History:
Aid, Tid, Bid, Delta, Time_stamp

Update Teller where Teller_ID = Tid:
Set Teller_Balance = Teller_Balance + Delta
Write Teller_Balance to Teller

Update Branch where Branch_ID = Bid:
Set Branch_Balance = Branch_Balance + Delta
Write Branch_Balance to Branch
COMMIT TRANSACTION

Return Account_Balance to driver

Jedná se o transakci aktualizující všechny čtyři tabulky. Požadováno je vrácení nového stavu účtu, takže při použití klasického SQL je to 3x UPDATE, 1x INSERT a 1x SELECT. Při použití specifických dialektů databází vystačíme se 3x UPDATE a 1x INSERT, protože databáze nabízejí nestandardní způsoby jak vracet hodnoty z příkazu UPDATE.

Hodnota transakce je v rozmezí od -999999 do 999999. 85% transakcí je domácích (transakce probíhá na pobočce BRANCH na které je veden účet) a 15% z jiné pobočky. Hodnoty TELLER se volí náhodně. Test musí probíhat 15 minut až jednu hodinu a diskový prostor musí být dostatečný pro uložení HISTORY za 8 hodin. Referenční integrita pomocí FOREIGN KEYS není vyžadována a protože snižuje výkon tak nebyla v TPC-B používána. Já jsem se jí ve svém testu rozhodl použít, protože v dnešním reálném nasazení se téměř vždy používá.

ACID testy

TPC-A/B test předepisuje ACID testy, které musí každá implementace splnit. Tyto testy ověřují konzistenci databáze, správnou funkčnost databázového engine a správnou implementaci testu. Všechny současné databáze podporující transakce jimi projdou bez problémů. S vyjímkou MySQL/MYISAM jsem nenašel databázi která by v testech selhala.

Atomicita

Transakce se musí provést buďto úplně celá nebo nesmí zanechat žádné změněné řádky. Test na atomicitu vykoná transakci s potvrzením COMMIT a pak SELECTy ověří zda byly správně aktualizované položky ve všech tabulkách. V druhé půlce testu je provedena transakce ale místo COMMIT je použit ROLLBACK. Spustíme stejné SELECTy ale data musí být nezměněná.

Konzistence

Test konzistence ověřuje zda jsou údaje tabulkách navzájem konzistentní. Pokud je obsluha chyb v transakci správně naprogramována - provádí rollback při chybě a není chyba v databáze enginu tak by měl tento test dopadnout vždy správně.

Data jsou konzistentní pokud:

  1. součet zůstatků účtů je stejný jako součet zůstatek pokladen a ten je stejný jako součet zůstatků poboček.

  2. V každé pobočce musí součet stavu pokladen pobočky odpovídat stavu pobočky

  3. V tabulce HISTORY musí být jeden záznam pro každou dokončenou transakci, žádný záznam pro zrušenou transakci a součet DELTA sloupce musí být stejný jako součet DELTA všech potvrzených transakcí.

  4. Pokud jsou data replikována na více uzlů, musí mít každý uzel konzistentní data.

Test na konzistenci překontroluje stav tabulek podle výše uvedených pravidel, pak provede 10 000 transakcí a překontrolují se data znova.

Izolace

Správná izolace současně prováděných transakcí musí zajistit stejný výsledek jako kdyby se transakce prováděli postupně jedna za druhou. Je vyžadováno aby čtení stejných záznamů v transakci vracelo vždy stejná data. Je tedy vyžadována úroveň izolace REPEATABLE READ.

Pro testování správné vzájemné izolace se používají dva testy:

  1. Test potvrzených transakcí

    1. Proveďte transakci bez potvrzení COMMIT.
    2. Připojte se do databáze znova a v druhé transakci se pokuste aktualizovat stejný pár hodnot AID, BID, TID jako v první transakci.
    3. Překontrolujte že druhá transakce čeká na dokončení první.
    4. Dokončete první transakci COMMITem.
    5. Druhá transakce by měla obdržet požadované zámky a dokončit se.
    6. Překontrolujte že hodnoty byly správně aktualizovány a zahrnují stav po provedení obou transakcí.
  2. Test odvolaných transakcí

    1. Proveďte transakci bez potvrzení COMMIT.
    2. Připojte se do databáze znova a v druhé transakci se pokuste aktualizovat stejný pár hodnot AID, BID, TID jako v první transakci.
    3. Překontrolujte že druhá transakce čeká na dokončení první.
    4. Odvolejte první transakci ROLLBACKem.
    5. Druhá transakce by měla obržet uvolněné zámky a dokončit se.
    6. Překontrolujte že hodnoty byly správně aktualizovány a zahrnují stav po provedení druhé transakce.

Trvanlivost

Trvanlivost znamená že jakmile je transakce potvrzena tak je databáze se schopna obnovit do stavu po potvrzené transakci. Systém musí být navržen tak aby odolal

  1. Selhání média které obsahuje databázi, tabulky nebo recovery logy. Pouze v tomto případě je povoleno rollforward recovery ze zálohy a recovery logů, takže se dá TPC-A/B splnit i bez mirrorovaných disků pokud se databáze umí vyrovnat se zničením disku obsahujícím recovery logy a přesto se korektně ukončit tak aby při dalším startu recovery logy k obnově nepotřebovala.

  2. Havárie systému vyžadující obnovu rebootem - kupříkladu kernel panic nebo zamrznutý systém v důsledku HW chyby. Použití zálohy pro obnovu je zakázáno.

  3. Selhání části nebo celé operační paměti. Použití zálohy pro obnovu je zakázáno.

Verze pro tisk

pridej.cz

 

DISKUZE

Test trvanlivosti 28.9.2010 10:32 Tomáš 'Heron' Crhonek
  L Re: Test trvanlivosti 30.9.2010 10:34 Radim Kolář




Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

15.5.2017 23:50 /František Kučera

Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě DIY, CNC, SDR nebo morseovka? Přijď na sraz spolku OpenAlt, který se bude konat ve čtvrtek 18. května od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).


Přidat komentář

12.5.2017 16:42 /Honza Javorek
PyCon CZ, česká konference o programovacím jazyce Python, se po dvou úspěšných ročnících v Brně bude letos konat v Praze, a to 8. až 10. června. Na konferenci letos zavítá např. i Armin Ronacher, známý především jako autor frameworku Flask, šablon Jinja2/Twig, a dalších projektů. Těšit se můžete na přednášky o datové analytice, tvorbě webu, testování, tvorbě API, učení a mentorování programování, přednášky o rozvoji komunity, o použití Pythonu ve vědě nebo k ovládání nejrůznějších zařízení (MicroPython). Na vlastní prsty si můžete na workshopech vyzkoušet postavit Pythonem ovládaného robota, naučit se učit šestileté děti programovat, efektivně testovat nebo si v Pythonu pohrát s kartografickým materiálem. Kupujte lístky, dokud jsou.
Přidat komentář

2.5.2017 9:20 /Eva Rázgová
Putovní konference československé Drupal komunity "DrupalCamp Československo" se tentokrát koná 27. 5.2017 na VUT FIT v Brně. Můžete načerpat a vyměnit si zkušenosti z oblasti Drupalu 7 a 8, UX, SEO, managementu týmového vývoje, využití Dockeru pro Drupal a dalších. Vítáni jsou nováčci i experti. Akci pořádají Slovenská Drupal Asociácia a česká Asociace pro Drupal. Registrace na webu .
Přidat komentář

1.5.2017 20:31 /Pavel `Goldenfish' Kysilka
PR: 25.5.2017 proběhne v Praze konference na téma Firemní informační systémy. Hlavními tématy jsou: Informační systémy s vlastní inteligencí, efektivní práce s dokumenty, mobilní přístup k datům nebo využívání cloudu.
Přidat komentář

15.4.2017 15:20 /František Kučera
Máš rád svobodný software a hardware nebo se o nich chceš něco dozvědět? Zajímá tě IoT a radiokomunikace? Přijď na sraz spolku OpenAlt, který se bude konat ve středu 19. dubna od 18:30 v Šenkovně (Sokolská 60, Praha 2).
Přidat komentář

5.3.2017 19:12 /Redakce Linuxsoft.cz
PR: 23. března proběhne v Praze konferenci na téma Cloud computing v praxi. Hlavními tématy jsou: Nejžhavější trendy v oblasti cloudu a cloudových řešení, Moderní cloudové služby, Infrastruktura současných cloudů, Efektivní využití cloudu, Nástrahy cloudových řešení a jak se jim vyhnout.
Přidat komentář

27.2.2017 22:12 /František Kučera
Pozvánka na 137. sraz OpenAlt – Praha: Tentokrát jsme si pro vás připravili neobvyklou akci. Ve středu 1.3. v 17:30 nás přivítá sdružení CZ.NIC ve svých prostorách v Milešovské ulici číslo 5 na Praze 3, kde si pro nás připravili krátkou prezentaci jejich činnosti. Následně navštívíme jejich datacentrum pod Žižkovskou věží. Provedou nás prostory, které jsou běžnému smrtelníkovi nedostupné!
Po ukončení prohlídky se všchni odebereme do hostince U vodoucha, Jagelonská 21, Praha 3 pochutnat si na některém z vybraných piv či dát si něco na zub. Rezervaci máme od 19:30, heslo je OpenAlt.
Ale pozor! Do prostor datového centra máme omezený přístup, dostane se tam pouze 10 lidí! Takže kdo přijde dříve, ten má přednost, a občanky s sebou! Kdo nebude chtít na prohlídku datového centra, může se pomalu přesunout do hostince U vodoucha a u nepřeberné nabídky piv počkat na ostatní.
Přidat komentář

18.1.2017 0:49 /František Kučera
Členové a příznivci spolku OpenAlt se pravidelně schází v Praze a Brně. Fotky z pražských srazů za uplynulý rok si můžete prohlédnout na stránkách spolku. Příští sraz se koná už 19. ledna – tentokrát je tématem ergonomie ovládání počítače – tzn. klávesnice, myši a další zařízení. Také budete mít příležitost si prohlédnout pražský hackerspace Brmlab.
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

15.6.2017 9:34 / Ondřej Havlas
php,

10.6.2017 10:39 / Temple
sell home for cash

11.5.2017 23:32 / lelo
Re: Problém se správcem balíčků

11.5.2017 5:45 / davd mašek
Re: Problém se správcem balíčků

10.5.2017 22:54 / lelo
Re: Problém se správcem balíčků

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2017) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze