Co jsou to embedded databáze?
Embedded databáze tvoří přesný opak architektury klient-server. Místo aby využívaly pro přístup k datům vyhrazený databázový server, běží v adresovém prostoru aplikace, která je využívá. Embedded databáze je knihovna, kterou si přilinkujete k aplikaci, a aplikace se tak stává sama svým miniaturním databázovým serverem – přistupuje prostřednictvím knihovny přímo k souborům s daty. Z přímého přístupu k databázovým souborům je vidět, že tyto databáze jsou primárně určeny pro práci v single-user režimu.
Historie
Dříve se tyto databázové systémy používaly téměř výhradně. Operační systémy MS-DOS a CP-M byly jednouživatelské a počítačové sítě téměř neexistovaly. Proto omezení těchto databází na single user přístup nikomu nevadilo. S nástupem LAN sítí se přesunuly databázové soubory z lokálních disků na síťové, implementovaly se jednoduché zamykací mechanismy a tyto databáze se ještě nějakou dobu hojně používaly. Pak se zjistilo, že jejich provozování přes síť není ideální a na LAN sítích se přešlo na architekturu klient-server. Důvodů pro to bylo několik. Zaprvé bylo nutno přenášet po síti značné množství dat, protože se zpracovávala na straně klienta a ne tam, kde byla uložena. Zadruhé tu byl problém s přístupovámi právy (která prakticky nebyla implementována) a za třetí tu byl problém spolehlivosti – výpadek stanice mohl ohrozit konzistenci dat na serveru. Přestože tyto databáze zmizely ze sítí LAN, používají se dodnes a počet jejich instalací mnohonásobně převyšuje počet instalací databází client-server.
Proč tyto databáze používat?
Důvody, proč tyto databáze ještě dnes používat, jsou:
Jednoduchost: Databáze neposkytují zdaleka všechny možnosti, které poskytuje SQL server. Poskytují jen to minimum, co aplikace nezbytně potřebuje. Z toho vyplývá, že API k databázi je obvykle velmi jednoduché.
Malá velikost: Zejména ve srovnání s SQL serverem. Přilinkování databáze obvykle vaši aplikaci o moc nezvětší.
Odladěnost: Pokud je něco malé a jednoduché, je zde mnohem menší možnost výskytu bugů, které by mohly ovlivnit naši aplikaci. Z tohoto důvodu programátor raději použije odladěnou knihovnu, než aby se pustil do vývoje své vlastní.
Snadná instalace: V dobách MS-DOSu byly staticky přilinkovány k aplikaci, dnes jsou obvykle ve formě dynamicky linkovaných knihoven, které jsou buď přímo součástí operačního systému, nebo jsou instalovány spolu s aplikací. Uživatel nemusí nic zvlášť instalovat a konfigurovat.
Nulová údržba: Narozdíl od SQL serverů se nevyžadují žádnou údržbu dat prováděnou mimo aplikaci. Aplikace obvykle nabízí možnost reindexace nebo reorganizace (pack) datových souborů.
Rychlost: Významnějším důvodem pro jejich použití je ovšem rychlost. V této oblasti jsou nedostižné. Je možné u nich dosáhnout až 50násobného výkonu oproti SQL serveru při operacích s rozumným objemem dat. SQL servery budou většinou rychlejší při zpracovávání velkých objemů (řádově gigabajty) dat.
Co v nich nenajdete
Přístupová práva
Tyto databáze obvykle neimplementují žádný systém přístupových práv založený na autorizaci uživatele. Vzhledem k tomu, že uživatel má přímý přístup k datům, postrádalo by to smysl. Bylo by totiž nutné data šifrovat, abychom je uchránili před zvědavým pohledem uživatele (použito například v borlandí databázi Paradox). Pokud je nějaký systém přístupových práv k datům potřebný, řeší se na aplikační úrovni.
Zamykání
Další věcí, kterou mohou tyto systémy vynechat, jsou různé druhy zamykacích mechanismů. Obykle jsou implementovány pouze dva database-wide druhy přístupu: readonly a read-write. S databází tak sice může pracovat více aplikací současně, avšak zapisovat do ní může pouze jedna. Většinou není koncept databáze jako soustavy tabulek implementován – místo toho se zamykání vztahuje k jednotlivým tabulkám (table-level lock) uloženým v samostatných souborech.
Některé embedded databáze ovšem implementují i jemnější dělení zámků: místo celých databází zamykají jednotlivé databázové bloky (page-level lock) nebo dokonce i jednotlivé řádky (row-level lock). Zatím jsem se nesetkal s embedded databází implementující MVCC (Multi Version Concurency Control). Čím jemnější zamykání je, tím více se database engine komplikuje a tím je také pomalejší.
Podpora SQL
Embedded databáze až na výjimky nenabízejí možnost použití dotazovacího jazyka SQL. K přístupu k datům je použit pár klíč-hodnota. Mezi podporované operace patří: vyhledání záznamu, smazání záznamu, vložení/změna záznamu a sekvenční procházení záznamů. Databáze může být organizována jako recordset – vyhledává podle pořadového čísla záznamu konstantní délky (např. DBASE a spol), hashtable – vyhledává podle hash hodnoty klíče (např. GNU DBM), či btree – vyhledává podle klíče (např. Berkeley DB).
Konzistence dat
Konzistence dat není silnou stránkou embedded databází. Atomické aktualizace tabulek nejsou až na výjimky podporovány. Z důvodu rychlosti jsou zápisy do databáze cachovány ve vyrovnávací paměti. Ve většině případů je jako jediný prostředek pro zajistění konzistence dat nabízena možnost synchronizace databáze na disku se stavem vyrovnávací paměti. Není zaručeno, že bez provedení sychronizace (nebo korektního uzavření db) nebudou datové struktury na disku poškozeny. Většina databází ovšem pozná neúplně zapsaný záznam.
Robustnost
Pod pojmem robustnost se rozumí odolnost databázového engine vůči chybám. V této oblasti také embedded databáze neexcelují. Protože sdílejí s aplikací stejný address-space, aplikace může omylem přepsat část paměti databázového engine, což téměř vždy vede k poškození dat. Databázový engine také nemá možnost kontrolovat správnost parametrů předaných mu přes pointry, ale v tomto případě aplikace obvykle skončí na segfault.
Představitelé embedded databází
1. Velké databáze:
Firmy Oracle a IBM, dodavatelé SQL Klient-Server databází, dříve dodávaly i jejich embedded verze. Firma Oracle ukončila jejich podporu ve verzi Oracle7 a firma IBM několik let předtím. Obě dvě tyto verze nahradily tzv. „Personal Edition“ verzí založenou na architektuře klient-server.
2. PC klasika: dBase
Mezi nejznámější databáze vůbec patří dBase, proslavená především svým formátem DBF, který je používán v řadě aplikací dodnes. Formát DBF byl de facto standard podporováný v celé řadě produktů (FoxBase, SuperBase, Clipper, …). Tyto databáze nabízely kromě embedded módu také vlastní scriptovací jazyk, ve kterém bylo možné psát aplikace (obvykle ne příliš rychlé).
3. Unixová klasika:
V Unixu se nejčastěji setkáme s některou databází z rodiny *dbm implementující ondisc hashtable. Do této rodiny patří dbm (originální veze) a různé její modifikace: GNU dbm, ndbm, …
4. Berkeley DB2
Vychází z dbm, byla však s postupem času značně přepracována. Dnes nabízí mnoho pokročilých vlastností: multi user concurent access, hot backup, rollforward recovery, multi table transactions, page level locking, zpracování xml dat. Mezi její nevýhody patří pomalost a špatně navržený systém zámků.
5. Konstantní databáze
Zvláštní kategorii tvoří konstantní databáze. Jsou to rychlé read-only on-disk hashtables. Používají se v případech, kdy se do databáze zapisuje velmi zřídka (je nutné vždy vygenerovat novou databázi). Představitelé: cdb, freecdb, tinycdb (navzájem kompatibilní) a puredb.
6. Nové napsané
Mezi nově napsanými dbm-like databázemi vynikají dvě: Superrychlá qdbm a tdb umožňující vícenásobný současný zápis. Opravdovou lahůdkou je však SQLite, která podporuje dotazovací jazyk SQL92. O té bude další článek.
