Optimizacija baze - da li odvajati u novu tabelu?

[Igor Manjenčić]

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]

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]

Originalno napisao Igor Manjenčić

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

Originalno napisao Igor Manjenčić

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]

Originalno napisao dinke

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.

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]

Kazu I kako onda dobijes jedan pool? Npr :

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 :

select whatever from foo_table where date_field = current_date();

[MorenoArdohain]

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]

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]

^ http://net.tutsplus.com/tutorials/ot...est-practices/

[dinke]

@MorenoArdohain
Dobro bre pusti coveka da prvo nauci MySQL, nemoj odmah te razne Kasandre, Ljovisne, Madres egoistas ...

[MorenoArdohain]

Dzabe uci MySQL ako nece moci da mu izgura zahteve