LINUXSOFT.cz Přeskoč levou lištu

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

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ů

28.11.2018 23:56 /František Kučera
Prosincový sraz spolku OpenAlt se koná ve středu 5.12.2018 od 16:00 na adrese Zikova 1903/4, Praha 6. Tentokrát navštívíme organizaci CESNET. Na programu jsou dvě přednášky: Distribuované úložiště Ceph (Michal Strnad) a Plně šifrovaný disk na moderním systému (Ondřej Caletka). Následně se přesuneme do některé z nedalekých restaurací, kde budeme pokračovat v diskusi.
Komentářů: 1

12.11.2018 21:28 /Redakce Linuxsoft.cz
22. listopadu 2018 se koná v Praze na Karlově náměstí již pátý ročník konference s tématem Datová centra pro business, která nabídne odpovědi na aktuální a často řešené otázky: Jaké jsou aktuální trendy v oblasti datových center a jak je optimálně využít pro vlastní prospěch? Jak si zajistit odpovídající služby datových center? Podle jakých kritérií vybírat dodavatele služeb? Jak volit vhodné součásti infrastruktury při budování či rozšiřování vlastního datového centra? Jak efektivně datové centrum spravovat? Jak co nejlépe eliminovat možná rizika? apod. Příznivci LinuxSoftu mohou při registraci uplatnit kód LIN350, který jim přinese zvýhodněné vstupné s 50% slevou.
Přidat komentář

6.11.2018 2:04 /František Kučera
Říjnový pražský sraz spolku OpenAlt se koná v listopadu – již tento čtvrtek – 8. 11. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma umění a technologie, IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

4.10.2018 21:30 /Ondřej Čečák
LinuxDays 2018 již tento víkend, registrace je otevřená.
Přidat komentář

18.9.2018 23:30 /František Kučera
Zářijový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 20. 9. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma IoT, CNC, svobodný software, hardware a další hračky.
Přidat komentář

9.9.2018 14:15 /Redakce Linuxsoft.cz
20.9.2018 proběhne v pražském Kongresovém centru Vavruška konference Mobilní řešení pro business. Návštěvníci si vyslechnou mimo jiné přednášky na témata: Nejdůležitější aktuální trendy v oblasti mobilních technologií, správa a zabezpečení mobilních zařízení ve firmách, jak mobilně přistupovat k informačnímu systému firmy, kdy se vyplatí používat odolná mobilní zařízení nebo jak zabezpečit mobilní komunikaci.
Přidat komentář

12.8.2018 16:58 /František Kučera
Srpnový pražský sraz spolku OpenAlt se koná ve čtvrtek – 16. 8. 2018 od 19:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát jsou tématem srazu databáze prezentaci svého projektu si pro nás připravil Standa Dzik. Dále bude prostor, abychom probrali nápady na využití IoT a sítě The Things Network, případně další témata.
Přidat komentář

16.7.2018 1:05 /František Kučera
Červencový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 19. 7. 2018 od 18:00 v Kavárně Ideál (Sázavská 30, Praha), kde máme rezervovaný salonek. Tentokrát bude přednáška na téma: automatizační nástroj Ansible, kterou si připravil Martin Vicián.
Přidat komentář

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

> Poslední diskuze

31.7.2023 14:13 / Linda Graham
iPhone Services

30.11.2022 9:32 / Kyle McDermott
Hosting download unavailable

13.12.2018 10:57 / Jan Mareš
Re: zavináč

2.12.2018 23:56 / František Kučera
Sraz

5.10.2018 17:12 / Jakub Kuljovsky
Re: Jaký kurz a software by jste doporučili pro začínajcího kodéra?

Více ...

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