[es] - MySQL dizajn za bolje performanse

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{17.03.2009. u 16:36 - pre 183 meseci}

Citat:

dusaSaLagera: Recimo ako imam tabelu friend(+s plus prefix pride :) ) sa kolonama friend_id1,friend_id2,...jos par kolona
Primarni kljuc mi je kompozitni friend_id1,friend_id2.
Dugo sam se dvoumio da li bi ikakvu korist dobio ako bih stavio kljuc i na friend_id1 jer se u where/joinima uglavnom ova kolona pojavljuje. Ako sam te dobro razumeo, moj pristup je ispravan, jel tako?

ne treba ti zaseban index na friend_id1 posto bi bio redundandan, samo bi usporavao insert/updata/delete a nista ne bi znacio pri select-u

Citat:

Takodje(ovako iz prve ruke da mi odgovoris ako mozes), u kolikoj meri je insert/update/select nad myISAM tabelama brze u odnosu na InnoDB engine?

sorry ali odgovor je ZAVISI :D

ako imas samo insert i nista vise, i to, bulk insert iz jednog treda ... myisam rulez :D brzi je ~3 puta od innodb-a

sve ostalo je "zavisi" ... myisam radi table lock a innodb radi row lock (u stvari page lock ali aj da ne idemo u crevca) sto znaci da teoretski 10 tredova mogu istovremeno da menjaju 10 razlicitih podataka ako koristis innodb a za myisam moraju jedan po jedan, posto myisam lepo zakljuca celu tabelu da bi dodao/promenio/obrisao jedan slog. tako da je u tom slucaju innodb brzi ..

za select .. zavisi .. select iz jedne tabele koja je dobro indexirana je nesto brzi sa myisam-om ali tu opet ima razlike kako je setovan server ... kada je join u pitanju sve zavisi ....

Citat:

Isto tako sam primetio da na vecini hostinga na kojima sam hostovao svoje web aplikacije InnoDB nije dobro podesen, pa se precesto desavalo pucanje(a uz to nisam znao tad za sve prednosti MySQLi - tipa automatski rollback transakcija i u slucaju pucanja skripte na nepredvidjenom delu - pre rollbacka...da napomenem - ako nije jasno, pricam o PHP) .

mnogi hosting provajderi su poceli da se bave hostingom sa par masina i pozajmljenim / ukradenim linkom.... stede na svemu, ponajvise na skupim/kvalitetnim inzenjerima tako da je u 99% slucajeva to problem ...
sa druge strane, ni mysql ni ostali open source db sistemi koje oni nude nisu bas optimizovani da ih koriste hosting provajderi ... mysql ne podrzava kvote po bazi tako da hosting provajderi idu i koriste trikove limitirajuci te sa kvotama na filesistemu (sto u slucaju povelike temp tabele ili prerastanja tvoje tabele zabada mysql jel mu filesistem uskrati dobrodoslicu - sto zabode CEO mysql a ne samo usera koji je napravio sr**e ...) ... neki pribegavaju skriptama koje "mere" velicinu pa ti zabodu usera kad ti baza predje kvotu i slicno ... isto tako ... ti ako na jednom serveru hostujes 10 baza, 1 user koji ima pristup jednoj bazi moze da "zauzme" ceo server ... tj da uzme sve resurse i da ostali useri mogu da pevaju ... sa prosecno nekoliko hiljada baza na hosting serveru to je prilicno veliki problem .... tako da hosting provajderi pribegavaju i tu trikovima i resetuju db server / zabadaju konekcije ako nesto "predugo traje" .. da ne spominjem opet da to uglavnom rade polupismeni ameri sa 2 nedelje kursa ili indijci koji su prepisivali na testu tako da je sve to u startu konfigurisano nogama :(

Citat:

Da li mi mozes dati neke inside informacije o cemu(kojim varijablama) da vodim racuna prilikom podesavanja mysql-a za InnoDB? Posto sada imam pristup svom serveru(tj nije bas moj, ali duga je to prica :) ). Da napomenem, recimo da mi je neki optimum da sajt radi normalno tako sto sam stavio 500 konekcija(mada cu verovatno morati vise) ka bazi u jednom trenutku. Dok je bilo na default podesavanjima(mislim da je oko 100 konekcija), ponestajalo je konekcija svakih par sekundi kad navale useri+botovi :)

:D :D :D
za botove imas da podesis u robots.txt koliko zelis da smaraju ... za ostala setovanja svog servera pogledaj temu namenjenu tome:
http://www.elitesecurity.org/t357167-Optimizacija-mySQL-servera
ili moj blog sa slicnim (malo drugacije organizovanim) informacijama: http://mysql.crsndoo.com/wp/2009/03/optimizacija-mysql-servera/

sto se php-a tice ... mysqli je mnogo bolji interface, ne znam koliko je stabilan ja ga licno nisam mnogo koristio (mozda 10tak malih projekata) ..
trebalo bi da je http://dev.mysql.com/downloads/connector/php-mysqlnd/ bolji od svih njih, ako ne "laksi" onda bar "Brzi" ali ja ga u zivotu nisam probao tako da .. tj http://dev.mysql.com/downloads/connector/php-mysqlnd/ je zamena za low level mysql drajver na php-u .. on bi trebalo da "poboljsa" rad sa mysqli-em .. ali .. "nikad probao" ..

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

dusaSaLagera
Kuci, Nema

Član broj: 191594
Poruke: 16
*.dynamic.sbb.rs.

Profil

Re: MySQL dizajn za bolje performanse

^{17.03.2009. u 17:23 - pre 183 meseci}

Hvala ti na odgovorima, a svakako cu prouciti malo i ovo sto si mi dao na linkovima.
Jedino da te razjasnim sta sam mislio na botove :) : nisam mislio samo na google, yahoo i ostale search & other stuff botove, vec na one zlonarne skripte koje ne daju nikakve dodatne informacije(tj ponasaju se kao i obici neregistrovani useri), ali stalno pokusavaju da se registruju i loguju na sajtu, imaju 100000 zahteva u sekundi(ovo sam resio na neki nacin, mada opet ne najbolji jer imam database session storage) i trose i bandwith i resurse. Mada sve ovo nije ni bitno i skroz je offtopic :).
Hvala jos jednom, ako budem imao jos nesto da pitam(a imacu sigurno) - pitacu.

Odgovor na temu

iizuzetan

Član broj: 186478
Poruke: 375
*.adsl.verat.net.

+16 Profil

Re: MySQL dizajn za bolje performanse

^{20.03.2009. u 09:30 - pre 183 meseci}

A da pitam, da li je brža pretraga ili računanje ili donosenje nekih računskih ili bilo kakvih zaključaka direktno iz MySQL baze podataka ili u PHP-u? Na primer imam dve tabele sa podacima i isčitam cele obe tabele pa napravim u PHP-u algoritam koji ce da mi pretrazi, izracuna ili donese odredjene zaključke.... Ili je brže ako napravim MySQL algoritam koji će to uraditi a u PHP-u da mi vrati samo krajnji rezultat pretrage ili šta već, tih dveju tabela?

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{20.03.2009. u 12:01 - pre 183 meseci}

Citat:

iizuzetan: A da pitam, da li je brža pretraga ili računanje ili donosenje nekih računskih ili bilo kakvih zaključaka direktno iz MySQL baze podataka ili u PHP-u?

:D .. zavisi :)

ako se mysql vrti na quad xeonu a php na 486 brzi je mysql, ako se mysql vrti na 486 a php na quad xeonu brzi je php .. ako su na istoj masini - zavisi ....

Citat:

Na primer imam dve tabele sa podacima i isčitam cele obe tabele pa napravim u PHP-u algoritam koji ce da mi pretrazi, izracuna ili donese odredjene zaključke.... Ili je brže ako napravim MySQL algoritam koji će to uraditi a u PHP-u da mi vrati samo krajnji rezultat pretrage ili šta već, tih dveju tabela?

vidi ovako, zamisli da su to dve "normalne" tabele sa po 2 miliona slogova ...
- iskopiras obe tabele u php
- napravis php skript koji ce da prodje kroz te podatke
- izracunas "rezultat"

kako to moze u bilo kom realnom slucaju da bude brze? Dakle to moze da bude brze samo ako su te dve tabele potpuno pogresno dizajnirane i taj upit napisan tako da mysql radi table scan ... pa cak i tada ce mysql nesto brze odraditi posao nego php...

uzmi primer .. imas tabelu od 1M slogova koja ima jedan integer. uradi "select avg(x) from t1;" iz mysql-a i povuci celu tabelu u php pa uradi u php-u avg ... onda izmeri vreme u prvom i vreme u drugom slucaju + izmeri koliko si memorije potrosio u prvom a koliko u drugom slucaju ...

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

iizuzetan

Član broj: 186478
Poruke: 375
*.adsl.verat.net.

+16 Profil

Re: MySQL dizajn za bolje performanse

^{20.03.2009. u 12:35 - pre 183 meseci}

Hvala na odgovoru. U principu shvatio sam odgovor, MySQL je "prva ruka" podataka a PHP "druga" pa je i logicno da je prva ruka brža jer "druga ruka" je malte ne dupliranje podataka i isčitavanje nepotrebnih. Samo da pojasnim naravno da je glupo i nisam mislio da treba izvlaciti sve podatke iz tabela pa praviti skriptu u PHP da bi se nesto naslo ako to "nesto" ima direktno ili indirektno iz par podataka iz baze. Mislio sam na neke podatke koje nemamo (skoro) direktno vec do kojih treba da se dodje recimo obradom mnogih podataka iz mnogih tabela a pritom pitanje je da li su i sve te tabele povezane (opisno na primer da bi to uradili preko baze MySQL upit treba da bude kilometarski :) ). Pitao sam jer nekako kako vreme odmice baze vise nisu baze podataka u izvornom smislu reci koje samo treba da omoguce brz pristup jednom podatku koji je trazen sa vise mesta u jednom trenutku vremena. Baze sve vise prerastaju u programe koji racunaju, uporedjuju idt koje je nekad radio samo program. Naravno ovo prosirenje funkcije baza je itekako opravdano ukoliko se bar 1% ubrzava donosenje krajnjeg rezultata. Nikad nisam radio u bazama koje imaju 1M slogova pa zato i pitam sta je brze jer ti imas iskustva. A glupo je išta testirati i meriti "prolazna vremena" vezano za stvari iz mog pitanja na MySQL bazi koja ima desetak ili sotinak tabela sa po desetak kolona. Na kraju krajeva ako se vec stvar krece u tom smeru da baze sve vise preuzimaju funkcije PHP programa ili bilo kog drugog onda je logicno da se integrisu PHP i MySQL u jednu celovitu, na primer nazovimo to "MyPHPSQL" programsku platformu, ili na primer PHP+BAZA, ili samo PHPB, ili MySQLPHP sve u zavisnosti da li PHP programeri ili MySQL programeri prvi naprave integraciju . Sto opet dolazimo do moje teorije da sve je jedinstveno po principu COMMODORE64 i da se vratimo Nemackom shvatanju filozofije računara a ne Američkom profitabilnom windows shvatanju i filozofiji!! Na primer RAM memorija i HARD, u buducnosti ce samo biti RAM jer je glupo imati sporu memoriju kad vec postoji brza tehnologija, kao i glupo je imati baze ako vec imamo programe itd da ne sirim temu, ili glupo je imati bazu ako vec imamo "inteligentne" procesor memorije u NASA-i i pentagonu. Ali naravno za nas OVCE od obicnih ljudi sve mora po Americkoj filozofiji da se "isecka" u male "porcije" kako bi se sto vise "isisao" novac i profit.

_{[Ovu poruku je menjao iizuzetan dana 20.03.2009. u 13:56 GMT+1]}

_{[Ovu poruku je menjao iizuzetan dana 20.03.2009. u 13:58 GMT+1]}

_{[Ovu poruku je menjao iizuzetan dana 20.03.2009. u 14:01 GMT+1]}

_{[Ovu poruku je menjao iizuzetan dana 20.03.2009. u 14:05 GMT+1]}

_{[Ovu poruku je menjao iizuzetan dana 20.03.2009. u 14:12 GMT+1]}

_{[Ovu poruku je menjao iizuzetan dana 20.03.2009. u 14:14 GMT+1]}

_{[Ovu poruku je menjao iizuzetan dana 20.03.2009. u 14:17 GMT+1]}

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{20.03.2009. u 13:28 - pre 183 meseci}

Citat:

MySQL je "prva ruka" podataka a PHP "druga" pa je i logicno da je prva ruka brža jer "druga ruka" je malte ne dupliranje podataka i isčitavanje nepotrebnih.

to je ok analogija, obrati paznju da nije samo pitanje o iscitavanju nepotrebnih podataka ... neke stvari mysql moze da izvuce direktno iz indexa bez pipanja tabele, neke stvari moze da izvuce na "specifican nacin", na primer ima storage engine koji ti u 1 koraku vraca bilo koji sum, avg, max, min podatak za bilo koji numeric iz tabele ... i slicno .. tako da, one podatke koje moze mysql da vrati, treba mysql da vrati, nista ti neces (pogotovo ne u php-u koji je interpreter) brze odraditi matematiku nego sto ce to odraditi mysql koji u pomoc moze da koristi i indexe, da cita samo potrebna polja i slicno.

Citat:

Samo da pojasnim naravno da je glupo

pored onog "there is no silver bullet", ja volim da kazem i da "nema glupih pitanja / glupih resenja" ... resenje moze da bude manje ili vise optimalno, ako radi - resenje je i nije glupo .. a da moze bolje - uvek moze bolje ..

Citat:

Mislio sam na....

teoretski, nekada se nad podacima mora izvrsiti malo kompleksniji zahtev. tada mozemo deo podataka baciti klijentu da ih obradi, ili, napisati "stored procedure" koja ce to odraditi ... ne bih sada ulazio u detalje posto je tema vezana za modeliranje baze podataka a ne za programiranje ...

Citat:

Pitao sam jer nekako kako vreme odmice baze vise nisu baze podataka u izvornom smislu reci koje samo treba da omoguce brz pristup jednom podatku koji je trazen sa vise mesta u jednom trenutku vremena

tu se necemo sloziti ... RDBMS je to, uvek je bio to i uvek ce biti to ... ono na sta treba obratiti paznju je da jedan "program" ne mora da ima samo jednu funkciju .. kao sto masina xyz moze i da pere i da susi ves a masina zzy moze samo da pere .. to ne znaci da sada pranje vesa postaje i susenje ... vec da masina moze i jedno i drugo ...

MySQL je RDBMS, ne pretenduje da radi nista drugo, nema u planu da u skorije vreme radi bilo sta drugo i ni u jednom trenutku nije zamisljen da radi ista drugo ... Ako pogledamo neki drugi sistem, na primer Oracle, on jeste pored toga sto je RDBMS i mnogo sta drugog .. MySQL je zamisljen kao deo nekog sistema koji je AS (isto kao i M$ SQL, DB2 i mnogi drugi), dok na primer Oracle pretenduje (od starta) da "bude sistem" da bude full platforma koja vrti celu aplikaciju... mislim .. oracle ima svoj web server ... sta dalje pricati .. RDBMS je samo jedan deo onoga sto Oracle moze ... (necemo sada ulaziti u to koliko one druge stvari dobro radi, niti je ovo mesto da pricamo o oraklu)

Citat:

Nikad nisam radio u bazama koje imaju 1M slogova

ne znam sta da ti kazem, 1M slogova je mala baza .. obican log / statistika za 3 bloga imaju nekoliko tabela sa vise od 1M slogova .. to su tabele po 10-20MB .. to uopste nije veliko .. velike tabele su preko 1G, ogromne su oko 1T a one vece su i dalje "veeeeeeeeeeeeeeelike" :D

Citat:

onda je logicno da se integrisu PHP i MySQL u jednu celovitu, na primer nazovimo to "MyPHPSQL" programsku platformu, ili na primer PHP+BAZA, ili samo PHPB, ili MySQLPHP sve u zavisnosti da li PHP programeri ili MySQL programeri prvi naprave integraciju

nisam bas preterano "Stalozen" da bi mogao ovo da prokomentarisem bez da ... - ovo je klasican sto x a ne y ... prvo .. zasto php a ne java ili c ili dot nemoj ili paskal ili rubi ili ... ne mislim da se php bilo cime istice u odnosu na bilo koji od ovih ... (nemoj me pogresno svatiti ja imam mnogo vise iskustva sa php-om nego sa javom i rubijem, mnoooogo vise nego sa dot nemoj ... ali .. nista php nije bolji od asp-a) ... no .. onda treba da integrisemo i web server? sto apache a ne websphere ili neki peti ? ...

MySQL je RDBMS, i on je deo jednog sistema (LAMP / SAMP / WAMP su najpopularniji ali nisu jedini) te niti postoji ikakav realan razlog - niti postoji bilo kakva pretenzija da mysql postane sistem per se. Uvek je bolje raditi jednu stvar da valja nego tri polovicno ... posebno sto nikakav benefit niko ne bi imao od toga ..

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu

bantu

Član broj: 38670
Poruke: 305
89.111.240.*

+27 Profil

Re: MySQL dizajn za bolje performanse

^{20.03.2009. u 14:12 - pre 183 meseci}

@iizuzetan: Al' ga sada otjera u neku tešku filozofiju.

Ja lično preferiram javu i mislim da kada bi se i desilo to o čemu pričaš ta integracija PHP MySQL da bi MySQL izgubio čitav jedan community programera. Ovako je bolje imaš slobodu da si izabereš platformu kako ti odgovara i bog te vido, RDBMS koji hoćeš, app server koji hoćeš i uživaj.
Ali mislim da se polako udaljavamo od teme. :)

Odgovor na temu

balavi

Član broj: 175011
Poruke: 797
79.101.76.*

+104 Profil

Re: MySQL dizajn za bolje performanse

^{10.04.2009. u 08:54 - pre 182 meseci}

Odlican text Bogdane, lepo objasnjena normalizacija, napokon je sad skontah!

Odgovor na temu

Miroslav Ćurčić
ex mVeliki
Novi Sad

Član broj: 19034
Poruke: 1118
..2.252.195.static.beotel.net.

+19 Profil

Re: MySQL dizajn za bolje performanse

^{10.04.2009. u 12:08 - pre 182 meseci}

Pre nekih 4 godine sam testirao brzine baš zbog ovakvih pitanja i došao do zaključaka:

vreme potrebno za izvršavanje jednog prostog upita (jednostavan SELECT) je isto kao i za stotinak naknadnih dovlačenja rezultata (fetch), pa je kod malih tabela (do 50kb) praktično isto hoćeš li čitati jedan red ili celu tabelu, tako da kad sam siguran da će mi bar nešto trebati iz tabele ja je pročitam celu u bafer pa kasnije kako šta zatreba vadim iz bafera

isto tako, kad bi istu tu malu tabelu umesto u mysql-u držao u običnoj lokalnoj datoteci i čitao je sa fread(), potrebno vreme je skoro 100 puta kraće

Test je bio na localhost wamp okruženju na 900mhz.

Posledica testa, tamo gde mi ne treba neka napredna pretraga ili join-ivanje (razne konfiguracione tabele npr.) držim u lokalnoj datoteci.

_{"The quieter you become, the more you are able to hear."}
Blog | PowerCMS

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.xdsl.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: MySQL dizajn za bolje performanse

^{10.04.2009. u 12:24 - pre 182 meseci}

Citat:

vreme potrebno za izvršavanje jednog prostog upita (jednostavan SELECT) je isto kao i za stotinak naknadnih dovlačenja rezultata (fetch), pa je kod malih tabela (do 50kb) praktično isto hoćeš li čitati jedan red ili celu tabelu, tako da kad sam siguran da će mi bar nešto trebati iz tabele ja je pročitam celu u bafer pa kasnije kako šta zatreba vadim iz bafera

isto tako, kad bi istu tu malu tabelu umesto u mysql-u držao u običnoj lokalnoj datoteci i čitao je sa fread(), potrebno vreme je skoro 100 puta kraće

Posledica testa, tamo gde mi ne treba neka napredna pretraga ili join-ivanje (razne konfiguracione tabele npr.) držim u lokalnoj datoteci.

mnoooogo se promenilo za 4 godine :)

1. svaki db server danas (ukljucujuci mysql) kesira podatke tako da ce ta tvoja tabela od 50k biti u ramu sve vreme ako je sve podeseno kako treba
2. mysql dodatno ima query_cache koji moze da se upotrebi
3. svaki iole normalan db server (ukljucujuci mysql) ima podrsku za memory tabele - tako da to uvek mozes da koristis kada je potrebno

varijantu da ti se 90% podataka nalazi u bazi a 10% po fajlovima na disku - to je dizajn koji ne zelim uopste da komentarisem

par cinjenica
- tabela sa manje od 100 redova slabo moze da iskoristi prednost indexa .. nju svejedno rdbms drzi u ramu i izbacuje iz istog samo kad mora
- ako vam upit vraca vise od 50% rezultata iz jedne tabele, index u toj tabeli nema preterano bitan uticaj na performanse - caj stavise - mozda usporava celu pricu
- kesiranje je jedan od osnovnih nacina za povecanje performansi... mysql sa "default" setovanjem ne uzima dovoljno ram-a za kesiranje .. pisano je vec o tome kako konfigurisati mysql server tako da necu sad da se ponavljam
- kesiranje ne podrazumeva samo kesiranje na bazi, postoji kesiranje u aplikaciji kao i kesiranje izmedju aplikacije i baze .. vise o tome neki drugi put (bas spremam neki txt na tu temu)
- normallizacija je bitna ali ne znaci uvek ubrzanje, potrebno je znati i neke interne stvari o serveru sa kojim radite da bi pravilno optimizovali bazu... na primer, spominjao sam da mysql u jednom upitu moze da koristi max 3 indexa... ima jos mnogo slicnih ogranicenja i za ovaj rdbms i za sve druge ..
- ne optimizuje se isto baza sa pata, sata ili san storage subsistemom ...
- ne optimizuje se isto baza koja ima odnos upit:upis 1000:1 i baza koja ima 2:1 ili 1:1 ili 1:50

etc etc etc ...

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Odgovor na temu