Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: JmJ 19. 10. 2015, 11:27:10
-
Zdravim,
nejsem databazovy guru a protoze me uplne nenapada nejvhodnejsi dotaz na google, tak se zkusim poradit s vami ;-).
Situace:
klientske stanice, na kterych bezi aplikace, ktera uklada data do db. Tyto stanice musi bezet vzdy, bez ohledu na to, zda maji spojeni na sit nebo ne. Proto maji sve db.
Server (sberne misto). Pokud klientske stanice maji spojeni na sit a vidi server, pak se synchronizuji s db serveru. Tedy klienti odeslou nova data na server, pokud na serveru dostlo napriklad ke smazani nejakych dat, ktera se soucasne vyskytuji na nektere stanici, tak se smazou i na stanici a tak podobne.
Je tohle resitelne replikaci db? Tedy funguje replikace tak, ze uprava v jakekoliv kopii db se promitne do vsech ostatnich kopii?
Jak jse vyse naznacil, idealne by mel server fungovat jako jakesi sberne misto, ve kterem jsou data ze vsech stanic, ale stanice maji jen sva data. Tedy na stanici A nejsou data ze stanice B, ale na serveru jsou oboji data z A i z B a lze je modifikovat a modifikace se pak promitnou i na prislusne stanici.
Dokaze i toto zaridit MySQL/MariaDB samotna?
Diky za postrehy.
-
NE, potreboval by si napr. galera cluster nebo si to osetrit sam, aby se zmeny promitnuly do ostatnich db(nodu),
Je nutne pouzit zrovna MariaDB? Zkus se podival bych se po CouchDB, ta umi replikaci, replikoval by jsi ze stanic na server(sberne misto).
O jaka data jde, mnozstvi, velikost, frekvenci ? Je nutne mit na stanicich vubec nejake DB systemy? Nebylo by lepsi pouzit napr nejaky protokolo pro telemetrii , viz. MQTT, predavat je na server brokerovi a ten uz poresit pres vlastniho lokalniho SUB prepis do db?
Max
-
No problem? https://mariadb.com/kb/en/mariadb/setting-up-replication/
-
Pokud jsem to pochopil dobre, tak potrebujes multi-master replikaci. To na urovni DB podle me uplne bezne nejde.
https://en.wikipedia.org/wiki/Multi-master_replication
Pokud by to mohlo nejakym zpusobem fungovat nad souborama, tak bych se podival na Bittorent Sync.
-
Potrebujes na serveru bezpodminecne do dat zapisovat nebo to slouzi jako backup nebo na analytiku? Kdyby ne, trochu si zjednodusis zivot a poslouzi ti replikace master-slave. Klienti budou masteri s DB A,B a budou se replikovat na server, kde pobezi slave DB A' a B'. V pripade, ze se nekdo neco pokazi je snadne replikace obnovit, protoze vis, ze platna data jsou jen u klientu.
Pokud musi zapisovat server i klient, pak master-master varianta. Pouzivas autoincrement? Pokud ano, musis pocitat s tim, ze je obvykly princip, ze master A bude mit licha a B suda idecka(mirne zjednodusene). V pripade, ze se replikace rozpadne muze byt znovuobnoveni replikace trosku slozitejsi.
-
SQLite a git? Nebo podobným směrem
-
Vzhledem k tomu že klientské stanice nejsou vždy online master-master replikace neprichazi v uvahu. Ja bych to resil produkuktem Lotus Domino od IBM. Opensource reseni bohuzel neznam.
-
Pokud data vznikají off-line na různých stanicích, pak je to na úrovni DB řešitelné velmi těžce.
Na tento problém je vhodnější aby si každá stanice komunikovala pouze ze svojí DB a stanice posílaly zprávy o změnách z/na server.
-
Couchdb. To je databáze stavěná přímo na tyto situace.
-
Potrebujes na serveru bezpodminecne do dat zapisovat nebo to slouzi jako backup nebo na analytiku? Kdyby ne, trochu si zjednodusis zivot a poslouzi ti replikace master-slave. Klienti budou masteri s DB A,B a budou se replikovat na server, kde pobezi slave DB A' a B'. V pripade, ze se nekdo neco pokazi je snadne replikace obnovit, protoze vis, ze platna data jsou jen u klientu.
Pokud musi zapisovat server i klient, pak master-master varianta. Pouzivas autoincrement? Pokud ano, musis pocitat s tim, ze je obvykly princip, ze master A bude mit licha a B suda idecka(mirne zjednodusene). V pripade, ze se replikace rozpadne muze byt znovuobnoveni replikace trosku slozitejsi.
Na serveru se data z klientu musi slevat do jedne databaze a musi se dat menit, ideal je, kdyz se tyto zmeny promitnou na klienty. Nejde o zalohu, jde predevsim o analyzu dat, bohuzel jde i o mozne upravy dat.
Autoincrement neuzivam, tak nejak jsem uz pred 5 lety tusil, ze to bude cele smerovat timto smerem a ID se generuji jinak.
Jak na klientovi tak na serveru se delaji vylozene databazove operace (prochazeni dat, tisk sestav atd.), takze oboji musim byt nejake forma databaze s rozumnym dotazovacim jazykem. Navic klient muze bezet uplne samostatne bez toho, ze by data nekam dale odesilal. Klientu muze byt teoreticky neomezeny pocet, prakticky 1 az 5.
Jde o aplikaci pro prumysl. Proto musi klienti jet, i kdyz nevidi server a tak podobne.
Z nekterych dalsich odpovedi jsem vyrozumel, ze pokud na sebe jednotlive "uzly" replikace aktualne nevidi, pak nelze do DB zapisovat? Cekla bych, ze to lze a ze az na sebe uzly vidi, tak se sesynchronizuji. Samozrejme za dodrzeni urcitych podminek jako jsou jedinecna ID v ramci vsech uzlu atd. Pokud na sebe totiz opravdu musi stale videt, pak vim, ze se replikaci nemusim dale zabyvat a muzu pokracovat v tom, ze si prenos dat resim sam svym protokolem.
-
Pokud se s tím bude v návrhu počítat, mohla by fungovat master-master replikace v mariadb (ne galera cluster) http://msutic.blogspot.cz/2015/02/mariadbmysql-master-master-replication.html Ta je asynchronní, takže by výpadek jedné strany neměl nijak vadit a po nahození by se to mělo sesynchronizovat samo (tak docela spolehlivě funguje replikace master-slave, samozřejmě to vyžaduje mít dostatečně velké binlogy, ale to už v dnešní době není problém).
Samozřejmě je potřeba si hlídat kolizní změny, ty v tom pak nadělají paseku. Ale to v každém řešení.
Nahození druhého stroje pomocí xtrabackupex je jednoduché a překvapivě robustní, hodně pomáhají jednoduché GTIDs MariaDB.
-
Asi někdy před půl rokem se zde řešila mobilní aplikace pro sběr dat, na kterou byly kladeny podobné požadavky. Zkuste to ve fóru najít.
Je třeba řešit řadu situací a je to dost komplikované. Hodně záleží na aplikační logice. Nedokážu si představit, že by existovalo nějaké automatické řešení. Co když dva klienti upraví stejný záznam? Anebo jeden klient záznam smaže a druhý ho ofline upravuje? Atd atd.
Nejlépe si to osobně dokážu představit jako práci s decentralizovaným verzovacím systémem. Tam se musí řešit kolize případně se dělají branche. Současně je vyřešeno, jak aplikovat inkrementálně změny na jeden a ten stejný záznam (patch). A potřebujete navíc testy, abyste se dozvěděl, zda výsledek funguje (zda jde program zkompilovat a zda se chová konzistentně vůči nějaké aplikační logice).
Přeji příjemnou zábavu :-)
-
Je třeba řešit řadu situací a je to dost komplikované. Hodně záleží na aplikační logice. Nedokážu si představit, že by existovalo nějaké automatické řešení. Co když dva klienti upraví stejný záznam? Anebo jeden klient záznam smaže a druhý ho ofline upravuje? Atd atd.
CouchDB
-
S Couchdb jsem neměl tu čest. Znáte to z praxe? Jak se s tím pracuje? Koukám na http://docs.couchdb.org/en/latest/replication/conflicts.html
-
Ano, používáme to v praxi ve dvou větších aplikacích. Jednou z těch aplkací je CRM, kde byla nezávislost na připojení přímo v zadání. Sdílíme na tom data přes pět počítačů, replikace probíhá obvykle nepravidelně několikrát do týdne.
CouchDB se na některé věci hodí lépe, na některé hůře. Distribuované databáze přes několik počítačů se s tím právě řeší lépe.
http://www.hobrasoft.cz/cs/blog/bravenec/couchdb
-
Díky, to je perfektní zápisek o CouchDB z praxe (koukal jsem mimochodem už dřív, že děláte zajímavé věci a líbí se mi i přístup k věci, nicméně to už je lehce offtopic). GUI máte v C++/Qt? Má CouchDB nějaké vlastní GUI, které by pro základní učely nahradilo aplikaci? To http rozhraní vypadá podle popisu spíš nízkoúrovňově.
-
Na me ucely to s CouchDB nevypada dobre. Na klientech se vygeneruje cca 800 zaznamu za 8 hodinovou smenu, nekde se jede na vic smen. Jeden zaznam ma cca 40 udaju tedy sloupcu. Data na klientech jsou vetsinou za posledni rok na serveru pak "co server snese", idealne se vubec nemazou. Z dat se dela statistika, seskupuji se podle ruznych vlastnosti atd. Pochopil jsem, ze na tohle CouchDB neni uplne nejlepsi nastroj. Je tak?
Krom zaznamu vzniklych provozem resime editaci nekolika ciselniku. Na to by CouchDB zrejme byla fajn, ale tim bychom museli zamotat do projektu dalsi typ db, coz jiste neni uplne nesmyslne, ale zkusil bych se tomu vyhnout.
V soucasnosti mame na prenaseni dat nas protokol a nas server. Jista nesikovnost nam hrozi jen pri editaci ciselniku, ale to poresime tak, ze trochu uhnem a editace ciselniku bude povolena jen tehdy, pokud ma klient spojeni se serverem (mysleno spojeni nasim protokolem). Ciselniky se edituji minimalne. Kdyz spojeni je, pozada se o zamek editace ciselniku atd. Pro opravnene uzivatele se treba umozni editace i v offlinu s tim, ze vedi co delaji ;-)
Jeste dodam, ze tu db mame fakt jednoduchou a resime vlastne asi 3 typy zaznamu, ktere vznikaji behem prace a pak cca deset ciselniku. Takze proste zustaneme u toho, ze si to vyresime po svem.
-
CouchDB má docela šikovné webové rozhraní - Futon. Je to přímo součástí databázového serveru, stačí se připojit na /_utils. Nad CouchDB se dá asi postavit i celá webová aplikace, ale s tím zkušenosti nemám. Web jde trochu mimo mě, většinou dělám v C++ a Qt - i servery a jejich webové rozhraní.
Jestli je CouchDB vhodná na takovou statistiku, to vám moc nepovím. Různé statistické funkce se tam dělat dají, ale přijde mi to těžkopádné. Klauzule "group by" v SQL je jednoduchá a velice výkonná. Počítám, že v aplikaci vám vznikne nějakých pět miliónů záznamu ročně. To je pro SQL databázi hračka. I v případě, že budete dělat různé neoptimalizované ruční dotazy, dočkáte se odpovědí v rozumném čase. S CouchDB nevím. Výsledky views se tam kešují, takže požadovaný výsledek můžete dostat z databáze rychle, ale jakýkoliv interaktivní dotaz spolu s jeho přípravou bude trvat nesrovnatelně déle. Zkušenost s CouchDB, s milióny záznamů a se statistikou nemám.
Asi bych do toho s databází CouchDB nešel a snažil se to vyřešit jinak - asi podobně, jak jste to popisoval.
-
Ok, diky za postrehy, konzultaci a za predvedeni CouchDB. Muze se hodit.