ano aj, ale mna vyrusuje to ze uz tri mesiace je zrejme ze ockovanie je vyznamny politicky problem a je schopny odstrelit dalsieho ministra. A napriek tomu sa nekona ziadne krizove riadenie, nikto sa nehadze na bodaky, cela vlada sa tvari ze problem vlastne neexistuje. A toto sa deje pri probleme kde to vsetci vieme, co potom tie co sa nedostali do novin a ich dopady su daleko v buducnosti?
1 Like
Neviem,neviem, Slovenkso nakupilo HW viac ako potrebuje na tie beziace aplikacie, vladny cloud je podla mna slabo vyuzivany a priestoru na beh aplikacii je tam dost, ci?
Pokial viem, tak @jsuchal realne cisla o vyuziti RAM, CPU, storage, … v gov cloude zhana uz dlho, ale stale ich nema(-me).
To vyjadrenie NCZI vnimam ako potvrdenie tych anekdot z OPIS, ze teda HW sa kupoval ako prvy a teda v case dokoncenia/uvedenia do prevadzky (t.j. cca 2-3 roky po zaciatku implementacie, radovo 5+ rokov po uvodnych analyzach a dizajne) je uz zastaraly, nepostacujuci alebo oboje. Podobnu skusenost ma vlastne NASES s UPVS.
Nuz a teda aj ja by som tie statistikyrealneho vyuzitia egov clodu videl rad prave preto, aby som si mohol byt doststocne isty, ze jeho navysenie bude riesenim napr. pre ten problem, ktory popisuje NCZI.
lenze to je stale rovnaky problem, dobre vieme (aj ti co sa tvaria ze nie) je ze vo vladnom cloude je alokacia na zelezo. To ze tam nieco bezi a nespotrebuje vykon na 90 percent, to neznamena ze tam bez problemov moze byt instalovane nieco dalsie. “Realne cisla” neprezradia aka je kapacita, len to ze tam je nejaky optimalizacny potencial.
A na problem ze realne kapacity nie su narazil aj NASES aj NCZI. Nedostatok kapacit tak riesili nakupom vlastneho HW. A navyse to ze sa nenavysil HW v ecloude znamena ze keby sa naozaj mali realizovat projekty OPII, tak to nebude kde nasadit.
A k “anektodam”, vacsina projektov sa realizovala zhruba za 2 az 3 roky, prakticky sa HW doviezol tak pol roka po podpisani zmluvy a jeho nasadenie trvalo dalsi pol rok a to uz tlacil na cas na integracne testovanie. Toto mozeme tak zaradit medzi bajky akych o OPISe beha plno.
NASES narazil na uplne iny problem, vlastne vsetci co do cloudu nieco niekedy chceli dat, tak narazili na uplne ine problemy. Mimochodom to, ze MV tvrdi, ze je plno este naznamena, ze je naozaj plno je. MV sa proste neveri ani nos medzi ocami, pokial ide o cloud.
Toto dnes nie je ziadnom o optimalizacnom potenciali 
toto je proste o tom, ze si kazdy vypytal kolko chcel, lebo to je zadarmo a MV to neriesi lebo “oni su prevadzkovatel, nie optimalizator a ich nezajima co tam ako a kto bezi”. Ja uz fakt nechapem, ako sa dnes este niekto dokaze s plnou vaznostou tvarit, ze toto nie je problem c. 1.
Cloud ma vyzerat ako cloud. Ma byt v prvom rade elasticky s moznostou navysovania vykonu v ocakavanych spickach … inak to nie je nic ine, len cudzi pocitac, kde mi bezia aplikacie a kde mam ulozene data. A to este s divnymi pravidlami vrstiev, firewallov a sietovania.
3 Likes
Ano, ale plus tam maju byt aj SW sluzby a aj snaha o zjednotenie platforiem atd.
to vsetci vedia, len sa musis k tomu prepracovat, inak to konci nakupom hw a budovanie infrastruktury ktora bude uz nadlho mimo
Vedia, vedia, akurat to tak realne nie je …
ved jasne, ale teraz to je skor o tom ze sa nevieme nikam dostar
To velmi nepomoze, ak aplikacie, ktore tam maju byt prevadzovane, nie su pripravene na prevadzku v cloude. Klasicky pripad su SQL-databazy, tam bez zmeny aplikacie pomoze iba
- pridanie CPU => to vsak ma fyzicke limity na pocet socketov
- pridanie IO => tu si limitovany zbernicou / priepustnostou ku diskom
Zmenit databazove ulozisko pre aplikacie z SQL na nieco ine/distribuovane je velmi vyrazny zasah do architektury aplikacie.
Taktiez vsak plati, ze maloktory egov system si nevystaci s klasickou SQL databazou.
Vynimka potvrdzujuca pravidlo : eZdravie si podla mna nevystaci s klasickou SQL-databazou.
VsZP ma za mesiac 22 milionov riadkov iba vo fakturach.
Pridaj ku tomu Doveru a Union, vynasob to troma ( lebo objednavka / vysledok / faktura ). Sme na 100-milionoch zaznamov mesacne.
Labaky vraj vyprodukuju pol-miliona zaznamov za doobedie ( spicka 8:00 → 12:00 )
Data nestaci iba zapisovat ( to by stacilo ukladat na nekonecny disk /dev/null ). Tie data je potrebne citat. Je potrebne zabezpecit kvalitu dat, t.j. vytvorit automatizovane kontroly a spustat ich vzdy pred zapisom dalsich udajov.
Toto SQL-neda…
A preco by to SQL nedalo? To SQL bezi na nejakych inych diskoch ako to NoSQL? Nejake ine datove struktury tam pouzivaju?
Facebook bezi na shardovanej MySQL, rusky yandex bezi na postgresql, potom su tu riesenia ako citusdb. Aurora od amazonu vyskaluje do 128TB. Ja osobne spravujem db s miliardami zaznamov v postgresql.
O com sa tu rozpravame?
Problem nie je SQL ale transakcny vykon. A suhlasim ze to narazi na vertikalne skalovanie a prechod na horizontalne skalovanie znamena prekopat architekturu.
Nie nutne. Uplne bezne sa da transakcny vykon skalovat tak, ze sa pred to postavi nejaky loadbalancer, porobia sa repliky na citanie, urobi sa partitioning/sharding na strane db. Ak to nativne db podporuje, tak aplikacia sa o tom ani nemusi dozvediet. Ak vsak niekto od zaciatku predpokladal, ze read a write pojde do tej istej masiny na veky vekov, tak … ano treba prekopat architekturu, ale problem by som hladal inde ako v tej architekture.
SQL nema horizontalnu skalovatelnost, t.j. nemozes skalovat vykon hore/dole podla zataze iba tym, ze budes pridavat/odoberat nody.
Skalovat vertikalne mozes iba po fyzikalne hranice ( pocet socketov, priepustnost zbernic ). Pri tych objemoch udajov pohoris na hlbke indexov a pocte IO-operacii pri citani indexovych/datovych stranok.
NoSQL pouziva ine datove struktury, takze na rovnakych diskoch mozes dosiahnut pre niektore operacie lepsi vykon. Nie je to vsak zadarmo, aplikacia musi pocitat s vlastnostami daneho uloziska. Pricom castokrat to riesia aj umyselnym duplikovanim udajov, tak aby bolo konkretne citanie co najrychlejsie.
Synchronne alebo asynchronne repliky ?
Synchronne => kazda replika spomaluje zapis.
Asynchronne => musis riesit konflikty => dopad na logiku aplikacie
Navyse nejako musis riesit aj skalovatelnost pre zapis, nie iba citanie.
Ten partitioning/sharding zrealizujes kedy ? Pri pociatocnom navrhu aplikacie ?
Ako odhadnes potrebnu velkost / pocet shardov / replik, ak vies ze udaje pre kazdeho pacienta mozes zmazat najskor 20-rokov po jeho smrti.
Nakupit HW s vyhladom, ze ho budeme pouzivat este o 100 rokov, nie je velmi rozumne.
Ako zmenis partitioning/sharding v beziacej aplikacii ? Idealne za jazdy bez odstavky.
V pripade eZdravia mas pravdu. Primarny problem pomalosti nie je SQL, ale bezpecnostna feature, kedy pre nacitanie udajov jedneho pacienta musi prebehnut niekolko desiatok sifrovanych sietovych SOAP volani.
Ked odstrania tuto pomalost, a konecne sa rozhodnu, ze pridaju aj validaciu vstupnych dat, az potom zistia, ze SQL-nestiha. Zadanie je : Za menej ako pol-sekundy je potrebne vyhladat/nacitat 1300-riadkov pre jedneho pacienta a presunut ich na aplikacny server, aby mohol za dalsiu pol-sekundu zrealizovat kontroly.
Mozem. Na read replikach to uplne bezne robievam. Na write to moze byt trochu problem (ale riesi ho napriklad citus hore)
Nie, naozaj nepouziva Hash, B+ tree, linked zoznamy, inverted index, spatial… vsetko ma aj trebars postgres.
Hej, v relacnych databazach to volame indexy, clustered tables s tym rozdielom, ze sa o tomto aplikacia ani nedozvie.
A toto ako presne riesi nosql? Uplne tak isto. Niekde moze byt synchronne, niekde asynchronne, niekde quorum.
Uplne lahke to nie je, ale da sa. Vid hore citusdb.
Ukoncil by som tuto vsuvku tym, ze problem nie je SQL ci relacna db. Problem bude skor v tom, ze potrebujes odrazu multi master zapis. Nieco sa da vyriesit uplne v pohode transparentne voci aplikacii aj za jazdy, nieco nie.
1 Like
Replikujes celu DB alebo iba shard ?
Ak celu DB => tak to pojde dost do penazi za disky/servre.
Ak shard => musis definovat a udrziavat sposob rozdelenia shardov (pravdepodobne manualne => s rizikom zanesenia chyby)
https://db-engines.com/en/article/Wide+Column+Stores
https://db-engines.com/en/article/Document+Stores
Pricom zapisy Ti postupne rozbijaju cluster table/index takze raz za cas musis reindexovat ( recluster ).
To nie je rozumny napad stavat aplikaciu bez ohladu na vlastnosti uloziska.
Ide o koncept ako sa vysporiadat so vzajomne si odporujucimi si poziadavkami aplikacie. Po case aj tak skoncis s tym, ze v aplikacii budu dopisane hinty, predpisujuce pouzitie konkretneho indexu.
Stary databazovy svet hovori : “Disky su drahe, praca programatora je lacnejsia”
Preto mame Boyce-Codd, tretiu, stvrtu normalnu formu a v SQL-svete sa snazime minimalizovat mnozstvo ulozenych udajov.
Novy (big-data) svet to otocil naruby a hovori : “Disky su lacne, praca programatora je draha”. Vysledkom je, ze z toho velkeho mnozstva udajov vytvorime este vacsie, pretoze mame viac kopii dat ulozenych vo formate vhodnom pre rychle citanie predspracovanych dat. Udrzba viacerych kopii je vsak v casovom rozpore s poziadavkou na “consistency”.
Dalsim rozdielom je ako prebieha spracovanie dat.
- trojvrstvova architektura presuva udaje po sieti medzi klientom ↔ aplikacnym serverom ↔ SQL-serverom ↔ diskovym polom
- cloud architektura (napr. Hadoop/Spark ) presuva algoritmus ku datam
Kedze algoritmus je mensi ako mnozstvo dat, tak usetris cas na sietovych volaniach.
Ako ktore noSQL. Zalezi od toho akeho je typu podla CAP-theoremy.
SQL je typu CA ( Consistency - Availability )
Cassandra je AP ( Availability - Partitioning )
Mongo je CP ( Consistency - Partitioning )
Pri navrhu algorimov nemozes ignorovat vlastnosti uloziska.
O tom to je.
Ak je to zlozite a drahe ( == spotrebuje to programatora/experta s rizikom vypadku celeho systemu), tak sa tomu budem snazit v prevadzke vyhnut.
Ak je to lacne ( == disky ), tak to nikto riesit nebude, hlavne je aby to fungovalo.
Pre aplikaciu (eZdravie), ktoru pouziva 30-tisic lekarov a 5-tisic lekarni po celom Slovensku ocakavas aku dostupnost ? Ja som cakal master-master v geograficky vzdialenych serverovniach.
Slovenske eZdravie pokial viem nema ani master-slave ( na slave nevydali peniaze ).
Poliaci uvazovali o master-slave s prepnutim do hodiny. Hodinovy vypadok pocas ordinacnych hodin zastavi lekarov na ambulanciach ale aj vydaj receptov v lekarnach 
Navyse prevadzkovat “slave” na ktory vacsinu casu iba pada prach je celkom drahy luxus.
Problemom master-master je poziadavka na “consistency”. Co sa stane ak uvedomely bagrista prekopne kabel medzi serverovniami ? Ktory z nich zostane master ? Ktore zapisy budu platne. Ako to zosynchronizujes, ked znova nadviazes spojenie ?
Privela otazok, ktore je neskoro riesit az ked japonec “sato-pototo”. Toto nema riesenie na DB-urovni, musi sa s tym vysporiadat algoritmus aplikacie. Uz v case navrhu architektury. Ak zrusis poziadavku na “consistency”, celkom dost veci to zjednodusi ale musis to zohladnit v algoritme.
Ja nezavrhujem SQL, ale zaroven hovorim, ze to nie je univerzalne riesenie pre vsetko.