Lehký úvod do CouchDB – 3 (shrnutí)

22. 2. 2010 | Ladislav Thon | Programování | 4768×

V minulém díle seriálu o CouchDB jsme si ukázali některé její pokročilejší vlastnosti a dnes se s ní po krátkém příkladu rozloučíme. Zkusíme si nad CouchDB postavit jednoduchý redakční systém, který bude z prohlížeče přes AJAX komunikovat přímo s databází, a nakonec se trochu prakticky zamyslíme.

Čistě z mojí pohodlnosti dnes opustíme knižní svět (chci ukázat stromy a momentálně si neumím představit žádnou strukturu, do které by se daly knihy kategorizovat, když jsem žánry vyčerpal jako tagy) a splácáme milióntýprvý redakční systém, ve kterém lze zadávat články a zařazovat je do stromové struktury. Začneme s tím lesem. Je mnoho způsobů, kterak v SQL ukládat stromy (viz např. tady), ale žádný z nich není ideální. My, v úplně jiném světě, použijeme ten na pohled nejmíň ideální ze všech: Strom uložíme do jediného dokumentu.

Máme k tomu jeden prostý důvod: Pro účely CMS, kde se stromy používají akorát pro kategorizaci dokumentů, je pravděpodobně nejvýhodnější všechny stromy hned ze začátku načíst do paměti a pracovat s nimi v aplikaci. (Na druhou stranu, když je potřeba se stromovými a obecně grafovými strukturami pracovat nějak seriózně ve velkém, nejspíš uděláme nejlíp, když si pořídíme grafovou databázi.) Nuž, představivosti se meze nekladou:

{"type": "tree", "root": {
  "name": "Články", "children": [
    {"name": "Programování", "children": [
      {"name": "Programovací jazyky"},
      {"name": "Databáze", "children": [
        {"name": "SQL"},
        {"name": "NoSQL", "children": 
          {"name": "Key-value stores"},
          {"name": "Sloupcové databáze"},
          {"name": "Dokumentové databáze"},
          {"name": "Grafové databáze"}
        ]}
      ]},
      {"name": "Web"},
      {"name": "Překladače"}
    ]},
    {"name": "Výkřiky", "children": [
      {"name": "UN*X"},
      {"name": "Alkohol"},
      {"name": "Blogísky o koních"}
    ]}
  ]
}}

Komu by se ovšem chtělo programovat GUI pro operace se stromem, že. Vezměme tedy jsTree; dokumentace by snesla nějakou tu péči, ale i v současné podobě je vcelku dobrá. jsTree má mimo jiné vlastní JSONový formát, ze kterého umí načítat a do kterého umí i ukládat, a protože se mi nechce řešit transformace, namísto formátu navrženého výše použijeme přímo tenhle. To samozřejmě opravdu není přístup vhodný pro skutečnou aplikaci, ale pro naši ukázku postačí.

A protože budeme chtít do jednotlivých uzlů stromu (kategorií) zařazovat články, budeme potřebovat ještě jednu položku, kterou jsme výše neuvedli: Každý uzel musí mít vlastní ID. V jsTree není problém při vzniku nového uzlu spustit nějaký kód a nová ID nám může generovat CouchDB (http://localhost:5984/_uuids, případně s parametrem count=10 apod.). V článku pak do jedné položky (topics) uložíme ID těch kategorií, do kterých je článek přímo zařazen, a pro účely vyhledávání do druhé položky (search_topics) ID všech kategorií a jejich rodičů. Jedním jednoduchým pohledem pak snadno získáme všechny články ve vybraném podstromu:

// map
function(doc) {
  if (doc.type == "doc" && doc.search_topics) {
    for (var topic in doc.search_topics) {
      emit(doc.search_topics[topic], doc);
    }
  }
}

Dál: Editace článků. Když máme všechno tak hezky dynamicky typované, struktura článku budiž definována prostě HTML formulářem. Jen si to představte:

<div id="docEdit">
    <div class="field">
        <label>Název:</label>
        <span class="w"><input type="text" name="name"></span>
    </div>

    <div class="field html">
        <label>Popis:</label>
        <span class="w"><textarea rows="5" cols="70" name="desc"></textarea></span>
    </div>

    <div class="field">
        <label>Autor:</label>
        <span class="w"><input type="text" name="author"></span>
    </div>

    <button id="saveDocButton">Uložit</button>
    <button id="cancelDocButton">Storno</button>
</div>

JSONový dokument pro uložení do databáze pak získáme vysloveně triviálně (používám jQuery):

// to je pro vytvoreni noveho dokumentu; pri editaci existujiciho bude doc
// vlastne ten dokument, ktery byl nacten z databaze
var doc = {};
$("#docEdit input, #docEdit textarea").each(function() {
  doc[$(this).attr("name")] = $(this).val();
});
// textarey v bloku s tridou „html“ budou instance TinyMCE (ma vlastni plugin pro jQuery)
$("#docEdit .html textarea").each(function() {
  doc[$(this).attr("name")] = $(this).html();
});

Dobře, tohle je úplně mimo téma, takže proč to ukazuji? Tenhle kód má jednu krásnou vlastnost: Naprostou nezávislost na struktuře dat. Přidám do HTML kódu jedno políčko – a šup, je v databázi. Není to nic sofistikovaného a bylo by pěkné rozšířit to například o seznamy či poddokumenty, ale čistý text a HTML pro ukázku docela dobře postačí. (Pozn.: Ve větší aplikaci bych samozřejmě nechtěl definovat strukturu dokumentu HTML formulářem, ale rozhodně bych ji nechtěl definovat ani strukturou tabulky v relační databázi.)

To byly dvě nejdůležitější věci ohledně našeho primitivního CMS. Kompletní kód, který je pochopitelně trochu složitější (asi 300 řádek), najdete v příloze. Není zrovna nejhezčí, ale je dost krátký na to, aby ho snad každý pochopil. Pro komunikaci s databází se nepoužívají přímo AJAXové funkce jQuery, ale jednoduchá knihovnička, která je součástí distribuce CouchDB a nad kterou je postaven Futon (v Debianu k nalezení v /usr/share/couchdb/www/script/jquery.couch.js). Aplikaci servíruje webový server, pro trochu věrnější simulaci reality, takže je potřeba vyřešit AJAXové volání na jinou doménu: Nejjednodušší je proxy ve webovém serveru, jak je v příkladu ostatně ukázáno. jQuery knihovna pro CouchDB s tímto použitím nepočítá, proto jsem ji musel lehce upravit (přidání proměnné uriPrefix a modifikace pár funkcí).

V příkladu je jako bonus ukázána zcela bezbolestná a bezkonkurenčně nejjednodušší metoda, jak lokalizovat data (popis v souboru l10n.txt). Zkusme se u ní na chvilku zastavit. Na tomhle ještě není nic divného:

<div class="field">
  <label>Název [EN]:</label>
  <span class="w"><input type="text" name="name_en"></span>
</div>

To jenom uložíme anglickou variantu názvu do databáze. Co s tím dál? Pokud se článek renderuje do HTML takto:

function(doc, req) {
  provides('html', function() {
    return '<h1>' + doc.name + '</h1><div>' + doc.desc + '</div><hr><p>Autor: <em>' + doc.author + '</em></p>';
  });
}

pak jediná zbývající potřebná změna je:

function(doc, req) {
  var lang = req.query.lang;
  if (lang) {
    for (var attr in doc) {
      if (doc[attr + '_' + lang]) {
        doc[attr] = doc[attr + '_' + lang];
      } else if (attr.match('_' + lang + '$')) { // attr.endsWith('_' + lang)
        // neni nutne, ale pro renderovani proste chci mit v dokumentu jen "kanonicke" atributy
        doc[attr] = null;
      }
    }
  }

  provides('html', function() {
    return '<h1>' + doc.name + '</h1><div>' + doc.desc + '</div><hr><p>Autor: <em>' + doc.author + '</em></p>';
  });
}

Jazyk uživatele je zde pro jednoduchost dán hodnotou parametru lang v URL. Abychom nemuseli měnit „šablonu“, pro účely renderování si kopii dokumentu pozměníme: Všechny atributy nahradíme jejich lokalizovanými verzemi, pokud existují. A… eh… to je vše.

Kód k příkladu: couch-cms.zip.

CouchDB má ještě řadu dalších funkcí, o kterých jsme se vůbec nezmínili (třeba sledování změn, dávkové operace nebo nativní erlangové API – ano, v prvním dílu jsem o jediném API v podobně HTTP trochu lhal :-)), ale momentálně byste měli mít vcelku přesnou představu o tom, co práce s CouchDB obnáší, a měli byste být schopni se rozhodnout, zda by pro vás CouchDB mohla být přínosem. Zkusme si to trochu shrnout.

Shrnutí

CouchDB je velmi robustní: Soubor, ve kterém je databáze uložena, se nikdy nepřepisuje, pouze se k němu připisuje. Nevýhodou může být, že takto může soubor docela slušně nabobtnat, takže je potřeba pravidelně volat garbage collector (viz první díl). V době běhu GC je databáze normálně použitelná, platná data se totiž kopírují do nového souboru, který se po dokončení začne používat namísto původního. Návrh „append only“ má samozřejmě určitou režii (skvěle funguje paralelní čtení, ale zápisy jsou vždy serializovány), takže nevhodným používáním lze snadno zabít výkon. CouchDB nemá transakce v obvyklém smyslu, ale změna jednoho dokumentu transakční (ACID) je. Zajímavé je, že návrh diskové struktury nevyžaduje žádnou obnovu po pádu, dokonce neexistuje žádné zvláštní „ukončení běhu“ a používá se normální zabití procesu.

CouchDB nemá schéma a umožňuje ukládat volné struktury. To se velmi dobře hodí pro rychlý vývoj nebo pokud mají data podobu dokumentů – naopak pokud jsou data vysoce strukturovaná a jejich podoba se příliš nemění, přináší bezschémový přístup spíše nevýhody. Ad hoc dotazování je v CouchDB problematické (eufemisticky řečeno).

CouchDB dobře škáluje, a to různými směry. Databázové jádro je napsané v Erlangu, takže není problém je provozovat na velkých serverech i na embedded systémech. Důležitou součástí je online i offline replikace (v relačním světě by se o ní řeklo, že je „multi-master“). CouchDB lze provozovat v clusteru, ale i jako úložiště osobních dat na několika různých zařízeních (stolní počítač, notebook, telefon, PDA, webový server), která se spolu synchronizují. CouchDB není databáze pro web, nýbrž na webu.

CouchDB není na světě příliš dlouho, ale pár let už za sebou má (vývoj začal v roce 2005), takže je dnes funkčně dosti bohatá a existuje kolem ní početná komunita a řada dalších projektů. Za všechny jmenujme couchdb-lucene (fulltext postavený nad Lucene), Lounge (clusterovací framework), couchdb-python (kromě knihovny pro Python i pár užitečných utilit), jcouchdb (knihovna pro Javu), několik knihoven pro Ruby nebo CouchApp (sada nástrojů pro vývoj aplikací přímo v CouchDB). Poměrně kvalitní dokumentace a spousta odkazů se nachází na wiki, zdarma je v elektronické podobě dostupná i výborná knížka CouchDB: The Definitive Guide.

Tímto končí naše série věnovaná CouchDB. Pokud bude zájem, pokusil bych se napsat něco málo i o jiných bezschémových databázích (MongoDB? Neo4j?), pokud nikoliv, pak jsem rád aspoň za to, že jste dočetli až sem :-) a možná se i dozvěděli něco nového.

       

Komentáře

[alblaho]

Já bych si tedy nějaké lehké povídání o jiných nosql udělátkách přečetl rád.

[amra]

Docela rad bych si pocetl o dalsich podobnych systemech, pripadne neco o Amazon SimpleDB, Google BigTable nebo HBase.

[Ladicek]

Já toho o sloupcových databázích moc nevím, zajímají mne spíš ty dokumentové mrchy. Kdybych se o ně začal zajímat, asi bych začal u Cassandry, protože ta narozdíl od HBase nebo Hypertable nepotřebuje samostatný distribuovaný souborový systém (HDFS, CloudStore). Ale Hadoop a příbuzné projekty jsou určitě vrcholně zajímavé, o tom žádná

[deda.jabko]

Ale Hadoop a příbuzné projekty jsou určitě vrcholně zajímavé, o tom žádná

jak rikaji neandrtalci: ,,toooo joooo''

mel jsem postaveny hadoop cluster z pocitacovych uceben, ktere se v noci zresetovali a ja tam nahodil hadoop i s HDFS. melo to jenom drobnou chybicku... vypocet musel probehnout do doby, nez rano prisli studenti a zacali mi jednotlive nody resetovat do windows....

uz asi pred rokem jsem o tom rozepsal ,,popularni'' clanek, protoze to, co je k tomu aktualne na netu (i v anglictine), je docela slabota... ale zatim to stoji na tom, ze je porad na praci neco zabavnejsiho (nebo nutnejsiho)... :-/

[Ladicek]

Já čtu o Hadoopu s oblibou http://www.cloudera.com/blog/, ale to je asi tak všechno. Někdy bych si to rád vyzkoušel v praxi

[deda.jabko]

ja jsem na tom delal toto. a moje zkusenost je asi takova... rozbehat cluster a spravovat jej je docela v pohode. po nejake dobe, clovek prijde i na triky, jak jej vyladit... nicmene, aby clovek zkousl tu rezii, kterou si bere implementace v jave a vsemozne presypani dat, je potreba mit velky cluster a docela slusne stroje v uzlech.

dobre je, ze naprogramovat funkce map a reduce jde vicemene pomoci jakehokoliv jazyka... vyzkousel jsem python a SBCL. ale prislo me, ze z pohledu vykonu je to dobre jenom na odzkouseni, ze dany algoritmus funguje. ve finale jsem musel sahnout po implementaci algoritmu v jave.

dalsi problem na ktery jsem casto narazel byla relativne chaba dokumentace. navic internetu jsou ukazky, jak s pomoci hadoop pocitat slova v textu, nebo navstivene URL, ale jinak nic moc navic... takze v nekterych momentech, kdyz jsem potreboval neco slozitejsiho jsem musel jit do zdrojaku a zjistit si, jak co funguje. ale mozna se to za tu dobu zlepsilo...

[Ladicek]

Ty příklady jsou asi velká pravda. Já vím akorát o Mahoutu, tam by mohlo být vidět víc.

[deda.jabko]

diky za info... v dobe, kdyz jsem s hadoop delal, mahout neexistoval, takze jsem na ty veci musel prijit sam... ale aspon jsem se neco naucil... mimojine, v te dobe se mi nepodarilo rozchodit ani hadoop pluginy do eclipse, takze jsem zdrojaky psal ve ViMu a kompiloval a spoustel jsem to pres sadu bashovych skriptu... to bylo panecku aspon IDE... ;-]

[MarSik]

Docela zajímavě vypadá také Sector/Sphere. Není jako jeden z mála v javě, vypadá to, že konfigurace je dosti jednoduchá a nemá (narozdíl od Hadoopu) single point of failure. Výkonostní testy také vychází lépe než pro Hadoop.

http://sector.sourceforge.net/index.html

[vorcigernix]

Vypadá to jako super koncept a líbí se mi ta logika, jenom jsem se na celý den zasekl na triviálním úkolu, předělat update skript. Aktuální stav je ten, že z txt souboru děláme pravidelně přes sqlplus update pomocí shell skriptu (asi je to v cronu).

Zmodifikovat to txt do json syntaxe není problém a zavolat potom curl -v -d@turnovers.json -X POST http://server:8080/turnovers/_bulk_docs jednou projde. Potom se ale dostanu do problému, že při dalším postu chce znát _rev, který do toho texťáku nedostanu. Asi by šlo volat každý dokument zvlášť a před každým POSTem zjistit jeho aktuální _rev, ale to mi jednak přijde jako nadbytečná komunikace a jednak nevím jak to udělat :)

Ideální by bylo kdyby se dala udělat nějaké view, které ty hodnoty zaktualizuje i bez _rev, ale v tom mi google moc nepomohl.

Díky za každou radu (kromě rady "nech to na oracle")

[vorcigernix]

Tak si částečně mohu odpovědět sám. Od verze 0.10 je k dispozici specifický design dokument, který umožňuje víceméně genericky updatovat i bez revizí (inplace).

Kód který mi funguje vypadá následovně: { "_id": "_design/update", "language": "javascript", "updates": { "in-place": "function(doc,req) {var field = req.query.field;var value = req.query.value;doc[field] = value;var message = 'set '+field+' to '+value;return [doc, message];}" } }

a volá se jako http://ucouch.xxx.xxx:8080/turnovers/_design/updatewgr/_update/in-place/1600?field=wgr&value=601 kde wgr updatujeme na hodnotu 601

Není to moc elegantní a budu muset vyrobit prvotní dokumentovou strukturu manuálně, ale funguje to hezky.