Ahoj, chtěl jsem Vás poprosit o radu s jedním problémem, který teď řeším. Když byl loni blázinec kolem EET, rozhodl jsem se jít vlastní cestou a pro svoje prodejny nasadil pokladní software v PHP (v PHP umím programovat, takže jsem si byl schopen do programu udělat implementaci EET). Celá věc mi běží na serveru a pokladny se tam připojují pomocí SSH tunelu. Co mi však začalo dělat starosti jsou výpadky připojení. Za celý rok jich bylo jen pár, přesto bych však nechtěl dostat pokutu za to, že v době výpadku nedávám lístky. Začal jsem si tedy pohrávat s myšlenkou, že bych aplikaci přesunul na každou pokladnu zvlášť (tzn. na pokladně by běžel nginx, PHP a mysql) a na server si dělal jen replikaci databází, abych pak mohl dělat z pokladen výkazy, aniž by byly v běhu. Až po sem myšlenka dobrá, jenže dnes mi došlo, že budu potřebovat některá data sdílet mezi pokladnami - například seznam produktů. Ten potřebuji mít přístupný lokálně, aby šlo produkty účtovat v případě výpadku, ale zároveň ho také potřebuji synchronizovat, aby se produkt do seznamu nemusel přidávat na každé pokladně zvlášť. No a tady nevím, jak k tomu mám přistoupit :-( Neřešil jste někdo podobný problém? Napadlo mě, zda nemít pro sdílená data druhou databázi, která by byla na serveru a replikovala se na pokladny. Přiznám se ale, že nevím, jak bych v tomto případě řešil zápisy do master databáze na serveru a čtení z lokální slave databáze na pokladně. Ocením jakoukoliv radu nebo odkaz. Všechny zdraví Honza -- Jan B. Kolář Zažeň nudu Hodolanská 17, 779 00 Olomouc tel: +420 605 800 859 e-mail: janbivoj.kolar@zazen-nudu.cz www.zazen-nudu.cz
Chápu, že umíš PHP a MySQL, takže učit se něco nového je zátěž navíc, ale jak jsem dočetl popis tvého problému, tak mi naskočila CouchDB <http://couchdb.apache.org/>, kterou používají třeba pro apku Wallet <https://play.google.com/store/apps/details?id=com.droid4you.application.wallet>. CouchDB má mu vlastnost, že si synchronizaci dat řeší sama, včetně toho který záznam je poslední, co s konflikty (ne, není to tak magické jak to zní) a nějaké výpadky spojení ji moc netrápí. Co si pamatuju z přednášky vývojáře Wallet, tak si data posbírají přes CouchDB a pak to z ní vycucnou a hodí do SQL databáze, se kterou pak pracují jak jsou zvyklí. Pokud by mě osobně tlačil čas, tak bych šel cestou nejmenšího odporu a z centrálního serveru bych kontroloval změny každých pět minut (třeba). Nedržel bych se replikace, protože udržovat *všude* stejnou databázi je zbytečná datová zátěž a kdyby mi někde vznikl konflikt (byt jenom se stejným ID u autoincrementu), tak bych si toho asi hodil mašli. Jarda On 07/02/2018 11:26 AM, Jan B. Kolář wrote:
Ahoj,
chtěl jsem Vás poprosit o radu s jedním problémem, který teď řeším.
Když byl loni blázinec kolem EET, rozhodl jsem se jít vlastní cestou a pro svoje prodejny nasadil pokladní software v PHP (v PHP umím programovat, takže jsem si byl schopen do programu udělat implementaci EET). Celá věc mi běží na serveru a pokladny se tam připojují pomocí SSH tunelu.
Co mi však začalo dělat starosti jsou výpadky připojení. Za celý rok jich bylo jen pár, přesto bych však nechtěl dostat pokutu za to, že v době výpadku nedávám lístky.
Začal jsem si tedy pohrávat s myšlenkou, že bych aplikaci přesunul na každou pokladnu zvlášť (tzn. na pokladně by běžel nginx, PHP a mysql) a na server si dělal jen replikaci databází, abych pak mohl dělat z pokladen výkazy, aniž by byly v běhu.
Až po sem myšlenka dobrá, jenže dnes mi došlo, že budu potřebovat některá data sdílet mezi pokladnami - například seznam produktů. Ten potřebuji mít přístupný lokálně, aby šlo produkty účtovat v případě výpadku, ale zároveň ho také potřebuji synchronizovat, aby se produkt do seznamu nemusel přidávat na každé pokladně zvlášť. No a tady nevím, jak k tomu mám přistoupit :-(
Neřešil jste někdo podobný problém? Napadlo mě, zda nemít pro sdílená data druhou databázi, která by byla na serveru a replikovala se na pokladny. Přiznám se ale, že nevím, jak bych v tomto případě řešil zápisy do master databáze na serveru a čtení z lokální slave databáze na pokladně.
Ocením jakoukoliv radu nebo odkaz.
Všechny zdraví
Honza
Ahoj, co člověk, to názor, tak můj je zde :) Držel bych se KISS principu. Ideálně měnit stávájící aplikaci co nejméně. Říkal jsi, že si voláš eet kód přes ssh tunel, co si lokálně přidat sqlite frontu, do které budeš přidávat nové EET k vystavení a mazat je až po úspěšném potvrzení (GET z PHP serveru nebo z MF)? Přijde mi nešťastné mít mysql replikovanou od uživatelských stanic na server, a díky neznámé latenci by to mohlo vést ke zvláštním problémům. To co řešíš je čistě aplikační problém, a měl bys k němu tak přistupovat. Hezčí řešení by bylo mít EET kód dostupný jako API, které voláš z klientů. Pak je na straně klientského kódu, aby si ohlídal, že se záznam úspěšně zapsal a případně to zkoušel dokud se nepodaří a měl ho uložený v nějakém persistentním storage. Lukáš On 2.7.2018 11:48, Jaroslav Týc wrote:
Chápu, že umíš PHP a MySQL, takže učit se něco nového je zátěž navíc, ale jak jsem dočetl popis tvého problému, tak mi naskočila CouchDB <http://couchdb.apache.org/>, kterou používají třeba pro apku Wallet <https://play.google.com/store/apps/details?id=com.droid4you.application.wallet>.
CouchDB má mu vlastnost, že si synchronizaci dat řeší sama, včetně toho který záznam je poslední, co s konflikty (ne, není to tak magické jak to zní) a nějaké výpadky spojení ji moc netrápí.
Co si pamatuju z přednášky vývojáře Wallet, tak si data posbírají přes CouchDB a pak to z ní vycucnou a hodí do SQL databáze, se kterou pak pracují jak jsou zvyklí.
Pokud by mě osobně tlačil čas, tak bych šel cestou nejmenšího odporu a z centrálního serveru bych kontroloval změny každých pět minut (třeba). Nedržel bych se replikace, protože udržovat *všude* stejnou databázi je zbytečná datová zátěž a kdyby mi někde vznikl konflikt (byt jenom se stejným ID u autoincrementu), tak bych si toho asi hodil mašli.
Jarda
On 07/02/2018 11:26 AM, Jan B. Kolář wrote:
Ahoj,
chtěl jsem Vás poprosit o radu s jedním problémem, který teď řeším.
Když byl loni blázinec kolem EET, rozhodl jsem se jít vlastní cestou a pro svoje prodejny nasadil pokladní software v PHP (v PHP umím programovat, takže jsem si byl schopen do programu udělat implementaci EET). Celá věc mi běží na serveru a pokladny se tam připojují pomocí SSH tunelu.
Co mi však začalo dělat starosti jsou výpadky připojení. Za celý rok jich bylo jen pár, přesto bych však nechtěl dostat pokutu za to, že v době výpadku nedávám lístky.
Začal jsem si tedy pohrávat s myšlenkou, že bych aplikaci přesunul na každou pokladnu zvlášť (tzn. na pokladně by běžel nginx, PHP a mysql) a na server si dělal jen replikaci databází, abych pak mohl dělat z pokladen výkazy, aniž by byly v běhu.
Až po sem myšlenka dobrá, jenže dnes mi došlo, že budu potřebovat některá data sdílet mezi pokladnami - například seznam produktů. Ten potřebuji mít přístupný lokálně, aby šlo produkty účtovat v případě výpadku, ale zároveň ho také potřebuji synchronizovat, aby se produkt do seznamu nemusel přidávat na každé pokladně zvlášť. No a tady nevím, jak k tomu mám přistoupit :-(
Neřešil jste někdo podobný problém? Napadlo mě, zda nemít pro sdílená data druhou databázi, která by byla na serveru a replikovala se na pokladny. Přiznám se ale, že nevím, jak bych v tomto případě řešil zápisy do master databáze na serveru a čtení z lokální slave databáze na pokladně.
Ocením jakoukoliv radu nebo odkaz.
Všechny zdraví
Honza
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Díky moc za odpověď, určitě se na podívám podrobněji, zda bych to zvládl implementovat/použít. Co se týká té replikace, tak jsem právě uvažoval nad tím, že by každá pokladna měla svou vlastní databázi, tzn. na serveru by bylo databází tolik, kolik by bylo pokladen. To by mi bohatě stačilo v případě účtenek, protože každá pokladna si řeší jen své účtenky a nepotřebuje vidět/upravovat cizí. Pak jsem si ale uvědomil, že mám data, která naopak potřebuji "sdílet" a tedy můj plán s replikací nebude fungovat. Mohl bys mi prosím trochu líp vysvětlit, jak myslíš ten poslední odstavec? Není mi totiž jasné, co myslíš tou centrální aplikací a kontrolou změn. Díky, Honza Dne pondělí 2. července 2018 11:48:18 CEST, Jaroslav Týc napsal(a):
Chápu, že umíš PHP a MySQL, takže učit se něco nového je zátěž navíc, ale jak jsem dočetl popis tvého problému, tak mi naskočila CouchDB <http://couchdb.apache.org/>, kterou používají třeba pro apku Wallet <https://play.google.com/store/apps/details?id=com.droid4you.application.wal let>.
CouchDB má mu vlastnost, že si synchronizaci dat řeší sama, včetně toho který záznam je poslední, co s konflikty (ne, není to tak magické jak to zní) a nějaké výpadky spojení ji moc netrápí.
Co si pamatuju z přednášky vývojáře Wallet, tak si data posbírají přes CouchDB a pak to z ní vycucnou a hodí do SQL databáze, se kterou pak pracují jak jsou zvyklí.
Pokud by mě osobně tlačil čas, tak bych šel cestou nejmenšího odporu a z centrálního serveru bych kontroloval změny každých pět minut (třeba). Nedržel bych se replikace, protože udržovat *všude* stejnou databázi je zbytečná datová zátěž a kdyby mi někde vznikl konflikt (byt jenom se stejným ID u autoincrementu), tak bych si toho asi hodil mašli.
Jarda
On 07/02/2018 11:26 AM, Jan B. Kolář wrote:
Ahoj,
chtěl jsem Vás poprosit o radu s jedním problémem, který teď řeším.
Když byl loni blázinec kolem EET, rozhodl jsem se jít vlastní cestou a pro svoje prodejny nasadil pokladní software v PHP (v PHP umím programovat, takže jsem si byl schopen do programu udělat implementaci EET). Celá věc mi běží na serveru a pokladny se tam připojují pomocí SSH tunelu.
Co mi však začalo dělat starosti jsou výpadky připojení. Za celý rok jich bylo jen pár, přesto bych však nechtěl dostat pokutu za to, že v době výpadku nedávám lístky.
Začal jsem si tedy pohrávat s myšlenkou, že bych aplikaci přesunul na každou pokladnu zvlášť (tzn. na pokladně by běžel nginx, PHP a mysql) a na server si dělal jen replikaci databází, abych pak mohl dělat z pokladen výkazy, aniž by byly v běhu.
Až po sem myšlenka dobrá, jenže dnes mi došlo, že budu potřebovat některá data sdílet mezi pokladnami - například seznam produktů. Ten potřebuji mít přístupný lokálně, aby šlo produkty účtovat v případě výpadku, ale zároveň ho také potřebuji synchronizovat, aby se produkt do seznamu nemusel přidávat na každé pokladně zvlášť. No a tady nevím, jak k tomu mám přistoupit :-(
Neřešil jste někdo podobný problém? Napadlo mě, zda nemít pro sdílená data druhou databázi, která by byla na serveru a replikovala se na pokladny. Přiznám se ale, že nevím, jak bych v tomto případě řešil zápisy do master databáze na serveru a čtení z lokální slave databáze na pokladně.
Ocením jakoukoliv radu nebo odkaz.
Všechny zdraví
Honza
-- Jan B. Kolář Zažeň nudu Hodolanská 17, 779 00 Olomouc tel: +420 605 800 859 e-mail: janbivoj.kolar@zazen-nudu.cz www.zazen-nudu.cz
Ahoj, kdyby clovek chtel byt moderni frikulin, tak by to cele slo postavit nad nejakou message queue (rabbitmq, kafka, zeromq, ...) a neresit prenaseni celeho aktualniho stavu, ale zmeny stavu/prikazy jako jednotlive message. V ramci prikladu vyse zkratkovite: kazda pokladna ma sve vlastni uloziste (jedno zda *sql, ci cokoliv dalsiho), stejne jako centrala, tyto uloziste vzajemne naprimo nijak nekomunikuji Veskera komunikace se jede pres message, tedy napr.: - msg o zmene seznamu dostupnych polozek, na kterou jsou prihlaseny jednotlive pokladny, ktere si podle toho zmeni svuj otisk - msg o nove objednavce, na kterou je zavesene hlaseni eet, pripadne treba centralni statistiky - volitelne msg o kompletni zmene seznamu polozek, ktera se normalne nepouziva, ale jde pouzit v pripade rozpadnuti seznamu na nejake pokladne klicova slova napr. "microservice messaging" Petr 2018-07-02 13:05 GMT+02:00 Jan B. Kolář <janbivoj.kolar@zazen-nudu.cz>:
Díky moc za odpověď, určitě se na podívám podrobněji, zda bych to zvládl implementovat/použít.
Co se týká té replikace, tak jsem právě uvažoval nad tím, že by každá pokladna měla svou vlastní databázi, tzn. na serveru by bylo databází tolik, kolik by bylo pokladen. To by mi bohatě stačilo v případě účtenek, protože každá pokladna si řeší jen své účtenky a nepotřebuje vidět/upravovat cizí. Pak jsem si ale uvědomil, že mám data, která naopak potřebuji "sdílet" a tedy můj plán s replikací nebude fungovat.
Mohl bys mi prosím trochu líp vysvětlit, jak myslíš ten poslední odstavec? Není mi totiž jasné, co myslíš tou centrální aplikací a kontrolou změn.
Díky,
Honza
Dne pondělí 2. července 2018 11:48:18 CEST, Jaroslav Týc napsal(a):
Chápu, že umíš PHP a MySQL, takže učit se něco nového je zátěž navíc, ale jak jsem dočetl popis tvého problému, tak mi naskočila CouchDB <http://couchdb.apache.org/>, kterou používají třeba pro apku Wallet <https://play.google.com/store/apps/details?id=com. droid4you.application.wal let>.
CouchDB má mu vlastnost, že si synchronizaci dat řeší sama, včetně toho který záznam je poslední, co s konflikty (ne, není to tak magické jak to zní) a nějaké výpadky spojení ji moc netrápí.
Co si pamatuju z přednášky vývojáře Wallet, tak si data posbírají přes CouchDB a pak to z ní vycucnou a hodí do SQL databáze, se kterou pak pracují jak jsou zvyklí.
Pokud by mě osobně tlačil čas, tak bych šel cestou nejmenšího odporu a z centrálního serveru bych kontroloval změny každých pět minut (třeba). Nedržel bych se replikace, protože udržovat *všude* stejnou databázi je zbytečná datová zátěž a kdyby mi někde vznikl konflikt (byt jenom se stejným ID u autoincrementu), tak bych si toho asi hodil mašli.
Jarda
On 07/02/2018 11:26 AM, Jan B. Kolář wrote:
Ahoj,
chtěl jsem Vás poprosit o radu s jedním problémem, který teď řeším.
Když byl loni blázinec kolem EET, rozhodl jsem se jít vlastní cestou a pro svoje prodejny nasadil pokladní software v PHP (v PHP umím programovat, takže jsem si byl schopen do programu udělat implementaci EET). Celá věc mi běží na serveru a pokladny se tam připojují pomocí SSH tunelu.
Co mi však začalo dělat starosti jsou výpadky připojení. Za celý rok jich bylo jen pár, přesto bych však nechtěl dostat pokutu za to, že v době výpadku nedávám lístky.
Začal jsem si tedy pohrávat s myšlenkou, že bych aplikaci přesunul na každou pokladnu zvlášť (tzn. na pokladně by běžel nginx, PHP a mysql) a na server si dělal jen replikaci databází, abych pak mohl dělat z pokladen výkazy, aniž by byly v běhu.
Až po sem myšlenka dobrá, jenže dnes mi došlo, že budu potřebovat některá data sdílet mezi pokladnami - například seznam produktů. Ten potřebuji mít přístupný lokálně, aby šlo produkty účtovat v případě výpadku, ale zároveň ho také potřebuji synchronizovat, aby se produkt do seznamu nemusel přidávat na každé pokladně zvlášť. No a tady nevím, jak k tomu mám přistoupit :-(
Neřešil jste někdo podobný problém? Napadlo mě, zda nemít pro sdílená data druhou databázi, která by byla na serveru a replikovala se na pokladny. Přiznám se ale, že nevím, jak bych v tomto případě řešil zápisy do master databáze na serveru a čtení z lokální slave databáze na pokladně.
Ocením jakoukoliv radu nebo odkaz.
Všechny zdraví
Honza
-- Jan B. Kolář
Zažeň nudu Hodolanská 17, 779 00 Olomouc tel: +420 605 800 859 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
participants (4)
-
Jan B. Kolář -
Jaroslav Týc -
Lukáš Němec -
Petr Sykora