HW nároky malých aplikací

lopata

Re:HW nároky malých aplikací
« Odpověď #60 kdy: 03. 03. 2017, 12:18:39 »
Aha... a co když zárověň editují dva lidi jeden dokument? Kterou verzi si vybereš? Myslíš, že to nemusíš řešit kvůli všemocné DB? Máš to jednoduché, ale úplně stejně nespolehlivé.
Jinak... k záznamům v DB dáš revizi a strana s vyšší revizí má správné soubory. Hledáš raketovou vědu tam, kde není. K tomu musíš ošetřit zámky na soubory ( a to v jakémkoliv případě ) a i tak musíš pořešit, co dělat, když se stejně podaří dvěma lidem otevřít stejný soubor pro zápis. A to vše zcela nezávisle na tom, jestli se ti válí soubory na poli, v DB, v čmoudu, nebo zazipovaný na 5ti vadných disketách u někoho v šuplíku.

Problém je v tom, že ty všechno musíš znovu reimplementovat. Každá normální databáze umí transakce i replikaci. Když dáš nějaká data mimo, tak o obojí přijdeš. Znovuvynalézáš kolo a reimplementuješ transakce a replikaci mimo databázi. Věř tomu, že to co vyrobíš, bude mnohem horší a mnohem víc zabugované, než implementace v databázi.

Takže to stojí víc peněz a je to méně spolehlivé. A proč? Protože si myslíš, že je to tak lepší...


Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:HW nároky malých aplikací
« Odpověď #61 kdy: 03. 03. 2017, 12:43:49 »
Aha... a co když zárověň editují dva lidi jeden dokument? Kterou verzi si vybereš? Myslíš, že to nemusíš řešit kvůli všemocné DB? Máš to jednoduché, ale úplně stejně nespolehlivé.
Jinak... k záznamům v DB dáš revizi a strana s vyšší revizí má správné soubory. Hledáš raketovou vědu tam, kde není. K tomu musíš ošetřit zámky na soubory ( a to v jakémkoliv případě ) a i tak musíš pořešit, co dělat, když se stejně podaří dvěma lidem otevřít stejný soubor pro zápis. A to vše zcela nezávisle na tom, jestli se ti válí soubory na poli, v DB, v čmoudu, nebo zazipovaný na 5ti vadných disketách u někoho v šuplíku.

Problém je v tom, že ty všechno musíš znovu reimplementovat. Každá normální databáze umí transakce i replikaci. Když dáš nějaká data mimo, tak o obojí přijdeš. Znovuvynalézáš kolo a reimplementuješ transakce a replikaci mimo databázi. Věř tomu, že to co vyrobíš, bude mnohem horší a mnohem víc zabugované, než implementace v databázi.

Takže to stojí víc peněz a je to méně spolehlivé. A proč? Protože si myslíš, že je to tak lepší...

No a to je ten omyl. Pokud řešíš master-master replikace, musíš to stejně aplikačně ošetřit, protože to za tebe DB neudělá... ono možná ne že by se jí nechtělo, ale ona nemá z principu jak!
A teď si k tomu představ, že si uživatelé ty soubory můžou stáhnout, offline je editovat a znova uložit... no páááni...
Já rozumím, že je strašně jednoduchý si namalovat aplikačku, nastrkat do ní knihovny, kolikrát z velmi pochybných zdrojů a s překrývající se funkcionalitou. Dělá to tak obrovská spousta jednotlivců i firem, tak je to asi v pořádku. Ale rozhodně bych to nenazval vývojem. Většinou se jedná jen o nedotažené prototypování nasazené do produkce.
Ale zajisté patříš k lidem, kteří si rádi koupí nejnovější a nejrychlejší auto na světě. Sice ještě nemá volant a brzdy, ale je fakt rychlý. Třeba se to časem dodělá, ne?

lopata

Re:HW nároky malých aplikací
« Odpověď #62 kdy: 03. 03. 2017, 12:59:01 »
No a to je ten omyl. Pokud řešíš master-master replikace, musíš to stejně aplikačně ošetřit, protože to za tebe DB neudělá... ono možná ne že by se jí nechtělo, ale ona nemá z principu jak!

Nejdřív si něco nastuduj o databázích, než začneš teoretizovat. Při synchronní replikaci za tebe databáze všechno udělá, nemusíš se o replikaci na aplikační úrovni vůbec starat, konflikt nenastane. Při asynchronní replikaci to jde opět udělat bez zásahu na aplikační úrovni, třeba tím, že dáš jednotlivým nodum prioritu a jeden z nich vždy vyhraje.

A teď si k tomu představ, že si uživatelé ty soubory můžou stáhnout, offline je editovat a znova uložit... no páááni...

A co má být?

Ale zajisté patříš k lidem, kteří si rádi koupí nejnovější a nejrychlejší auto na světě. Sice ještě nemá volant a brzdy, ale je fakt rychlý. Třeba se to časem dodělá, ne?

Ty patříš k lidem, kteří si auto nekoupí. Koupíš si sedadla, kola, volant, brzdy a auto si vyrobíš doma. Protože si myslíš, že umíš auto udělat lépe, než ti neschopní výrobci.

tnr

Re:HW nároky malých aplikací
« Odpověď #63 kdy: 03. 03. 2017, 13:01:45 »
No a to je ten omyl. Pokud řešíš master-master replikace, musíš to stejně aplikačně ošetřit, protože to za tebe DB neudělá... ono možná ne že by se jí nechtělo, ale ona nemá z principu jak!
A teď si k tomu představ, že si uživatelé ty soubory můžou stáhnout, offline je editovat a znova uložit... no páááni...
Já rozumím, že je strašně jednoduchý si namalovat aplikačku, nastrkat do ní knihovny, kolikrát z velmi pochybných zdrojů a s překrývající se funkcionalitou. Dělá to tak obrovská spousta jednotlivců i firem, tak je to asi v pořádku. Ale rozhodně bych to nenazval vývojem. Většinou se jedná jen o nedotažené prototypování nasazené do produkce.
Ale zajisté patříš k lidem, kteří si rádi koupí nejnovější a nejrychlejší auto na světě. Sice ještě nemá volant a brzdy, ale je fakt rychlý. Třeba se to časem dodělá, ne?

Tak jsi vybral jeden pripad (offline workflow - download, offline editace, upload), kde to DB nevyresi (ani nic jinyho, protoze to nejde), a dal ? Pro takovy workflow je vubec otazka, zda tam na to pouzivat DB, zda vubec neco takoveho resit pomoci nejakeho IS, kdyz to jako backend v podstate zvlada verzovany FS :-D

Ale realnych pripadu je samozrejme mnohonasobne vice, treba v momente kdy to bude online, transakcni operace. Treba nejake davkove operace (ktere v nasich systemech bezne delame) nad dokumenty, ktere samozrejme musi byt transakcni, pekne dekuju tohle resit manualne :-D

A dalsi vec, jak sice rikam, nejsem priznivcem ukladani BLOBs do SQL databazi (i kdyz to obcas opodstatneni ma), ale druha vec je tez si rici o BLOB storage. Viz treba FILESTREAM na MS SQL je pomerne dobre efektivni zalezitost.

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:HW nároky malých aplikací
« Odpověď #64 kdy: 03. 03. 2017, 13:06:52 »
dáš jednotlivým nodum prioritu a jeden z nich vždy vyhraje
No, tak tím bych to ukončil :D Dál to nemá cenu řešit :D Právě jsi možná někomu zničil spoustu práce, protože chudák nebyl na tom správným místě a boj o dokument vyhrála uklízečka, která někomu náhodou hodila hadr na klávesnici. :D Ano, to je dnešní vývoj :D


tnr

Re:HW nároky malých aplikací
« Odpověď #65 kdy: 03. 03. 2017, 13:07:58 »
A teď si k tomu představ, že si uživatelé ty soubory můžou stáhnout, offline je editovat a znova uložit... no páááni...

A co má být?

On imho resi takove umele workflow (i kdyz je pravda, ze nektere systemy se takhle idiotsky chovaji), kdy uzivatel stahne dokument, offline ho zedituje a nahraje novou verzi. I kdyz i to se da celkem jednoduse vyresit s pomoci DB, jen se musi evidovat checkouty dokumentu / uploady / verzovani:)

A hezka vec je to, ze pak tu replikaci resi clovek na jednom centralnim miste a nemuze se stat, ze se kdykoliv rozhodi FS a DB. Ono by to samozrejme resili transkacni FS, ale to nabizi nejak pouzitelne snad jen Microsoft (Transactional NTFS), coz treba my moc pouzivat nechceme...

Je ale pravda, ze jsou i efektivnejsi zpusoby ulozeni BLOBs nez SQL databaze. Ale obcas to ma sve implementacni kouzlo, nektere veci tim proste clovek vyresi nejjednodusseji.

tnr

Re:HW nároky malých aplikací
« Odpověď #66 kdy: 03. 03. 2017, 13:11:47 »
No, tak tím bych to ukončil :D Dál to nemá cenu řešit :D Právě jsi možná někomu zničil spoustu práce, protože chudák nebyl na tom správným místě a boj o dokument vyhrála uklízečka, která někomu náhodou hodila hadr na klávesnici. :D Ano, to je dnešní vývoj :D

A on te nekdo nuti pouzivat async. replikaci, ze se tu prsis, jak bys to vyresil lepe (i kdyz by me zajimalo, kolik distribuovanych, transakcnich systemu nad TB sized daty jsi uz naprogramoval, protoze tvuj pohled je skutecne ve stylu ja vim vse lepe, vsichni ostatni jsou idioti) ?  :) Async. replikace ma jasne dane vyhody a nevyhody. Proto se pouziva tam, kde to ma smysl a kde podobne veci bud nevadi, nebo nenastavaji, nebo benefity prevysuji nad nevyhodami.

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:HW nároky malých aplikací
« Odpověď #67 kdy: 03. 03. 2017, 13:16:35 »
Ono to ve výsledku k tomu verzování stejně spěje, třeba nilfs je dobrá volba.

Re:HW nároky malých aplikací
« Odpověď #68 kdy: 03. 03. 2017, 13:21:53 »
Je ale pravda, ze jsou i efektivnejsi zpusoby ulozeni BLOBs nez SQL databaze. Ale obcas to ma sve implementacni kouzlo, nektere veci tim proste clovek vyresi nejjednodusseji.
Hlavně ty provozní, adminům to ušetří spoustu práce a starostí... ale dobře vedený vývoj ví že to zároveň spoustu rizik (a tedy časem i práce) naopak přinese. Jenomže tím vzniká konflikt, který může (a musí) vyřešit vyšší vrstva, tj. management (od toho tam je, že).
Jenomže tam bohužel převládne názor "tak řekněte jak to je, vždyť jste všichni ajťáci" a ani je nenapadle, že se ve skutečnosti jedná o dva různé kmeny na válečné stezce.

tnr

Re:HW nároky malých aplikací
« Odpověď #69 kdy: 03. 03. 2017, 13:23:19 »
Ono to ve výsledku k tomu verzování stejně spěje, třeba nilfs je dobrá volba.

NILFS je fajn, ale transakcni FS to v dusledku neni. Umoznuje sice checkpointing, navrat k predchozi verzi FS, mountovani readonly starsich verzi FS, ale to neni v dusledku reseni paralelnich transakci (alespon kdyz jsem to pred nejakou dobou studoval, mohlo se to zmenit). Skutecne transakce na urovni FS nabizi, pokud vim, pouze Microsoft pomoci TxF - tam uz je to reseni mnohem zajimavejsi, zejmena diky moznosti napojeni na DTC, tzn. moznost sdileni transakce s DB, ruznymi dalsimi pocitaci atd.

lopata

Re:HW nároky malých aplikací
« Odpověď #70 kdy: 03. 03. 2017, 13:24:02 »
No, tak tím bych to ukončil :D Dál to nemá cenu řešit :D Právě jsi možná někomu zničil spoustu práce, protože chudák nebyl na tom správným místě a boj o dokument vyhrála uklízečka, která někomu náhodou hodila hadr na klávesnici. :D Ano, to je dnešní vývoj :D

Při konfliktu v asynchronní replikaci vždycky zničíš nějaká data, jde jen o to, která to budou. Přístupů k tomu je hodně (http://www.dba-oracle.com/art_dbazine_mm_repl.htm) a každý má nějaké výhody a nevýhody. Ale já zapomněl, ty si uděláš vlastní lepší replikaci...

tnr

Re:HW nároky malých aplikací
« Odpověď #71 kdy: 03. 03. 2017, 13:28:27 »
Hlavně ty provozní, adminům to ušetří spoustu práce a starostí... ale dobře vedený vývoj ví že to zároveň spoustu rizik (a tedy časem i práce) naopak přinese. Jenomže tím vzniká konflikt, který může (a musí) vyřešit vyšší vrstva, tj. management (od toho tam je, že).
Jenomže tam bohužel převládne názor "tak řekněte jak to je, vždyť jste všichni ajťáci" a ani je nenapadle, že se ve skutečnosti jedná o dva různé kmeny na válečné stezce.
No tot otazka. (Zejmena SQL) databaze nejsou, nebyly a nebudou kdovijak efektivni v praci s BLOBy. Ale na druhou stranu svoje use casy to ma, viz treba transakcni prace s dokumenty (to fakt neni download & upload v jine transakci).

Az budou bezne filesystemy, ktere podporuji na ruznych platformach distribuovanou transakci, ktera se da napojit s XA databazi, tak se muzeme bavit o tom, ze je to 100% horsi reseni to ukladat v DB, do te doby moc ne.

tnr

Re:HW nároky malých aplikací
« Odpověď #72 kdy: 03. 03. 2017, 13:30:52 »
Při konfliktu v asynchronní replikaci vždycky zničíš nějaká data, jde jen o to, která to budou. Přístupů k tomu je hodně (http://www.dba-oracle.com/art_dbazine_mm_repl.htm) a každý má nějaké výhody a nevýhody. Ale já zapomněl, ty si uděláš vlastní lepší replikaci...

Hlavni pointa je, ze async replikace se typicky pouziva tam, kde to vubec nevadi z podstaty charakteru tech dat... Je tradeoff za performance.

Lojza

  • *****
  • 672
    • Zobrazit profil
    • E-mail
Re:HW nároky malých aplikací
« Odpověď #73 kdy: 03. 03. 2017, 13:33:08 »
v ISASu mohl s konkretnim dokumentem v jednu chvili pracovat vzdy jen jeden uzivatel (myslim ze to vypisovalo i zkratku jmenaprijmeni takze mu slo zavolat at to zavre ze na tom potrebuju delat) jinak kdyz chtel druhy si jej take otevrit tak mu to nabidlo jen kopii pro cteni kterou pak mohl ulozit pod novym nazvem (navic kazdy uzivatel mel pristupova prava jen do jednotlivych modulu ISASu co potreboval k jeho agende, k celemu ISASu jen administrator coz byla specialne funkce - 1 vycleneny zamestnanec na soudu, ktery treba resil konflikty nejakych zaznamu, duplicit ..) .. samozrejme ISAS dusledne logoval kdo co kdy kde nejen zapisoval editoval, mazal ale dokonce i nahlizel a jake provadel dotazy atd ... ten monitoring useru tam byl do nejmensich podrobnosti, stejne tak nahlizeni do CEO na jakou osobu k jake spisove znacce atd.. slo zpetne overit jestli to potreboval nebo nebyla  existujici sp. zn. pouzita na nesouvisejici osobu kdyz si nekdo chtel zjistit neci osobni udaje

co se mi libilo i nelibilo zaroven bylo odstineni uzivatelu od komplikovanych sql queries, byli tam proste prednastavene potrebne jako gui tlacitka,a nic jineho neslo, ono asi nespravnym zadanim sql dotazu by bylo mozno celou databazi tak vytizit ze uz by nezvladala vyrizovat pozadavky ostatnich useru, kterych v jednu dobu pracovalo v ISASu vice nez 130 ...

Tuxik

  • *****
  • 1 473
    • Zobrazit profil
    • E-mail
Re:HW nároky malých aplikací
« Odpověď #74 kdy: 03. 03. 2017, 13:45:11 »
Za prvé, se musím trochu omluvit tnr, protože o tom ví víc, jak minimálně 95% dnešních "vývojářů".
Dodal bych k tomu, že základním předpokladem téměř každého vývojáře je mylný dojem, že pokud běží jedna databáze (nebo cokoliv jinýho) na více místech, bude na 100% dostupná, což bohužel neplatí.
Manager rozhodující o nákupu systému je většinou nekompetentní a rozhodne se na základě ceny, ignorujíc absolutní většinu ostatních argumentů. V případě, že se to potom celý rozsype, tak brečí, že se k ničemu několik dní nedostane, protože se obnovuje 50TB databáze. To je přesně ten moment, kdy je typickej vývojář v řiti jak Baťa s dřevákama, není schopnej poskytnout jakoukoliv podporu a manager chystá výpovědi smluv, matně si začíná vzpomínat, že ho někdo varoval a začíná řešit, jak to napravit. Po incidentu se udělají analýzy, který se velmi pečlivě zlikvidují, zůstane se u starého řešení, protože kdyby se dostalo na vyšší místa, že celej systém stojí za starou bačkoru a bylo by potřeba začít znovu, jelikož je vše špatně už od návrhu, tak by to managora stálo teplý místo.