Linux ili apgrejd na Win 10?

Ma znam, ali to je bilo pre 10+ godina :) . Malo se promenilo.... Taj API je bas jako brz.

Drugo i bitnije, za ono od malopre: JAko je bitno kako tune-ujes i mysql i posgrers, i storage ispod njih. Default config koji dolazi uz njih nije isti, mysql jos uvek dolazi sa configom koji trosi nesto smesno memorije sve sa ciljem "da radi na svemu", psql je malo, ali vrlo malo bolji - a on ima i vise da se podesava. Sustina je: Nijedan od tih tvojih default nije u produkcionom podesavanju. Tvoj "brzi test" je samo to - brzi test. Mogu verovatno i jedan i drugi dosta brze ako se podese da budu sami na masini i da je potrose do kraja. Dodatno, struktura baze je bitna, nije isto insert u tabelu sa jednim i nijednim indexom, pitanje je kako ih pravis, kako se oni snadju.... Evo, sad gledam neke dve masine, jedna mi izvlaci 560 inserta u sekundi, a to je onako, prilicno krs sprava - neki i7-7700, 64GB RAM, na Hetzneru, sa obicnim Micron SATA SSD-ovima.... Nista specijalno masina, 50EUR/mesecno. To su cisti inserti, samo to gledam na grafiku. Pri tom, opet, nikakvo znacajno opterecenje. Nemam disk I/O na tom grafiku, ali to je SATA a CPU je oko 1%... I to je jos MySQL 5.6, Percona.

Moze MySQL dosta da izvuce, nije frka. :) Ova druga masina je malo jaca, Xeon W-2145, 128GB RAM i 4xNVMe u RAID10. Ta jede za dorucak ovu prvu. Ona bez problema gura par hiljada insert/s i ne znoji se.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

"Moze MySQL dosta da izvuce, nije frka. :) "

Moze, ali ni blizu tps-a kolko treba za sajt sa milionima korisnika. Znaci klasika middleware koji ljusti u neki svoj engine, a onda na batch procesiranje u bazu.
Kolko uopste sad mysql moze da hendluje konekcija?

Ali nemas ti milione konekcija :) . Facebook ima fazon 50 datacentara po celom svetu, nisu svi korisnici u jednoj bazi. Plus, vecina korisnika ne PISE u bazu, ako u bazi drzis korisnike, onda ti samo CITAS kad se on uloguje, i odma to zakesiras. Pises samo kad menja ime, password tako nesto.... Nije to toliko strasno koliko se na prvi pogled cini. Mislim da moze i do fazon 100,000 da ide max_connections, ili nesto bas veliko, ali, vodi racuna i o tome, ti mozes mnogo toga kroz jednu konekciju da guras. Takodje, jedna konekcija moze vise od jednog upisa u sekundi, moze desetine ili stotine.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

"Mislim da moze i do fazon 100,000 da ide max_connections, ili nesto bas veliko, ali, vodi racuna i o tome, ti mozes mnogo toga kroz jednu konekciju da guras. Takodje, jedna konekcija moze vise od jednog upisa u sekundi, moze desetine ili stotine. "

Hm, da mozda ne mislis na neku ozbiljnu bazu a ne mysql? Sva moja iskustva sa mysql je da za takve stvari treba ozbiljna baza...

Branimire, ima kung fu majstora sa većim znanjem i iskustvom od tvojih iskustava.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Mysql/MariaDB je jako napredovala u zadnjih 7-8 godina...
Meni je isto bilo muka i sve sam uvijek htio na postgresql prebacivati, danas stvarno nema potrebe, MySQL čak bolje handlea veći broj konekcija i veći traffic dok Postgres bolje handlea kompliciranije queryje, za high traffic web je MySQL/MariaDB bolji odabir (IMHO).

Ovo je i moje iskustvo. Od 5.5, a posebno od 5.7 MySQL je potpuno ozbiljna baza. Ovo u verziji 8 je vec prica za sebe, imam je u produkciji ali ne jos na high traffic sajtovima. :) Trebalo je da ide, ali Corona, bla bla.... MySQL 8 - bombonica od baze. Svasta nesto ima lepo, radi k'o zmaj.

I da, PgSQL jeste i dalje bolji kad imas kompleksnu in-database logiku, ali za brdo konekcija MySQL odlican. Realno, za bas brdo prostih upita, MySQL je bolji nego Oracle Database, po mom iskustvu - sve dok tu nema slozenih Join-ova i tako toga.

Inace, nemam vise iskustva od Baneta (znamo se IRL), samo sam eto vise tuneovao baze... od kad ne radimo zajedno, nekih 9 godina, bukvalno svaki posao mi je tune-ovanje MySQL-a za high performance. :) Nakupi se....

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

https://www.8bitmen.com/what-d...ook-use-a-1000-feet-deep-dive/

Ako je tacno:

I šta bi Branimire? Šta na kraju koristi facebook? Koristi li MySQL kao primarnu bazu i ima nekoga na svetu pametnijeg od tebe?

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Nikad nisam koristio Rocks u ozbiljnoj produkciji, ali da... Koristi. Brdo su oni para upucali u MySQL tesko ce od njega odustati. Ali da, naravno da ima mnogo kesiranja i da je arhitektura same baze uzasno bitna. Nacin na koji se prave tabele, nacin na koji se prave indexi posebno, upiti, sto manje join-ova, pravilna (de)normalizacija..... Ovo je sve jako puno posla. Moze mnogo toga da se izvuce i sa InnoDB, ja se jos uvek drzim njega, mada ja ne znam dovoljno matematike da skontam unapred kad je dobro preci na Rocks (srecom nije mi trebalo do sad, da jeste verovatno bi ga merio pa tako odlucio). Pogledaj i TokuDB ako ti se gledaju alternativni storage engines, to je tek ludilo sta moze.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Facebook je presao na mikroservis arhitekturu, pa ne znam koliko ima poente raspravljati "koju bazu koristi" kad svaki servis ima posebno svoje baze. A servisa ko zna koliko ima (Netflix ima oko 400)...

Testirao sam neki server da se odjednom uloguje 10 000 korisnika iz MySQL baze. Ma, nema sanse, posle par stotina krene "TIMEOUT..." upozorenje. Za takve stvari samo in-memory baza. MNESIA tih 10 000 uloguje za 2-3 sekunde.

Koristi, to nisam sporio, ali ocigledno baza nije bez middleware-a, kao sto sam rekao.

Da, to pise na onom linku. Ocigledno imaju middleware koji odradjuje pritisak korisnika, dok baza stoji iza.

Microservices su trenutno popularni, pa ima i dosta hype-a. Kao sto Bane kaze, imati middleware koji kesira bazu je normalno, to se radilo i dok smo koristili SOA, pa je samo preneto na microservices - isto kao i hexagonalni paterni i jos svasta. MySQL sam po sebi moze da ima 10,000 konekcija, to nije problem, samo ako imas resurse, mozda ne znas da ga podesis - ali ni to nije toliko bitno, nijedan login servis nece svaki login gadjati bazu - kao sto opet Bane rece, normalno je da imas servis ispred koji kesira.

Glavna "fora" nije da taj kes bude in-memory, naravno da ce biti, vec kako inteligentno resiti distribuirano invalidiranje tog kesa po svim instanacama servisa. :) Naravno, koncept da se in-memory key-value store drzi odvojeno je skroz validan, ali ne tako skalabilan, tj. onda opet imas problem sa skalabilnoscu, samo malo pomeren. Ovo je ozbiljna tema (mozda neko od moderatora da razdvoji), ali nije ni blizu jednostavna za resavanje.

Treci deo price, to sto kazes da "svaki servis ima svoju bazu", to je nesto sto se ocekuje, sa stanovista design patterna. Ali, sa stanovista biznis logike, to nije nimalo jednostavno izvesti. Zamisli da imas bas korisnike u bazi. Trebaju ti korisnici za servis za autentikaciju (proveri username i password), trebaju ti korisnici za servis za accounting (koliko nekog resursa koji korisnik trosi, treba mu ID), i za servis za billing (ovaj pita i bazu od accounting-a koliko je potrosio i bazu korisnika za to koji su podaci korisnika). Ako je sve u relacionoj bazi, resenje je poznato odavno, upiti brzi, JOIN radi po primarnom kljucu. Ako svaki servis ima svoju bazu, onda imas problem, prvo jer ti je data denormalizovana (pa se kolicina povecala), drugo jer je treba sinhronizovati. Neko resenje koje se korisit je da ubacis neki middleware mikroservis za citanje ka bazi, ali onda opet imas sve podatke u jednoj bazi (koja onda trpi pritisak), koji ces resavati kesiranjem, kako na nivou tog middleware servisa, tako i kesiranjem za svaki servis odvojeno (da bi dodatno smanji pritisak ka bazi). E sad, onda imas problem sa invalidacijom kesa, jer ti izmene na jednom servisu idu nazad ka bazi, pa to treba vratiti nazad na ostale servise zbog invalidacij njihovog kesa, pa imas back-pressure koji puni bafere koji to citaju, pa moze sve da se blokira....

Mikroservisi su super dok su stateless, ja obozavam taj fazon - REST, hexagonalni pattern, stateless, milina. Odlicni su i za obradu neke unstructured date, tipa "zveknem sve u fajlove/objekte/S3" i udri. Ali kad ti treba relaciona data, nije jednostavno. I da se razumemo, najlakse je reci "pa pravi nerelaciono" - ali nije model taj na osnovu koga se modelira data, vec poslovne potrebe. Jednostavno, ljudi koji su pravili relacioni model (Codd i ekipica) tamo sedamdesetih nisu to radili "jer su pametni", nego jer su posmatrali realne poslovne procese. Ove in-memory strukture deluju super kad imas test case i nesto sitno korisnika, ali kad shvatis da ti treba da ti data bude ACID compliant i da ti nije prihvatljivo da izgubis nijedan jedini zapis, jer ti je tupple zapravo finansijska izjava i imas regulativu (poresku) koja potencira na integritetu tihi podataka, sve postane... zanimljivije. :D

Malo se raspisah.

tl;dr : Nije mikroservis arhitektura resenje za sve.

Potpis

Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'

Član nkrgovic je pominjao da facebook nema složene upite sa ne znam kakvim JOIN-ima.

Ja ne znam kakvi su mu upiti, ali imaju složenu analizu grafova (u ovom slučaju prijateljstava i lajkova) da bi odredili profil ličnosti za prikazivanje reklama.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

"MySQL sam po sebi moze da ima 10,000 konekcija, to nije problem, samo ako imas resurse, mozda ne znas da ga podesis"

Mislio sam da mysql kad pustis 10000 klijenata na njega zaglupi samo tako. Mislim iz iskustva doduse to je bilo sa pocetka 2000ih
sam pravio workerthreadove koji su serijalizovali mysql upite u 16 threadova a sa druge strane prihvatali hiljade konekcija
upravo da bi baza mogla da radi. Ispada da su sada to sto je nekad moralo da se radi sada baza sama radi?
Mislim to ima MSSQL to sam video, ali za mysql sam se ubio od posla da bi to narpavio :P

Nego, ima li neko da kaže nešto na temu, koja piše u naslovu?

Ja sam svoje odavno napisao. Gro poruka su off topic.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Evo, Branimir Maksimovic je tvrdio da će se u prvih pola godine udeo Linux-a na desktopu duplirati, pa da vidimo. Koliko vidim, udeo Linux-a na desktopu je iz meseca u mesec sve manji.

Potpis

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Tema je prezvakana. Ovo je interesantnije i ozivljava diskusiju.

Zavisi koji sajt gledas. Kao sto dobro znas broje se klikovi i gleda user agent. Ti podaci ne predstavljaju nikakav pouzdan podatak.