Devel.cz Lupa Měšec Podnikatel Root Zdroják.cz DigiZone Slunečnice Vitalia TopDrive KupDnes Navrcholu NovýTarif Dobrý web Weblogy Woko Jagg Computer.cz SK: MojeLinky

Hlavní navigace

Vlákno názorů k článku
CouchDB – tak trochu jiná databáze (1. část)

Nuko
Nuko (neregistrovaný) ---.hzsol.cz
24. 8. 2009 8:18

Zamky

A co zamky u konkurencniho zapisu?

Gorilka
Gorilka (neregistrovaný) ---.egexpert.cz
24. 8. 2009 8:35

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.

ego
ego (neregistrovaný) ---.net.upc.cz
24. 8. 2009 9:40

Re: Zamky

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

Martin Malý aura:93
24. 8. 2009 9:44

Re: Zamky

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

MarSik
MarSik (neregistrovaný) ---.redhat.com
24. 8. 2009 9:53

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

aprilchild
aprilchild (neregistrovaný) ---.zapcechy.adsl-llu.static.bluetone.cz
24. 8. 2009 10:19

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.

povinná
povinná (neregistrovaný) ---.62.broadband3.iol.cz
24. 8. 2009 18:57

Re: Zamky

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

Zasílat nově přidané příspěvky e-mailem