 |
|
| Igor Manjenčić |
14. 12. 2010. 00:04 |
Optimizacija baze - da li odvajati u novu tabelu?
Oduvek me je interesovala optimizacija baze podataka i stalno slušam svakakve "cake" za poboljšanje performansi.
Da li je skuplja operacija pronalaženja tabele (u moru tabela) i izvršavanje jednostavnog upita nad manjom tabelom (sa manje unosa i manje polja) ili izvršiti jedan upit nad većom tabelom? Da li je uopšte skupa operacija pronalaženja same tabele u ogormnoj bazi.
Drugo pitanje, na koji način biste realizovali sistem notifikacija (kao fb recimo) gde imamo nekoliko hiljada korisnika online koji na 1 sekund izvršavaju upit nad tom tabelom (ili tabelama)? A opet potrebno je u tu tabelu često ubacivati. Ok, ta tabela (ako je jedna) ne bi imala više od 3 polja i ne bi imala mnogo unosa jer bi se stariji arhivirali u drugu tabelu koja bi se zvala tek po potrebi. Da li je to jedino što se može učiniti. Šta predlažete?
Treće pitanje je vezano za chat sistem i kako optimizovati taj deo baze. I ako možete da se ograničite samo na mySQL :)
Hvala
|
| misk0 |
14. 12. 2010. 00:15 |
Ne postoji 'silver bullet' koji rjesava sve probleme tj 'najoptimalnija varijanta za sve'. Uvijek je rijesenje zavisno od konkretne situacije tako da bi bilo bolje da dodjes sa konkretnim tabelama, upitima, upisima, frekvencijom i slicno pa ti se onda moze i pomoci.
Facebook mislim da koristi Cassandra-u tj noSQL bazu podataka gdje su pravila drugacija.
|
| dinke |
14. 12. 2010. 00:15 |
Citat:
Originalno napisao Igor Manjenčić
(Napišite 92854)
Oduvek me je interesovala optimizacija baze podataka i stalno slušam svakakve "cake" za poboljšanje performansi.
Da li je skuplja operacija pronalaženja tabele (u moru tabela) i izvršavanje jednostavnog upita nad manjom tabelom (sa manje unosa i manje polja) ili izvršiti jedan upit nad većom tabelom? Da li je uopšte skupa operacija pronalaženja same tabele u ogormnoj bazi.
|
Mislim da bi kreiranje gomile malih tabelica koje na ne znam koji nacin nalazis pa vrsis upite nad njima bio totalno pogresan nacin, svojsvten onima koji slabo poznaju rdbms sisteme (mada ko zna mozda sam ja u krivu) :)
Dakle, onako kako bih ja resio pomenuti problem:
1) Prvo pogledas sadrzaj tih tabela, da li sva polja koja pretrazujes moraju biti tu? Da li su tipovi polja optimizovani u odnosu na sadrzaj tabele? Npr ako za neko checked 0/1 koristis int, to znaci da trosis 3 bajta po polju vise nego sto treba, pa puta milion slogova = 3MBajt ... veca tabela = sporija tabela
2) Koristi fiksne tipove kada je to moguce, npr za smestanje ip adresa bolje je koristiti char nego varchar polje (brze je). Not null bi trebao biti brzi od Null polja itd.
3) Koristi indexe i explain za optimizaciju istih :)
4) Ako imas puno upisa/citanja istovremeno predji na innodb, u nasem slucaju pokazao se mnogo bolje od myisam (low level locking)
5) Bolji hardware
Citat:
Originalno napisao Igor Manjenčić
(Napišite 92854)
Drugo pitanje, na koji način biste realizovali sistem notifikacija (kao fb recimo) gde imamo nekoliko hiljada korisnika online koji na 1 sekund izvršavaju upit nad tom tabelom (ili tabelama)? A opet potrebno je u tu tabelu često ubacivati. Ok, ta tabela (ako je jedna) ne bi imala više od 3 polja i ne bi imala mnogo unosa jer bi se stariji arhivirali u drugu tabelu koja bi se zvala tek po potrebi. Da li je to jedino što se može učiniti. Šta predlažete?
Treće pitanje je vezano za chat sistem i kako optimizovati taj deo baze. I ako možete da se ograničite samo na mySQL :)
Hvala
|
Memcache? |
| misk0 |
14. 12. 2010. 00:25 |
Citat:
Originalno napisao dinke
(Napišite 92856)
2) Koristi fiksne tipove kada je to moguce, npr za smestanje ip adresa bolje je koristiti char nego varchar polje (brze je). Not null bi trebao biti brzi od Null polja itd.
|
Za IP adrese kazu da je najbolje koristiti - INT i ugradjene INET_ATON i INET_NTOA funkcije.
Kôd:
mysql> SELECT INET_ATON('192.168.10.50');
+----------------------------+
| INET_ATON('192.168.10.50') |
+----------------------------+
| 3232238130 |
+----------------------------+
1 row in set (0.00 sec)
mysql> SELECT INET_NTOA(839559360);
+----------------------+
| INET_NTOA(839559360) |
+----------------------+
| 50.10.168.192 |
+----------------------+
1 row in set (0.00 sec)
|
| dinke |
14. 12. 2010. 00:39 |
Kazu :) I kako onda dobijes jedan pool? Npr :
Kôd:
select whatever where ip like '192.168.%';
Ovo gore ce kao suffix search koristiti index, da vidim da to urdi neka f-ja :) I inace (kada je optimizacija u pitanju) uvek je bolje koristiti fixed pretragu nego f-ju, npr:
PHP kôd:
$current_date = date("Y-m-d");
$db->query("select whatever from foo_table where date_field = '$current_date' ");
ce biti brze nego :
Kôd:
select whatever from foo_table where date_field = current_date();
|
| MorenoArdohain |
14. 12. 2010. 00:40 |
Ako imas mogucnosti da furas nesto drugo osim MySql, istrazi non-relational baze tipa MongoDB, Cassandra ili Redis (key-value dbs).. Imas boljih resenja koje po performansama tuku MySQL nekoliko desetina puta (procackaj benchmark testove na netu). Jedina caka je sto ce ti trebati vise vremena da udjes u stos, pogotovu ako si dosad radio samo sa relational bazama.
|
| misk0 |
14. 12. 2010. 00:50 |
Citat:
I inace (kada je optimizacija u pitanju) uvek je bolje koristiti fixed pretragu nego f-ju,
|
Ovo ne znam za mySQL ali kad sam citao Oracle literaturu rekli su da se vrijednost fixira na pocetku upita i da nece tokom svake iteracije ponovo da poziva funkciju i izracunava vrijednost. |
| dinke |
14. 12. 2010. 00:53 |
|
| dinke |
14. 12. 2010. 00:55 |
@MorenoArdohain
Dobro bre pusti coveka da prvo nauci MySQL, nemoj odmah te razne Kasandre, Ljovisne, Madres egoistas ...
|
| MorenoArdohain |
14. 12. 2010. 00:56 |
Dzabe uci MySQL ako nece moci da mu izgura zahteve :)
|
| Vreme je GMT +2. Trenutno vreme je 20:10. |
|
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.
Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.