da pocnem sa omiljenim citatom "there is no silver bullet" .. dakle, ne postoji unverzalno resenje ali neke "osnove" vezano za optimizaciju:

neki uvod:
- sve sto napisem u ovom postu vazi za linux, solaris i ostale unixolike sisteme, ako terate db server na windozama vi nemate potrebu da taj db server bude optimizovan, ali vecina stvari iz ovog posta moze da se primeni i na windoze
- DB server treba da bude dedicated. Nije obavezno, nije neophodno, ali za iole ozbiljniji DB server - ocekuje se da je to jedini app koji se vrti na masini

neke osnove:
ako zanemarimo klaster koji je posebna kategorija i nema mnogo veze sa obicnim mysql-om .. treba da obratimo paznju na osnovna 3 resursa koja su bitna za bazu podataka:
1. CPU
2. RAM
3. IO

CPU
- kada je MySQL u pitanju, jedna konekcija je jedan thread, dakle jedna konekcija / jedan upit ne moze da iskoristi vise od jednog jezgra
- kada je MySQL u pitanju, sorage enginei kao i sam kor mysql-a se JAKO LOSE SKALIRA ... max procesorskih jezgara koji MySQL ume da iskoristi je 8 (da, osam), sve preko toga samo "smeta" ..
- baze podataka RETKO KORISTE CPU, tj, vrlo retko ce vam usko grlo na serveru biti CPU

RAM
- sto vise rama to bolje :D
- MySQL ima nekoliko "storage engine-a", od "siroko koristenih" i "dzaba" su bitni MyISAM i InnoDB. MyISAM NIJE transakcioni engine dok InnoDB to jeste. SVE transakcije su MEMORY BASED, znaci, ako nema dovoljno rama da se cela transakcija izvrsi u ram-u - transakcija nece proci. Primer, ako imas tabelu od 2G i uradis u jednoj transakciji promenu cele tabele, dakle imas 2G izmena a imas samo 1G slobodnog ram-a, transakcija nece proci
- mysql ume da kesira rezultate u ram-u
- mysql uma da kesira pristup disku u ram-u

IO
- ovo je glavno usko grlo svake baze podataka, podaci se nalaze na disku i odatle ih treba procitati.
- tek kada se podaci fizicki zapisu na disk i dobije potvrda o tome - podaci su sigurni
- u IO spada i mreza, slanje i primanje paketa kroz mrezu isto opterecuje IO sistema

neke optimizacione osnove vezane za mysql bazirane na osnovama malopre pomenutim

1. CPU - ovde nema sta mnogo reci ... uzeti server sa vise od 8 jezgara da bude mysql server je "bacanje para", 4 jezgra je idealno, dakle, za mysql, mnogo bolje ce posao raditi dual core na 4GHz nego 16core masina na 2GHz ...

2. RAM
podesiti swappiness parametar kernela (linux) na 0 (default od 60 je ok za desktop ali zastrasujuce los za server), slican parametar postoji i za ostale unix-e

dati InnoDB-u sto vise rama za innodb_buffer_pool_size. To je bafer gde innodb kesira pristup disku, on to sam mnooogo bolje radi nego sistem cache tako da mu treba dati sto vise rama ovde. Za InnoDB only sistem 70-80% ram-a je idealna cifra, za sisteme koji nisu 100% innodb (dakle koriste i MyISAM ili neke druge storage engine) neka manja cifra je ok

query cache
- za sisteme sa mnogo vecim odnosom read : write veliki query_Cache je super stvar (kesira rezultate upita), (do 1G)
- na sistemima gde postoji veliki broj upisa/promena koriscenje "query hintova" gde se mysql-u kaze koje upite da kesira a koje ne je uputno uz veliki query cache (100M - 2G)
- na sistemima gde je broj upisa veliki i nad istim je podacima kao citanje, query cache treba ugasiti ili setovati na vrlo malu cifru (1-3M)
Ako ne znas sta i kako, ok je staviti nekih 10-20M pa pratiti query cache hit ratio
ostali baferi .. ostale bafere podesiti vezano za upotrebu aplikacije - ovde ne postoje "generalni saveti"

3. IO
- NEMOJTE KORISTITI NAS za storage subsystem, SAN je ok ali NAS ubija performanse jaaaako
- za MyISAM razdvojite indexe od podataka na razlicite spindlove (na razlicite diskove - ne razlicite particije istog diska)
- za InnoDB log bacite na razlicite spindlove od onih gde je data fajl
- LVM ne sluzi nicemu ako koristiti InnoDB
- za InnoDB koristite ODIRECT kako bi zaobisli duplo kesiranje (izbegnete kesiranje fajl sistema) na linuxu
- InnoDB podatke stavite na "forcedirectio" particiju na solarisu (slicno kao ODIRECT na linuxu)


toliko za sada ... spremam malo "opsezniji" tekst EDIT: http://mysql.crsndoo.com/wp/2009/03/optimizacija-mysql-servera/ eto ga tu ...



_{[Ovu poruku je menjao bogdan.kecman dana 07.03.2009. u 00:19 GMT+1]}

Procitao sam i sad su neke stvari jasnije :) Koja je cijena MySQL Enterprise Monitora da mogu nadredjenima napraviti prijedlog za kupovinu? Da li monitor moze pratiti vise servera odjednom? Svakako cu probati testnu verziju ali vikend je i znatizelja me izjeda :)

drago mi je :)
pogledaj i ono ovde posto je to malo "drugacije organizovana" ali vise manje ista prica ... (ovo na ovom forumu sam cukao iz glave a ono tamo sam kao prvo nacukao u txt editoru, prisredio pa ..)
ako ima dodatnih pitanja ... "do not hesitate"


ja se ubih smarajuci odgovarajuce strukture u sun-u po ovom pitanju ali sam u manjini. vec sam vise puta na nasim internim listama obrazlozio kako bi izdvajanje merlina bilo vrlo dobar potez i kako ima veliki broj ljudi koji bi platili da imaju merlin .. no .. za sada nista od toga.

merlin je "dzaba" za nekoga a nedodirljiv za nekog drugog. sta to znaci, ako imas mysql enterprise subscription - uz nju dobijes merlin: http://www.mysql.com/products/enterprise/features.html
zavisno od nivoa servisa koji uzmes - takav set "saveta" dobijes uz merlin, dakle sam monitoring (logovi, grafovi, stanja) ima svako, a "saveti" (na primer, "povecaj innodb_buffer_pool" ili "smanji sort_buffer") su bazirani na nivou subscription-a tako da postoji 3 seta "advisory rules" koje mozes da imas.

merlin moze da prati mnogo servera odjednom, imamo klijente koji prate 20K servera jednim merlinom, merlin dozvoljava da pratis onoliko servera za koliko servera imas enterprise subscription

pogledaj: http://www.mysql.com/products/enterprise/monitor.html
i obavezno: http://www.mysql.com/products/enterprise/benefits.html


pvde prati 6 servera odjednom - pocetna strana:


analizator upita:



replication monitor:


saveti:

Kakav alat, kakva steta. Steta je takodje sto nije problem da se takav proizvod plati. Malo je bezobrazno da te tjera da kupis Enterprise server da bi mogao da imas ovako dobru analizu rada servera :( Ali, sta sad, nije toliki problem zivjeti bez necega bez cega se moze. U svakom slucaju drzacu se tvojih preporuka, na kojim sam mnogo zahvalan :)

mi zivimo od support-a, sve ostalo je added value .. to je "company policy" od kada postoji mysql... e sada, slazem se da su neki od tih "added value" kompletni i odlicni proizvodi i da bi bilo super imati ih zasebno .. no sta je tu je .. rekoh da sam se od prvog dana zalagao za izdvajanje merlina kao zasebnog proizvoda (interni naziv za enteprise monitor je merlin - a tako se zvao i u startu - sada je NMAS / MEM / Enterprise Monitor)... no .. sta je tu je... taj "enterprise server" je isto value added service, ti njega ne kupujes, enterprise binary je isto "adde value" uz podrsku...

ono sto je zgodno napomenuti je da je support prilicno "jeftin".. posebno ako se uzme u obzir kvalitet podrske i sta ona sve daje kao added value ... pogledaj http://www.mysql.com/products/enterprise/features.html

za 4000E godisnje (ispod 350E mesecno) po serveru dobijes (pored ostalih "standardnih stvar")
- Remote Troubleshooting - dakle, ja se okacim na tvoj server, pronadjem gde je problem i popravim ga ..
- Replication Review - provera da li replikacija radi kako treba, da li je nasetovano sve kako treba, da li koristis upite koji su problematicni, da li moze optimalnije ...
- Partitioning Review - provera da li partitioning radi kako treba ... ---||---
- Query Review - posaljes nam upit i mi ti kazemo da li je ok, zasto nije, da li moze bolje, kako moze bolje
- Schema Review - posaljes na db model, mi ti kazem da li je ok, zasto nije, da li moze bolje i kako moze bolje
- Performance Tuning - nasiljimo ti server da bude najbrzi moguci za tvoje specificne potrebe
- Customer Code Reviews: MySQL Client APIs - ne radi ti kod, posaljes nam sors i mi ga popravimo
- Customer Code Reviews: MySQL User Defined Functions & Server Extensions - --||--
- Customer Code Reviews: MySQL Stored Procedures, Triggers & Functions --||--

ako uzmemo u obzir da jedan prosecan dbadmin koji ovo sve ne ume da radi ni 1% dobro koliko to mi radimo kosta u beogradu 1200E netto, dakle jedno 2000E brutto MESECNO mislim da je kalkulacija vrlo jednostavna .. da ne spominjemo koliko taj isti dbadmin kosta u "razvijenom svetu" ...

Inace limit na broj servera u samom merlinu je "warning", bar za sada, dakle, ako imas pravo na 1 server a monitorujes 10, merlin ti kaze "warning: imas pravo da monitorujes 1 server a monitorujes 10, molim te da proveris licencu" .. i sve "radi" .. e sad, to mozda vec u sledecoj verziji ne bude tako, mozda prvih 10dana bude warning pa onda prestane da radi .. mozda odma .. mozda ... nebitno - sada je samo upozorenje

inace, fora koju dosta firmi iz zemalja poput srbije (zimabwe, jordan, kazahstan, tadzikistan, turkmenistan, kongo...) koristi je da uzme probnu verziju merlina, prati tih 30 dana svoj server, i iskoristi te podatke da ga optimizuje, onda nikad ne kupe "pravi proizvod".... moram priznati da je preko 90% njih koji uzmu trial uzelo isti sa tom idejom ... ono sto je tu super je sto preko 50% njih ostanu korisnici posto odlepe na proizvod i shvate da vredi svaki dinar (nemacki, americki ili kojim vec dinarima placaju) :)

Izvini, sad sam tek shvatio kako je mogao zvucati moj prethodni post. Nisam htio da optuzujem, samo sam htio da konstatujem da bi stvarno bilo super da merlin mogu da kupim bez enterprise licence. Za sada nemam problema sa hardverom, nemam problema sa opterecenjem baze, i ako se nesto desi ipak sve uspijem rijesiti malim pregledom koda, pa zbog toga nije primarno da moram imati takav vid podrske ili placati MySQL Enterprise. S vremenom cu vjerovatno doci na taj nivo, za sada je ok. Ali, merlin bi mi sada vrijedio, kao neka "prva stepenica". Opet, s druge strane, razumijem i da ga se ne moze nabaviti bez kupovine Enterprise editiona jer, pored svega sto sam vidio na printscreenovima, vjerovatno mi ne bi palo na pamet da kupim Enterprise Edition samo zbog bolje podrske jer, merlin bi odradio masu stvari prije nego sto bi zatrebala dodatna podrska. U svakom slucaju dobar proizvod i posebne pohvale tebi na spremnosti da objasnis sve sto te pitamo :)

ja mislim da sam te potpuno pravilno razumeo - ja isto mislim da bi bilo mnogo iskusno da moze da se kupi kao zaseban proizvod, rekoh da sam se zalagao za to i objasnih zasto je to sada tako kako je .. alat je extra, nisam siguran kako ide varijanta sa "30day trial" ... znam da za to vreme mozes da postavis samo dva pitanja i da moraju da budu vezana za merlin, dakle ne moze "zasto mi je server spor" .. za to vreme valjda imas fully functional merlin ... e ne znam da li to kosta neke pare ili samo tamo popunis to i dobijes na testiranje ...

Da li je problem ako se koristi innodb odirect na LVM particiji? Prvenstveno, da li bi mogao biti problem ako mysql direktno pise na disk, a pritom odradim LVM snapshot radi nekog backupa, prebacivanja ili bilo cega slicnog? Da li su podaci u tom slucaju ispravni i da li su u opasnosti?

InnoDB je tu prilicno nezgodan ... tako da .. ja iskreno ne volim LVM ali ne postoji konsenzus .. samo cinjenice ..

u cemu je stvar, ako mysql-u na bilo koji nacin kazes da "prestane da pise po disku" da bi ti iskopirao sadrzaj - to za innodb prosto ne radi. sve varijante gde ti uradis flashovanje na disk i lokovanje tabela pri kopiranju innodb table space "nije cist" i ti kada vratis taj "bekap" mysql radi crash recovery, dakle cak i ako korists mylvmbackup, pitanje je samo da li ce skripta odma ili mysql kasnije da radi recovery .... "flush tables with read lock;" za innodb ne radi isto sto i za myisam...

moje licno misljenje, dakle, da ponovim, moje licno, je da to nije bekap. bekap treba da bude konzistentan i treba da bude u nekom trenutku u vremenu ... ako ja treba da radim "crash recovery" nad bekapom - **** bekap

ako zaboravimo taj bekap bez gasenja mysql-a, sa lvm-om je brze
- ugasis mysql
- odradis snapshot
- upalis mysql
- bekapujes snapshot
- obrises snapshot

dakle server jeste offline, ali je offline samo tokom pravljenja snapshot-a.... ako nemamo lvm, onda server mora da bude offline tokom kopiranja datadir-a na drugu lokaciju ... dakle nesto duze ... no ako uzmemo u obzir da optimalno podesen server radi "regularno gasenje" nekoliko minuta .. ceo taj proces uopste nije taka kratak i "down time" uopste nije mali sto jedan ozbiljan klijent sebi svejedno ne moze da dopusti.

tu je sada na tebi .. da li ces da pristanes na ~3-10% IO usporenja koja donosi LVM da bi radio brze bekap.

Ja sam uvek za varijantu da bekap pravis tako sto imas slave server, ugasis, napravis bekap na tenane .. a nikako za varijantu da trpis taj LVM overhead "non stop". Tu se samnom nece sloziti 50% ljudi u firmi .. PeterZ koji je jedan od poznatijih (ako ne i najpoznatiji) a i najvecih strucnjaka za optimizaciju rada mysql-a na primer zagovara koristenje LVM-a... on u startu datadir stavlja na LVM... ja se opek apsolutno protivim lVM-u ako se koristi innodb.

IO je najbitniji kod optimizovane baze .. uglavnom je tu usko grlo, tih 3-10% je, po meni, mnogo, posebno sto tih 3% ja nikad nisam video, nikada nisam izmerio ispod 7% a u nekoliko slucajeva sam merio i 15-20% usporenja (software raid + lvm na linuxu) ... ako dodatno uzmemo u obzir da mysql radi na online backup-u, to je prosto "layer viska"...

vezano za sigurnost ODIRECT-a ..

problem 1. https://bugzilla.redhat.com/show_bug.cgi?id=446599

dakle, ako kernel ima odirect bug - moze da bude belaja

problem 2. u nekim slucajevima - opet zbog problema sa kernelom - ovaj put feature a ne bug - ODIRECT moze da uspori select drasticno

tako da, O_DIRECT uvek mora da se "proba" .. to nije "default" bolja varijanta ... ako ne postoji o_difrect kernel bug - podaci su sigurni (cak i ako je fs na lvm-u; lvm tu samo usporava stvar nista drugo).. ako postoji kernel bug podaci su opet sigurni samo ce mysql da "rikne" ...

mysql ima tu foru da u slucaju da nije siguran sta se desava - rikne .. posto je filozofija "bolje da ja segfaultujem nego da upisem pogresne podatke na disk"

Dobro, kod mene ne bi trebalo da bude toliki procenat usporenja jer je u pitanju SCSI 15k na hardware-skom RAID-u. Pomenuo sam ti u PP kakav je racunar u pitanju, ali opet nije zgorega izvuci jos poneki promil performansi :) Backup je jako bitan i radi se cesto...

_{[Ovu poruku je menjao Schmidt dana 10.03.2009. u 14:19 GMT+1]}

procenat je procenat :D .. sto je brzi HW to je procenat usporenja koji doda LVM veci :D (realno, LVM dodaje neke fiksne mikrosekunde tu tako da sto je storage subsystem brzi to su te mikrosekunde "Veci procenat")

sto se bekapa tice to je velika tema .. i prilicno ozbiljna ... sve u svemu - ja podrzavam varijantu "slave backup" .. dakle imas slave server koji samo za to koristis ... kad oces da uradis bekap, odvojis slave sa mreze, odradis bekap kako god ti milo i drago i vratis slave nazad na mrezu da sustgne mastera .. no ... ne bih sad ulazio u detalje posto je prica oko optimizacije servera a ne o pravljenju bekapa...

dodatno je bitno koji storage engine ... sa myisam-om lvm je super .. cak ponekad i neophodan, bekap myisam tabela sa lvm-om je pesma etc etc ... dok opet, innodb ima svoj "table space" koji moze da se baca okolo, koji je filesystem za sebe .. tako da tu osnovna prednost LVM-a (snapshot) ne pomaze :(

e sad .. imao sam prilike da vidim servere sa par desetina hiljada upita u minuti i par hiljada konkurentnih konekcija koji su "default" namesteni ... i ladno su na 10% CPU/IO iliti mogu jos 10* toliko bez da se primeti ... dok sam video i one koji imaju po 10 upita u minuti i kolje ih IO ili CPU ... imamo klijenta koji pravi dns aplikaciju .. u pozadini je mysql .. on ima po 300K upita u minuti :) i to jedna "pateticna" masina sa par giga rama i xeonom od pre 4 godine pljuje iz zezanja ... opet, sad se smaram sa nekim papanima .. ma .. sve ima svoje .. u 99% slucajeva, ponavljam se, optimizacija se svodi na dobro napravljen DB model.... kada pogledam kako ljudi prave tabele, od toga kakva imena koriste do toga sta sa cim stavljaju pripadne mi muka ....

jedan zanimljiv detalj .. covek, tehnicki direktor i "glavni developer" jedne velike (preko 100 zaposlenih, preko 6cifara mesecni obrt) firme u Londonu (nisu MySQL klijenti, ja sam im radio privatno konsaltin pre nego sam otisao u mysql) koji je u tu firmu dosao iz opet drzavne firme (neki inspektorat) gde je radio kao "senior developer" .... pita sledece:

imao sam

gde t1 ima nekih 200M slogova i upit:


meni sada treba ovako nesto



i sada upit traje 40 minuta?!?!?!? sta da radim???

ja se okacim na server (inace neki p1) i uradim "alter table t1 add key (f1_userid);" .. kazem mu da pusti upit i isti se izvrsi za manje od 1sec ... on zove krene da place i pita sta sam uradio ... ja mu lepo kazem "nista pametno, dodao sam index na polje po kom radis pretragu" ... na to dobijem odgovor "why did that help"!!!!!!!!!!! onda mu ja kazem nesto tipa "pa moras da dodas index da sql server ne bi sekvencijalno isao kroz celu tabelu i trazio rezultat" na sta me covek zabode stosom "there is a way other then reading the table sequentially?"

To je covek koji ima 10000GBP brutto MESECNO!!!!!!!!! i prodaje se kao PHP+MYSQL DEVELOPER!!!!!!!!!!!

U kojoj mjeri je moguće povećanjem RAM memorije sve vezano za MySQL "strpati" u sam RAM? Kako bi se naravno drastično poboljšale performanse. Naglasak na drastično.

"drasticno" je vrlo subjektivan pojam :)

samo ram u svakom slucaju nije dovoljan, posto, ako imas tabelu od 2M slogova, i cela tabela je u ram-u, i tabela nema indexe search na toj tabeli ce biti mnogo sporiji nego search na istoj toj tabeli koja je na disku a koja ima pravilno napravljene indexe ..

dakle, strpas sve u ram i ako nije dobro dizajnirana baza i dalje imas lose performanse (naravno mnogo bolje nego da je ta ista baza na disku, ali mnogo losije nego sto mozes da imas sa dobrim dizajnom).

sto se tice koristenja ram-a ...
- ako ima dovoljno ram-a stavljanje /tmp na ram disk (tmpfs) moze znacajno da ubrza upite koji koriste blobove posto takve temporary tabele uvek idu na disk, ako je taj disk u ram-u ubrzanje je nekoliko puta (drasticno)
- za innodb, innodb buffer je ultra bitan, sto vise rama mu dati to bolje, u slucaju da je innodb bafer veci od baze cela baza ce biti u ram-u (ucitace se prvom prilikom) - dakle ubrzanje u odnosu na "mali innodb buffer" je nekoliko puta ... evo covek koji je inicirao ovu pricu, bez ikakve promene upita i db modela (a mnooogo toga bi moglo da se promeni da se ubrza i do 20x) je upit ubrzao 40tak puta koliko sam svatio time sto je povecao innodb, drugi kolega ovde sa foruma je query koji se nije zavrsio posle 2 minuta prekinuo i kukao kako je mysql spor, onda je digao innodb buffer na 256M i dobio rezultat za 2 sekunde .. (to mu dodje preko 120x ubrzanje) ... i pritom, u svim ovim slucajevima je buffer bio manji od velicine tabele sa kojom se radilo i "mnogo manji" od velicine cele baze (bar u ovom drugom slucaju, za prvi nisam pitao koliko ima ram-a i koliko je velika baza) ..
- za myisam nije tako jednostavno .. on koristi fs cache .. tako da tu OS pomaze sa svojim kesiranjem ..

e sad ... razli baferi .. query_cache posebno mogu mnoooooogo da pomognu ako se koriste kako treba (sa hintovima i slicno) ... memcached (nema veze sa mysql-om ali se vrlo cesto koristi u kombinaciji) moze isto puno da pomogne .. no to je sad van direktnog pitanja ...

obrati paznju da je mysq cluster do 5.1 / 6.x imao sama "in memory data" ..tj na klasteru svi podaci su u memoriji ... to daje ogroman troughput ali opet sa druge strane zbog organizacije klastera (distribuiranih podataka) na visenodnom klasteru kopleksan join moze da bude bezobrazno spor .. (nema taj problem na 2node clusteru posto su svi podaci na jednom nodu)... no tu moze da se vidi benefit in memory baze, najveci problem koji imamo sa klasterom su lcp-ovi posto su i najbrzi diskovi suvise spori da povremeno snime lcp (nedo bog da se od njih zahteva da to non stop rade) ..

hahhaha
@bogdane tvoje iskustvo i prisustvo na ovom forumu je neprocjenjivo! Ne znam odakle crpis energiju.. reci nam jos to pa nam ne treba vise nista ;)

:D :D :D iz ovakvih komentara :D :D :D

sve se svodi na "give something back" ... ja vec duuuuuuuuuuugo vremena zivim jako lepo od open source-a ... sto tako sto sam ga koristio za projekte (mysql, pgsql, php, gcc, openldap, linux.... i mnogo projekata oko toga) tj u svojim projektima, posle tako sto sam "ovoj i onoj" firmi smanjio troskove drasticno i ubrzao proizvodnju tako sto sam ih prebacio na OS/FOSS .. pa sve do rada direktno za jedan FOSS projekat kakav je mysql ... 99% stvari koje znam sam naucio iz "ukradenih" tekstova sa foruma, gofera i sl. vreme je da nesto od toga vrnem nazad ...

nadam se da ces i ti, sutra, kada budes radio "samo jedan posao", budes imao malo slobodnog vrmena i malo vise znanja, resiti da to podelis sa drugima i "give something back" ...

no .. da se vrnemo na temu ...

mislim da je Durdenovo pitanje pomoglo da se pojasni cinjenica da je za MySQL jako bitno o kom se storage engine-u prica ... optimizacija za innodb nije ista kao optimizacija za myisam, falcon je opet posebna prica, maria posebna ... gomila drugih, sto free, sto proprietary storage engine-a koji postoje za mysql su opet zasebna prica ... dakle, odabir storage engine-a je jako bitan i utice na sve ...

ono sto mogu da kazem, a nije bas "javna informacija" .. (mada nije bas ni strogo cuvana tajna), je da kako trenutno imamo merlin koji skuplja i analizira gomilu podataka o serveru, vec imamo neke "ideje" oko automatskog setovanja servera .... u WL-u je da se u 6.1/6.2 stavi "auto config" gde je jedini info koji korisnik daje mysql-u "nemoj da trosis vise od XYZ G ram-a" a mysql sve ostalo konfigurise sam, realtime, u odnosu na statistike o koriscenju skupljenje tokom rada.... no .. ja ne ocekujem 6.0 ove godine tako da .. ima do toga vremena ..

Za ovog engleza sam tacno znao da ce biti do kljuca, jos dok sam citao vec sam se poceo smijati. Desavalo se i meni takvih stvari, ali koliko god da ih se desi uvijek me nasmiju i iznenade :)

nije problem sto on nije stavio kljuc .. desava se i najboljima da nesto previde, da zablokira mozak, da ... ma necu ni da pocinjem sa mojim biserima ... poenta je da taj covek uopste ne zna sta je to index, on bazu zamislja kao sistem koji jako brzo cita txt fajlove i vadi podatke .. iliti sto bi nas svet reko "kako mali perica zamislja rdbms" - e taj covek ima toliku platu i na takvom je polozaju i smatraju ga "expertom" - to je ono sto boli ..

offtopic: snas'o se covek ;) mada, ako se ne varam, uveliko su tu outsourcing i SaaS...
ontopic: odlicna objasnjenja! :)

momsab, de se snaso .. 99% ih je takvih tamo .. (u engleskoj .. po evropi i americi je dosta druga prica .. ali ta ostrva) ... a vezano za taj outsourcing - takav ti bude "project manager" ... a za saas nije resenje u takvim slucajevima .. da njima radi posao postojeca aplikacija - ne bi razvijali svoju :)

hvala hvala, napisah malo "sredjenije" i mozda malo opsirnije istu stvar ovde

Bogdane, bas me je zainteresovala ova tvoja prica o MySQL-u, ja sam mislio da je to igracka od baze...

S tim u vezi kako se MySQL snalazi u Enterprise vodama, npr kao baza za manja i srednja preduzeca za finansijske i poslovne aplikacije.

U poredjenju sa npr Oraclom, recimo baza od 50-100 GB, da li moze da izdrzi to opterecenje, kolicinu transakcija itd...
Koje su joj mane u poredjenju sa Oraclom, cena joj je ocigledno veliki plus.

Ili je to ipak baza za web?

:) ima ono nesto ... svaka puska u necijoj ruci ubojita ... da ne jurim sada kako ide original, verujem da znas na sta mislim



pogledaj listu klijenata koji su "javni" - mozes samo da mi verujes na rac za listu klijenata koji nisu javni (posto nas ugovor sprecava da njihovo ime koristimo medju referencama - uglavnom zato sto od svoje konkurencije kriju da taj posao moze da se odradi i za mnooooooooooooogo manje para): http://www.javasvet.net/sastan...0Belgrade%202008%20800x600.pdf strana 4



na istoj masini moze da izdrzi 30% vise opterecenja od orakla na toj bazi .. 50-100G je "srednja - mala baza" ima dosta instalacija sa 10T i vise



brzi je od orakla u 90% slucajeva a u onih 10% je "ista brzina"
oracle ima neke "dobre fore" koje mysql nema (na primer materialized view), oracle je application server a ne database server tako da ti realno mozes celu aplikaciju da napises u oracle-u, mysql je samo database server tako da za aplikaciju moras da koristis "nesto drugo" (c/c++/php/perl/python/dot nemoj/java/....) ..
mysql stored procedure su iskljucivo po sql standardu, nemaju extension/moc koju oracle daje sa pl/sql-om
mysql nema online backup (za sada, bice u 6.0)
nisam 100% siguran ali mislim da oracle ima sinhronu replikaciju - mysql to ima samo u klaster verziji ali klaster nikako nije za "normalnu upotrebu"
....

moze ovako do prekosutra .. mysql ima dosta nedostataka u poredjenju sa oracle-om ali ima i dosta prednosti u odnosu na oracle (koje se, da budemo posteni, sve vrte oko performansi i par ok feature-a ... naravno - cena)

sve u svemu, preuzeli smo dosta klijenata (koristili oracle pa presli na mysql ... 2 velike japanske banke, i neki veliki korisnici koje ne bih spominjao) .. oteli mnooogo poslova oracle-u na tenderima etc etc ... necu da ulazim u x vs y ... oracle ima puno prednosti .. ali mysql jeste open source resenje koje radi posao u enterprise vodama vec vrlo dugo i vrlo zahvalno ... moram priznati da sto se samog orakla tice, mnogo vise klijenata koji menjaju oracle za "nesto drugo" biraju pgsql umesto mysql-a zbog neverovatno lakse prepravke aplikacija, pgsql ima bolje alate za tranziciju i kompatibilniju sintaksu od mysql-a .. no .. nije mesto opet za x vs y .. moja firma je najveci donor pgsql-u godinama, njihovi inzenjeri rade sa nasim inzenjerima :) .. to je odlican proizvod, koji opet ima svoje prednosti i mane - no ovo je tema o mysql-u pa da ostanemo na tome .. cak stavise - tema je o optmizacije mysql servera

vezano za "u Enterprise vodama, npr kao baza za manja i srednja preduzeca za finansijske i poslovne aplikacije."

pogledaj zakacenu sliku ili linkovani pdf ... pogledaj desni gornji segment ...

SAGE najveci accounting / business analytic software u evropi ako ne i sire
Adobe (do skoro nismo smeli da koristimo njihovo ime) - ima embedded mysql u PhotoShop-u, Adobe Acrobat-u, AI-u i skoro svim ostalim Adobe aplikacijama

To su "veliki" .. i to veliki u "svakom pogledu" .. "srednjih" biznisa ima toliko da ne bi mogao da ih nabrojim za dan sve i kada bi smeo :)

Bogdane, hvala na informativnom i zanimljivom postu :)

Samo da pojasnim sta znaci OEM .. (Adobe, SAGE i mnoooogi drugi) ... OEM klijenti ukompajliraju ceo MySQL u njihovu aplikaciju ... dakle nema nigde mysql-a da se vidi spolja .. ali aplikacija izvrsava sql-ove i prica sa mysql-om kao da je servis ... Adobe ga ima u skoro svim aplikacijama (iskreno - nemam pojma cemu sluzi mysql u photoshop-u ali tu je)... SAGE ga koristi u svakom svom segmentu - a kao software za vodjenje poslovanja - prilicno je jasno za sta koristi RDBMS ...

Ako pogledamo taj isti screenshot .. ili cetvrtu stranu te tuzne prezentacije (sta da radim, meni stvarno to nije posao, pravio sam tu prezentaciju 3 dana i opet je ispala ocajno :( a morao sam da pratim "company guidelines", da je saljem na approval ... ma ... tuga i zalost) ... videcemo web/web 2.0 segment ... (da, mysql jeste najbolje sto postoji za web) .. i tu su, pored nekih manje poznatih, wikipedija sa mnoooogo servera, oni su do skoro trosili 4.1 sada se prebacuju lagano na 5.1 (server po server) ... wikipedija ima veci traffic nego bilo koji enterprise app na svetu .. realno imaju veci load nego google / nego bilo ko drugi na webu ... flickr je prilicno poznat .. reklo bi se .. nemam ideju ni koliko servera imaju ni koliki load na bazi .. no .. da se pretpostaviti ... facebook ... za njih znam detalje .. 20K servera .. svi drze sve podatke .. 5 miliona korisnika online u svakom trenutku koji "nesto rade" .. to nesto ide u mysql i mora da bude na svih 20k servera ... ebay je koristio oracle, sada (vec neko vreme) su na mysql-u ...

pogledamo dalje .. on demand / saas / hosting ... ok, skoro svi hosting provajderi nude mysql (bar ja ne znam nijednog da to ne radi), ovi ovde imaju ugovor sa mysql-om .. dakle ove firme ovde sve placaju support i konsalting mysql-u .. nisu samo "korisnici dzabe baze" .. ovde fali jos jedan dobar deo provajdera no nije bilo mesta .. dodao bi na primer rackspace koji je "najbolji hosting provajder" mnooogo godina za redom (nude server hosting, ne one 2$ mesecno varijante) ...

dalje .. telekom .. ok, ovo su vecma mysql cluster korisnici .. fale mnogi kojima se ime ne sme koristiti ... (na primer erikson :D ) ..

dalje .. enterprise 2.0 ... (ko izmisli ovo ime crko dabogda) .. to je enterprise koji koristi mysql kao bazu podataka .. tu fale jos 2 banke, jos mnogo firmi ... ali to je prilicno reprezentativni uzorak .. jedna ogromna japanska banka, jedna ogromna prodavnica (mozda najveca prodavnica igracaka na svetu - oni su inace na web-u drzaly sybase - sada su full i na webu i enterprise app sa mysql-om), ogromna gradjevinska kompanija, novinska agencija, marketing kompanija .... dakle iz razlicitih svera firme, sve imaju full interni sistem na mysql-u .. skoro sve ove firme su bile na nekom sybase-u, na oracle-u, na db2 .... pa su presle na mysql

btw, tu sliku inace nisam ja pravio, da sam se ja pitao ja bi stavio neke druge reference, ali posto ja nisam bas upucen tacno koja firma jeste a koja nije javno nas klijent (na primer nokija je godinama branila da se igde pisne da oni koriste mysql cluster - to nam je svima bila posebna klauzula u ugovoru .. onda se nesto desilo i postali su "javno" nas klijent ... a ljudi imaju preko 50 laboratorija gde testiraju klaster pod najrazlicitijim uslovima i okolnostima, nokija je no1 "krivac" sto je klaster toliko dobar koliko je dobar )

Kolega Matt Yonkovit je napisao odlican tekst o "odaberi mysql server za 5minuta" koji sam ja na brzaka preveo na srpski

bacam link ovde posto ima veze sa optimizacijom samog mysql server

Odlicne informacije... keep it coming :)

sve dalje , sve bolje.

kolega Bogdan, dali možeš malo pisati što možemo očekivati u budučnoti od mysql?

što će biti novo, što se planira?

recimo ono što ima oracle, tj. neke stvri koje fale, pa onda stveri koje nemaju druge baze, a planiraju se kod mysql-a ako postoji takvo što?


koliko ljudi radi na razvoju mysql-a?

ono što mi nije jasno, kako firme mogu bacat lovu recimo na oracle kad je tu pqsql ili mysql?
kao što je Bogdan rekao , firme nisu prije imale izbor, a sada je komplicirano prebacit na mysql.


vidio sam da se u americi dosta traže mysql db admini , a sa plačom su čak jači od oracle, ima u nekim slučajevima da je mysql admin duplo plačeniji u odnosu na oracle admina.

da bi se svladao cijeli oracle+rac i ostalo treba 12-15 godina učenja i iskustva, za db2 nije dosta cijeli život ono što db2 nudi , tako kažu.

zašto uopće postoji blob polje do 4 GB?

zašto nije ograničeno do nekoliko MB?
pošto je pravilo da se u bazu ne spremaju dokumenti?

jel neki od klijenata drži veće file-ove u bazi?

ja tesstiram bazu na atlhon 3500 xp +
disk maxtor 7200
1 GB rama- > od toga 128 na grafičkoj
ja sam onaj kolega kojemu je upit trajao preko 2 minute, dok nisam digao polol_size_buffer na 500 MB.
radilo se o zbrajanju 1 M slogova.
na sporijim diskovima vrijeme bilo kakve operacija raste exponencijalno sa brojem slogova.
sad kad je buffer na 500 MB
zbrajanje 1 M slogova -> 2 s
zbrajanje 2 M slogova -> 4 s
zbrajanje 12 M slogova -> preko 2 minute i kusor

dali postoje veći diskovi od 15 000 rpm?

sad još moram testiran i na linuxu.ali to će malo pričekati.

dali ima netko samo schemu baze koja ima barem 20 tablica?
za testiranje.

Ako Bog da, nadam se da ću vjerojatno uspijet se spremiti za certifikat do kraja godine uz sve ostale obaveze.
samo ne znam gdje ću se kod nas s tim zaposliti?
uletilo mi programiranje, iako pucam na linux administraciju oduvijek i eventualno mysql administraciju.
ili potražiti sreću preko bare.

sto ne otvori novu temu :) :D :) ..

da ostanemo "on topic" ...
- bolje performanse
- veca skalabilnost
- vise feature-a
- manje bagova


:D :D :D

ja razumem da si ti radio na oraklu pre nego si probao mysql, ali nije orakl izmislio baze podataka ... orakl ima neke super fore, slazem se, ali je zbog tih super fora ogroman i tezak i trom, i u velikom broju slucajeva mnoooogo sporiji od konkurencije...

mysql nikad (bar ne da ja znam, bar ne da iko sada to planira) nece imati pl/sql, tj. necemo ga mi razvijati, ako ga neko napravi kao plagin - dobrodosao ... nikad nece praviti pdf parser (osim ako ga neko ne napravi kao plagin), nikad nece praviti application server ....

mysql ima cilj da
- ima sigurne podatke
- ima dobre performanse

mysql uopste nema cilj da se poredi sa bilo kim drugim ... implementiraju se featuri po sledecem redosledu
1. najveci prioritet imaju feature-i koje neko plati (dodjes platis XYZ para za neki feature, mi ga implementiramo, dobijes ga ti i svi ostali)
2. ono sto trazi community (ako imate zelju, sastavite je na pravilan nacin i prijavite na bugs.mysql.com kao feature request), ako ima vec takav feature request, dodajte svoj komentar da to vama "treba" i "zasto"
3. ono sto nasi developeri misle da je potrebno



~200


mysql NIJE uvek najbolje resenje. isto tako nije ni oracle uvek najbolje resenje ... ne postoji univerzalno najbolje resenje ... "silver bullet?!?!? anyone???"
- pgsql moze da bude nekad najbolje resenje
- oracle je nekad najbolje resenje
- mysql je nekad najbolje resenje

nekada posao moze da odradi bilo koji od ta tri, nekad cak i ms sql server ili dbf reader mogu da odrade posao .. onda je pitanje preferenci firme ... ako firma ima zaposlena 3 oracle dba, svi developeri imaju iskustvo sa oracle-om, firma ima dovoljno para da plati licence i podrsku oraklu .. i orakle im radi posao .. zasto ne bi implementirali to sa oraklom? mozda je mnogo skuplje u tom slucaju zaposliti jos 3 mysql dba i obuciti developere da rade sa mysql-om .. ili .. kojim vec drugim rdbms-om ... to je kao da ja tebe pitam zasto bacas pare i koristis windoze sa ms office-om umesto linux i open office??? svaki taj proizvod ima svoju nisu .. i nije posteno to nazivati bacanje para ..

doduse, vrlo cesto to jeste bacanje para i jedini razlog za odabir resenja je neznanje, reklama i slicno .. ali .. zasto je firma X odabrala bazu Y gde baza Y nije mysql nije pitanje za temu o "optimizaciji mysql servera" a nije uopste ni za forum o mysql-u ... moze da bude za "baze podataka uopste", ili neki a vs b ... no ja time ne zelim da se bavim ...



danas je najprodavanija knjiga na orajliju c# ... pre neki dan je bila neka druga ... danas se mnogo traze mysql admini, do pre 6 meseci su se trazili oracle admini, pre toga neko treci ... nije to pokazatelj nicega osim "sta trenutno bolje prolazi" .. ali trenutno je razmak mesec dana tamo vamo .. drugo, ako odes na planetmysq tamo samo pricaju o mysql-u .. ako odes na neki m$ loving sajt pricaju kako je vista dosta sa neba i kako nema boljeg os-a od viste i kako je m$ najbolji i najlepsi i dolazi u kutiji sa mnogo boja ...



da bi se savladao rad sa bazama podataka - mora da se zna teorija ... mnogo teorije .. za to ti treba 10-15 godina. onda posle toga treba da naucis da koristis neki od rdbms sistema .. za to ti treba od godinu do par godina .. onda ti treba iskustvo ... iskustvo trazi vreme i mesto ... ako pravis sajt sa 100 poseta mesecno nikad neces steci iskustvo, ako radis sa 500 servera u replikaciji i par stotina hiljada upita u minuti naucices (ili izgoreti) za par meseci vise nego neko za ceo zivot ... tako da te procene batali ... to za ceo zivot .. to ti je sigurno pricao neko ko je db2 dba :D ... db2 je "najlaksi" za nauciti, sve je po standardu - oni su ga napravili :D .. znaci sva dokumentacija za sve postoji ... setovanja su relativno jednostavna posto se prokletinja sama steli ... to je odlicna baza podataka, mnooogo bolja od orakla .. al .. ovo je tema o mysql-u



pravila nisu "set in stone" ... postoje izuzetci .. postoji mnogo razloga zasto je to korisno (na primer full text search)



naravno



za taj problem je krivo mnogo toga ...
- jako spor IO
- vrlo malo ram-a
- indexi

tu sad mogu da se prave specificne optimizacije kada su cesti takvi upiti, no,... jos memorije :) posto tebi "hot" data ovde ne stize da se kesira kada predjes neku vrednost ... jos ako ti se desava nesto paralelno ... ode sve u .... plus .. problem sa memorijom .. na tih ~800M .. 500 je otislo u buffer pool, 500 je otislo na windoze, 100 na disk cache ... cek, to je vise od 800 .. ah da .. swap ?!


vidi, kako se razvija tehnologija ne postoji sansa da cu ja da ti odgovorim na ovo pitanje osim sa "ja nemam" .. najbrzi koji sam ja drzao u ruci je 15K .. a kapiram da ima brzih .. mi sada dosta testiramo SSD ..



da sumiram .. pusti poredjenje mysql-a i drugih proizvoda ... kada imas problem XYZ gledas kako ces da ga resis na sistemu koji imas. Ne gledas kako bi nacin resavanja problema XYZ sa sistema ZZZ upotrebio na sistemu YYY...

zivis na selu, vodu dobijas tako sto
- sednes na konja
- odes na potok i natocis vodu
- dovezes vodu konjem

zivis u gradu
- sednes u kola
- odes na potok i natocis vodu
- dovezes vodu kolima

aaaaaaaaaaaaa .. NE ... odes u klonju i odvrnes slavinu !!! zaboravi voznju i dovozenje ... koncept na koji se problem X resava alatom Y je razlicit od koncepta kojim se problem X resava alatom Z ... implementacija prvog koncepta koristenjem drugog alata dovodi samo do konfuzije i loseg finalnog resenja

Obratiti paznju samo da *ne postoji univerzalno resenje* .. u zavisnosti od toga sta vasa aplikacija radi i kakve podatke cuvate, konfiguracija moze jako da odudara od ovih opstih nacela. Takodje, ima tamo jos brdo nekih parametara na koje se mora obratiti paznja u svakom zasebnom slucaju ali oni toliko zavise od slucaja do slucaja da to iskustvo stvarno ne bih mogao da pretocim u nekoliko postova ...

Extra poredjenje :)

Odlicno stivo za citanje :)

Sto se pitanja za brzinu diskova tice, trenutno na trzistu postoje SSD diskovi iliti kako ih EMC u svom portfoliju naziva Flash Drives i prema onome sto sam video mogu vam reci da nam se smesi svetla buducnost kada cene ovih diskova opadnu (30 puta veci IOPS - I/O operations per second sa flash diskovima u Symmetrix DMX-4 storage-u) i konacno se pomeramo od ogranicenja mehanike diskova za database sisteme.

vec su neko vreme u upotrebi u production sistemima ko imaju velike IO zahteve .. meni je zao sto ne mogu da okacim nase interne rezultate poslednjeg testiranja brzine .. (myisam, innodb, innodb+google patch, innodb+mysql patch, ndbcluster - sve to na obicnim 15K rpm diskovima i na SSD) posto su rezultati vrlo zanimljivi .. verujem da ce dobar deo tih grafikona biti dostupan posle MySQL User Conference 2009 ..

SSD diskovi imaju svoje mane koje ce se nadam se uskoro otkloniti ... imaju cesto manji retension rate nego obicni diskovi, manji vek trajanja (broj pisi brisi po jednom mestu) i slicno ... no kako je HP / IBM lab najzad "otkrio / napravio" memristor, mozemo se nadati novim RAM modulima neslucenih kapaciteta ...

Pozdrav drugari

Primjetio sam prije par dana jako kvalitetne diskusije ovde pa da se uključim...

Od iskustva imam žulj na dupetu nastao zadnjih 10-ak dana kako aktivno čitam dokumentaciju oko naprednog podešavanja MySQL-a i uopšte stvari oko HA sistema zasnovanih na MySQL-u i drugim bazama... Od obrazovanja imam položen predmet "Baze podataka" na ETF-u na kome smo pravili bazu podataka za neki video klub ili auto praonicu (ne sjećam se.. :)).. u MS Access-u .. Šalu na stranu.. :)

Što se tiče literature kupio sam High Performance MySQL (2nd edition) - http://www.amazon.com/High-Per...p;pf_rd_r=1W2PRHJ0TDVNWVWCJNDP.

Neka optimizacija se može napraviti i alatima sa http://www.ibm.com/developerworks/library/l-tune-lamp-3.html (u dnu stranice)

Poz i do čitanja...

Offtopic: Vidim da se prave majice ze ljeto i mislim da je Bogdan zaslužio minimalno jednu:)
a ovom što je postavio temu i ne treba ;)

pozz

odlicna knjiga. obrati paznju da je "tacna" samo za linux .. (ne moze se 1/1 primeniti na ostale os, no to joj nije ni bio cilj)... ima par delova oko HA gde se ne slazu svi sa petrom (deo oko drbd-a je sporan) ali generalno od pisanih izvora to je najbolja knjiga vezano za optimizaciju mysql-a na trzistu. svi koautori su radili nekoliko godina kao mysql support inzenjeri pre nego su odlicili napraviti svoju firmu, dakle za knjigu - svaka preporuka ... mislim da sam vec spominjao ali http://www.mysqlperformanceblog.com/ je njihov blog - najbolja online referenca vezano za mysql performance tuning.

Redovno čitam njihov blog... Tamo sam i našao knjigu i kupio je sa Amazona...

sva sreća da znam što se uči na fakultetima i to nema veze sa vezom ni praksom nni ičim drugim.

naučiš osnove i to je to.

a sve ostalo administracija , optimizacija, optimizacija sql-a, učiš na pravomj bazi u praksi.