Názory k článku
CouchDB – tak trochu jiná databáze (1. část)

A co zamky u konkurencniho zapisu?

Vzhledem k tomu, že se autor poněkud topí už u zamykání dat a concurency modelu na DB serveru, nemá cenu tuto otázku ani pokládat.
Ale jinak pěkný článek.

Doufam, ze autora tento bezcenny a arogantni prispevek neznechuti tak, aby nas pripravil o dalsi dily.

Autor dodal celý miniseriál najednou, takže o další díly nebudete připraveni.

Nejsou potřeba. Všdy se zapisuje celý dokument a pokud v požadavku nesedí (povinný) klíč _rev s aktuálně platnou revizí, zápis se neprovede a databáze informuje klienta o konfliktu verzí. Ten na to pak může reagovat.

Není to databáze na ukládání transakčního logu burzy, na to se opravdu lépe hodí relační (vyřešená tak, aby zamykání nezpomalovalo). Ale na data pro eshop nebo publikační systém vypadá velmi dobře.

Krom toho má zabudovány replikační mechanizmy, distribuovanost a fail-over mechanizmy erlangu, což by mohlo být dost zajímavé.

Zadne zamky nejsou, prectu dokument, spolu s nim ziskam cislo revize, pri ukladani musim cislo zpetne posilat, pokud mezitim vznikla nova revize, ulozeni selze. Pokud selhalo, zkusim opakovat. V CouchDB neni definovano, kdy ulozeni projde, v pripade caste konkurence muze cyklus teoreticky trvat vecne.

Pokud k danemu problemu dojde, v naproste vetsine pripadu se jedna o chybu navrhu. Je treba se malinko odprostit od klasickeho relacniho pohledu. Klasickym prikladem budiz bankovni transakce (penize z uctu na ucet). Oproti transakci v klasicke databazi (bez transakce by taky penize mohli zustat nekde viset:), spociva reseni v CouchDB (jen pro priklad, ne, ze to v tom nekdo napise bankovni aplikaci:) v nasledujicim zpusobu:

Kazdy ucet si drzi zakladni dokument s udaji o vlastnikovi, ale nikoliv o zustatku (protoze pri urcitem objemu transakci by nebyl zarucen zapis „nekdo mi posila penize a zaroven je odesilam jinemu“). Pro kazdy prevod se vytvori novy dokument s castkou, od koho/komu atp. Zustatek je pro kazdy ucet spocitan pres „reduce“ iteraci pres kolekci techto dokumentu vybranych na zaklade „koho/komu“. Protoze pri prevodu vznika jeden dokument (oproti klasickemu reseni „sniz zustatek u odesilatele, zvys u prijemce“), penize nemizi, „transakce“ je zarucena.

Slovo, po kterém tak marně tápete, se píše „souběžný“.

pekne napsane, kamera chvali. po vecne strance trochu horsi, kamera kara.

Shodou okolnosti zrovna s CouchDB koketuju takze uvitam clanky na toto tema. CouchDB je svym zpusobem genialni napad, autor by mel vice rozvest dalsi ficurky jako skalovatelnost, replikaci atd. Ukazkova aplikace by byla taky super, jen nejaka jina nez v couchdb dokumentaci…aby z toho serialu nebylo jen prekladani dokumentace, coz by byla skoda, protoze CouchDB ma potencial.

Já bych spíš uvítal i srovnání s jinými systémy, používam mongodb a rád bych si nějak strukturovaně uložil rozdíly.

Děkuji autorovi za zajímavý článek, těším se na pokračování.

Vzhledem ke jménu Damien Katz a popsaným principům (dokumentově orientovaná databáze, UUID) apod. soudím, že inspirace přišla ze strany Lotus Notes. Jsem dychtivý přečíst si pokračování.

ano jako bývalého „notesaře“ mě to taky hned napadlo..... :o)))

Na tohle téma doporučuju video couchdb and me.

Som netusil, ze Tom Cruise je programator.. :)

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].
3. Kromě tabulky produktů zde bude ještě jedna, ve které se budou ukládat dvojice [produkt, parametr] a jedna další hodnota podle typu [hodnota_int, hodnota_text, hodnota_float, hodnota_timestamp, hodnota_bool]

Jedná se sice jen o rozšíření typu 2, ale přidáním sloupce pro každý používaný datový typ omezíme jeho nevýhody.

Navíc může mít jeden parametr více hodnot různého typu, které se dají využít bez nutnosti duplikovat parametr v tabulce.

Jinak hezký článek o zajímavé databázi, už se těším na další díl.

Ten bod 3. vyznívá podivně. Jestli jsem to pochopil správně, není z něj zřejmé, že pro každý typ uložené hodnoty bude třeba samostatná tabulka [produkt, hodnota]. (Předpokládám běžnou relační databázi.), s tím, že pro nalezení hodnot vztahujících se k danému produktu, budu třeba prohledat všechny tabulky.

Takže komplexnější řešení by bylo: Tabulka produktu [produkt(id), [..Další sloupce s vlastnostmi stejnými pro všechny produkty..]]

Tabulka parametrů [parametr(id)[­..vlastnosti společné pro parametry, například jeho název, autor, datum vložení.. ]]

Vazební tabulka mezi produkty a parametry [produkt(id), parametr(id)]

Toliko k vazbě parametr produkt. Pro relační databáze běžná záležitost. Nyní chceme spolu s parametry ukládat ještě konkrétní hodnoty.

Možností je několik a všechny závisí na parametrech cílového využití takové struktury. Tz. jaká data do toho potečou, jaké operace se s nimi budou provádět, v jakém množství, …

ř1] V tabulce parametrů budou navíc dva sloupce [typ_hodnoty, hodnota_v_binar­nich_datech_s_pro­mennou_delkou­] V situaci, kdy by se hodnoty vztahovaly k jednotlivým jednotlivým parametrům. výhody: obejití nutnosti založit pro každý typ samostatnou tabulku, mnoho specifických typů hodnot nevýhody: specifický přístup binárních datům, specifika vyhledávání podle binární hodnoty

ř2] Samostatná tabulka hodnoty_parametrů [hodnota(id), typ_hodnoty, hodnota_v_binar­nich_datech_s_pro­mennou_delkou­] a vazební tabulka [parametr(id), produkt(id), hodnota(id)] Pro situaci, kdy jsou hodnoty parametrů vztažené k jednotlivým produktům. výhody: jako ř1 nevýhody: jako ř1

ř3, ř4] Analogie k ř1 a ř2 ale místo binárních dat je použit textový řetězec. výhody: „lidštější“ práce než s binárními daty, o něco lepším možnost využít standardního aparátu DBMS nevýhody: omezení délkou řetězce, větší nároky při encodování/de­kódování celočíselných hodnot, binárních dat, strukturovaných formátů jako datum a čas, …

ř5] Samostatné tabulky pro každý typ [hodnota(id), hodnota] a provázání na produkty / parametry, vazební tabulkou výhody: bez nutnosti encodování/de­kódování hodnot (to udělá DBMS automaticky sám) nevýhody: tabulka pro každý typ ukládaných hodnot o obsluha této struktury

Určitě by s k tomu dalo najít ještě spousta řešení. Možností je mnoho, záležet bude na konkrétním nasazení.

Špatně jsem se vyjádřil – jednalo by se o jednu tabulku, a jeden sloupec pro každý používaný datový typ.

Tozn. tabulka by měla tyto sloupce:

produkt integer, parametr text, hodnota_int integer, hodnota_text text, hodnota_float float, hodnota_timestamp timestamp, hodnota_bool boolean

Taky řešení. Pak by to chtělo logiku, která by dohledávala ve kterém z těch sloupců je obsah a které jsou jen vycpávka.

Ahoj, moc děkuji… pouze prosím o doplnění nálepky CouchDB pro snadnější nalezení tohoto článku zde, na skvělém Zdrojáku…

Děkuji ;-)