Lehký úvod do CouchDB – 1 (základní API)

27. 1. 2010 | Ladislav Thon | Programování | 9845×

V posledních letech získává na oblibě zejména mezi webovými programátory jistý druh nerelačních databází, které můžeme souhrnně označit jako bezschémové. V tomto trojdílném seriálu si představíme jednu z nich, která se těší poměrně velké popularitě, totiž CouchDB. V prvním díle si na příkladech popíšeme prakticky celé základní API.

Obsah

• Úplné základy čili CRUD (Create, Read, Update, Delete)
• Revize dokumentu čili současný přístup více uživatelů
• Dotazy čili pohledy čili indexy
• Příště

Půjdeme na to čistě prakticky, teorii si můžeme nechat na později. CouchDB je dnes ve verzi 0.10.1, kterou najdete kupříkladu v Debianu unstable. V testingu je 0.10.0, což nám postačí, takže např. aptitude install couchdb a s chutí do toho; uživatelé jiných distribucí si snad poradí sami, případně se obrátí na wiki. Lehký přehled o vnitřnostech získáte třeba v technical overview – pro nás to teď nebude nutné, ale zájemcům vřele doporučuji. CouchDB se mimochodem používá například jako lokální úložiště dat pro Ubuntu One (viz též desktopcouch), což znamená, že vydáním Ubuntu 9.10 se zvýšil podíl instalací Erlangu na osobních počítačích minimálně o stovky procent :-)

Úplné základy čili CRUD (Create, Read, Update, Delete)

CouchDB má jediné API: JSON přenášený přes HTTP. Skutečně, je to tak, můžete si pohrát třeba z příkazové řádky a HTTP klienta najdete snad pro jakýkoliv programovací jazyk. Server poslouchá na portu 5984, takže pro seznámení:

$ curl -X GET http://localhost:5984/
{"couchdb":"Welcome","version":"0.10.1"}
$ curl -X GET http://localhost:5984/_all_dbs
[]

Aha, ještě žádnou databázi nemáme vytvořenou! To snadno napravíme. API je RESTové, vytvořit novou kolekci objektů znamená volat PUT. A když jsme v tom, smazání je pochopitelně DELETE.

$ curl -X PUT http://localhost:5984/pokus
{"ok":true}
$ curl -X GET http://localhost:5984/_all_dbs
["pokus"]
$ curl -X DELETE http://localhost:5984/pokus
{"ok":true}
$ curl -X GET http://localhost:5984/_all_dbs
[]

Poznatek: „systémové“ identifikátory začínají podtržítkem.

Na ten DELETE na chvilku zapomeňme, řekněme, že tedy máme databázi pokus. Jen tak na hraní. Mějme dokument… nějaký pěkný, třeba tenhle:

{"type": "book", "author": "Dan Simmons", "name": "Drood"}

Co s ním?

$ curl -X POST -d '{"type": "book", "author": "Dan Simmons", "name": "Drood"}' http://localhost:5984/pokus
{"ok":true,"id":"317d691f7c21937824bf9b55e1994486","rev":"1-4ffc368db414b81bf524c6d4c421b93f"}

POST volaný na kolekci znamená vytvořit v ní nový objekt a automaticky mu přiřadit ID. Což se také stalo:

$ curl -X GET http://localhost:5984/pokus/317d691f7c21937824bf9b55e1994486
{"_id":"317d691f7c21937824bf9b55e1994486","_rev":"1-4ffc368db414b81bf524c6d4c421b93f",
  "type":"book","author":"Dan Simmons","name":"Drood"}

(Pro snazší čtení odřádkovávám a odsazuji dvěma mezerami.)

Now come on, it can't be that simple, can it? Poznatek: CouchDB patří mezi dokumentové databáze, kterým není nutné předem říkat, jaká bude struktura ukládaných dat. Datové schéma je čistě věcí aplikace.

Řekněme, že bychom chtěli ukládat i žánrové zařazení. Nebo spíš žánrová zařazení, těch může být vždycky víc. Aktualizace existujícího objektu je PUT:

$ curl -X PUT -d '{"_id":"317d691f7c21937824bf9b55e1994486","_rev":"1-4ffc368db414b81bf524c6d4c421b93f",
  "type":"book","author":"Dan Simmons","name":"Drood", "genres": ["fantasy", "thriller", "detektivka"]}'
  http://localhost:5984/pokus/317d691f7c21937824bf9b55e1994486
{"ok":true,"id":"317d691f7c21937824bf9b55e1994486","rev":"2-fa897debf5c1a63193f121798e85b6e3"}

Nešálí vás zrak, jako jednu z položek jsem opravdu uložil seznam. Když se mi zlíbí, do toho seznamu si můžu klidně uložit třeba další dokumenty (mapy, hashe), není v tom problém. A pokud nevadí tohle – neměly by ty žánry být někde v číselníku a u knihy jenom odkazy do něj? Hm, člověk nikdy neví, tak prozatím řekněme, že žánry jsou pro nás něco jako tagy na webu a uvidíme, co s nimi dál.

Ostatně, když jsme u toho, co ten autor? Ten by přece určitě měl být uložený samostatně a u knihy by na něj měl být jen odkaz, ne? Přijde na to – v jednom mém oblíbeném webovém knihkupectví například vůbec nemají stránky autorů a umí podle jejich jmen jen vyhledávat.

Revize dokumentu čili současný přístup více uživatelů

A protože v tuhle chvíli z otázek až oči přecházejí, na chvilku zpomalíme a podíváme se na záhadné položky _id a _rev. _id je, inu, ID, jednoznačný klíč, podle kterého lze dokument najít. ID si můžu nechat generovat od CouchDB při vytváření nových dokumentů, jako tomu bylo výše (v takovém případě se vyrobí nové UUID), nebo si ho zadat sám:

$ curl -X PUT -d '{"type": "book", "author": "Orson Scott Card", "name": "Enderova hra",
  "genres": ["sci-fi", "humanismus"]}' http://localhost:5984/pokus/enderova-hra
{"ok":true,"id":"enderova-hra","rev":"1-0b1b7e88639474892f4eb950bf139e27"}
$ curl -X GET http://localhost:5984/pokus/enderova-hra
{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27","type":"book",
  "author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"]}

Automatické generování UUIDů je víc než vhodné minimálně v případě, kdy je databáze „distribuovaná“ (CouchDB disponuje hezkou funkcí replikace s řešením konfliktů, ale tím se teď zabývat nebudeme). Naopak číselná ID v rostoucí posloupnosti mohou být pro databázi příjemnější kvůli způsobu, jakým jsou ukládána a vyhledávána data (už jsem říkal, že základní a vlastně jedinou diskovou strukturou CouchDB je B-strom?).

A co to _rev? Jistě, je to od slova revision, což ovšem neznamená, že by se CouchDB dala použít jako verzovací systém. Číslo revize slouží k řešení současného přístupu k datům: Už výše jsme viděli, že když chci dokument změnit, musím ho poslat včetně položky _rev. CouchDB povolí zápis jen tehdy, pokud se číslo revize v ukládaném dokumentu shoduje s aktuálně platným číslem revize v databázi.

$ curl -X PUT -d '{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27",
  "type":"book","author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
  "stars": "5/5"}' http://localhost:5984/pokus/enderova-hra
{"ok":true,"id":"enderova-hra","rev":"2-823eb2f692da425220f17b96b231082b"}
$ curl -X PUT -d '{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27",
  "type":"book","author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
  "stars": "6/5"}' http://localhost:5984/pokus/enderova-hra
{"error":"conflict","reason":"Document update conflict."}
$ curl -X PUT -d '{"_id":"enderova-hra","_rev":"2-823eb2f692da425220f17b96b231082b",
  "type":"book","author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
  "stars": "6/5"}' http://localhost:5984/pokus/enderova-hra
{"ok":true,"id":"enderova-hra","rev":"3-1be8a2371b004f49b284061433ba9b48"}

Staré revize je stále možné získat, ovšem pouze tehdy, pokud jsou v databázi ještě dostupné.

$ curl -X GET http://localhost:5984/pokus/enderova-hra?rev=1-0b1b7e88639474892f4eb950bf139e27
{"_id":"enderova-hra","_rev":"1-0b1b7e88639474892f4eb950bf139e27","type":"book",
  "author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"]}
$ curl -X POST http://localhost:5984/pokus/_compact
{"ok":true}
$ curl -X GET http://localhost:5984/pokus/enderova-hra?rev=1-0b1b7e88639474892f4eb950bf139e27
{"error":"not_found","reason":"missing"}

Poznatek: CouchDB používá multigenerační architekturu a řešení souběžných přístupů je tedy optimistické. Garbage collector (compact) je, pokud vím, nutné volat ručně (viz též wiki) a po dobu jeho běhu lze databázi normálně používat.

Bližší informace o revizích dokumentu získáte použitím parametrů revs=true nebo revs_info=true:

$ curl -X GET http://localhost:5984/pokus/enderova-hra?revs_info=true
{"_id":"enderova-hra","_rev":"3-1be8a2371b004f49b284061433ba9b48","type":"book",
  "author":"Orson Scott Card","name":"Enderova hra","genres":["sci-fi","humanismus"],
  "stars":"6/5","_revs_info":[
    {"rev":"3-1be8a2371b004f49b284061433ba9b48","status":"available"},
    {"rev":"2-823eb2f692da425220f17b96b231082b","status":"missing"},
    {"rev":"1-0b1b7e88639474892f4eb950bf139e27","status":"missing"}
  ]}

Obdobně funguje mazání: Je to vlastně vytvoření nové revize.

$ curl -X DELETE http://localhost:5984/pokus/enderova-hra
{"error":"conflict","reason":"Document update conflict."}
$ curl -X DELETE http://localhost:5984/pokus/enderova-hra?rev=3-1be8a2371b004f49b284061433ba9b48
{"ok":true,"id":"enderova-hra","rev":"4-d71e7ad84ec3801b0504b739e925e8b7"}
$ curl -X GET http://localhost:5984/pokus/enderova-hra
{"error":"not_found","reason":"deleted"}

Dotazy čili pohledy čili indexy

Nu, takže základní operace s dokumenty máme za sebou, co dál? Ovšem, dotazy. SQL? Ale kdeže, JavaScript! JavaScript a MapReduce. Přidejme si nejdřív pár dalších knih, ať je to zajímavější:

$ curl -X POST -d '{"type": "book", "author": "Dan Simmons", "name": "Ílion",
  "genres": ["sci-fi"]}' http://localhost:5984/pokus
{"ok":true,"id":"4ac9d40eff110178bfbb73d0e2c808bc","rev":"1-987ed35e7539446335290fb6ef1ed909"}
$ curl -X POST -d '{"type": "book", "author": "Dan Simmons", "name": "Olymp",
  "genres": ["sci-fi"]}' http://localhost:5984/pokus
{"ok":true,"id":"0ddd69f92f541e27b554f3ebed1d87a3","rev":"1-b4e1ebabd59a3bb677f1d00cb3a2c935"}
$ curl -X POST -d '{"type": "book", "author": "Orson Scott Card", "name": "Enderova hra",
  "genres": ["sci-fi", "humanismus"]}' http://localhost:5984/pokus
{"ok":true,"id":"59403880473a6bda402a21d64ad8c4cf","rev":"1-0b1b7e88639474892f4eb950bf139e27"}
$ curl -X POST -d '{"type": "book", "author": "Orson Scott Card", "name": "Sedmý syn",
  "genres": ["fantasy"]}' http://localhost:5984/pokus
{"ok":true,"id":"7e3891e4e1b5cf147137a0b0d609420e","rev":"1-ce3f425332eff2edd000b059a1aee8b9"}
$ curl -X POST -d '{"type": "book", "author": "Orson Scott Card", "name": "Rudý prorok",
  "genres": ["fantasy"]}' http://localhost:5984/pokus
{"ok":true,"id":"309a09f8ea790c232472cb66049fa2dd","rev":"1-9a1af3cbc31c3b1a3dc5dacc131a9003"}
$ curl -X POST -d '{"type": "book", "author": "Orson Scott Card", "name": "Učedník Alvin",
  "genres": ["fantasy"]}' http://localhost:5984/pokus
{"ok":true,"id":"82df2dd330d5c426d7509789fdda9bb8","rev":"1-42c1f75fc1046ed1c458b0b670bb61ef"}

Pozn.: Kódování znaků musí být utf-8, případně lze používat klasické unicode escape sekvence \uNNNN.

A co dál? Třeba jména knih podle žánrů:

// map
function(doc) {
  if (doc.type == "book" && doc.genres) {
    for (var genre in doc.genres) {
      emit(doc.genres[genre], doc.name);
    }
  }
}

Hodně… neobvyklé, to přinejmenším. Pojďme se na to podívat podrobněji: CouchDB má pohledy. Ty pohledy jsou definovány jednou nebo dvěma funkcemi v programovacím jazyce (konkrétně v JavaScriptu, ale rozhraní je obecné a existuje podpora pro další jazyky, viz wiki). Názvy těch funkcí pocházejí z funkcionálního světa: map a reduce, a nesou si z něj ještě jednu vlastnost: Musí být idempotentní. To zjednodušeně znamená, že nesmí nic změnit (pro jeden dokument musí za každých okolností vrátit tu samou hodnotu, nepřichází v úvahu ani žádné globální proměnné), a to zase zjednodušeně vede ke krásným důsledkům: Pohledy lze počítat inkrementálně a paralelně. Funkce map je povinná a slouží k filtrování a transformování. Je zavolána pro každý dokument v databázi a sama každým voláním emit generuje jednu položku pohledu: Dvojici <klíč; hodnota> (v příkladu výše <žánr; název knihy>). Funkce reduce je nepovinná, takže ji na chviličku vynecháme. Výsledky se ukládají na disk (takže ten pohled je vlastně materializovaný), a to vždy seřazené podle klíče (takže je to vlastně i index).

Teď jak tedy tu funkci do databáze dostat. Z řádky už mě to nebaví, takže si v prohlížeči otevřu http://localhost:5984/_utils, kde se nachází Futon, webové GUI ke CouchDB. Futon je z velké části javascriptová aplikace, s CouchDB komunikuje AJAXem stejným způsobem, jako jsme si to předvedli výše. Vlezu do databáze pokus a vpravo nahoře zvolím View: Temporary view… Do pole Map Function vložím kód uvedený výše a tlačítkem Run si můžu hned zobrazit výsledky:

To je dočasný pohled, ten ještě není uložený na disku a pokaždé se počítá znovu. Tak tedy Save As…, Design Document: _design/books, View Name: by_genre a Save. Když pak opět vpravo nahoře zvolím View: All documents, vidím, že v databázi vznikl nový dokument s ID _design/books. Zkuste se podívat na jeho obsah, případně pod záložkou Source se skrývá čistý JSON.

$ curl -X GET http://localhost:5984/pokus/_design/books/_view/by_genre
{"total_rows":10,"offset":0,"rows":[
{"id":"317d691f7c21937824bf9b55e1994486","key":"detektivka","value":"Drood"},
{"id":"309a09f8ea790c232472cb66049fa2dd","key":"fantasy","value":"Rud\u00fd prorok"},
{"id":"317d691f7c21937824bf9b55e1994486","key":"fantasy","value":"Drood"},
{"id":"7e3891e4e1b5cf147137a0b0d609420e","key":"fantasy","value":"Sedm\u00fd syn"},
{"id":"82df2dd330d5c426d7509789fdda9bb8","key":"fantasy","value":"U\u010dedn\u00edk Alvin"},
{"id":"59403880473a6bda402a21d64ad8c4cf","key":"humanismus","value":"Enderova hra"},
{"id":"0ddd69f92f541e27b554f3ebed1d87a3","key":"sci-fi","value":"Olymp"},
{"id":"4ac9d40eff110178bfbb73d0e2c808bc","key":"sci-fi","value":"\u00cdlion"},
{"id":"59403880473a6bda402a21d64ad8c4cf","key":"sci-fi","value":"Enderova hra"},
{"id":"317d691f7c21937824bf9b55e1994486","key":"thriller","value":"Drood"}
]}
$ curl -X GET 'http://localhost:5984/pokus/_design/books/_view/by_genre?key="sci-fi"'
{"total_rows":10,"offset":6,"rows":[
{"id":"0ddd69f92f541e27b554f3ebed1d87a3","key":"sci-fi","value":"Olymp"},
{"id":"4ac9d40eff110178bfbb73d0e2c808bc","key":"sci-fi","value":"\u00cdlion"},
{"id":"59403880473a6bda402a21d64ad8c4cf","key":"sci-fi","value":"Enderova hra"}
]}
$ curl -X GET 'http://localhost:5984/pokus/_design/books/_view/by_genre?startkey="a"&endkey="n"'
{"total_rows":10,"offset":0,"rows":[
{"id":"317d691f7c21937824bf9b55e1994486","key":"detektivka","value":"Drood"},
{"id":"309a09f8ea790c232472cb66049fa2dd","key":"fantasy","value":"Rud\u00fd prorok"},
{"id":"317d691f7c21937824bf9b55e1994486","key":"fantasy","value":"Drood"},
{"id":"7e3891e4e1b5cf147137a0b0d609420e","key":"fantasy","value":"Sedm\u00fd syn"},
{"id":"82df2dd330d5c426d7509789fdda9bb8","key":"fantasy","value":"U\u010dedn\u00edk Alvin"},
{"id":"59403880473a6bda402a21d64ad8c4cf","key":"humanismus","value":"Enderova hra"}
]}

Vidíme, že výsledky pohledu jsou skutečně řazené podle klíče (key) a nádavkem pro každou položku obsahují ID dokumentu. Parametry key, startkey a endkey musí být platný JSON, proto ty uvozovky. Takže umíme hledat podle hodnoty i podle rozsahu; o dalších možnostech si můžete přečíst na wiki. Podobně jako materializované pohledy v relačních databázích mají pohledy v CouchDB výhodu výborného výkonu: Není potřeba nic počítat, stačí jen číst.

Dál: Co si trochu zaredukovat? Nepovinná funkce reduce slouží k agregování. Řekněme, že chceme pro každý žánr vědět, kolik knih do něj patří. Zkusíme si takový lehký myšlenkový veletoč:

// map
function(doc) {
  if (doc.type == "book" && doc.genres) {
    for (var genre in doc.genres) {
      emit(doc.genres[genre], 1);
    }
  }
}

// reduce
function(keys, values, rereduce) {
  // log({"keys": keys, "values": values, "rereduce": rereduce});
  return sum(values);
}

Tak tohle už začíná být víc než zvláštní – kdo nikdy neslyšel o MapReduce, bude asi pořádně zmatený. Zkusme trochu osvětlit princip: Pro každý dokument systém zavolá mapovací funkci, která může emitovat libovolně mnoho dvojic <klíč; hodnota>, to už jsme viděli. Všechny takto vyrobené dvojice se vezmou, vyrobí se z nich množina dvojic <klíč; seznam všech hodnot emitovaných pro tento klíč> a pro každou z těchto dvojic se následně zavolá redukční funkce. Ta musí být komutativní a asociativní a musí vždy vrátit právě jednu hodnotu (v našem případě je to číslo, ale může to být klidně i seznam apod.), proto se jí říká redukční.

V našem případě funkce map vygeneruje pro každou knihu v každém žánru jednu jedničku a funkce reduce ty jedničky po jednotlivých žánrech sčítá.

$ curl -X GET http://localhost:5984/pokus/_design/books/_view/genres_count?group=true
{"rows":[
{"key":"detektivka","value":1},
{"key":"fantasy","value":4},
{"key":"humanismus","value":1},
{"key":"sci-fi","value":3},
{"key":"thriller","value":1}
]}

S trochou snahy se tenhle princip dá pochopit, je tu ale jeden problém: Výklad výše je ve skutečnosti lež. Redukce v CouchDB neprochází prostřední fází (seskupování hodnot podle klíče). Parametr keys obsahuje pole různých emitovaných klíčů (a také ID dokumentů, ze kterých byly klíče emitovány), parametr values pole odpovídajících emitovaných hodnot. K tomu se ještě přidává skutečnost, že pohledy se v CouchDB vyhodnocují inkrementálně. Kvůli tomu přibývá ještě parametr rereduce: Je-li jeho hodnota true, znamená to, že redukční funkce nedostane na vstup hodnoty z mapovací funkce, ale musí zkombinovat svoje vlastní předchozí výstupy. Ty jsou v parametru values, v parametru keys je v takovém případě null.

Protože tohle už je poměrně vysoká magie a detailní vysvětlení předchozího odstavce by zabralo celý další článek, odkazuji na wiki a přidávám jeden užitečný tip: Jak vidno na zakomentovaném řádku v kódu výše, při vyhodnocování javascriptových funkcí v CouchDB lze logovat. (Zkuste si to, log je ve /var/log/couchdb/couch.log). Každopádně když nic jiného, můžete těchto pár odstavců brát jako ukázku způsobu, kterým se dneska hromadně zpracovávají obrovské objemy dat – na ad hoc dotazování to ovšem stojí za starou belu. Pro tyto účely je asi nejlepší použít couchdb-lucene (i když například vývojáři Mozilla Raindropu používají techniku zvanou Megaview).

Poznatek: Indexované MapReduce pohledy jsou silná zbraň, ale v ad hoc dotazování je CouchDB slabý.

Příště

A to by bylo dneska všechno. Příště se podíváme, jak tedy uložit toho autora, jak k dokumentu přidat přílohu, jak validovat ukládaná data nebo přímo z databáze servírovat HTML.

       

Komentáře

[Lukáš Zapletal]

Ten reduce-process se pak provádí v JavaScriptu? Když pominu možnost paralelizace, není to přesto pomalé? Nebo se to překlopí do něčeho jiného?

[Ladicek]

Generování obřích pohledů trvá opravdu dlouho, ale pro spoustu účelů je to rychlé až až. Nejsem si jistý, jestli myslíš rychlost javascriptu (používá se mozillí implementace, ale teď nevím, jestli už TraceMonkey), nebo rychlost komunikace [erlangový proces CouchDB] <-> [proces view serveru, tedy obvykle céčkové couchjs], každopádně view server lze mít v jakémkoli jazyce a pro opravdu náročné je možné psát pohledy přímo v Erlangu

[okbob]

Jádro pudla je v >>inkrementální<< aktualizaci. Zátěž se rozloží v čase.

[Messa]

Ano. Ale když pohled nějakou dobu nepoužíváš a pak ho najednou potřebuješ, tak stejně čekáš hodinu.

[okbob]

Nejsem si jistý, ale myslím si, že není důvod proč by se tak mělo chovat - je to určitá analogie materializovaných pohledů - maximálně může zdržovat než se agregované hodnoty načtou z disku - ale jedná se už o agregované hodnoty - tj funkce map a reduce se při zobrazení neprovádějí.

[Messa]

Pokud jsem od posledního přístupu k pohledu změnil/přidal gigabajty dat, tak se ty gigabajty dat budou muset někdy naindexovat. A protože se indexy (pohledy) neaktualizují průběžně, ale až při přístupu na ně, tak si pak také počkám...

[okbob]

To právě že ne. Proč si myslíte, že se indexy aktualizují až při přístupu?

[Messa]

Proč si myslím, že se aktualizují až při přístupu? Protože na jejich aktualizaci čekám, když na ně přistoupím. I ve Statusu (ve Futonu) je vidět, jak se aktualizují. (Verze 0.10.1, bez zásadních změn nastavení.)

[okbob]

tak to pak mají blbě - to by bylo pro provoz nepoužitelný - tipoval bych si, že v tom bude nějaký háček.

[Messa]

CouchDB FAQ

[Ladicek]

Pohledy se skutečně aktualizují až při přístupu na ně. Kontrolu aktuálnosti ale můžete přeskočit (stale=ok) a aktualizovat na pozadí. Viz též http://wiki.apache.org/couchdb/Regenerating_views_on_update.

Lze psat ty view i v Erlangu, coz odpadne vas problem. Lze pouzit i jine jazyky. Napriklad Ruby...

http://github.com/candlerb/couchdb_ruby_view

[Amarok]

Pozitivne hodnotim mnozstvi prikladu. Nicmene smysl clanku je navnadit na tento typ databazi, coz u me nefungovalo, jeste vic me to odradilo :-/ To se musi pouzivat ten curl, nebo existuje aspon i nejaky interaktivni klient?

[alblaho]

Má to i nějaké nějaké hezčí rozhraní přímo v prohlížeči. Říkají tomu Futon.

http://couchdb.apache.org/screenshots.html

Pokud vím, tak existují různé javascriptové udělátka, které umožní jakýsi "vývoj" "aplikaci" i přímo v prohlížeči. Víc ví Ládíček

Mně se ty curl examply právě líbí, ukazuje to pravou podstatu technologie.

[Ladicek]

Proč jenom curl? Je to úplně normální HTTP, můžete použít cokoliv, co se umí tvářit jako HTTP klient. Pro spoustu jazyků jsou dostupné přímo knihovny zaměřené na CouchDB, ale těmi jsem článek nechtěl zatěžovat. Pár odkazů bude v posledním díle, ale Google rád poradí

[kkaarreell]

No jeje, takova mila vzpominka na temer zapomenuty flame. No uvidime...

[Přemek Vyhnal]

Super! Vypada to fakt pekne ;)

[balki]

Trosku mi chyba teoria okolo toho, v com spociva nerelacnost, bezschemovost, kedy je vhodnejsie pouzit takuto datbazu atd ...

Inac pekny clanok, len ked sa hovori o couchDB, mi vzdy unika preco, naco, zaco ....

[Ladicek]

Já nejsem žádný velký databázový teoretik, takže ve třetím dílu jsem to shrnul asi takhle: vysoce strukturovaná data, jejichž forma se moc nemění => relační databáze, data v podobě dokumentů nebo objektů, časté změny struktury => dokumentová databáze. To je samozřejmě velké zjednodušení a do hry vstupuje řada dalších faktorů (jsou i další druhy databází a další případy použití, všichni znají SQL, …), takže jsem se snažil napsat seriál tak, aby čtenář získal dost informací na to, aby se rozhodl sám

[balki]

Aha, chapem, takze

Relacne databazy - tabulky su tvorene n-ticami o pevnej sirke. Naviac v kazdej n-tici je pritomny kluc, ktory jednoznacne identifikuje n-ticu. Vyhoda: je garantovane, ze iste operacie na tejto tabulke pojdu spravit Nevyhoda: siroke tabulky, respektive potreba ich normalizacie ako vysledok je potom kopec poloprazdnych tabuliek. Vyhoda: je garantovane, ze iste operacie pojdu spravit.

Nerelacne - Stlpce nemaju pevnu sirku, ani tie kluce tam nemusia byt. Vyhoda - volnym okom lepsie citatelne data Nevyhoda - clovek nevie vobec, aky bude vysledok po nejakom query. :)

To je moj zjednoduseny pohlad :)

[Messa]

Jak jsi zmínil normalizaci, vzpomněl jsem si na další argument. Normalizovaná SQL databáze (resp. schéma databáze) vypadá pěkně a ve škole se to tak učí dělat, a funguje to pěkně, dokud se všechno nějakým způsobem vejde do diskové cache. Až vám kvůli znormalizovaným datům rozlezlým do sta míst v různých tabulkách (tj. sto různých míst na disku) začne hodně seekovat disk, začnete denormalizovat a nakonec se dostanete k něčemu, co bude dokumentovou databázi docela dost připomínat :)

[balki]

Uz to je offtopic: Ale normalne sa to ma robit pri navrhu takto: chaos -> normalizacia -> denormalizacia.

Pricom vysledne entity maju ovela lepsiu strukturu ako povodny chaos, ale su menej vypoctovo narocne ako normalizovana forma.

To len tak :)

[Messa]

Vzhledem k jednoduchosti (je to v podstatě key-value databáze) by tyto "NoSQL" databáze měly být rychlejší než tradiční SQL databáze a mít lepší možnosti škálování (a to někde úplně jinde, než nějaké master-slave u MySQL); proto by měly být vhodnější i pro velké objemy dat. Jak moc to splňuje zrovna CouchDB ponechám na vašem úsudku :)

[Ladicek]

NoSQL databáze se obvykle rozlišují na key-value úložiště, sloupcové databáze, dokumentové databáze a grafové databáze. Samozřejmě nerelačních databází je ještě víc druhů, ale jak říkám, tohle je v hnutí NoSQL takové obvyklé rozdělení. CouchDB je dokumentová databáze, nikoliv key-value store, i když je dost jednoduchá. Třeba takové MongoDB je mnohem složitější (přejímá některé vysokoúrovňové principy z relačních databází, třeba explicitní rozdělení databáze na jednotlivé kolekce nebo "normální" indexování a dotazování).

[osvc01]

kdyz uz se tu nekdo ptal na to, k cemu to je, tak bych rad prednesl aktualni problem:

prave se potykam s nabidkou udelat webovou prezentaci, ktera je vlastne jednoducha co se graficke upravy tyce. Data, ktera se maji zobrazovat jsou v desetitisici word-dokumnetech. Kazdy takovy word dokument je castecne strukturovany - neco jako manualove stranky v unixu -> tedy odstavce textu maji nadpisy (nemoc, diagnoza, komplikace ... ano je to z oblasti lekarstvi a tito lide maji skutecne tezkosti neco strukturovat - vymlatit z nich, co vlastne chteji bude asi ten nejvetsi problem).

Samozrejme, ze ty word dokumenty obsahuji obrazky a take tabulky, seznamy apod. Nyni stojime pred rozhodnutim, co na to vzit. Urcite by bylo mozne rozsekat ty word dokumenty na casti, ktere by pak byly takrikajic ulozeny pod odpovidajicim sloupeckem v rel. databazi. Datovy typ takoveho sloupce je pak nejaky velky text. Uz z toho je videt, jak krkolomne by to v rel databazi bylo a jak se na to nehodi = ta rel. databaze vubec nic neprinese. Myslim si, ze to je presne pripad, kdy vyuzit NoSQL db.

Myslim, ze takovych pripadu bude pribyvat. Ve firmach je mnozstvi dokumentu, ktere se valeji po ruznych pocitacich vsecch spolupracovniku, pozoruji snahu ve firmach dostat do toho nejaky poradek.

[Heron]

Upřímně řečeno ani v tomhle příkladě nevidím výhody NoSQL nad SQL. Tak jako tak ty word dokumenty musíte nějakým způsobem zpracovat, případně prostě uložit jako BLOB do DB. Jaký je přínos NoSQL DB?

K článku. Chápu to správně tak, že pro každý typ dotazu si musím vytvořit (naprogramovat) pohled?

[Ladicek]

To v CouchDB skutečně musíte – nebo vyrobit nějaký chytrý pohled použitelný pro víc typů dotazů (ala zmíněné Megaview). Filozoficky jsou pohledy v CouchDB někde mezi dotazy, materializovanými pohledy a indexy z SQL databází

[balki]

Cize problem sa spracovania sa presuva, dobre rozumiem ?

Pri klasickych relacnych databazach prevazuje predspracovanie. (Da sa robit za behu, ale trpi vykon)

V couchDB to spracovanie robi predovsetkym "za behu", pricom databaza je na taketo srandy optimalizovana. Je to pomalsie, ako uplne strukturovanymi datami ale nie az take katastrofalne ...

Tak to je ?

[Ladicek]

Spíš naopak, v relačních databázích se data obvykle "dolují" ze struktury v době čtení, tedy při vyhodnocování dotazu, zatímco v těch nerelačních je běžné rovnou ukládat data, která bude později potřeba přečíst. Tedy denormalizace je zde úplně normální, zatímco v relačních databázích se k ní přistupuje až když trpí výkon.

Dokumentové databáze (CouchDB, MongoDB) mají nějaké prostředky k omezení té denormalizace (MapReduce, "normální" indexy a dotazy), ale třeba v key-value úložištích (já tomu česky říkám spíš persistentní mapy) už to jinak nejde.

To klíčové jste ale vystihl: zpracování dat se přesouvá jinam.

[jimik]

tesim sa na pokracovanie

[qwertzuiop]

O (relačních) databázích a SQL vím jen trochu, nejsem žádný odborník.

Pokud tomu rozumím správně, mezi položkami této DB neexistují vztahy ve smyslu, že části jedné položky mohou být v jiných položkách. Tedy: v relační DB bychom měli tabulku autorů, tabulku knih a tabulku žánrů; položka (např. kniha s informacemi o ní) by vznikla, kdybychom vzali z tabulky knihu a pomocí nějakých vztahů s jinými tabulkami vytvořili jednotku "kniha + autor + žánr".

V této DB to, předpokládám, chodí tak, že položky není při výběru potřeba pomocí nějakých vztahů vytvářet z částí, stačí je získat pouze pomocí ID. Jinými slovy, v této DB se duplikují data, protože každá položka má všechny údaje "v sobě" a například změna názvu žánru by znamenala změnu všech položek.

Jestli tomu je tak, je tato DB asi výhodná ve chvíli, kdy se ukládají nesouvisející položky (dokumenty, například poznámky v programu Tomboy, jak je patrno z odkazu Desktopcouch), ale nevýhodná ve chvíli, kdy bychom chtěli třeba udělat světovou DB všech knih, autorů a žánrů, protože by se to prostě špatně spravovalo (duplicity, absence schématu, které by bylo v daném případě zcela jednoznačné).

Může mi moje domněnky někdo potvrdit, nebo mě vyvést z omylu?

[Ladicek]

Myslím, že v zásadě už jsem tady v diskusi odpověděl, takže řeknu ještě tohle: jsou samozřejmě situace, kdy máte související informace uložené ve dvou nebo více dokumentech. Jak se tohle řeší bude ve druhém dílu.

[qwertzuiop]

No, tady se baví hlavně lidé, co s databázemi umí, takže jsem tomu moc neporozuměl. Takže, lze alespoň formou ano/ne potvrdit platnost mého 2. a 3. odstavce?

[Ladicek]

Tak já to zkusím: intuitivně na to jdete správně, ale není to úplně přesné. V SQL databázi je základní jednotkou tabulka (s předem daným počtem a typem sloupců), v dokumentové databázi obecný dokument (obvykle JSON) bez předem dané struktury. Už to může rozhodovat, která databáze je kdy vhodnější.

Když máte vysoce strukturovaná data, když se struktura moc často nemění, když je důležité transakční zpracování, nebo když prostě "potřebujete" nějakou vlastnost SQL databází, použijte je. Když máte data v podobě dokumentů (třeba ty poznámky v Tomboyi, ale klidně i složitější), jejichž struktura je předem nejasná nebo se často mění, můžete použít dokumentovou databázi.

Dokumenty nemusí obsahovat všechna data v sobě, ale obvykle je různých typů dokumentů méně než tabulek v odpovídající SQL databázi (třeba ta situace kniha + žánry by vedla hned na 3 tabulky). Když budu mít autora v jednom dokumentu a každou jeho knihu v dalším dokumentu, není problém je získat najednou (bude v tom příštím dílu).

Doufám, že je to srozumitelnější

Napriklad dokumentove-orientovana databaze Riak ma neco jako relace mezi jinymi dokumenty. Nazyvaji to link.

[okbob]

plus minus to tak je.

Představte si to asi tak, že máte doma skříň na věci. Uvnitř skříně můžete mít buďto chaos - hromadu krabic s nějakým obsahem - co je v krabicích nevíte - maximálně máte štítek na krabici. Věci dáváte do skříní po krabicích, a vyndaváte po krabicích. Pokud vždy potřebujete obsah krabice, tak je to super. Popadnete celou krabici. Problém je, když hledáte něco, co úplně přesně nevíte, kde je. Pak musíte rozbalit každou krabici. Takhle zhruba fungují NoSQL databáze.

Také můžete mít skříň plnou polic, a v každé polici pouze určité věci. Při hledání víte, kam se podívat. Na druhou stranu, musíte vymyslet systém, pokud dostáváte věci k uklízení po krabicích, tak potřebujete určitý čas, k tomu, abyste roztřídil obsah krabice, a totéž, pokud po Vás někdo bude chtít krabici s něčím, tak potřebujete čas, abyste dohledal a naplnil obsah krabice. Pokud potřebujete zjistit obsah jedné police, tak super. Nic Vás nezdržuje. To je zhruba přístup relačních databází.

[osvc01]

ten priklad s tou skrini je fantasticky a uz nyni vidim, jak to muzeme dal rozvinout, abychom presne dokazali ukazat na problematiku uschovavani dat.

- prvni problem rel. databazi je mozno videt v nasledujicim:

vidime, ze ten truhlar (databazovy analytik) k tomu, aby mohl udelat tu skrin spravne musi 'bohuzel' predtim, nez zacne rezat znat pokud mozno obsahy vsech krabic, ktere budou 'rozlozene' ukladany do skrine. Jeste vetsi problem nastava, kdyz se pote co byla skrin udelana zjisti, ze obsahy krabic prece jen meni. (firma zmenila strukturu sve cinosti, doslo k posunu na trhu ..).

[okbob]

Stejně tak jak v životě - kupujete nové skříně a prodáváte staré.

[qwertzuiop]

Díky všem za vysvětlení.

[Radek Miček]

Nemyslel jste místo idempotentní spíše čistá?

[Ladicek]

Idempotentní a čistá a referenčně transparentní a já nevím co všechno Může být, že mám tu terminologii špatně – funkcionální teorii nemám úplně zmáknutou.

[Radek Miček]

Osobně si nemyslím, že je to totéž. Ve Wikipedii říkají

invoking the procedure a single time or multiple times has the same result; i.e., after any number of method calls all variables have the same value as they did after the first call

a podle mne tím myslí f(f(x))=f(x) případně u procedur, co nic nevrací tím myslí, že se stav světa nezmění po 2., 3. a dalších voláních (například zruším objednávku).

Zato referenční transparentnost znamená, že výraz mohu nahradit jeho výsledkem, tedy u procedur to znamená, že je nemusím vůbec volat, protože nic nevrací -- idempotentní procedury mohou mít side-effect, ale referenčně transparentní ne (čistě funkcionální jazyky nemají procedury).

[토토사이트]

You made such an interesting piece to read, giving every subject enlightenment for us to gain knowledge. Thanks for sharing the such information with us to read this. 토토사이트

[토토사이트]

You made such an interesting piece to read, giving every subject enlightenment for us to gain knowledge. Thanks for sharing the such information with us to read this. 토토사이트

[온라인바카라]

I’m not sure exactly why but this weblog is loading incredibly slow for me. Is anyone else having this problem or is it a problem on my end? I’ll check back later on and see if the problem still exists. 온라인바카라