20 komentářů k článku CouchDB – tak trochu jiná databáze (1. část):

    1. Gorilka

      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.

      1. ego

        Re: Zamky

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

    2. MarSik

      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é.

    3. aprilchild

      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.

  1. yossarian

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

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

  2. (nill)

    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.

    1. Almad

      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.

  3. Lokutus

    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í.

  4. Viliceq

    "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].
    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.

    1. Mintaka

      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_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í.

      1. viliceq

        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

        1. Mintaka

          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.

  5. WuDo

    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 ;-)

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3068