ARCHIV

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

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

DISKUZE Test trvanlivosti 28.9.2010 10:32 Tomáš 'Heron' Crhonek   Re: Test trvanlivosti 30.9.2010 10:34 Radim Kolář Zobrazit označené Zobrazit vše Příspívat do diskuze mohou pouze registrovaní uživatelé.