Fórum Root.cz
Hlavní témata => Server => Téma založeno: Tuxik 02. 03. 2017, 06:37:34
-
Ahoj,
nějak mi to už nedá a musím se zeptat na vaši zkušenost. Poslední dobou je v módě na jakoukoliv blbost požadovat server 4 až 8 jader s 8 až 16 GB paměti. Většinou samozřejmě pro různé webíky v různých super frameworcích. Občas se tak řeší i "statické" stránky, které by šlo bez problémů napsat čistě v HTML5 a provozovat klidně na RPi.
Občas je to možná přehnanými požadavky managerů, kteří mají představu, že na jejich stránky budou přistupovat stovky lidí současně - většinou se pak jedná o stovky lidí za rok a z toho je třetina z firmy, třetina od vývojářů, třetina boti a na reálné návštěvy se nedostane.
Nebo mi uniká nějaká nová IT soutěž s tématem "vyžebrej co největší dělo na co největší kravinu"?
-
Manažérom, ktorí počet jadier serverov zaokrúhľujú na násobky štyroch smerom hore, kapacitu pamäte zaokrúhľujú na násobky šesnáctich smerom hore a udávať diskový priestor v gigabajtoch je pre nich nadávka treba nimi požadovaný hardvér prenajať na AWS a následne im ho dať zaplatiť.
-
Tady souhlasím s Croninem - viděl jsem to mnohokráte... V okamžiku, kdy se do ceny čehokoli (projektu, vývoje, provozu) promítnout reálné ceny HW se zrazu zjisti, co je opravdu potreba. Tedy po tom, co všechny zúčastněné proberou ze šoku, ze i HW něco stojí a není zdarma :-)
-
HW je levný. To lidská práce je drahá.
-
HW je levný. To lidská práce je drahá.
Ano, ano. Zejména práce těch, co toto tvrdí, vychází velmi draho.
-
Ale určitě ano, HW je levný - ale pokud máte ve firmě několik stovek VM a řešíte požadavek na zásadní zvětšení kapacity, pak už to není triviální otázka. A z mé zkušenosti stačí naznačit zpoplatnění (i symbolické - řekněme jenom cenu prosté reprodukce) tak se objeví spousta volného místa :-)
-
(https://image.ibb.co/eP67va/serverload.png)
No sorry jako... takhle to dopadá... několik kontejnerů, databáze, java a prd z toho. Několik v podstatě statických webových stránek... Ono mě to zase tak netrápí, běží to na virtuálu, CPU to nežere, volné RAMky jsou mraky... ale tohle jsou MINIMÁLNÍ POŽADAVKY!!! od těch bastlířů. A to chtěli fyzický stroj, že na virtuálu můžou být problémy... smutný, co?
-
Moment, já myslel, že na statický stránky je cache.
Posledně, co jsem měl co do činění s webem, jsme to dělali tak, že se obsah dělal dynamicky pro přihlášený, jinak první anonymní návštěva po změněně stránky vygenerovala HTMLko na disk dokud se nezměnilo, rozesílalo se všem nepřihlášeným. Zátěž CPU klesla na 15%, spotřeba paměti na 20%.
-
(https://image.ibb.co/eP67va/serverload.png)
ahoj, ktory sw zobrazuje info takto graficky? dikes
-
htop ?
-
htop ?
Neblazni, na to treba minimalne Grafanu, inac nie si cool a s dobou ;-)
-
Moment, já myslel, že na statický stránky je cache.
Posledně, co jsem měl co do činění s webem, jsme to dělali tak, že se obsah dělal dynamicky pro přihlášený, jinak první anonymní návštěva po změněně stránky vygenerovala HTMLko na disk dokud se nezměnilo, rozesílalo se všem nepřihlášeným. Zátěž CPU klesla na 15%, spotřeba paměti na 20%.
Nene... na statický stránky musí na serveru běžet nějakej java supr čupr frejmwork, klientovi ten java bastl pošle obří javascript, zásadně se odesílá NOCACHE, a čím víc blikátek, tím víc kůůůůůl.... To všechno ti spíchne nějaká firma za pouhých pár mega, takže potom vlastně není důvod řešit, kolik stojí HW. Co na tom, že ve výsledku by to zvládla líp libovolná sekretářka ve wordu, která by prostě uložila dokument se svojí skvělou představou o webu jako html a bylo by.
-
A jistě, že je to htop .
-
vygenerovala HTMLko
Naprosty souhlas, jen misto filesystemu na to pouzivame Redis.
-
(https://image.ibb.co/eP67va/serverload.png)
No sorry jako... takhle to dopadá... několik kontejnerů, databáze, java a prd z toho. Několik v podstatě statických webových stránek... Ono mě to zase tak netrápí, běží to na virtuálu, CPU to nežere, volné RAMky jsou mraky... ale tohle jsou MINIMÁLNÍ POŽADAVKY!!! od těch bastlířů. A to chtěli fyzický stroj, že na virtuálu můžou být problémy... smutný, co?
A s cim mas presne problem ? Je to naddimenzovane, load CPU nula, RAM tez, takze zadny problem. Proc to je naddimenzovane, tezko rict, ale je to celkem bezna praxe :) A navic zadna ultra konfigurace to neni. Radove pronajem takoveho virtualu za cenu 2-3 hodin programatora, v tom vazne problem nevidim.
HW je opravdu proti lidske praci velmi levny.
-
A jistě, že je to htop .
super dikes, mozem teraz tym ohurovat manzelku:)
-
Proc to je naddimenzovane, tezko rict, ale je to celkem bezna praxe :)
To je velmi jednoduché.
- Na začátku je business plán pro novou super webovou aplikaci. Aby byl plán schválen, tak je potřeba přesvědčit držitele peněz (nadřízené, board, invenstory, atd) že to bude super populární. Možná ne jako facebook, alespoň na začátku...
- Napíše se aplikace a udělá se odhad nároků. Ten typicky děla nějaký "tech lead" a ten si rozhodně nedělá iluze o kvalitě (na rozdíl od jednotlivých vývojářů, on má nějakou zodpovědnost). Takže udělá transitivní uzávěr přes všechny bugy a prasárny co ještě nenašel a co se projeví při výše uvedené zátěži.
- Odhad se, jako všechny odhady, vynásobí magickým koeficientem. 300% je oblíbený.
- V provozu se to ukáže jako naddimenzované.
- V ideálním sluníčkovém světě tady zafunguje zpětná vazba, by se na data z monitoringu podívá někdo z vývoje a z nich pak odvodí jaké je správné dimenzování. To se pak provede v produkci.
- V reálném korporátním světě ale nějaké analýzy a výpočty stojí čas, který pak patřičný manager musí vykázat. Takže je může pěkně ušetřit. A on je ušetřit musí, protože už takhle je v pořádných sračkách a musí vymýšlet zoufalé výmluvy, jakto že tam nikdo neleze (a když tam nikdo neleze, tak to nic nevydělává!).
- V opravdu posraném světě pak žádná zpětná vazba není a informace o reálném provozu se objeví pouze na root.cz
-
...A to chtěli fyzický stroj, že na virtuálu můžou být problémy... smutný, co?
Tj, taky obcas potkavam podobny ... nejlepsi je, kdyz na statickou vyzitku chtej instalovat jak reseto deravej .."frejmwork" (specielne ten, o kterym tu sou newsky co tejden aspon dve). Nastesti u spousty firem maj podobby cypoviny na starosti marketaci, a ja tudiz muzu v klidu delat, ze nevim ze to existuje.
BTW: Celej seznam bezel na P133 ...
-
A s cim mas presne problem ? Je to naddimenzovane, load CPU nula, RAM tez, takze zadny problem. Proc to je naddimenzovane, tezko rict, ale je to celkem bezna praxe :) A navic zadna ultra konfigurace to neni. Radove pronajem takoveho virtualu za cenu 2-3 hodin programatora, v tom vazne problem nevidim.
HW je opravdu proti lidske praci velmi levny.
S čím mám problém? No s CPU ani ne, tam je mi to jedno, když to není vytížený. U RAM nastává potencionální problém, protože každej stroj dříve nebo později celou paměť sežere na cache. Ono se říká, že paměť je levná, ale:
- 128GB moduly opravdu levný nejsou
- fyzický stroj má omezený maximální množství paměti
- jeden fyzický stroj stojí jak hodně pěkný auto, špička už se blíží cenou k bytu až baráku
- každý fyzický stroj jsou desítky tisíc jen na energiích za rok, další energie jde na klimu, je potřeba mít dostatečně dimenzovaný záložní napájení atd
Ono se to může zdát jako sranda, ale provozovat spoustu flákajících se strojů, kterým stojí procesory a mají narvaný RAMky z velké části zbytečnou cache, to už taková sranda není.
A pronájem? No naštěstí ne každej je takovej čmoudofil a ne každej chce mít svoje data poházený kdoví kde.
Ono nejde o to, že je jeden takovejhle naddimenzovanej virtuál. Ono jde o to, že to je dneska zcela běžný požadavek každé firmy na jakoukoliv kravinu. A když už je ten požadavek na podobný kraviny několikátý jen za letošní rok, tak už začínám mít opravdu na podobný debility alergii.
Kdyby se raději ty zbytečný investice narvali do vzdělávání vývojářů, kteří by potom začali opravdu něco tvořit a ne jen malovat nenažranosti ve frejmvórcích, to by bylo krásně na světě, co?
-
HW je opravdu proti lidske praci velmi levny.
To je právě jedna z těch tisíckráte opakovaných lží dneška. Ve skutečnosti to platí jen v určitých případech, ale nelze to zevšeobecňovat. Hlavně to není žádná lineární závislost. Jinými slovy - proč optimalizovat databázi, to je lidská, tedy drahá práce, když HW to zvládne i tak. Jenže v určitém momentu to překročí bod, kdy se najednou ukáže, že cena HW začíná vykazovat své exponenciální chování oproti lidské práci a že náprava celé té situace vyjde několikanásobně dráž, než kdyby se to bývalo udělalo pořádně hned na začátku.
To je pak podobná logika, jako nač věnovat pečlivost zakládání budovy. Dvě patra to unese a až budeme přistavovat páté, tak to třeba začneme řešit. Kdyby tak někdo spočítal, kolik tahle krátkozraká řešení, aby se ušetřilo, stála nakonec peněz navíc...
-
imho kazdy si to musi vzdy spocitat jestli se mu vyplati najmout si experta na dany konkretni problem (kolik tim utrati a usetri na optimalizovanem hw) nebo to zatluce kladivem (koupi vic ram apod.)
spis mne stve ze vetsina webu uz davno neni statickych ani dynamickych s jednoduchym rotujicim zavinacem v javascriptu, dneska uz to jsou spis komplexni aplikace bezici v browseru, casem nejspis uz jakoby desktopove interaktivni aplikace bezici v browseru
btw 35 tabu v google chrome mne sezere behem 1 dne veskerych 6 gb ram na mem mac os x a druhy den uz si neco odswapuje ...
-
U RAM nastává potencionální problém, protože každej stroj dříve nebo později celou paměť sežere na cache.
A v čem je problém, když se nepotřebná RAM využije na keš?
-
imho kazdy si to musi vzdy spocitat jestli se mu vyplati najmout si experta na dany konkretni problem (kolik tim utrati a usetri na optimalizovanem hw) nebo to zatluce kladivem (koupi vic ram apod.)
spis mne stve ze vetsina webu uz davno neni statickych ani dynamickych s jednoduchym rotujicim zavinacem v javascriptu, dneska uz to jsou spis komplexni aplikace bezici v browseru, casem nejspis uz jakoby desktopove interaktivni aplikace bezici v browseru
btw 35 tabu v google chrome mne sezere behem 1 dne veskerych 6 gb ram na mem mac os x a druhy den uz si neco odswapuje ...
On je problém jinde... Většina jednání o nasazení podobných sra*ek probíhá na úrovni manager(zákazník)-manager(dodavatel). Zákazník dělá machra, jak není problém zajistit železo, dodavatel dělá machra, jak je jejich řešení nejlepší. Reálně o tom ani jeden nemá ani páru, požadavky jsou násobně předimenzovaný jen proto, aby byl dodavatel vykrytej proti tomu, že není schopnej odvést práci pořádně a proto, že zákazník neví, co dodavatel plácá za kraviny, ale nechce být za blbce.
Finálně je to tak, že reálný provoz nedosáhne ani desetiny toho, co bylo poptáno, nicméně pokud se nějakým zázrakem stane, že se dostane přes tu desetinu, aplikace se sesype na nějaké prasečině, kterou dodavatel odflákl.
Jinak s tím expertem, který to udělá dobře... přesně takový experty slibuje každý dodavatel, už jsem četl spoustu těch marketingo-managorských sra*ek a nikdy nikdo nenapsal "jsme levní amatéři bez známek logického myšlení a bez elementární znalosti dané problematiky".
Schválně někdy udělejte pokus, pokud něco takovýho řešíte na straně zákazníka...
- vyberte si nějaký ne moc důležitý projekt ve fázi implementace, který kromě nějaké webo sra*ky potřebuje i nějakou databázi, ideální je nějakej éšopík
- vyžádejte si dokumentaci k zálohování
- pokud se záloha provádí "online", požadujte podrobnou dokumentaci řešení konzistence dat
Nejčastější odpověď bude něco jako:
"eeee... hmmmm... noooo... víte, záloha se dělá ve 2 ráno, to tam stejně nikdo nebude, takže je to v pohodě"
případně rovnou
"eeeee cože?"
-
U RAM nastává potencionální problém, protože každej stroj dříve nebo později celou paměť sežere na cache.
A v čem je problém, když se nepotřebná RAM využije na keš?
Třeba v tom, že reálně využitá paměť je 2G a cache sežere 14G, jenom proto, že jsem tomu tu paměť dal, protože tak to dodavatel řešení vyžaduje? Střední servřík s 256GB tak zvládne (zanedbáme-li režie) 16 virtuálek a paměť je pryč. Přitom by takových virtuálek zvládl klidně 64 a stále by každá ještě měla 2GB volné paměti na cache a cokoliv jinýho. Pokud tedy budu chtít 64 virtuálek, potřebuji 4 servery místo 1, což jsme bratru na rozdílu milión jen za HW! Ano, mega nic není, ale tohle je totálně zbytečný mega + totálně zbytečný náklady kolem!!! A teď pozor... schválně jak dlouhej je běžnej support na servery a za jak dlouho budu kupovat nový?
-
htop ?
Neblazni, na to treba minimalne Grafanu, inac nie si cool a s dobou ;-)
jj. Najlepsie taku co chrusta asci art na GPU. :-D
-
Třeba v tom, že reálně využitá paměť je 2G a cache sežere 14G, jenom proto, že jsem tomu tu paměť dal, protože tak to dodavatel řešení vyžaduje? Střední servřík s 256GB tak zvládne (zanedbáme-li režie) 16 virtuálek a paměť je pryč. Přitom by takových virtuálek zvládl klidně 64 a stále by každá ještě měla 2GB volné paměti na cache a cokoliv jinýho.
Co používáš za virtualizaci? LXC i OpenVZ sdílí diskouvou cache mezi kontajnery, takže tvůj výpočet neplatí.
-
Třeba v tom, že reálně využitá paměť je 2G a cache sežere 14G, jenom proto, že jsem tomu tu paměť dal, protože tak to dodavatel řešení vyžaduje? Střední servřík s 256GB tak zvládne (zanedbáme-li režie) 16 virtuálek a paměť je pryč. Přitom by takových virtuálek zvládl klidně 64 a stále by každá ještě měla 2GB volné paměti na cache a cokoliv jinýho.
Co používáš za virtualizaci? LXC i OpenVZ sdílí diskouvou cache mezi kontajnery, takže tvůj výpočet neplatí.
Ani LXC ani OpenVZ nejsou plnohodnotná virtualizace. Používáme VMWare, protože je to jediná virtualizace jak s podporou pro hypervizor jako takový, tak od ostatního (komerčního) SW.
-
Ani LXC ani OpenVZ nejsou plnohodnotná virtualizace. Používáme VMWare, protože je to jediná virtualizace jak s podporou pro hypervizor jako takový, tak od ostatního (komerčního) SW.
No vidíš, s LXC bys neměl problém ;)
-
Ani LXC ani OpenVZ nejsou plnohodnotná virtualizace. Používáme VMWare, protože je to jediná virtualizace jak s podporou pro hypervizor jako takový, tak od ostatního (komerčního) SW.
No vidíš, s LXC bys neměl problém ;)
No měl, protože většina SW i HW je držená v podpoře a ta má samozřejmě určité podmínky. Pokud SW říká, podporujeme instalace na fyzickém HW, nebo virtuál na VMWaru, prostě s tím neudělám nic. A můžeš mi věřit, že ta podpora se občas hodí ;)
-
Taky používám LXC, takže full virtualizace se samostatným imagem paměti mě nenapadla...
-
U RAM nastává potencionální problém, protože každej stroj dříve nebo později celou paměť sežere na cache.
A v čem je problém, když se nepotřebná RAM využije na keš?
Zeby v tom, ze z pohledu pripadnyho virtualu je to RAM pouzita, a tudiz ji nemuze pridelit dalsimu stroji, kterej by v ni trebas mel i neco uzitecnyho?
...
Nejčastější odpověď bude něco jako:
"eeee... hmmmm... noooo... víte, záloha se dělá ve 2 ráno, to tam stejně nikdo nebude, takže je to v pohodě"
případně rovnou
"eeeee cože?"
... co je to zalohovani?
Co používáš za virtualizaci? LXC i OpenVZ sdílí diskouvou cache mezi kontajnery, takže tvůj výpočet neplatí.
Pokud mas realnej skutecnej virtual tak asi tezko.
-
Pokud mas realnej skutecnej virtual tak asi tezko.
To už je tvoje volba, co použiješ. Aplikaci je jedno, jestli běží ve full virtualizaci nebo v operating system level virtualizaci.
-
S čím mám problém? No s CPU ani ne, tam je mi to jedno, když to není vytížený. U RAM nastává potencionální problém, protože každej stroj dříve nebo později celou paměť sežere na cache. Ono se říká, že paměť je levná, ale:
- 128GB moduly opravdu levný nejsou
- fyzický stroj má omezený maximální množství paměti
- jeden fyzický stroj stojí jak hodně pěkný auto, špička už se blíží cenou k bytu až baráku
- každý fyzický stroj jsou desítky tisíc jen na energiích za rok, další energie jde na klimu, je potřeba mít dostatečně dimenzovaný záložní napájení atd
Ono se to může zdát jako sranda, ale provozovat spoustu flákajících se strojů, kterým stojí procesory a mají narvaný RAMky z velké části zbytečnou cache, to už taková sranda není.
A pronájem? No naštěstí ne každej je takovej čmoudofil a ne každej chce mít svoje data poházený kdoví kde.
Ono nejde o to, že je jeden takovejhle naddimenzovanej virtuál. Ono jde o to, že to je dneska zcela běžný požadavek každé firmy na jakoukoliv kravinu. A když už je ten požadavek na podobný kraviny několikátý jen za letošní rok, tak už začínám mít opravdu na podobný debility alergii.
Kdyby se raději ty zbytečný investice narvali do vzdělávání vývojářů, kteří by potom začali opravdu něco tvořit a ne jen malovat nenažranosti ve frejmvórcích, to by bylo krásně na světě, co?
Jasne, nebudeme pouzivat frameworky, nebudeme pouzivat high level jazyky, budeme to developovat 4-10x delsi cas, ale hlavne ze to pobezi na levnejsim HW, to se zcela jiste vyplati :-)
Ses proste zavrenej v svym sysadminovskym svete, vsichni ostatni jsou pro tebe idioti a podle toho to vypada :) Staci se podivat, jak se dneska tvori vetsina aplikaci - spoustu z nich se dela jako proof of concept, proste se to zkusi, dulezity je zejmena time to market, za pulroku z toho mozna bude uplne jina aplikace, nebo se to naopak cele zrusi, protoze se to neujalo. Doba waterfall tvorby software, kdy vse navrhnes od stolu, zoptimalizujes do nejmensiho detailu a pak to za 2 roky pustis ven, je davno a davno pryc, hlavne je to navic model, ktery je pro vetsinu firem zcela nepouzitelny.
Prave proto je pro spoustu firem dnes uzitecny pouzivat bud reseni ala cloudy, kde platis za spotrebovany vykon (tzn. nemusis resit zadne z techto problemu, co rikas - protoze memory/cpu zmenis okamzite, ci dokonce automaticky - vysoka dostupnost tez neni problem, pokud to bezi v vice regionech - cloudy sice vypadavaji [stejne jako vlastni HW], ale pri spravnem navrhu to neni problem osetrit), uplne stejne se to da resit v ramci privatnich cloudu. A nebo nejlepe pomoci kontejneru, kde se prostredky s minimem rezie daji krasne sdilet mezi jednotlivymi aplikacemi, to je osobne za me to nejlepsi reseni.
O tom, ze to, co mate, je spatne, neni moc treba diskutovat. Ale problem neni dle meho az tak v aplikaci, ale primarne v tom, jak to mate nastavene a vyresene s dodavateli, z cehoz plyne i takto totalne neefektivni vyuziti prostredku na fyzickem zeleze.
Ale na druhou stranu je faktem, ze s HW prostredky se plytva, protoze opravdu levne jsou vuci praci. Oni nejsou tak levne, pokud pouzijes waterfall model, vis presne na zacatku, co od te app chces, jak bude vypadat, jak se zoptimalizuje a ze se takto nezmenena bude pouzivat nekolik let. Ale takhle to typicky vubec neni. A kdyz se nad tim zamyslis, ze optimalizaci by ses dostal treba na nizsi naklady na HW v adekvatni hodnotu nekolik malo hodin vyvoje,tak se to opravdu nevyplati. Protoze ta aplikace se stejne bude menit, predelavat, takze bys optimalizoval vse do detailu porad a v dusledku to stalo 10x tolik. Samozrejme, nejake zakladni veci ma smysl resit vzdy (indexy, design db, pouziti vhodnych nastroju), ale diskuse nad tim, zda pouzivat nebo nepouzivat frameworky, aby usetrili nejaky treba 1 GB RAM [a to kdovi jestli], je uplne mimo.
-
To je právě jedna z těch tisíckráte opakovaných lží dneška. Ve skutečnosti to platí jen v určitých případech, ale nelze to zevšeobecňovat. Hlavně to není žádná lineární závislost. Jinými slovy - proč optimalizovat databázi, to je lidská, tedy drahá práce, když HW to zvládne i tak. Jenže v určitém momentu to překročí bod, kdy se najednou ukáže, že cena HW začíná vykazovat své exponenciální chování oproti lidské práci a že náprava celé té situace vyjde několikanásobně dráž, než kdyby se to bývalo udělalo pořádně hned na začátku.
To je pak podobná logika, jako nač věnovat pečlivost zakládání budovy. Dvě patra to unese a až budeme přistavovat páté, tak to třeba začneme řešit. Kdyby tak někdo spočítal, kolik tahle krátkozraká řešení, aby se ušetřilo, stála nakonec peněz navíc...
to je samozrejme castecne pravda. Ale na druhou stranu faktem je ten, ze cost vetsinu vychazi v neprospech lidske prace nez HW. Ono by to platilo, jak jsem psal, v pripade, ze by ta aplikace byla staticka, jednou se udelala a pak bezezmeny provozovala, tam ma smysl to jednou zoptimalizovat poradne (i kdyz, i to je otazka jak moc se to vyplati). Ale ono je rozdil to optimalizovat a delat blbe. Neudelat napr. alespon elementarne spravny navrh databaze, indexu, pouzit vhodne datove struktury a nastroje - pokud se nedela tohle, tak je to prote jen blbe, protoze to jsou ve vetsine pripadu veci, ktere nestoji zadnou praci navic.
Ale nepouzivat moderni frameworky, high level jazyky (Java, C#, Python, ....), to uz spada pouze do kategorie nesmyslne optimalizace pro drtivou vetsinu aplikaci, jelikoz by z toho plynulo oprovske navyseni pracnosti.
-
Ani LXC ani OpenVZ nejsou plnohodnotná virtualizace. Používáme VMWare, protože je to jediná virtualizace jak s podporou pro hypervizor jako takový, tak od ostatního (komerčního) SW.
No, to je ale pak presne ta chyba, je potreba jednat s dodavateli a vybirat vhodne technologie. Jakoze, popravde, bez LXC/OpenVZ/Dockeru si opravdu zivot uz predstavit nedokazu, neskutecne to usnadnuje zivot a nasi praci, neni problem se sdilenim prostredku, neni problem s deploymentem, pripravou staging prostredi atd.
VMware samozrejme pouzivame taky, ale kontejnery nam bezi na nekolika malo VM, VMware nam nasledne zajistuje vrstvu nad tim.
-
tnr: proof of concept bohužel znamená "zbastlíme to stejně jak finální aplikaci". Frameworky mají svoje místo, netvrdím, že se má pokaždé všechno znovu vymýšlet a stavět na zelené louce, ale je třeba to brát trochu inteligentně. Nemám to "vývojářům" (čti aplikačním malířům) za zlé, chyba je i na straně zákazníka, že dokáže na neskutečný prasečiny podepsat smlouvu.
Typický příklad:
Zákazník: chci statický web, asi 5 stránek, pár návštěv za den
Dodavatel: Fajn, uděláme to v XY, potřebujeme 8 jader, 16GB RAM, 2 měsíce, 2 mega
Z: a pak chci IS na míru, 100 uživatelů, cca 50 současných přístupů
D: Fajn, uděláme to v XY, potřebujeme 8 jader, 16GB RAM, 10 měsíců, 10 mega
Z: Aha... a to můžete něčím podložit, nebo si to cucáte z prstu?
D: Sme snad blbci, nebo co? Máme zkušenosti, jsme špička v oboru, tak jsme řekli, tak to bude.
Smutnou realitou je, že absolutní většina SW malířských firem nemá ani páru o tom co dělá. Opakovaně za jejich vývojáře řeším jejich problémy, který oni odmítají řešit s tím, že máme rozbitý a pomalý servery a v absolutní většině případů je problém na straně SW. Oblíbená fičura je SQL dotaz s 50 joinama a z toho aspoň 10 LIKE %kokotina%. Aháááá a to se jako nesmí? Vždyť to fungovalo... dokud nebylo moc dat... no tak přidáme indexy, neee? Na rootu jsem četl, že indexy to zrychlujou... WTF? My jsme špičkoví vývojáři a né ňácí pošahaní databázisti. Buďte rádi, že jsme to spíchli aspoň nějak.
Další oblíbenou fičurou je škálovatelnost... fajn, něco se rozrůst může až za nejbláznivější původní představy, ale co s tím? Joooo přihodíme jádra... aha, on ten výpočet jede jenom v single threadu... no tak rychlejší CPU... no vidíte, už to netrvá hodinu, ale jenom 3/4, měli jste to rozbitý...
A co teprve lahůdky typu totálně zasekanej server a přitom se CPU nudí a paměti je dost... takový wait for interrupt je pěkná svině... A co to je? A proč to je? Máte to rozbitý, nám to na našich testovacích datech (kterých je možná setina oproti ostrým) funguje skvěle.
A nějaký navazující věci? Zálohy? Monitoring? Kontroly konzistence? Heee? Ste spadli z jahody na znak? To nedělá nikdo.
Takže jinak. Profesionální práci si představuji takhle:
Aplikační jádro cca 2GB
Každý připojení si může spustit proces, kterej potřebuje 10-100 mega, průměrně to bývá kolem 30, maximum je při takové a takové operaci
Chcete to pro 50 současných přístupů? 2048+50*30 a doporučujeme přidat 30 procent rezervu na špičky + tolik a tolik pro OS.
Klidně začněte s tím, že bude 10 přístupů, přidat se dá vždycky. Ostatně, jako profesionálové máme v ceně projektu analýzu po 3, 6 a 12 měsících, po které vždy upravíme nastavení, přidáme indexy kde budou třeba a případně dáme další doporučení.
Líbí, nebo nelíbí? A jestli víš o někom, kdo je toho schopnej, tak sem s ním.
Co se týče výběru dodavatelů... jsou prostě věci, kde není moc z čeho vybírat a tam je potřeba se přizpůsobit. Jinak rozházet servery na několik různých virtualizací je dobrej nápad... kromě toho, že se musíš starat o víc systémů, tak chci třeba vědět, jak v případě potřeby přemigruješ bez výpadku virtuálku mezi OpenVZ, LXC, Dockerem, VMW... aha... to asi neklapne...
-
2Tuxik: Prakticky 100% adminu by vsechny ty appky napsalo 10x lip a 10x driv, nez tyhle "vyvojarsky spicky", jenze na to nemaj cas, protoze to po tech kretenech musej vsechno opravovat a udrzovat v chodu.
Pro zajimavost, eet ... konfigurace ... vydajovy doklad na ni sere ... podle vyjadreni tech idiotu je to vporadku, protoze je prece normalni ze neco sere na konfiguraci, protoze vydajovy doklady do eet ... vetsinou nespadaji.
O selectech do databaze ani nemluvim ... protoze pokud neco zrychlis o 5 radu, tak to rozhodne neni optimalizace dotazu, ale totalni imbecilita tvurce.
Nebo ... chces neco vytisknout ... no tak nekdy a nekde ti tisk nabidne ... F5, jindy a jinde F8, a jeste jinde treba ctrl+P ... podle toho, jakej debil zrovna tu kterou cast psal. Vse samo jedna aplikace.
A sranda nejvetsi ... dodavatel vznes pozadavky na HW ... poridili sme asi tak 100x vykonejsi ... a ... nedalo se to pouzivat.
-
Další skvělej nápad je: Budeme ty dokumenty ukládat do BLOBu v databázi. ??? Cože? Bavíme se o stovkách GB ročně!!! Ale to se tak normálně dělá... Cože? A nešlo by je uložit na úložiště pod nějakým vygenerovaným jménem a do DB uložit jen původní název, vygenerovaný jméno a klidně nějaký další metadata? Ehmmm... eeeerrr.... noooo.... ale jooo... šlo by to... ale víte... hmmmm... máme to napsaný jinak... eeeee... ono by to bylo strašně drahý...
-
2j: To je to, co si ti malíři aplikací tak trochu neuvědomují... každej admin musí být zároveň hacker, aby se dokázal tím dnešním standardním shitem prokousat a buď ho opravit, nebo alespoň ukázat, kde přesně je chyba. K tomu musí být navíc i psycholog, aby jim dokázal vysvětlit, že to tím opravdu bylo, protože spousta expertů ti je schopná říct, že to chyba nebyla a že se náhodně "samo" opravilo něco jinýho, nebo tě rovnou obvinit, že jsi schválně zároveň opravil něco jinýho, aby jsi nebyl za blbce. Ale vrátit to zpátky do rozbitýho stavu už je pak nedonutíš, protože nemaj čas :D
-
Každý druhý sysadmin tady skuhrá, že nemá ani 30 tisíc hrubého ale koukám, že sebevědomí některým nechybí. :) Sice v diskusích vyplynulo, že nemá peníze pomalu ani na 8GB RAM, ale vše by napsal z voleje líp. Řekl bych, že na tebe všude čekají s otevřenou náručí, "j".
-
Mám sto chutí sem dát pár veselých historek z opačné strany (např. o tom jak aplikace sice uměla ukládat dokumenty na disk, ale admini trvali na tom že to bude v db dokud nezískají rozpočet mego/rok na komerční síťový FS), ale asi to nemá cenu... všechno je to typické selhání managementu.
Více na http://dilbert.com
-
Mám sto chutí sem dát pár veselých historek z opačné strany (např. o tom jak aplikace sice uměla ukládat dokumenty na disk, ale admini trvali na tom že to bude v db dokud nezískají rozpočet mego/rok na komerční síťový FS), ale asi to nemá cenu... všechno je to typické selhání managementu.
Více na http://dilbert.com
Ono je to potom taky o tom, jak máš nastavený všelijaký pravidla, procesy atd. Pokud ti spusta menších věcí jede na jedné DB a najednou ti někdo, kdo už tu DB používá nějakým normálním způsobem přijde s tím, že tam chce rvát BLOBY, tak je to na zabití. Mimochodem, perfektní filtr na supr čupr kůůůl aplikační malíře je Oracle. Perfektně se na tom rozezná firma, co má něco za sebou a dva bráchové, kteří se tváří jako nadnárodní korporát. Každej šašek zná MySQL, MariaDB, trošku lepší potom MSSQL nebo PG, ale jak šašek zaslechne Oracle, vyskočí mu pot na čele a začne se klepat :D
-
k te blbine, ze hw je levny a prace je draha.....vtip je v tom ze psat neco ne jak prase, ale jak clovek vetsinou nestoji vic casu. i jakakoliv modifikace je pak levnejsi. navic kdyz si to prase pak odejde jinam, tak je po nem daleko vetsi (a drazsi) svincik.
navic ani nemyslim ze bu pronajem vykonneho hw byl nejak levny. vloni me zajimalo, za kolik si muzu a kde pronajmout cpu/gpu pro rendering, kdyz je to prece tak levny, a vsude to bylo teda pekne mastny, tech nul v castkach bylo ponekud moc....
-
k te blbine, ze hw je levny a prace je draha.....vtip je v tom ze psat neco ne jak prase, ale jak clovek vetsinou nestoji vic casu. i jakakoliv modifikace je pak levnejsi. navic kdyz si to prase pak odejde jinam, tak je po nem daleko vetsi (a drazsi) svincik.
navic ani nemyslim ze bu pronajem vykonneho hw byl nejak levny. vloni me zajimalo, za kolik si muzu a kde pronajmout cpu/gpu pro rendering, kdyz je to prece tak levny, a vsude to bylo teda pekne mastny, tech nul v castkach bylo ponekud moc....
No tak logicky, když nějakej čmoudař nakoupí HW, platí za něj elektriku, údržbu atd, musí ty peníze dostat zpátky a ještě vydělat. Ano, nakupují pravděpodobně levněji, ale nebude to zase takovej rozdíl, aby se to finálně mohlo zákazníkovi ve velkým opravdu vyplatit. Jeden, dva stroje, pro malou firmu, možná ve světě jo, tam ušetřím jednoho drahýho člověka, ale u nás si tam posadí absolventa za pár drobných a ještě se k tomu bude starat o stanice. To platí o dedikovaným serveru. U sdílených serverů to bude jinak, pokud nepotřebuji nonstop výpočetní výkon, ale chci provozovat nějakej soukromej webík pro 3 návštěvy denně. Mám 2 VPS servery a platím za ně dohromady asi tolik, kolik by mě stál hoooooodně úspornej PC zapnutej doma jenom za energii. A bez starostí. Ale zase s tím rizikem, že i na těch pár webících, co tam běží, je občas poznat, že nejsou tak svižný. Samostatnou kapitolou právě může být ten rendering, komplikovaný výpočty, simulace atd. Tam se na jednorázovou akci vyplatí vysolit nehorázný peníze za blbý dva dny provozu, protože na HW, kterej bych za ty prachy koupil, to budu dělat rok.
-
k te blbine, ze hw je levny a prace je draha.....vtip je v tom ze psat neco ne jak prase, ale jak clovek vetsinou nestoji vic casu.
O tom nikdo nepochybuje. Myslim, ze tohle se resi pri porovnani postavit to na frameworku XY vs from scratch. ve vetsine FW se da psat ciste a stejne tak prasit. FW si vezme vice protoze je vice abstraktni, ale vyvoj je o nekolik radu rychlejsi. To je ta pointa.
-
Další skvělej nápad je: Budeme ty dokumenty ukládat do BLOBu v databázi. ??? Cože? Bavíme se o stovkách GB ročně!!!
Tak jestli se bojíš pitomých pár stovek GB ročně, tak to nech pořádným chlapům a dál si hraj jen s hračkama pro děti z mateřský školky.
Ale to se tak normálně dělá... Cože? A nešlo by je uložit na úložiště pod nějakým vygenerovaným jménem a do DB uložit jen původní název, vygenerovaný jméno a klidně nějaký další metadata? Ehmmm... eeeerrr.... noooo.... ale jooo... šlo by to... ale víte... hmmmm... máme to napsaný jinak... eeeee... ono by to bylo strašně drahý...
Pravděpodobně říkali věci jako "A kdo ty soubory smaže při rollbacku transakce?", ale ty evidentně netušíš, která bije.
Přidám ještě jednu ukázku z praxe, tentokrát z druhé strany:
D: Jak to, že nejsou logy na vývojovém serveru?
A: No, my jsme je smazali.
D: A proč jste je smazali? My je potřebujeme na zkoumání chyb.
A: No, ono tam došlo místo.
D: Jak to, vždyť mají jen pár desítek giga?
A: No, on ten server běží ve virtuálu a na tom fyzickém stroji je jich víc a tak vychází na jeden virtuál málo místa.
D: Hele, vedle je Alza, já tam skočím a koupím tam za svoje nějaký 3TB disk, ten bude stačit na devel logy za celý rok.
A: No to nejde, to musí být super speciální extra hyper cool serverový disk.
D: Super serverový disk? Na logy z vývojového serveru????
A: No...
-
Tak jestli se bojíš pitomých pár stovek GB ročně, tak to nech pořádným chlapům a dál si hraj jen s hračkama pro děti z mateřský školky.
Ne, nebojím se pár set giga ročně, ale...
https://www.root.cz/zpravicky/naucte-se-adminovat-databazi-oracle-skoleni/
tam ti jistě rádi vysvětlí, jak fajnovej nápad je zasvinit si tím databázi, jaké to má khůůůůl výhody a proč to přesně tak udělat.
A až se vrátíš domů, opiš 1000x "Už nejsem vůl a už nikdy nebudu cpát zbytečný bloby do databáze".
-
Kam na to chodíte, že klient si objedná železo za milión?
Typický prípad: my máme vlastný server, nemôžete to dať tam? 10 rokov nám beží bez problémov!
Antispam otázka "Ve kterém měsíci proběhla sametová revoluce?" by mohla brať november ako správnu odpoveď. Človek musí googliť...
-
Tak jestli se bojíš pitomých pár stovek GB ročně, tak to nech pořádným chlapům a dál si hraj jen s hračkama pro děti z mateřský školky.
Ne, nebojím se pár set giga ročně, ale...
https://www.root.cz/zpravicky/naucte-se-adminovat-databazi-oracle-skoleni/
tam ti jistě rádi vysvětlí, jak fajnovej nápad je zasvinit si tím databázi, jaké to má khůůůůl výhody a proč to přesně tak udělat.
A až se vrátíš domů, opiš 1000x "Už nejsem vůl a už nikdy nebudu cpát zbytečný bloby do databáze".
no napriklad justice pouziva ISAS - Informacni system pro administrativu soudu coz neni nic jineho nez graficka nadstavba nad oraclem v jave a tam se normalne ukladaji vsechny soubory napr. *.doc, *.pdf do databaze, je tam dokonce i featura ze by to umelo fulltextove prohledavat ale co pamatuju nebyla zapnuta coz bylo skoda kazdy znovuvynalezal kolo (kazdy okresni soud ma svuj ISAS na jednom svym serveru v baraku soudu, jednotlive ISASy umoznuji dalkovy pristup pro moznost proverek atd.. pres noc se replikuji nekam dal kde ma nekdo k dispozici vsech 87 ISASu okresnich soudu, krajske vrchni nejvyssi, nejvyssi spravni a ustavni soud maji plus minus podobne systemy) akorat mene objemnou agendu tak asi maji nad tim zapnutej i ten fulltext
-
A až se vrátíš domů, opiš 1000x "Už nejsem vůl a už nikdy nebudu cpát zbytečný bloby do databáze".
Problém je, že nevidíš důsledy rozdělení dat. Kdybys chtěl dát některá data mimo databázi, tak musíš navíc řešit:
- Referenční integritu. Kdo zajistí, že se soubor mimo databázi smaže, pokud neprojde insert transakce? Kdo zajistí, že se soubor nesmaže, pokud neprojde delete transakce? Co dělat, když se to nepovede smazat?
- Zálohování. Jak a kam se data mimo databázi budou zálohovat?
- Replikaci. Jak to celé během provozu bezpečně zreplikuju na jiný server?
- Upload. Jak ten soubor dostanu na filesystém? scp, ftp, něco jiného? Musím to implementovat a udržovat.
Stojí to za ty problémy? Mám to dělat, protože si admin myslí, jak je to skvělý nápad? Ne děkuji.
-
Kam na to chodíte, že klient si objedná železo za milión?
Typický prípad: my máme vlastný server, nemôžete to dať tam? 10 rokov nám beží bez problémov!
Ale to potom není klient, ale problém. Rozumná firma by je měla poslat do řiti, nebo alespoň do čmoudu. Ale to nikdo neudělá, naslibuje se to, ideálně levně, vyúčtuje se 3x tolik za blbosti, trpí zákazník i dodavatel a nakonec se to ani neuvede do produkce, protože to prostě fungovat nebude. Ale pokud to za to spoustě "profesionálních top garážníků" stojí, tak OK.
-
Stojí to za ty problémy? Mám to dělat, protože si admin myslí, jak je to skvělý nápad? Ne děkuji.
Neumíš si poradit se základními problémy vývoje? No tak asi nevyvíjej. Namalovat okýnko s tlačítkem umí každý dítě ze školky, na to tě nikdo reálně nepotřebuje. Ano, z pohledu vývoje je to cůůůl, žádná práce, pohoda klídek, všechny problémy se hodí na DB a je to cajk.
Ale jedna jediná reálná výhoda by byla full text prohledávání, ale na to jsou o několik řádů efektivnější nosql databáze, do kterých se obsah naindexuje.
-
A až se vrátíš domů, opiš 1000x "Už nejsem vůl a už nikdy nebudu cpát zbytečný bloby do databáze".
Problém je, že nevidíš důsledy rozdělení dat. Kdybys chtěl dát některá data mimo databázi, tak musíš navíc řešit:
- Referenční integritu. Kdo zajistí, že se soubor mimo databázi smaže, pokud neprojde insert transakce? Kdo zajistí, že se soubor nesmaže, pokud neprojde delete transakce? Co dělat, když se to nepovede smazat?
- Zálohování. Jak a kam se data mimo databázi budou zálohovat?
- Replikaci. Jak to celé během provozu bezpečně zreplikuju na jiný server?
- Upload. Jak ten soubor dostanu na filesystém? scp, ftp, něco jiného? Musím to implementovat a udržovat.
Stojí to za ty problémy? Mám to dělat, protože si admin myslí, jak je to skvělý nápad? Ne děkuji.
jeste si vzpominam ze sice v ISASu se "pripoji soubor do databaze" ale fyzicky nejde o pridani *.doc do databazoveho souboru oracle, jde vlastne jen o link na soubor na disku (kdyz v ISASu kliknu na Otevrit tak se soubor nacte z disku ne z databaze), samotne soubory ktere nalezi prislusnemu soudnimu spisu (elektronicky spis) jsou pod nazvem sp. zn. jako nazvem adresare normalne ulozeny na filesystemu - na disku v uvedene adresarove strukture rok/sp.zn/...
-
jeste si vzpominam ze sice v ISASu se "pripoji soubor do databaze" ale fyzicky nejde o pridani *.doc do databazoveho souboru oracle, jde vlastne jen o link na soubor na disku (kdyz v ISASu kliknu na Otevrit tak se soubor nacte z disku ne z databaze), samotne soubory ktere nalezi prislusnemu soudnimu spisu (elektronicky spis) jsou pod nazvem sp. zn. jako nazvem adresare normalne ulozeny na filesystemu - na disku v uvedene adresarove strukture rok/sp.zn/...
Celkem nečekaně... on totiž každej, kdo měl někdy co do činění s několikaterovou databází, nejlíp padlou na hubu, tak si pro příště rozmyslí, co do ní cpe.
2Lojza: Jinak ti dám radu, commit pustíš, až je vše na svém místě, takže nejhorší varianta je, že se ti válí na disku soubor, kterej není v DB... no katastrofa... oprava řádově na minutu.
-
Tak když už se bavíme o opravdu velkých blobech, tak na to jsou objektové databáze.
-
jeste si vzpominam ze sice v ISASu se "pripoji soubor do databaze" ale fyzicky nejde o pridani *.doc do databazoveho souboru oracle, jde vlastne jen o link na soubor na disku (kdyz v ISASu kliknu na Otevrit tak se soubor nacte z disku ne z databaze), samotne soubory ktere nalezi prislusnemu soudnimu spisu (elektronicky spis) jsou pod nazvem sp. zn. jako nazvem adresare normalne ulozeny na filesystemu - na disku v uvedene adresarove strukture rok/sp.zn/...
To je škoda, že ten systém nenavrhoval někdo kompetentní, ale dělal to asi nějaký admin... Nicméně u státní správy se ani moc nedivím...
-
Jinak ti dám radu, commit pustíš, až je vše na svém místě, takže nejhorší varianta je, že se ti válí na disku soubor, kterej není v DB... no katastrofa... oprava řádově na minutu.
Jak uděláš master-master replikaci dat na jiný server za provozu? Co když někdo vytvořil v jedné instanci novou verzi nějakého souboru? Ve druhé instanci máš nesmazanou starou verzi, co uděláš, kterou si vybereš? Syncneš nejdřív databázi a potom filesystém, nebo opačně? V prvním případě budeš mít v databázi záznamy, které ještě neexistují na disku. Ve druhém případě mažeš soubory z disku, na které ještě odkazují záznamy v databázi.Dovedeš si představit, jak složité a nespolehlivé řešení by to bylo?
-
ja databazim nerozumim tak nevim jestli je to navrzene dobre nebo spatne, jen popisuji co si pamatuju .. jinak prumerny okresni soud vygeneruje+prijme radove stovky tisic *.doc *.pdf *.rtf.. rocne, vsechny rocniky jsou v jedne databazi, ISAS se zavadel cca v roce 2005 takze nyni uz ma 11 let v databazi takze u nekterych vetsich okresnich soudu pocet dokumentu v databazi muze byt v radu jednotek milionu, nevim jestli je to velka nebo mala databaze, co pamatuju tak byla docela svizna a i vyhledavaci dotazy (jsou tam predpripravene v gui , zadne selecty joiny ...) byly docela svizne, nejdele jsem cekal u komplikovanych spojenych dotazu tak minutu
-
Jinak ti dám radu, commit pustíš, až je vše na svém místě, takže nejhorší varianta je, že se ti válí na disku soubor, kterej není v DB... no katastrofa... oprava řádově na minutu.
Jak uděláš master-master replikaci dat na jiný server za provozu? Co když někdo vytvořil v jedné instanci novou verzi nějakého souboru? Ve druhé instanci máš nesmazanou starou verzi, co uděláš, kterou si vybereš? Syncneš nejdřív databázi a potom filesystém, nebo opačně? V prvním případě budeš mít v databázi záznamy, které ještě neexistují na disku. Ve druhém případě mažeš soubory z disku, na které ještě odkazují záznamy v databázi.Dovedeš si představit, jak složité a nespolehlivé řešení by to bylo?
proto se ta replikace (+treba upgrade) delala pres noc, povinnosti bylo ze vsechny PC ukoncili praci v ISASu, vsichni lidi jiz odesli z budovy soudu
-
Jinak ti dám radu, commit pustíš, až je vše na svém místě, takže nejhorší varianta je, že se ti válí na disku soubor, kterej není v DB... no katastrofa... oprava řádově na minutu.
Jak uděláš master-master replikaci dat na jiný server za provozu? Co když někdo vytvořil v jedné instanci novou verzi nějakého souboru? Ve druhé instanci máš nesmazanou starou verzi, co uděláš, kterou si vybereš? Syncneš nejdřív databázi a potom filesystém, nebo opačně? V prvním případě budeš mít v databázi záznamy, které ještě neexistují na disku. Ve druhém případě mažeš soubory z disku, na které ještě odkazují záznamy v databázi.Dovedeš si představit, jak složité a nespolehlivé řešení by to bylo?
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.
-
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ší...
-
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?
-
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.
-
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.
-
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
-
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.
-
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.
-
Ono to ve výsledku k tomu verzování stejně spěje, třeba nilfs je dobrá volba.
-
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.
-
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.
-
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...
-
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.
-
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.
-
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 ...
-
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.
-
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.
Proc je to mylny predpoklad ? Vysoce dostupnou DB zajistit lze, na SQL i NoSQL databazich. 100% samozrejme ne, ale velmi tomu se blizici se samozrejme ano. Od toho mame prave ruzne replikace, log shippingy, clustering, atd. Ze si to nekdo blbe rozhodne je samozrejme vec jina, my na to nase zakazniky bezne upozornujeme, nekdo to chce, nekdo si rekne, ze se mu HA reseni nevyplati (naklady > skoda pri vypadku - coz je samozrejme zcela OK rozhodnuti z pohledu firmy). Samozrejme to neco stoji, melo by se s tim idealne pocitat uz od zacatku vyvoje SW (ale pokud se rozhodneme jen pro hot standby reseni, tak to neni nezbytne problem, pokud se s tim na zacatku nepocitalo).
Ale souhlas s tim, ze rozhodovani podle ceny, je neskutecny mor. Ale to neni nic specifickeho pro vyvojare, managery, adminy, tenhle mor je trochu v cele spolecnosti - uplne stejne kroutim hlavou nad tim, ze si nekdo koupi parodii na maslo ci sunku v Tescu, protoze "to bylo tak levny, no nekup to voe", jako kdyz podobne vystrelky dela C level v korporaci pri nakupu HW/SW/vyvoji. Ale je to kazdeho vec, urcite bych to negeneralizoval.
-
Paradoxně nejvíc problémů v HA prostředí způsobuje HA prostředí, nicméně většina se nedotkne uživatelů a tak to má být. Ale když to pak přijde doopravdy, je potřeba s tím počítat.
-
Ale nepouzivat moderni frameworky, high level jazyky (Java, C#, Python, ....), to uz spada pouze do kategorie nesmyslne optimalizace pro drtivou vetsinu aplikaci, jelikoz by z toho plynulo oprovske navyseni pracnosti.
GC opravdu z Javy či C# high level jazyk neudělá...
-
Ale nepouzivat moderni frameworky, high level jazyky (Java, C#, Python, ....), to uz spada pouze do kategorie nesmyslne optimalizace pro drtivou vetsinu aplikaci, jelikoz by z toho plynulo oprovske navyseni pracnosti.
GC opravdu z Javy či C# high level jazyk neudělá...
GC dělá tak akorát z patlalů mistry a z mistrů patlaly :D Kdo si nedokáže ohlídat ani vlastní bordel, ten asi jen s těží vytvoří něco kvalitního.
-
GC opravdu z Javy či C# high level jazyk neudělá...
Kde v mem prispevku vidis formulaci, ze HLL z Javy ci C# dela GC ?:-D
GC dělá tak akorát z patlalů mistry a z mistrů patlaly :D Kdo si nedokáže ohlídat ani vlastní bordel, ten asi jen s těží vytvoří něco kvalitního.
Jasne. A poradny ridic nepotrebuje automatickou prevodovku (proto ji kazdy lepsi sportak spolu s launch control :-d). A skutecni programatori nepouzivaji fortrtan. a 640 kB pameti musi stacit kazdemu :-D wait a moment...
Hele nevim, kolik si toho naprogramoval uz za zivot, ale tenhle nazor povetsinou slysim od lidi, co o tvorbe SW maji predstavu asi jako ja o stavbe jaderne elektrarny (je tam nejaky reaktor, okruh, to prece nemuze byt tak slozity :-D). Je to pitomost. Ja dodnes porad programuji v C/C++ nejaky high performance kod a u komplexnich systemu stejne vetsinou skoncil u toho, ze nejakou primitivni formu automaticke spravy pameti jsem si naimplementoval musel (jednoduse z toho duvodu, ze ty data se musi sdilet, casto mezi X vlakny a kdy se maji uvolnit nejde uplne rict staticky). Stejne tak nemam pocit, ze moji praci v Haskellu a LISP, ktere pouzivame na nejake research projekty, snizuje fakt, ze se tam pouziva GC :-D
GC je proste nastroj. Usetri spoustu prace, zabrani spouste chyb, za cenu drobne CPU latence a lehce zvysene pametove narocnosti, coz je vec, ktera v 99.9% pripadu nevadi (resp. je opodstatna temi vyhodami). A fakt me netrapi, jestli treba konkretne jeden system, ktery jsem delal, ktery pracuje nad 60 TB Oracle databazi, pouziva 30 GB RAM misto 29 GB (kdyby nemel GC) a netrapi to ani zakaznika :)