Ukládání dat je záležitost, kterou řeší vývojáři téměř denně. Existuje mnoho cest, jak k problému přistoupit. jednou z cest může být například CouchDB: distribuovaná, dokumentově orientovaná databáze s HTTP RESTful JSON API (tolik zkratek pohromadě…), kterou lze indexovat ve stylu MapReduce.
Proč jsou ECMAScript moduly lepší než CommonJS? Už nastal ten správný čas přepsat všechny své NPM balíčky na ECMAScript moduly?
Je vhodné používat skryté nadpisy pro navigační bloky? Je responzivní design nutný pro splnění požadavků zákona? Kdy začít řešit přístupnost našeho webu či aplikace? Další otázky (a odpovědi) na téma přístupnost.
Co je to Fluentd? Je další generací logování? Jak v něm fungují pluginy a pipelines pattern?
Zamky
A co zamky u konkurencniho zapisu?
Re: Zamky
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.
Re: Zamky
Doufam, ze autora tento bezcenny a arogantni prispevek neznechuti tak, aby nas pripravil o dalsi dily.
Re: Zamky
Autor dodal celý miniseriál najednou, takže o další díly nebudete připraveni.
Re: Zamky
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é.
Re: Zamky
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.
Re: Zamky
Slovo, po kterém tak marně tápete, se píše „souběžný“.
Re: CouchDB – tak trochu jiná databáze (1. část)
pekne napsane, kamera chvali. po vecne strance trochu horsi, kamera kara.
Uz se tesim na dalsi dily.
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.
Re: Uz se tesim na dalsi dily.
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.
Hezký článek
Děkuji autorovi za zajímavý článek, těším se na pokračování.
Lotus Notes
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í.
Re: Lotus Notes
ano jako bývalého „notesaře“ mě to taky hned napadlo….. :o)))
Re: Lotus Notes
Na tohle téma doporučuju video couchdb and me.
Re: Lotus Notes
Som netusil, ze Tom Cruise je programator.. :)
"koho napadne další, má bod"
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.
Re: "koho napadne další, má bod"
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_binarnich_datech_s_promennou_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_binarnich_datech_s_promennou_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í/dekó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í/dekó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í.
Re: "koho napadne další, má bod"
Š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
Re: "koho napadne další, má bod"
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.
Nálepka
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 ;-)