Příspěvky

331

Server / Re:HW nároky malých aplikací

« kdy: 03. 03. 2017, 12:11:57 »

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.

332

Server / Re:HW nároky malých aplikací

« kdy: 03. 03. 2017, 11:15:51 »

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.

333

Server / Re:HW nároky malých aplikací

« kdy: 03. 03. 2017, 11:04:21 »

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.

334

Server / Re:HW nároky malých aplikací

« kdy: 03. 03. 2017, 10:50:30 »

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.

335

Server / Re:HW nároky malých aplikací

« kdy: 03. 03. 2017, 06:05:46 »

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".

336

Server / Re:HW nároky malých aplikací

« kdy: 02. 03. 2017, 22:28:14 »

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.

337

Server / Re:HW nároky malých aplikací

« kdy: 02. 03. 2017, 19:15:23 »

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

338

Server / Re:HW nároky malých aplikací

« kdy: 02. 03. 2017, 18:26:26 »

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

339

Hardware / Re:outdoor kamera s nejlepší výbavou pod 3000

« kdy: 02. 03. 2017, 18:21:19 »

Teď jsem zahlídl cosi v kauflandu asi za 1600, ale přiznám se, nestudoval jsem, co je to zač...
Jinak ten popis pro gitup na Heuréce nezklamal, jako je jejich dobrým zvykem
Zařazení   Digitální kamera (Full HD)
4K   ano
Full HD   ano
Celkové rozlišení   16 Mpix
Rozlišení videa   1920 x 1080 px

a další fór... když jsem to sem kopíroval, u 4K a rozlišení se mi sem zkopírovalo slovíčko "opravit", který není na stránce vidět

340

Server / Re:HW nároky malých aplikací

« kdy: 02. 03. 2017, 18:13:30 »

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ý...

341

Server / Re:HW nároky malých aplikací

« kdy: 02. 03. 2017, 17:49:19 »

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...

342

Server / Re:HW nároky malých aplikací

« kdy: 02. 03. 2017, 15:52:19 »

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í

343

Server / Re:HW nároky malých aplikací

« kdy: 02. 03. 2017, 15:40:37 »

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.

344

Server / Re:HW nároky malých aplikací

« kdy: 02. 03. 2017, 14:27:33 »

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ý?

345

Server / Re:HW nároky malých aplikací

« kdy: 02. 03. 2017, 14:16:07 »

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?"