CouchDB – tak trochu jiná databáze (1. část)

CouchDB je relativně mladá databáze. Vývoj započal roku 2005 Damien Katz, minulý rok (tj. 2008) se dostala pod křídla Apache Foundation a oficiálně se stala Apache CouchDB.

Proč CouchDB?

Proč bych se měl zajímat o nějakou další databázi? Předně to může být její zajímavou architekturou – sama je napsána v Erlangu, své API zpřístupňuje přes HTTP a pohledy ve stylu MapReduce (o těch něco málo později) jsou psány v JavaScriptu (ovšem ten může být nahrazen prakticky čímkoli jiným, kupř. Perlem, Pythonem, Ruby atd.).

JSON

V perexu stojí, že CouchDB je dokumentově orientovaná databáze. Dnes se vývojáři nejvíce setkávají s relačními databázemi. Ty jsou založeny na léty ověřeném relačním modelu. CouchDB se ale ubírá jinudy. Místo toho, abyste definovali rigidní strukturu (schéma), do které se budou data ukládat, CouchDB vám poskytuje jednu základní flexibilní jednotku – dokument. Dokument není nic jiného než libovolně složitý JSONovský objekt. CouchDB vás nijak neomezuje v tom, co v dokumentu být smí či nesmí – všechno je to na vás, resp. vaší aplikaci.

Bez schématu

Schémata jsou ale dobrá, ne? Jsou. Avšak dříve nebo později můžeme narazit. Řekněme, že máme obchod a chceme ke každému produktu, který prodáváme, přidávat různé informace – parametry. Pokud budeme uvažovat relačně, dá se vydat dvěma cestami (koho napadne další, má bod).

1. Budeme tabulku zvětšovat do šířky – pro každý parametr bude nový sloupec.
2. Kromě tabulky produktů zde bude ještě jedna, ve které se budou ukládat trojice [produkt, parametr, hodnota].

Problémem prvního řešení je, že ve většině řádků, v závislosti na tom, jak moc rozličné zboží prodáváme, zůstane mnoho sloupců nevyužito. Problémem druhého zase to, že ve sloupci hodnota se budou míchat data různých typů (některý parametr je číslo, jiný řetězec, další zase logická hodnota).

Podobně dopadnete, budete-li chtít do relační databáze ukládat vícejazyčné záznamy.

ID dokumentů

U relačních databází je nejčastějším způsobem, jak identifikovat záznamy, nějaký druh samozvyšujícího se ID (auto increment ID). To znám. Je v tom snad problém? Ano, docela ano – jelikož CouchDB si dává hned dva přívlastky (distribuovaná a s RESTful rozhraním), které tomuto přístupu poněkud brání.

RESTful rozhraní (viz článek zde na Zdrojáku o architektuře REST - pozn.red.) by měla mít tu vlastnost, že jejich chování nezávisí na předchozích požadavcích – všechno, co potřebujeme k vrácení výsledku, by mělo být založeno na datech právě tohoto požadavku a žádného jiného. Jak v tom brání auto increment ID? Je to stav, který je závislý na předchozích požadavcích. Pokud budu postupně vytvářet záznamy, musím si uchovávat, u jakého ID jsem skončil. Takže k vytvoření nového záznamu zkombinuji data z požadavku s daty ovlivněnými předchozími požadavky.

U distribuovaného prostředí by se takové auto increment ID muselo udržovat napříč servery, což přináší další zbytečnou komunikaci a nepotřebné komplikace rozhraní.

CouchDB tedy místo toho k identifikování záznamů používá UUID (universální unikátní identifikátory). Dokumenty jsou poté distribuovány právě podle toho, jaké mají UUID.

Žádné zámky, žádné čekání

Jako většina databází se i CouchDB drží architektury klient-server. Aby mohlo najednou ke stejným datům přistupovat více klientů, databáze to musí řešit. Mnoho databází používá zámky. Zámky jsou špatné, áno? Ve své podstatě ne, protože neumožní dvěma klientům, aby si zároveň přepisovali data, nebo aby jeden klient četl data, jejichž zápis ještě druhý nedokončil. Ale (vždycky je tu ale) klienti musí čekat a čekat a čekat. A čekání už špatné je. Nikdo nečeká rád.

Problém přístupu více klientů ke stejným datům v jeden okamžik je u CouchDB řešen pomocí MVCC (Multiversion Concurrency Control) – místo toho, aby dokument, do kterého chceme zapisovat, zamkla pro zápis (takže by se k němu ostatní klienti nedostali), vytvoří zcela novou revizi dokumentu, která bude obsahovat změněná data. Když je nová revize úspěšně zapsána, je dalším požadavkům vracena ona. Ovšem mezitím, co je zapisována, ostatní klienti mohou paralelně číst starší revizi dokumentu, a nemusí tedy čekat. Ale (opět je tu ale) tento přístup je vykoupen tím, že databáze potřebuje více diskového prostoru.

Instalace

Jako primární zdroj informací o instalaci berte wiki. Tam byste měli najít ty nejaktuálnější informace.

Linux

Pokud vaše distribuce má balíčkovací systém, nejdříve zkuste jej.

Debian a jeho deriváty (Ubuntu)

# apititude install couchdb

Gentoo

# echo dev-db/couchdb >> /etc/portage/package.keywords
$ emerge -pv couchdb
# emerge couchdb

Arch Linux

CouchDB je dostupná v AURu. Instalace pomocí  yaourt:

$ yaourt -S couchdb

Pokud chcete mít opravdu bleeding edge CouchDB, nahraďte couchdb-svn namísto  couchdb.

Instalace ze zdrojových kódů

A samozřejmě je možná instalace ze zdrojových kódů. Můžete použít tarbally, nebo checkoutnout SVN repozitář na http://svn.apache.org/repos/asf/couchdb/trunk/. Závislosti naleznete v souboru README. Jestliže máte zdrojové kódy z čerstvého checkoutu, spusťte:

$ ./bootstrap

Zkompilujte pak svatou trojkombinací:

$ ./configure
$ make
# make install

V případě, že se vám nechce databázi instalovat, využijte:

$ make dev
$ ./utils/run

Mac OS X

I když si na Mac OS X můžete též hezky zakompilovat, existuje tu snazší způsob, jak si na něm pohrát s CouchDB – pomocí CouchDBX. Sice se jedná o neoficiální aplikaci, ale instalace je velice pohodlná – stáhněte, dvojklikněte a máte běžící CouchDB.

Další možností je využít MacPorts:

$ sudo port selfupdate
$ sudo port install couchdb
$ sudo launchctl load -w /opt/local/Library/LaunchDaemons/org.apache.couchdb.plist

Poslední příkaz spustí CouchDB a přidá ji do seznamu démonů spouštěných po startu.

Windows

CouchDB sice není oficiálně na Windows podporována, ale existuje pro ni neoficiální binární balíček. Samozřejmě budete potřebovat Erlang. Poté ještě Visual C++ 2008 Redistri­buables a OpenSSL. Proklikejte se přes všechna „Next“ a počkejte, až instalátory všechno zařídí.

Nakonec přejděte do podadresáře bin/ vaší CouchDB instalace a spusťte couch_start.bat. Mělo by dojít k otevření Erlang shellu (který s trochou štěstí nevypíše žádné závažné chyby) a CouchDB by měla běžet.

První krůčky

Ověřit si, jestli CouchDB běží, je opravdu jednoduché – otevřete si v prohlížeči adresu http://localhost:5984/. Uvidíte něco jako (verze se s největší pravděpodobností bude lišit):

{"couchdb":"Welcome","version":"0.10.0a799862"} 

Tohle je uvítací hláška, kterou vás CouchDB obštědří, pokud provedete GET požadavek na /. Jelikož budeme chtít odesílat i jiné požadavky, než jen GET, bude potřeba nějaký nástroj, ve kterém se to bude moci nastavit

Milovníci práce se shellem si vystačí s utilitkou curl. Nejdůležitější přepínače jsou -X <metoda>, kdy za metodu dosaďte, co bude potřeba ( GET, POST, PUT, DELETE); -d <data>, kterýžto odešle daná data v těle požadavku; -v, aby byly vidět detailní informace, co se všechno děje; a -H pro nastavení zasílaných hlaviček.

Nebo použijte telnet a požadavky si sestavujte opravdu na míru.

Pro příznivce Firefoxu je tu doplněk RESTClient.

Co když nepoužívám Firefox a nechce se mi pachtit v shellu? Dokonce i když máte Firefox a shell ze srdce rádi, CouchDB vám nabídne hezké Ajaxové administrační rozhraní zvané Futon. Dostanete se k němu ze svého oblíbeného prohlížeče napsáním http://localhost:5984/_utils/ do adresního řádku.

K Futonu se ještě vrátíme, ale až na konci, do té doby si vystačíme s HTTP požadavky. V dalších dílech bude proto používán curl; zápisy jsou pochopitelné, takže by neměl být problém s pomocí předchozího popisu poslat stejné požadavky vaším oblíbeným klientem.

Abychom mohli ukládat dokumenty, je potřeba si nejdříve vytvořit přihrádku, kam půjdou – databázi. O tom, jak pracovat s databázemi a jak vytvářet dokumenty, si povíme v další části článku.