Helios Green aneb nejsprasenejsi aplikace kterou znam

[Jezevec]

Jedeme dal. Tak si predstavte, mate nejaky seznam (ciselnik) zaznamu a nastavite si, ze nad doklady typy XYZ se ma automaticky doplnit hodnota 123 (z toho seznamu). No a kdyz hodnotu 123 ze seznamu smaznete, tak ten default s naprostym klidem narve do databaze id jiz neexistujiciho zaznamu, coz navrch znamena, ze onen doklad nelze beznym uzivatelskym zpusobem nijak upravovat.
Pekne vam takto vzniknou nekonzistentni data a pri trose stesti to zjistite az po par tydnech/mesicich.

[Jezevec]

Navazuju na sve predchozi zazitky a pokracuji v osvete pro ty, kteri by se nekdy nahodou dostali do kontaktu s timto bastlem.

30 zaznamu je strasne moc. Neverite ? V roce 2010, TB databazi ... ? Mate 90 zamestnancu? To jste na tom jeste dobre, mzdove listy budete tisknout 3x. Vic nez 30 najednou je proste strasne moc a system vas posle doprdele. Jiste, stejna data ziskate z databaze dotazem bezicim sekundu, ovsem sytemu to trva minuty a tak, misto aby se vyresil adekvatni vykon, nastavi se omezeni na 30.

Mate pocit, ze spravce aplikace tu je od toho, aby vam nastavoval firemni postupy, pripadne administroval opravneni a dalsi aspekty ? Omyl, spravce je tu od toho, aby neustale resil neschopnost dodavatele. Napr ohledne navrhu databaze. Indexy si musi vymyslet sam, ovsem samozrejme, pokud neco prestane fungovat, dodavatel to svede prave na jeho indexy. Ve standardnim stavu trva takova extremne neobvykla vec, jako je pridani firmy na objednavku, bez problemu minutu i dele - podotykam, ze na naprosto nezatizenem SQL serveru. Nu coz, naflakate si tam indexy, zvetsite databazi na dvojnasobek, prikoupite za par M dalsi TB uloziste a zjistite, ze jakekoli ulozeni cehokoli trva 2x dele, protoze update vs indexy ...

Prijde vam normalni, ze system z verze na vezi umi sam udpovodajicim zpusobem osefovat databazi tak, aby vse fungovalo ? No to jste ale nekde jinde. HeG prevedete na novou verzi a zacnete se divit, ze misto Ano/Ne se vam ve formularich objevi 1/0 pripadne A/N ... proste to, co reprezentuje stav v databazi. Pak si samozrejme sami vyzkoumate(dodavatel nevyzkouma nic, jen vam posila nesmyslne odkazy na kdejakou hovadinu), ze je to tim, ze nova verze neumi pracova s typem char, tak si to alespon v uzivatelskych tabulkach prevedete na varchar a zjistite, ze stejny problem je v tabulkach dodavatele. Myslite si, ze to opravi ? Ale kdeze, opet vam posle odkazy na hovadiny, takze vam nezbyva nez to riskout, zmenit datovy typ a modlit se, aby v neblizsich 10ti letech na danou tabulku nesahal (coz se samozrejme nestane, struktura se meni s kazdou aktualizaci).

Myslite si, ze dodavatel, ktery se chlubi na svem webu ze je dodavatelem nejvetsiho ceskeho ERP ma lidi schopne programovat ? Jak naivni. Nejsem programator, ale co je to for tedy vim (narozdil od lidi prgajicich HeG). Myslite si, ze neco tak velkeho se navrhuje a programuje objektove ? Kdyby to tak bylo, tak by se preci nemohlo stat, ze nad stejnym objektem muzete pouzivat konkretni funcionalitu podle toho, z ktere strany do nej vlezete. Neuveritelne, ale celkem standardni. Prislo by vam normalni, nastavovat konfiguraci poptavek nad necim(pro znale poradacem), co se jmenuje poptavky ? Me take, ne tak vyvojarum HeG. Musite vlezt do dat. Prisilo by vam normalni nastavovat chovani a predvolene nastaveni funkcni nad seznamem funkci ? Nj, to by ste ale nesmeli byt u LCS/Asseco. Jim prijde normalni, ze si funkci pustite, vybleje to na vas tabulku, ktera muze byt pri jine prilezitosti jina, a po jejim vyplneni mackate "tajnou" kombinaci klaves "toto chci ulozit jako default".

Myslite si, ze by "moderni" ERP mel narosto normalne zvladat veci jako nastavovani uzivatelskeho vzhledu pro uzivatele/skupiny uzivatelu adminem ? Na to rovnou zapomente. Uzivatel si muze neco ubastlit a ulozit si to, ovsem pokud potrebujete neco zmenit centralne, tak musite vsem uzivatelum jejich nastaveni smaznout. Neco jako nastavit skupine X neco a Y neco jineho ... Muzete ovsem obehat vsech svych N uzivatelu a ponastavovat jim to rucne.

Jeste neco k pravum, neco uz sem zminoval, tak rada pro pripadne malo privilegovane uzivatele. Pokud vas neco zajima, staci kdyz v systemu mate pristup k filtrum (i radkovym). Do tech se da uplne vpohode vlozit query. Na webu se tomu rika sql injection a povazuje se to za jednu z nejzasadnejsich chyb jakou muze web mit. A pokud neznate strukturu databaze, nebojte se, system vam rad napovi, staci kdyz si do tzv "velkeho" filtru date vlozit vyraz. Nabidne vam to pekne seznam vsech policek. A co muzete s temer 100% jistotou ziskat ? No protoze na vsech dokladech je policko pachatel, tak pokud ho vidite, jako ze na 99% ano, tak mate pristup k veskerym udajum o zamestnancich - rodna cisla, mzda ...

[e1]

Wow, ten posledný odstavec je perfektný. Mať niečo takéto vo veľkej spoločnosti, alebo v banke to by bolo peklo.

[Jezevec]

Mno ... pouziva to dcerinka CEZu I&C Energo ... maji tusim 10k zamestnancu (zajistujou servis pro CEZ) .... nechapu jak stim muzou zit. Sice v tom asi nedela moc lidi zaroven, ale pocitaj jim v tom vejplaty.

Ad vykon, 50lidi zaroven, nedelajicich prakticky nic jinyho nez vytvareni dokladu (objednavky, vydej, prijem ...) sezere 2x4 na procesoru SQLka na 100%. To myslim celkem slusne vypovida o uzasnem navrhu databaze. Nacteni prehledu dokladu pak trva v nekteryh pripadech i 30+s, insert do DB i minutu a vic. Tzv "tenky" klient sezere vpohode dvoujadro na 100%. Zato tzv "aplikacni" server nedela nic (ale pro jistotu se kazdou noc restartuje IIS).

Co se bezpecnosti tejce, proste se spoleha na to, ze uzivatel je dement, kterej nikam nepoleze.

[peta303]

Kdo studoval na ZCU, mohl by referovat o kvalite databaze a ovladaci aplikace STAGu, pomalosti a molochovosti portalu a kravskemu predzapisu, ktery "zvenci" nefungoval a kdyz, tak jen velmi omezene a na fakultach mimo trojuhelnik take dovedene k dokonale nepouzitelnosti (tedy jeste pred dvema lety to tak platilo, ze se zadal pozadavek na misto na prednasce / seminari a za dve minuty to bud bylo, bylo obsazeno nebo doslo k chybe, to vse pak nasledovane celodenni seanci s papirovanim)... Na FAV to bylo jinak, tam se naklusalo do ucebny, povybiralo a za pul hodiny bylo i v indexu.

[Geeker]

Kdo studoval na ZCU, mohl by referovat o kvalite databaze a ovladaci aplikace STAGu, pomalosti a molochovosti portalu a kravskemu predzapisu, ktery "zvenci" nefungoval a kdyz, tak jen velmi omezene a na fakultach mimo trojuhelnik take dovedene k dokonale nepouzitelnosti (tedy jeste pred dvema lety to tak platilo, ze se zadal pozadavek na misto na prednasce / seminari a za dve minuty to bud bylo, bylo obsazeno nebo doslo k chybe, to vse pak nasledovane celodenni seanci s papirovanim)... Na FAV to bylo jinak, tam se naklusalo do ucebny, povybiralo a za pul hodiny bylo i v indexu.

bajecny STAG zavadeli pred 6 lety ve Zline na UTB. Chyby systemu se omlouvali vyvojem a testovanim. Ja 4 roky po promocich jsem se opet setkal s timto "super systemem" a opet stejne chyby. Takze alespon na UTB se nic nezmenilo.

[Jezevec]

A mame tu dalsi pokracovani serialu . Viz vyse zminovane indexy. Dodavatel se(presne dle ocekavani) ohani tim, ze tam mame svoje indexy a ze je to pomale kvuli nim(inserty samo). Ale kdyz tam ty indexy nebyly, bylo to jeste 100x pomalejsi(na vsem ostatnim, protoze selecty) . Minuly tyden se samozrejme jedna nejmenovana odbornice pres databaze (select je pro ni sprosty slovo) vyjadrovala v tom smyslu, ze indexy nicemu nevadej a na namitky, ze to zpomaluje inserty rekla "ale jenom trochu". Mno ono u 120GB databaze to bude asi "trochu vic" .

Jinak celkem standard. Sefko dodavatele se svoji ekypou nasliboval, jak vsechno do dnes vyresi a dnes se po 15:00 ozval nakej jejich mamlas a ptal se, co ze to vlastne ma resit a plkal, ze sme nerekli co konkretne je pomaly (trace z databaze s odchycenymi 30s query mu je zrejme malo). Je uplne jedno s kym od nich se budeta bavit, pokud je to obchodak/managor, naslibuje vsechno. Pokud je to kdokoli jinej, posle vas doprdele. Jediny co uz od minulyho tejdne resej je, kde najit duvod nefunkcnosti na nasi strane (pro sychr mame HW dimenzovanej min 10x vejs, nez byly jejich pozadavky pro danej pocet useru). Navic pres nekolikere upozorneni ze se bude testit vykon systemu si nerekli co kde mame pozapinat a ted se ohanej tim, ze nemaj logy.

BTW: Pro znalce. Zkuste si predstavit insert, kterej obsahuje cca 5ti az 10ti nasobnej case + takovych 5 subselectu + joiny pres varchar ... taky vam vstavaji vlasy hruzou ? Vase nocni mura ? Ale kdeze, to je tak prumernej stav tohodle zazraku.

[wong]

Mno ... pouziva to dcerinka CEZu I&C Energo ... maji tusim 10k zamestnancu (zajistujou servis pro CEZ) .... nechapu jak stim muzou zit. Sice v tom asi nedela moc lidi zaroven, ale pocitaj jim v tom vejplaty.

Nejsme uz dcera CEZu a zamestnancu je cca 1500. Kdyz se pocitaji vyplaty, tak je system naprosto nepouzitelnej a neda se s nim normalne delat.

[Jezevec]

2wong: kdyz sme byli na navsteve (uz to bude tak 2 roky), tak nam tvrdili, ze vejplaty pocitaj 3 dny v kuse . Jinak ze si sem tam nekdo vyrobi objednavku na dily.
2petrik: dve ctyrjadra + 64GB RAM ti prijde malo ? + SAN cx3-10 (FC, SQL ma pro sebe dokupy 18x 15k disk v R10) ?

[wong]

Jezevec: ano tak nejak to je, proto jsem opravoval pocet zamestnancu...

[Petrik]

2petrik: dve ctyrjadra + 64GB RAM ti prijde malo ? + SAN cx3-10 (FC, SQL ma pro sebe dokupy 18x 15k disk v R10) ?

Hm, vsadim se, ze kdyz se zbavite toho SANu a nahradite ho jednim, nebo nejlepe nekolika X25-E/M s dobrym HW RAIDem R10, tak se vykon zmnohonasobi, tedy za predpokladu ze se neco z tech disku vubec taha. SAN ma totiz jeden problem a tim jsou latence. Porovnej latence FC (tedy neco ala ethernet) vs. lokalni SATA/SAS disk/SSD. Navic tech 15k disku vpoli muzes mit treba milion, ale latence budou porad radove horsi nez u jedineho SSD. V jedne firme jsem udelal obyc server s raptorem a 16GB RAM a oracle na tom behal rychleji nez na nejakym brutalnim IBM POWER serveru a to jen kvuli tomu, ze tam bylo nejaky hyper mega ultra SAN pole (celkem za miliony), ktery bylo desne pomaly...

SAN ma podle me smysl u clusteru, kdy to bez nej nejde (jde, viz google ), ale pro jeden server existuji lepsi vecicky a vyrabi je napr. firma Fusion-iO

http://www.fusionio.com/products/iodriveduo/ tahle hracka uz asi neco zvladne

NAND Type Single Level Cell (SLC) Multi Level Cell (MLC)
Write Bandwidth 1.4GB/s (32K packet size) 1.0GB/s (32K packet size)
Read Bandwidth 1.5GB/s (32K packet size) 1.4GB/s (32K packet size)
IOPS* 185,022(4K read packet size)
129,699(75/25 r/w mix 4K packet size) 122,601(4K read packet size)
121,008(75/25 r/w mix 4K packet size)
Access Latency <50µs Read <80µs Read

Mimochodem tohle DUO ma dvojnasobne latence nez "single", ktery ma 26µs, coz je proste mazec. To uz ma bliz k RAMce, nez k diskum.

Dalsi vec je pocet jader a skalovani vykonu. Nezapomenu, jak jsem do onoho obyc serveru s oraclem dal misto 3GHz dualcore 2.9GHz quadcore a vykon sel kam? vykon sel do kytek (4x pomalejsi), protoze vsemocny buh Oracle zvolil nejaky suboptimalni algoritmus nebo co a pomohla az nova verze Oracle serveru... jen mimochodem v te dobe jsem o SQL nemel ani paru, ten Oracle resil jeden dost zkuseny DBA..

Netusim jak je na tom MS SQL vs. skalovani vs. multithreading, ale napr. vim, ze MySQL pro jedno spojeni pouziva jen jedno vlakno, takze jader muzu mit treba deset a je mi to prd platny (proto ho provozuju na OC dualcore).