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

Metodika vývoje testovacích programů

Testování sedmi databází vyžadovalo napsání stejného množství jednoduchých testovacích programů. Bylo by také možné napsat jen jeden program a do něj zahrnout drivery pro jednotlivé databáze. Já jsem se rozhodl pro první variantu, protože je jednodušší.

Tyto testovací programy jsou z větší části stejné, liší se jen ve způsobu komunikace s vlastní databází. Je tedy možné vzít program s rozhraním NDBM a ten pak ručně doupravit pro příslušnou databázi. Tomuto způsobu programování se říká Copy and Paste. Problém nastane, pokud budeme chtít upravit něco ve společné části kódu. Bude nutné tyto změny provést v sedmi programech ručně, což je náročné na čas programátora. Lepší je použít nějaký version control systém.

U klasických version control systémů, jako je CVS nebo Subversion, je nejlepší nahrát do vcs jen základní program a úpravy pro jednotlivé databáze provádět jen v pracovních kopiích. Změny ve společné části pak stačí zakomitovat a pracovní kopie aktualizovat, což obě verze sloučí. V těchto systémech nedoporučuji si moc hrát s vytvářením a slučováním větví. Přináší to víc starostí než užitku.

Já jsem se rozhodl pro použití version control systému GNU Arch, který podobně jako BitKeeper nebo Darcs umožňuje velice pohodlné slučování změn (a to i obousměrné) mezi jednotlivými větvemi.

Test č. 1

Začneme čím jiným než vytvořením databáze. Budeme vkládat 70 tisíc záznamů o délce klíče 4 bajty a délce záznamu 40 bajtů, celem 3080000 bajtů dat. Kromě rychlosti budeme měřit i overhead způsobený řídícími záznamy databáze. Test byl prováděn 3×, vzal jsem nejlepší výsledek, což zmenší chybu měření.

Většina databází umožňuje při vytváření databáze použít uživatelem definovanou velikost stránky místo defaultní, která je obvykle jen 512 bajtů. Některé databáze umožňují také vypnout zamykání. Pokud jsou tyto volby možné, najdete databázi ve výsledcích dvakrát. Jednou s defaultním nastavením a podruhé s 4KB stránkou a bez zámků. Pod označením ndbm se skrývá db1 s tuningem, jenž se použije při přístupu pomocí ndbm api, které tuning db enginu standardně neumožňuje.

Databáze DB4.1 nebyla schopna test s 4K blokem dokončit, neboť skončila deadlockem sama se sebou. Podobné výkony vidíme i v operačních systémech Win 95/8, kde není neobvyklým jevem zařízení, které je v konfliktu samo se sebou.

Výsledky testu

Nejrychleji umějí vytvářet databázi tzv. konstatní databáze. V našem testu jsou zastoupeny cdb a puredb. U tdb databáze s vypnutým zamykáním můžeme hezky vidět, jak použití mmapu zefektivní výsledný program. QDBM byla jediná databáze s tak dobře nastavenými defaulty, že dosáhla s 4K stránkou horšího výsledku. Za zmínku stojí i fakt, že pokud k db1 přistupujete přes db1 native api, jsou db1 defaulty nastaveny velmi špatně. Komerční vývojáře jistě potěší fakt, že nejrychlejší databáze jsou jim licenčně nakloněny. Tdb s mmapem je mimo hru, neb OS WinDos stejně není mmapem podporován. Dále vidíme, že data po vložení do databáze nabobtnají zhruba v poměru 1.6; u SQL databázových serverů je tento poměr trošku vyšší – zhruba 2.1.

Test č. 2

V dalším testu budeme všecha uložená data přepisovat, a to hned třikrát. Poprvé přepíšeme data jinými o stejné délce. V ideálním případě bychom neměli pozorovat žádný nárůst velikosti db a tato operace by měla být z přepisových operací nejrychlejší.

Přepis všech původních dat daty o poloviční délce. Tato operace by měla být pro databázi náročnější, neboť je potřeba přidat uvolněné místo do free listu. Zdaleka ne všechny databáze to však dělají, některé na to kašlou, a tak, pokud přepíšete záznam záznamem o kratší délce, zbylé volné místo zůstane již dále nevyužito. Také by se mohl celkový soubor zmenšit – to však nedělá žádná mně známá databáze.

Výsledky tohoto testu ukázaly, že přepis kratšími daty databázi znatelněji nezatěžuje. Výsledná velikost souboru se snížila jen u konstatních databází. Tyto databáze neumějí soubor s daty aktualizovat – místo aktualizace ho znovu vytvoří, tuto operaci zvládají mnohem rychleji než klasické databáze.

Přepis všech záznamů daty o dvojnásobné velikosti. Zde bych za nejzajímavější údaj označil změnu výsledné velikosti souboru.

V závěrečném dílu se podíváme na rychlost čtení a na práci s poškozenými datovými soubory.