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
Ahoj, couchdb jsem používal na správu čárových kódů ve skladu na mobilním zařízení a přišla mě při velkém množství záznamu nestabilní, napr nesel smazat zaznam dle pk, normálně bych to udělal v MySQL měj se čau
Odesláno z iPhonu
25. 9. 2018 v 19:08, Jan B. Kolář janbivoj.kolar@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@zazen-nudu.cz www.zazen-nudu.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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áš
- 2018 v 19:08, Jan B. Kolář janbivoj.kolar@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@zazen-nudu.cz mailto:janbivoj.kolar@zazen-nudu.cz www.zazen-nudu.cz http://www.zazen-nudu.cz/_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
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áš
- 2018 v 19:08, Jan B. Kolář <janbivoj.kolar@zazen-nudu.cz
mailto:janbivoj.kolar@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@zazen-nudu.cz www.zazen-nudu.cz _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj,
máš pravdu, že řešit synchronizaci sám v aplikaci není úplně triviální problém, a určitě bys narazil na hodně ošklivý edge-case kde to prostě nepůjde vyřešit tak snadno.
Každopádně, doporučil bych napsat si různé scénáře v jazyce ve kterém se ti pohodlně testuje, a různě zkoušet spojit/rozpojit nody. Můžeš taky vyzkoušet co se stane když uděláš implementaci těch skladových zásob oběma způsoby.
Možná by se ta část připojování/odpojování nodů snadno simulovala pomocí dockeru nebo VM. Možná by to taky šlo přes iptables, ale za mě osobně bych asi zvolil docker (víc s ním umím).
Co se týče bodu 1), z uživatelského hlediska bych byl opravdu hodně naštvaný když bys mi neumožnil něco editovat (jasně, nejde internet, je to polehčující okolnost, ale i tak).
No a nakonec, dle toho článku co jsem posílal, CouchDB verzuje dokumenty. Takže pokud bys měl “produkt”: “sklad”: “ks”, který by se lišil, měl bys několik verzí toho dokumentu s jiným timestampem. A stejně by to bylo na tvé aplikaci jak vyřeší konflikt. CouchDB sama o sobě nemůže konflikt vyřešit, protože neví kontext daného dokumentu.
Dle tvého příkladu:
1) pokladna1 si GETne stav skladu a počet kusů: zboží1 10ks 2) pokladna2 udělá totéž, zboží1: 10ks 3) pokladna1 se odpojí, a někdo prodá 1ks, takže se po připojení uloží do DB zboží1: 9ks 4) pokladna2 se mezi tím taky odpojila a někdo prodal 1ks, do DB se po připojení uloží "_conflicts”:true a zboží1: 9ks 5) v DB máš 2 verze stejného záznamu, oba mají 9ks, a poslendí má konflikt. Pak je potřeba zjistit z verzí toho záznamu jaký má být výsledek.
To je ale nesprávně! Tedy aplikace musí postupně přehrát LOG transakcí. A možná že by takový způsob byl nejlepší, ale opět, jakmile je problém distribuovaný, tak je to opravdu komplikované.
Asi bych raději upravil zadání toho projektu. Například: každá pokladna má LOKÁLNÍ DB, která se synchronizuje. V případě výpadku online připojení NELZE editovat záznamy sdílené mezi více pokladnami. V takovém případě můžeš použít CouchDB, a usnadníš si práci.
Lukáš
- 2018 v 12:38, Jan B. Kolář janbivoj.kolar@zazen-nudu.cz:
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 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í:
- 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".
- 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 http://guide.couchdb.org/draft/conflicts.html#resolution
Lukáš
- 2018 v 19:08, Jan B. Kolář <janbivoj.kolar@zazen-nudu.cz mailto:janbivoj.kolar@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@zazen-nudu.cz mailto:janbivoj.kolar@zazen-nudu.cz www.zazen-nudu.cz http://www.zazen-nudu.cz/_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz mailto:Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list 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@zazen-nudu.cz mailto:janbivoj.kolar@zazen-nudu.cz www.zazen-nudu.cz http://www.zazen-nudu.cz/_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz
-
Honza Macik -
Jan B. Kolář -
Lukáš Němec -
Petr Vanek