Hlavní navigace

Embedded databáze - Úvod

Radim Kolář

Embedded databáze jsou malé a rychlé databázové stroje určené pro databázové potřeby vaší aplikace.

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.

Našli jste v článku chybu?

30. 11. 2004 15:04

logik (neregistrovaný)

To jsem pouzival, tabulky byly nejmene v 11NF :-), a stejne jsem musel opravovat spoustu pokazenych databazi. Navic ta rychlost... :-(

30. 11. 2004 10:21

noregret (neregistrovaný)

Paradox byl pro mnoho databazistu (specialne foxkaru) nepochopitelny z toho duvodu, ze vyzadoval existenci primarnich klicu a nutil vyvojare normalizovat databazi. Kdo tohle pochopil, tak se mu nikdy nemohlo stat, ze by mel nekonzistentni databazi (nejen v Paradoxu).

Podnikatel.cz: Změny v cestovních náhradách 2017

Změny v cestovních náhradách 2017

Vitalia.cz: Taky věříte na pravidlo 5 sekund?

Taky věříte na pravidlo 5 sekund?

DigiZone.cz: TV Philips a Android verze 6.0

TV Philips a Android verze 6.0

Vitalia.cz: Jmenuje se Janina a žije bez cukru

Jmenuje se Janina a žije bez cukru

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání

Měšec.cz: U levneELEKTRO.cz už reklamaci nevyřídíte

U levneELEKTRO.cz už reklamaci nevyřídíte

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...

Měšec.cz: Jak levně odeslat balík přímo z domu?

Jak levně odeslat balík přímo z domu?

Lupa.cz: Insolvenční řízení kvůli cookies? Vítejte v ČR

Insolvenční řízení kvůli cookies? Vítejte v ČR

Podnikatel.cz: Udávání a účtenková loterie, hloupá komedie

Udávání a účtenková loterie, hloupá komedie

Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?

Vitalia.cz: Pamlsková vyhláška bude platit jen na základkách

Pamlsková vyhláška bude platit jen na základkách

Měšec.cz: Jak vymáhat výživné zadarmo?

Jak vymáhat výživné zadarmo?

Podnikatel.cz: Snížení DPH na 15 % se netýká všech

Snížení DPH na 15 % se netýká všech

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

120na80.cz: Na ucho teplý, nebo studený obklad?

Na ucho teplý, nebo studený obklad?