[vpsFree.cz: community-list] CouchDB - praktické zkušenosti

[Jan B. Kolář]

Ahoj,

díky za reakci i odkaz na článek. Kupodivu mi nějak unikl, vycházel jsem 
z informací o Eventual Consistency: 
http://docs.couchdb.org/en/stable/intro/consistency.html

Přesně jak píšeš, výpadky jsou minimální, takže by se dala použít 
on-line databáze a v případě výpadku nějaká dočasná lokální kopie. I s 
touhle myšlenkou jsem si pohrával, ale narazil jsem právě na problém, 
jak správně data mezi on-line databází a lokální kopií synchronizovat. V 
globále v podstatě řeším následující:

1) Mám "sdílené" tabulky, které potřebuji mít v nějaké rozumně aktuální 
podobě k dispozici v lokálních databázích (např. produkty, uživatelé, 
zákazníci). Do těchto tabulek se nemusí nutně zapisovat v případě 
výpadku, tzn. je li výpadek, nepůjde upravit produkt, přidat zákazník a 
tak dále. Lokální kopie tedy může být "read-only".

2) Mám tabulku účtenek, do které pokladna bude zapisovat i v případě 
výpadku. Z hlediska použitelnosti by bylo nejideálnější, kdyby na lokále 
byla aktuální data (tzn. i v případě výpadku je přístup ke všem 
účtenkám, např. kvůli reklamaci). Do této tabulky nebudou zapisovat jiné 
pokladny (pokud nebude sdílená pro všechny účtenky, každopádně by ale 
pokladna neměla upravovat řádky jiné pokladny). Na serveru mi zase stačí 
"read-only" kopie, abych se mohl z administrace dostat ke všem účtenkám 
všech prodejen, případně, aby se mohla třeba řešit reklamace na jiné 
prodejně, než byl produkt zakoupen.

Dá se tedy říct, že potřebuji synchronizovat data - některá ze serveru 
na pokladnu a jiná z pokladny na server. Přičemž právě synchronizace dat 
se nejvíce bojím - přijde mi to jako obsáhlý problém a myslím že to se 
svými znalostmi nejsem schopen podchytit v aplikaci. A právě CouchDB mi 
přišlo jako ideální řešení, protože mi zaručí dostupnost dat jak na 
lokálech, tak na serveru. Jenže ke CouchDB nemůžu najít moc zdrojů a 
nejsem si jist, jak mám některé věci implementovat - jak jsem psal, 
třeba právě sklad a skladové zásoby. Je dobré si udělat dokument "sklad" 
a v něm udržovat seznam všech produktů s jejich počtem. Nebo si v 
podstatě naroubovat relační přístup a vytvořit pro každý produkt 
dokument s obsahem "produkt", "sklad", "počet ks". Nebo udržovat 
skladové zásoby uvnitř dokumentu "produkt"?

Neotravoval bych Vás tím, jenže obvykle to u mě probíhá tak, že se s 
vervou pustím do implementace a když jsem tak v půlce, tak mi začnou 
docházet komplikace daného postupu. Tak všechno zahodím a pustím se do 
jiného způsobu, kde obvykle opět dojdu k jiným komplikacím. No a když už 
je to po páté a po týdnu není nic hotového, tak bych to s chutí 
roztřískal :-D

Zdraví

Honza


Dne 26.9.2018 v 10:41 Lukáš Němec napsal(a):
> Ahoj,
>
> dle popisu CouchDB a tvého problému, se zdá, že to řeší přesně to co 
> potřebuješ. Avšak co se týče konfliktů, určitě bych si napsal testy na 
> několik různých scénářů kde dojde ke konfliktu, a zjistil co se přesně 
> stane. To že je něco v dokumentaci, je jedna věc, ale taky můžeš 
> narazit na něco kompletně jiného.
>
> Jen taková poznámka, nemůžou ty pokladny předpokládat, že budou v 
> 99.99% případů kdy je někdo použije online, a tedy používat online 
> databázi na serveru, a v případě výpadku internetu bys použil lokální 
> “kopii” kterou bys musel synchronizovat po připojení. Samozřejmě by 
> tam taky mohlo dojít ke konfliktu, ale můj point je, že v naprosté 
> většině případů ten internet fungovat bude. Případně, pokud se jedná o 
> tak kritickou věc, stálo by za zvážení použít jiného poskytovatele 
> jako “fallback” připojení - ADSL+4G nebo něco podobného.
>
> Asi předpokládám, že jsi četl tenhle článek: 
> http://guide.couchdb.org/draft/conflicts.html#resolution
>
> Lukáš
>
>> 25. 9. 2018 v 19:08, Jan B. Kolář <janbivoj.kolar at zazen-nudu.cz 
>> <mailto:janbivoj.kolar at zazen-nudu.cz>>:
>>
>> Ahoj,
>>
>> nemáte tu prosím někdo praktické zkušenosti s CouchDB? Možná si 
>> vzpomínáte, že jsem tu před časem psal ohledně pokladního software. 
>> Po zvážení všech odpovědí jsem dospěl k názoru, že největší problém 
>> pro mne je udržovat synchronizovaná data mezi pokladnami a serverem. 
>> Jak věřím, tak CouchDB by pro mne tyto věci dokázala ohlídat, trochu 
>> se ale potýkám s nedostatkem informací. Kromě oficiálního manuálu se 
>> mi nepodařilo najít příliš stránek, které by o nasazení CouchDB v 
>> praxi psaly.
>>
>> Nejsem si jist, zda jsem zcela správně pochopil vnik a řešení 
>> konfliktů v CouchDB. Aktuálně řeším problém skladů a skladových 
>> položek - myslel jsem, že bych vytvořil dokument "produkt", který by 
>> jako jednu z položek měl pole s dvojicemi "sklad":"počet ks". Každá z 
>> pokladen by pak odečítala ze svého řádku "sklad":"počet ks".
>>
>> Jestli jsem to však z manuálu pochopil správně, tak každá změna 
>> vyvolá změnu celého dokumentu. A v případě, že dojde k výpadku jedné 
>> z pokladen, dojde k vytvoření velkého množství konfliktů, které se 
>> budou muset řešit ručně. Nebo se mýlím?
>>
>> Napadlo mne to vyřešit tak, že bych vytvořil dokument "sklad" a v něm 
>> bych udržoval dvojice "produkt_id":"počet ks". Kvůli nedostatku 
>> informačních zdrojů si však nejsem jist, zda je tohle správný přístup 
>> k problému.
>>
>> Mohl by mi prosím někdo zkušenější poradit?
>>
>> Díky, Honza
>>
>> -- 
>> Jan B. Kolář
>>
>> Zažeň nudu
>> Hodolanská 17, 779 00 Olomouc
>> e-mail:janbivoj.kolar at zazen-nudu.cz
>> www.zazen-nudu.cz
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz <mailto:Community-list at lists.vpsfree.cz>
>> http://lists.vpsfree.cz/listinfo/community-list
>
>
>
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list

-- 
Jan B. Kolář

Zažeň nudu
Hodolanská 17, 779 00 Olomouc
tel: +420 605 800 859
e-mail: janbivoj.kolar at zazen-nudu.cz
www.zazen-nudu.cz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20180926/a3c6299f/attachment.html>