Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

MySql nakon Postgresql-a (rant)

[es] :: MySQL :: MySql nakon Postgresql-a (rant)

Strane: 1 2

[ Pregleda: 3537 | Odgovora: 39 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 14:01 - pre 40 meseci
Imas dva izbora:

- Da nadjes bar nekoliko matoraca koji znaju sta rade i debelo ih platis
- Da gledas kako se desava ovo sto je Bogi opisao i sve se raspada....
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 14:11 - pre 40 meseci
ne mora nesto specijalno da ih plati, ali mora necim da ih privoli da
rade na tom projektu :D
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
p2-115.p59.bvcom.net.



+1064 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 15:30 - pre 40 meseci
Citat:
djoka_l:
Da se ne shvati pogrešno, ja volim da radim u MySql-u. Jbg, nema gomilu stvari na koje sam navikao na Oracle ili pg, ali kad prihvatiš ograničenja, lepo vozi.
Još kad uzmeš koliko si para platio, radi i više nego dobro.

Međutim, insistiranje da logika treba da bude na strani app ne u bazi, u mnogo slučajeva ne pije vodu.
Banalan primer, uzmi slučaj da treba da napraviš neku statističku analizu, razlika je da li ćeš da prebaciš preko mreže 100.000 slogova sa baze na app server, ili ćeš tih 100.000 slogova da odradiš u stored proceduri i vratiti 10 linija rezultata.

Ono što je klasična boljka je da se ne radi, u praksi, dovoljna separacija slojeva.
Realan slučaj, pukne ti insert u Oracle bazu, insert pokuša upis null u not null polje. Uzmeš da debaguješ, nađeš da ti je prethodni sloj poslao slog koji sadrži u svim poljima null. Vratiš se još jedan korak i nađeš roman od exception stacka da je neuspela konverzija u int. Vratiš se još jedan sloj i vidiš da je idiot od programera stavio na formu input polje, gde se očekuje numeric a jbn korisnik je uneo slovo.

Programer nije napravio kontrolu unosa po tipu podatka. Bezvezni podatak je prosledio sledećem sloju, koji, takođe, nije proverio ulaz, on sledećoj proceduri ... pa tako 50 nivoa dok neko nije pozvao konverziju u int. Onda je lepo bibliotečka procedura pukla, programer je uredno uneo u log exception stack, a zatim potpuno ignorisao exception, nego je slog sa neinicijalizovanim varijablama poslao dalje.

Zato ja volim da svoju Oracle bazu "ogradim" gomilom stored procedura, zato što znam da imam programere koji nisu bolji od treniranih majmuna.


Znas kako ja do sada nikada nisam izlagao bazu mrezi, nego je logika u middleware aplikaciji koja cuci ispred baze, pa onda komunicira sa klijentima.
No sad baze mogu da se nose sa 1000+ klijenata pa mogu da razumem ;)
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 15:36 - pre 40 meseci
@branimir, ja mogu da ti potpisem da, ma koliko mozda mogu da rade sa
1000+ klijenata nijedna nije sigurna da bude vidljiva direkt sa mreze
... za mysql i psql mogu dam ruku, a za ostale ti je dovoljno da
pogledas javne cve-ve pa ce ti bude jasno :D ..
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 15:48 - pre 40 meseci
btw vezano za one lose programere, plate etc... savetujem svima da procitaju

http://remaster.ff.uns.ac.rs/m...d_20201109_psi_320029_2017.pdf

bez obzira sto nije vezano za temu direkt... obavezno procitati
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 16:22 - pre 40 meseci
Citat:
Branimir Maksimovic:
Znas kako ja do sada nikada nisam izlagao bazu mrezi, nego je logika u middleware aplikaciji koja cuci ispred baze, pa onda komunicira sa klijentima.
No sad baze mogu da se nose sa 1000+ klijenata pa mogu da razumem ;)

Gledaj, sve i da imas komlpetnu in-database logiku, imaces ispred neki API koji je mnogo lakse obezbediti, a DB server i API server pricaju u privatnoj mrezi, iza firewall-a (switch ili cloud VPC, sve jedno je).
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 21:24 - pre 40 meseci
Ne znam kakve to aplikacije prave oni koji misle da logika u bazi nije potrebna.
Recimo, ako imaš 200 db jobova koji hendluju asihrnone događaje preko AQ mehanizma, zašto tome nije mesto u bazi?
Ako događaj u bazi (commit) treba da okine 20 asinhronih događaja, zašto kod da ne bude u bazi?
Ako treba da sinhronizuješ 50 baza podataka, a da to bude malo "pametnije" od replikacije, zašto ne kod u bazi?

Ne radimo svi forume i on line prodavnice, da bi nam kod u bazi bio luksuz.
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 21:39 - pre 40 meseci
Primer: za jedan posao moraš da obezbediš end-to-end odgovor u roku od 3 sekunde. A takvih poslova imaš 10.000 dnevno.
Za drugi posao moraš da obezbediš 10s end-to-end response, a i njih ima 10.000 dnevno.
Sve to dok ti baza od 3TB ima 100-200 commita u sekundi, 500 aktivnih sesija (od kojih je 50 prema "spolja", webu i drugim eksternim kanalima).

Sada, da šetaš podatke između DB servera i srednjeg sloja, zavisiš od latencije i opterećenja mreže...
Zato sve lepo odradiš u bazi, ono što moraš, uradiš odmah, ono što može kasnije upucaš na AQ BUS pa pozadinski poslovi odrade ostatak posla (koji ne bi stao u one 3s).
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 22:36 - pre 40 meseci
@djoka, postoji veliki broj aplikacija gde ti je app server neophodan...
npr skoro svaki ERP ali iako postoji neki broj ERP resenja koja koriste
MySQL ja bi rekao da je MySQL tu pogresno odabran rdbms.

e sad, sve ovo o cemu pricas je "princip" od pre hrista (ili kako sad
kazu Before Corona i After Corona) i ako pogledas "moderna" SAS resenja
istih sistema koji rade upravo tako (sve je u bazi, van baze je bukvalno
samo shell) can i ERP-ovi nemaju u bazi nikakvu logiku vec je logika
potpuno detached od baze i od fronta i vrlo cesto je cak "serverless" ..
tako da, ne radimo svi webshopove ali ne zivimo svi ni u 20. veku ... a
kada smo prinudjeni da koristimo sistem 20. veka onda za app server ne
biramo MySQL vec nesto drugo :D

potpuno je cudno da sam ja kao neko ko radi za mysql taj koji ovde
govori da mysql nije pravo resenje za sve probleme i da u nekim
slucajevima mysql prosto ne pije vodu
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: MySql nakon Postgresql-a (rant)27.11.2020. u 23:01 - pre 40 meseci
OK, I'll bite:

Job nije u bazi i ne inicira se u bazi - job (skoro uvek) inicira user. Samim tim, ne mozes logiku posmatrati data-centric, kad je aplikacija user-centric. Jednom kad promenis paradigmu, shvatis da je baza ono sto ti je Bogi rekao: state storage koji cuva datu (state) i obezbedjuje mu integritet. Ako razmisljas, ajde da malo parafraziram, na unix nacin, to znaci "do one thing and do it well". MySQL je olicenje toga.

E sad, ako imas trista izmena nad datom koje sve idu odjednom i zajedno, normalno, to je posao nad datom - i radis ga u bazi. Ali, ako imas trista izmena nad trista data, koje nisu (relaciono) vezane - onda nema razloga zasto tu datu ne bi razbio na trista baza (schema, bar za pocetak). Ako imas job queue njemu je mesto u queue softveru (zeroMQ, AMQ, stagod) a ne u bazi. Sta je prednost ovoga: Skaliranje. Ako imas jednu, monolitnu bazu ti po pravilu mozes pisanje u nju da skaliras samo vertikalno. Ako imas mnogo baza i obradu koja je stateless (jer je state u bazi, a obrada uvek radi samo na osnovu inputa) ti obradu mozes da skaliras horiznotalno, a baze su pojedinacno mnogo rasterecenije. Pazi, ovo je potpuno druga paradigma, ali cesto ima dosta prednosti.

Redductio ad absurdum ovog principa je nestruktuirana data. Kao takva, ona je mnogo teza za obradu, ali, ako obradu vrsis na nacin koji je paralelabilan, map-reduce ce ti omoguciti da krajnji rezultat dobijes mnogo brze i mnogo jevtinije. Jednostavno, manje kosta trista masina po 256GB RAM-a i 64 core-a, nego jedna sa 32TB RAM-a 640 core-ova, ako je ova druga manje od trista puta veca (odokoativno 10/100 puta) - posebno ako znas da ove prve mozes, kao commodity, da iznajmis na minut, samo koliko ti treba, a ova druga, ako i ima da se kupi, kosta milione.

Ne kazem da su velike baze zastarele. Ima primena gde imaju smisla, gde sva data jeste povezana i tu nemas puno izbora. Ako porastes dovoljno, javice se neko da ti proda Exadata za to, za lepe pare i Oracle stvarno radi vrhunski te sisteme. Stavise, to sad cak ima i kao cloud. Ali, ako mozes da skaliras horiznotalno, uvek ces biti u prednosti, zato treba razmisljati o tome na vreme.

BTW, mysql bez problema ima desetine hiljada insert/update upita u sekundi na masini koja kosta par stotina EUR mesecno. E, ali taj mysql (konkretan, sad ga nesto gledam) nema trigere, nema stored procedure, sve to je prebaceno na aplikativnu logiku. Biznis logika je u aplikaciji. Baza radi svoj deo i radi ga fantasticno brzo, a sporiji i zahtevniji deo posla je na aplikaciji koja moze da se - paralelizuje.

Opet, kazem, slazem se da ima primena gde je database-centric prava mera, ali, ako mozes, uvek je bolje to izbeci.
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 02:07 - pre 40 meseci
Radio sam sa kontejnerima i mikroservisima.
Kada aplikaciju razbiješ na 100 mikroservisa, a uptime svakog od njih je 99%, znaš kolika je raspoloživost sistema?
36%

Ako napraviš monolitnu aplikaciju, db centric, a raspoloživost baze je 99% dobiješ raspoloživost sistema od 99%
Osim toga, gubi se gomila vremena kad se sistem razbije na puno mikroservisa na komunikaciju između njih, ne samo zbog konačnog truputa mreže i latencije mreže, nego i zbog konstatnog konvertovanja podataka kojima se komuniciraju poruke između servisa (ono, imaš int podatak, konvertuješ u JSON, pa JSON na drugoj strani konvertuješ u int).
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
p2-115.p59.bvcom.net.



+1064 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 05:52 - pre 40 meseci
Citat:
djoka_l:
Primer: za jedan posao moraš da obezbediš end-to-end odgovor u roku od 3 sekunde. A takvih poslova imaš 10.000 dnevno.
Za drugi posao moraš da obezbediš 10s end-to-end response, a i njih ima 10.000 dnevno.
Sve to dok ti baza od 3TB ima 100-200 commita u sekundi, 500 aktivnih sesija (od kojih je 50 prema "spolja", webu i drugim eksternim kanalima).

Sada, da šetaš podatke između DB servera i srednjeg sloja, zavisiš od latencije i opterećenja mreže...
Zato sve lepo odradiš u bazi, ono što moraš, uradiš odmah, ono što može kasnije upucaš na AQ BUS pa pozadinski poslovi odrade ostatak posla (koji ne bi stao u one 3s).


Ne znam, ja sam do sada radio srednji sloj da bi zastitio bazu od downtime-a, naime baza nije mogla da opsluzi...
 
Odgovor na temu

dejanet
Beograd

Član broj: 19240
Poruke: 1181



+835 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 09:02 - pre 40 meseci
Citat:
bogdan.kecman : "velika separacija slojeva" je kao i "agile sistem" i mnogo sta moderna
buda...stina... da ne ulazimo sada u detalje ima vise nego dovoljno
analiza toga zadnje dve tri godine kada se dovoljno ljudi opeklo, raditi
bilo sta na silu zato sto "tako pise u nekoj knjizi" je .... primer koji
si dao nije problem separacija slojeva nego lenstine koje ne rade
kontrolu greske i kontrolu date ... vec je "u apiju pise da uvek vraca i
ja ocekujem da UVEK vraca" .. i slicni junoski stavovi koji se onda u
manjku kvalitetnog kadra promovisu u seniore bez realnog znanja i
iskustva i onda imamo "seniore" koji pisu takav kod


Citat:
djoka_l: Kada aplikaciju razbiješ na 100 mikroservisa, a uptime svakog od njih je 99%, znaš kolika je raspoloživost sistema?
36%


Izvinjavam se ako sam izvukao iz konteksta, posto bolje ne mogu da napisem od ovoga gore
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 10:19 - pre 40 meseci
Citat:
djoka_l: Radio sam sa kontejnerima i mikroservisima.
Kada aplikaciju razbiješ na 100 mikroservisa, a uptime svakog od njih je 99%, znaš kolika je raspoloživost sistema?
36%

Ako napraviš monolitnu aplikaciju, db centric, a raspoloživost baze je 99% dobiješ raspoloživost sistema od 99%

Ima ovde dve stvari:

- Ako je uptime svakog od 100 servisa 99% i AKO SVAKI IMA DOWNTIME U RAZLICITO VREME uptime celog sistema je 36%
- Uptime od 99% je mozda OK za jedan kompleksan sistem, uptime od 99% je katastrofalno lose za mikroservis koji ima jedan prost task. :) Vreme da restarujes kompleksnu bazu, tipa prost update-and-reboot za DB server ti oduzme pola sata. Vreme da uradis redeploy mikroservisa koij samo radi login (cita iz baze, vrati token) ti napravi downtime od oko 30s, plus ako imas vise od jedne instance servisa, realni downtime pri deploy/udpate je nula.

OK ti je matematika, samo mnogo pretpostavljas. Vecina sisetema ima mnogo bolji uptime od 99% - posebno prostih.
Citat:

Osim toga, gubi se gomila vremena kad se sistem razbije na puno mikroservisa na komunikaciju između njih, ne samo zbog konačnog truputa mreže i latencije mreže, nego i zbog konstatnog konvertovanja podataka kojima se komuniciraju poruke između servisa (ono, imaš int podatak, konvertuješ u JSON, pa JSON na drugoj strani konvertuješ u int).

Ovo je zapravo mnogo bolji argument. Apsolutno si u pravu. Ja i ne kazem da je sve dobra meta za mikroservise - stavise ja tvrdim da mnogo toga NIJE dobra meta za mikroservise. Layered monolit je super model, laksi je za rad, bolje funkcionise. Ali :

- Monoliti lose skaliraju. DB centric monolit katastrofa skalira - jer skalira samo vertikalno.
- Monolit koji ima logiku u aplikaciji i dalje bolje skalira jer, ako je aplikacija stateless, a state drzi u bazi (koja samo obezbedjuje data storage i referencijalni integritet, kao sto je gore Bogi lepo rekao), ti bar mozes da skaliras aplikativni sloj horizontalno.

Cak i izuzimajuci mikroservisknu arhutekturu (koji sam naveo kao svodjenje na apsurd, tj. ekstremni slucaj), i dalje se logikom u bazi gubi skalabilnost sistema. Monolit sa logikom u aplikaciji skalira bolje od monolita sa logikom u bazi. Dodatno, ako je domenska logika u aplikaciji, a aplikacija je takva da je vecina obrade podataka citanje, izmestanje logike u aplikaciju ti omogucava da iz aplikacije kesiras podatke kad se koriste samo za citanje (prezentaciju korisniku) i time dodatno ubras celu stvar. Dalje, ako je aplikaciaj stateless, ili cak ima shared state storage, ti mozes da imas vise od jedne instance u startu - i da imas tako implementiran high availability. Implementirati multi-master high-availability na bazi i sistemu koji je db-centric jeste moguce, ali je jako, jako skupo.

Moj argument protiv db centric sistema nije vezan za to da li je to "dobar" sistem - samo da je skup u startu i da jos skuplje skalira. Ti pricas o sistemima koji imaju 50 transakcija u sekundi, ja pricam o sistemima koji imaju 5000 ili 50,000.
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
p2-115.p59.bvcom.net.



+1064 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 10:41 - pre 40 meseci

Nikola:"izmestanje logike u aplikaciju ti omogucava da iz aplikacije kesiras podatke kad se koriste samo za citanje (prezentaciju korisniku) i time dodatno ubras celu stvar."

Pa to recimo imas izvlacenje mesecnih/godisnjih izvestaja koji uzimaju po 15 minuta do pola sata po queriju. I ono 10-20 klikova i baza je neupotrebljiva.
Lepo sam stavio da kesira, moze kolko hoce klikova jer onda treba samo jedan query na n klikova ;)
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 10:50 - pre 40 meseci
@djoka, moz bidne a ne mora da znaci :) .... ti pricas o sporom
glomaznom inertnom sistemu poput nekog erp-a u nekoj delti... ja vec 15
godina zivim od sistema gde minuti downtime-a znace milione gubitka i
99.0% se ne smatra u prihvatljivu cifru, prihvatljivost krece od 5
devetki na gore i tu se racuna i "planned maintenance" .. znaci sve sa
planiranim downtimeom moras da imas 5 devetki, dakle stvari poput online
upgrade i online backup su stvarnost a sistemi nisu tromi poput nekog
erp-a vec vrlo dinamicni i obradjuju u minuti vise date nego jedan erp
za godinu dana :D .... sve ima svoje, TOC je vrlo kompleksna stvar,
koliko kosta sw, koliko kosta hw, koliko kosta odrzavanje, koliko kosta
razvoj sto u ljudstvu sto u vremenu ... tu je nekad cena samog rdbms-a
ili apps-a potpuno nevazna (iako je u milionima npr) ... ali zato ultra
fancy support za mysql bez ndbcluster-a kosta 5000$ godisnje sto je
priznaces pateticno obzirom na benefit koji dobijas (to ti je jedna
mesecna plata prosecnog dba) dok recimo ista firma za mysql ndbcluster
support naplacuje isti OD 40,000$ godisnje (startna cifra je 40k i ne
ukljucuje mnogo toga) .. a mogu ti kazem da je prosecna cifra koju moji
klijenti placaju za support (tj da imaju pristup meni i par mojih
kolega) oko 10,000,000 godisnje :) ... nemam ideju koje su cifre za
oracledb, exadata, db2...

takodje sve i da pricamo o 99% a ne o bar 99.999% opet ti je matis za
36% los :D posto opet zavisi od toga kako si dizajnirao sistem :) ...
100*95% moze da bude 100.00% a moze da bude 10% zavisi kako je sistem
dizajniran

% su statistika, realnost je da je recimo jedan klijent imao 100% uptime
10 godina i onda je, ljudskom greskom, imao downtime 3.5h ... steta oko
15 miliona evra, i to im je poje4$#@$ uptime na 99.996%  ... tako da je
sad pitanje kako to racunas, dal samo tu godinu, ili svih 10 godina
koliko sam ja zaduzen za njih, ili racunamo 15M stetu ili ne racunamo
uopste posto je sistem ok nego je doso tenkre i zas123 motku ili ...
kako racunas uptime % kada teroristicki napad u usa ugasi 10 data
centara od ukupno 20 na celom kontinentu (bilo davno) ili kada jedini
kabl izmedju usa i evrope bude presecen?.... tako da .. je...es
procente, gledas sta ti je SPOF, DPOF, gledas kako da se zastitis od
seniora iz kine, indije, srbije .. uplatis jednom godisnje neki dinar
pravoslavnoj, katolickoj, budistickoj, islamskoj, jevrejskog i svim
ostalim crkvama koje nadjes zlu netrebalo ako se desi da je neka od njih
ipak u pravu ko zna mozda pomogne, i to je to .. i pre svega dobro
dokumentujes ceo sistem ukljucujuci sve procedure i nadas se najboljem
:) ..
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 11:02 - pre 40 meseci
> Pa to recimo imas izvlacenje mesecnih/godisnjih izvestaja
> koji uzimaju po 15 minuta do pola sata po queriju.
> I ono 10-20 klikova i baza je neupotrebljiva.

napravis lepo read only repliku koja je uvek up2date a nad kojom vrsis takve smaracke upite i bole te uvo sto si zabo tu instancu baze na X sati ... to je jedan od glavnih razloga zasto neke aplikacije koje bi imale ozbiljan benefit od psql-a ipak koriste mysql jer psql replikacija tek zadnjih godinu dana "donekle radi" a i to je pateticno a neke ozbiljnije stvari poput group replication, innodb cluster, galera i slicno psql jos uvek moze samo da sanja ..

dodatno, na zalost samo na cloud verziji mysql-a, postoji rapid engine koji radi kao shadow engine iza innodb-a i optimizer bira da li da izvrsi upid nad jednim ili drugim se te olap i slicni reporting upiti rade gzilion puta brze na petabajtnim podacima... nesto sto bi normalno gurao u redshift ili neki map reduce sada mozes direkt iz mysql-a ... no, ko sto rekoh, na zalost samo na oracle cloudu... no cena je takva da ima smisla... imas za mariju columnar se koji pokazuje da ce mozda biti iskusan u buducnosti no glavni developer je zapalio u prijatniji tim za rad pitanje sta ce biti sa tim.. a ko zna, mozda rapid dodje na on-prem, jednom, ako ne foss onda bar za $$
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
p2-115.p59.bvcom.net.



+1064 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 11:13 - pre 40 meseci
Bogdan:"napravis lepo read only repliku"

Da al, i nad tom replikom ce da potraje ;)
Mislim da je cache u ovom slucaju bolje resenje zato sto prakticno dobija iluziju da to traje na nivou milisekunde..
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 11:15 - pre 40 meseci
vezano za procente, evo jedan primer iz realnog zivota

mysql cluster ima

 - management nodove

 - data nodove

 - api nodove

management nodovi su bitni u slucaju starta sistema, sistem ne moze da
startuje bez njih i novi nod ne moze da se prikljuci klasteru ako mgm
nodovi (bar jedan) nije prisutan, oni rade i logovanje ali realno ako
bar jedan mgm nod radi sve je ok, ako svi nodovi crknu novi "ne mgm" nod
ne moze da se prikljuci klasteru i nemamo logovanje

data nodovi cuvaju i isporucuju datu, u grupama su po dva znaci uvek ih
je paran broj i dokle god je grupe od dva jedan radi klaster je
dostupan, ako umru 2 iz iste grupe cluster je down ... znaci ako imamo
100 data nodova moze 50 da crkne i da sistem bude up a moze 2 da crkne i
da sistem bude down, zavisi "koja 2" crknu ...

api nodovi su tvoja aplikacija

i sad, imamo americki nosac aviona koji koristi mysql cluster u sistemu
navigacije, ne radi mysql cluster i nosac gubi navigaciju i upravljanje,
recimo da je to bitna stvar za jedan nosac aviona, meni zvoni telefon u
neko nevreme, umro je klaster na nosacu aviona i sve je otislo u .!.

resimo problem, ne bude nista strasno, steta nula, radimo postmortem

0. imaju setup sa 4 mgm noda, 4 data noda i brdo api nodova

1. crko im je jedan mgm nod pre 6 meseci, jedan mgm nod pre 3 meseca i 1
mgm nod pre mesec dana, rade sa samo jednim mgm nodom - ok za sistem ali
admin ignorise mrtve nodove mesecima!!!

2. crko im je jedan data nod pre 6 meseci, admin ignorise to da mu jedan
data nod mrtav 6 meseci!!!!

3. sad im je crko drugi data nod u istoj grupi i klaster je down

koji je planirani uptime ovog sistema i ko je kriv? onaj ko je
dizajnirao sistem ili pajser koji je trebao da pazi na njega al je
navikao da "to radi sta god da mu se desi" pa ga je ignorisao do
"sledeceg revampa u portu"
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: MySql nakon Postgresql-a (rant)28.11.2020. u 11:43 - pre 40 meseci
@branimir, ja pricam o delu "zabodes bazu i ona bude..." .. napravis
repliku i pevas .. kesiranje je cool ali ne moze uvek jedna read-only
replika za potrebe reporta, bekapa i slicno je uvek mega korisna :D
 
Odgovor na temu

[es] :: MySQL :: MySql nakon Postgresql-a (rant)

Strane: 1 2

[ Pregleda: 3537 | Odgovora: 39 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.