Hlavní navigace

Embedded databáze: Crash and Speed test db enginů (4)

Radim Kolář

Po rychlostním závodu následuje slibované "demo". V tomto případě je slovo Demo je od slova demolovat. Dnes budeme demolovat aplikace. Ne abyste to pak zkoušeli v produkci!

V minulých dílech jsme měřili rychlost embedded databázových enginů. V dnešním dílu bude měřena jejich odolnost. Měřit odolnost je mnohem těžší, jelikož nikdy nenasimulujete ten druh havárie, který vás postihne příště. Jelikož způsob ukládání dat se v použitých enginech značně různí, jedno poškození může jeden engine zcela odrovnat a druhý to přežije jen s povrchovým zraněním.

Embedded databáze nemají rády, pokud je odstraníte z paměti bez rozloučení. Jsou to veskrze citliví jedinci, a podle toho se s nimi musí jednat. Slušné zacházení s embedded databází je v zájmu programátora, neboť to jsou jeho data, která půjdou do háje.

Test č. 1 – Zavírejte dveře, utíkají vám data!

V prvním testu nezavoláme uzavření databáze a vykráčíme z programu pomocí exit(). To není zase tak drastická, jak by se mohlo zdát. Inteligentní embedded databázový engine se zaregistuje při otevírání pomocí atexit() a provede něco ve smyslu „Brano zavírá samo“. To ovšem pouze teorie.

Tabulka č. 620
Databáze Výsledek
DB1 Všechna data zničena. Výsledný soubor není identifikován jako soubor obsahující databázi, a to ani pomocí utility file ani pomocí dbm_open. Toto chování DB1 je velmi znamé.
DB4 Soubor je identifikován jako databáze a lze jej otevřít. Ze 70 tisíců testovacích záznamů se podařilo přečíst jen 546 kusů.
CDB Podobné jako u DB4. Databáze byla poznána, úspěšně přečteno 0 záznamů. Naprostá většina CDB implementací atomické updaty má, tato však nikoliv – programátor si to musí vyřešit sám.
GDBM Všechny záznamy jsou v pořádku.
Pure DB Má atomické updaty, takže stará data zůstala nedotčena, nová jsou kompletně pryč.
QDBM Soubor nebyl identifikován jako databázový.
TDB Všechny záznamy jsou v pořádku.

Je vidět, že naprostou většinu embedded databází rozhodí už pouhé neuzavření databáze. Pouze dvě databáze, gdbm a tdb, shodou okolností obě s GPL licencí, obstály na jedničku.

Test č. 2 – Sebevražda

V tomto testu nahradíme funci exit funkcí abort(). Abort je pořád ještě detekovatelná událost, před ukončením programu je spuštěna obsluha signálu SIGABRT.

Tabulka č. 621
Databáze Výsledek
DB1 Celý soubor zničen.
DB4 Přečteno 546 záznamů.
CDB Přečteno 0 záznamů.
GDBM Všechny záznamy jsou v pořádku.
Pure DB Díky atomickým updatům jsou stará data nepoškozená.
QDBM Celý soubor je zničen.
TDB Všechny záznamy jsou v pořádku.

Od minula žádná změna.

Test č. 3 – Nestrkejte prsty tam kam nemáte

Teď ukončíme operaci segfaultem a podíváme se, co na to počítač. Tato událost se dá také detekovat pomocí signálu SIGSEGV, případně SIGBUS.

Při jeho kódování mne překvapilo, že GCC-3.4 -Wall vůbec neprotestuje při kompilaci následujícího kódu. Neškodilo by, kdyby GCC umělo alespoň minimální sémantickou analýzu kódu.

void segfault(void)
{
    int *poynter;

    poynter=0;
    *poynter=55;
}
Tabulka č. 622
Databáze Výsledek
DB1 Celý soubor zničen.
DB4 Přečteno 546 záznamů.
CDB Přečteno 0 záznamů.
GDBM Všechny záznamy jsou v pořádku.
Pure DB Díky atomickým updatům jsou stará data nepoškozená.
QDBM Celý soubor je zničen.
TDB Všechny záznamy jsou v pořádku.

Od minula žádná změna. Začíná to už být nudné, že?

Test č. 4 – To je vražda, napsala

Sérii testů zaměřených na likvidaci aplikace zakončíme ukončením aplikace pomocí kill –9, což je jeden ze signálů, který aplikace nemůže detekovat.

Tabulka č. 623
Databáze Výsledek
DB1 Celý soubor zničen.
DB4 Přečteno 546 záznamů.
CDB Přečteno 0 záznamů.
GDBM Všechny záznamy jsou v pořádku.
Pure DB Díky atomickým updatům jsou stará data nepoškozená.
QDBM Celý soubor je zničen.
TDB Všechny záznamy jsou v pořádku.

Opět žádná změna. Naštěstí už končíme.

Závěr

Sérií testů jsme si ukázali, že odolnost embedded databází vůči haváriím je různá. Nejvíce mne překvapily konstantní výsledky testů. Databáze DB4 umí transakce, v tomto testu však nebyly použity, abychom srovnávali srovnatelné.

Databáze DB1 a QDBM naprosto zklamaly, protože nebyly schopné datový soubor ani otevřít, natož z něj pak něco přečíst. CDB to sice dokázala, ale žádná data v něm nenašla. DB4.1 byla naopak schopná přečíst již velmi malé procento záznamů. MySQL při havárii také ztratí data, ale tato ztráta se pohybuje v jednotkách procent. Pure DB skončila na výbornou díky atomickým updatům. Jelikož se jedná o konstantní databázi, výsledek se dal předvídat. Stejného výsledku může programátor dosáhnout i s CDB.

Naprostým vítězem testu jsou GDBM a TDB. Obě dvě nezničily ani jediný záznam. Jelikož z minulého dílu víme, že TDB je i databází nejrychlejší, je volba nejlepší databáze snadná – TDB. Moc Open Source projektů ji ale nepoužívá – jsou to spíše výjimky. Je to škoda, protože je to kvalitní výrobek.

Našli jste v článku chybu?
22. 12. 2004 9:31
Tomáš Šimek (neregistrovaný)

ad c) To teda nejste noc náročnej. Když použiju embeded db, chci od ní 1) stabilitu 2) rychlost 3) jednoduchost Např. SAMBA ukládá konta a hesla do tdb. Uživatele si je občas mění, jsou tam ukládany stavová informace. Díky chybicce mi nedávno samba padala pri tisku, pri představě, nasledné havárie databáze kont se mi po vašem výroku (U techto typu databazi se preci _pozaduje_ aby je uzivatel po pouziti korektne zavrel) otevirá kudla v kapse

21. 12. 2004 23:11
freza (neregistrovaný)

a) Na "*((type *) 0x00) = val;" neni nic nelegalniho, nevidim duvod proc by si mel kompilator stezovat. b) Nevim proc chvalit knihovny za to, ze se opovazuji osetrovat signaly do kterych jim nic neni. To je naopak dost negativni vlastnost. c) Nechapu pointu clanku. U techto typu databazi se preci _pozaduje_ aby je uzivatel po pouziti korektne zavrel. Pokud to neudelate, prijdete o data -- a co? Je to jako stezovat si ze nemuzu precist CD ktere jsem behem vypalovani vyrv…