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 5370×

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ů

23.5.2018 20:55 /Ondřej Čečák
Od pátku 25.5. proběhne na Fakultě informačních technologií ČVUT v Praze openSUSE Conference. Můžete se těšit na spostu zajímavých přednášek, workshopů a také na Release Party nového openSUSE leap 15.0. V na stejném místě proběhne v sobotu 26.5. i seminář o bezpečnosti CryptoFest.
Přidat komentář

20.5.2018 17:45 /Redakce Linuxsoft.cz
Ve čtvrtek 31. května 2018 připravuje webový magazín BusinessIT ve spolupráci s Best Online Média s.r.o. pátý ročník odborné konference Firemní informační systémy 2018. Akce proběhne v kongresovém centru Vavruška (palác Charitas), Karlovo náměstí 5, Praha 2 (u metra Karlovo náměstí) od 9:00 hod. dopoledne do cca 15 hod. odpoledne. Konference je zaměřena na efektivní využití firemních informačních systémů a na to, jak plně využít jejich potenciál. Podrobnější informace na webových stránkách konfrence.
Přidat komentář

14.5.2018 7:28 /František Kučera
Květnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 17. 5. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát na téma: Audio – zvuk v GNU/Linuxu.
Přidat komentář

7.5.2018 16:20 /František Kučera
Na stránkách spolku OpenAlt vyšla fotoreportáž Pražské srazy 2017 dokumentující srazy za uplynulý rok. Květnový pražský sraz na téma audio se bude konat 17. 5. 2018 (místo a čas ještě upřesníme).
Přidat komentář

17.4.2018 0:46 /František Kučera
Dubnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 4. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tématem tohoto srazu bude OpenStreetMap (OSM) aneb svobodné mapy.
Přidat komentář

16.3.2018 22:01 /František Kučera
Kulatý OpenAlt sraz v Praze oslavíme klasicky: u limonády a piva! Přijďte si posedět, dát si dobré jídlo a vybrat z mnoha piv do restaurace Kulový blesk, který najdete v centru Prahy nedaleko metra I. P. Pavlova na adrese Sokolská 13, Praha 2. Sraz se koná ve čtvrtek 22. března a začínáme v 18:00. Heslo: OpenAlt. Vezměte s sebou svoje hračky! Uvítáme, když si s sebou na sraz vezmete svoje oblíbené hračky. Jestli máte nějaký drobný projekt postavený na Arduinu, nějakou zajímavou elektronickou součástku, či třeba i pěkný úlovek z crowdfundingové akce, neváhejte. Oslníte ostatní a o zábavu bude postaráno.
Přidat komentář

13.2.2018 0:41 /František Kučera
Únorový pražský sraz OpenAltu se koná 15. 2. 2018 a tentokrát se vydáme na návštěvu do jednoho pražského datacentra. Sejdeme se v 17:50 v severovýchodní části nástupiště tramvajové zastávky Koh-I-Noor. Po exkurzi se přesuneme do restaurace U Pštrosa (Moskevská 49), kde probereme tradiční témata (svobodný software a hardware, DIY, CNC, SDR, 3D tisk…) a tentokrát bude k vidění i IoT brána od The Things Network.
Přidat komentář

11.2.2018 23:11 /Petr Ježek
Hledáte lehký a rychlý prolížeč PDF souborů? Pokud vás již omrzelo čekat na načítání stránek či jiné nešvary, zkuste xreader.
Přidat komentář

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

> Poslední diskuze

20.2.2018 18:48 / Ivan Majer
portal

20.2.2018 15:57 / Jan Havel
Jak využíváte služby cloudu v podnikání?

16.1.2018 1:08 / Ivan Pittner
verejna ip od o2 ubuntu

15.1.2018 17:26 / Mira Harvalik
Re: Jak udělat HTML/Javascript swiping gallery do mobilu?

30.12.2017 20:16 / Michal Knoll
odmocnina

Více ...

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