DevProTalk

Forumi IT profesionalaca
web development, web design, e-business, SEO


Idite nazad   DevProTalk > Web development i web aplikacije > SQL baze podataka - Sponzor: Baze-Podataka.net
Beach Wedding Dresses - Looking for the Wedding Dress? Here, 1dress.co.uk stunning collection of beach wedding dresses is just what you are looking for.
charles wang

SQL baze podataka - Sponzor: Baze-Podataka.net MySQL, MSSQL, Oracle, Access, ODBC. Ako imate problem brže i preciznije ćete dobiti odgovor ako priložite strukturu tabela ili skript koji kreira tabele i puni ih test podacima umesto što to problem opisujete samo rečima. Sponzor: Baze-Podataka.net - Blog o bazama podataka

Odgovori
 
Alati teme Način prikaza
Staro 14. 12. 2010.   #1
Igor Manjenčić
novi član
Na probnom radu
 
Avatar Igor Manjenčić
 
Datum učlanjenja: 10.12.2010
Poruke: 11
Hvala: 2
1 "Hvala" u 1 poruci
Igor Manjenčić is on a distinguished road
Default 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
__________________
Igor Manjenčić blog
Igor Manjenčić je offline   Odgovorite uz citat
Staro 14. 12. 2010.   #2
misk0
majstor
Wrote a book
 
Avatar misk0
 
Datum učlanjenja: 30.01.2006
Lokacija: Lugano - Switzerland
Poruke: 1.251
Hvala: 219
106 "Hvala" u 67 poruka
misk0 će postati "faca" uskoromisk0 će postati "faca" uskoro
Pošaljite ICQ poruku za misk0 Pošaljite poruku preko Skype™ za misk0
Default

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.
misk0 je offline   Odgovorite uz citat
Staro 14. 12. 2010.   #3
dinke
Super Moderator
Invented the damn thing
 
Avatar dinke
 
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
591 "Hvala" u 193 poruka
dinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamen
Default

Citat:
Originalno napisao Igor Manjenčić Pogledajte poruku
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ć Pogledajte poruku
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?
__________________
Caught in a Web|Blogodak
With great power comes great responsibility!
dinke je offline   Odgovorite uz citat
"Hvala" dinke za poruku:
Staro 14. 12. 2010.   #4
misk0
majstor
Wrote a book
 
Avatar misk0
 
Datum učlanjenja: 30.01.2006
Lokacija: Lugano - Switzerland
Poruke: 1.251
Hvala: 219
106 "Hvala" u 67 poruka
misk0 će postati "faca" uskoromisk0 će postati "faca" uskoro
Pošaljite ICQ poruku za misk0 Pošaljite poruku preko Skype™ za misk0
Default

Citat:
Originalno napisao dinke Pogledajte poruku
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)
misk0 je offline   Odgovorite uz citat
Staro 14. 12. 2010.   #5
dinke
Super Moderator
Invented the damn thing
 
Avatar dinke
 
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
591 "Hvala" u 193 poruka
dinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamen
Default

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();
__________________
Caught in a Web|Blogodak
With great power comes great responsibility!
dinke je offline   Odgovorite uz citat
Staro 14. 12. 2010.   #6
MorenoArdohain
Knowledge base
Wrote a book
 
Avatar MorenoArdohain
 
Datum učlanjenja: 16.06.2005
Lokacija: Novi Sad
Poruke: 1.437
Hvala: 37
131 "Hvala" u 82 poruka
MorenoArdohain će postati "faca" uskoroMorenoArdohain će postati "faca" uskoro
Default

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.
__________________
Năo quero mais seguir um só caminho
MorenoArdohain je offline   Odgovorite uz citat
Staro 14. 12. 2010.   #7
misk0
majstor
Wrote a book
 
Avatar misk0
 
Datum učlanjenja: 30.01.2006
Lokacija: Lugano - Switzerland
Poruke: 1.251
Hvala: 219
106 "Hvala" u 67 poruka
misk0 će postati "faca" uskoromisk0 će postati "faca" uskoro
Pošaljite ICQ poruku za misk0 Pošaljite poruku preko Skype™ za misk0
Default

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.
misk0 je offline   Odgovorite uz citat
Staro 14. 12. 2010.   #8
dinke
Super Moderator
Invented the damn thing
 
Avatar dinke
 
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
591 "Hvala" u 193 poruka
dinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamen
Default

^ http://net.tutsplus.com/tutorials/ot...est-practices/
__________________
Caught in a Web|Blogodak
With great power comes great responsibility!
dinke je offline   Odgovorite uz citat
Staro 14. 12. 2010.   #9
dinke
Super Moderator
Invented the damn thing
 
Avatar dinke
 
Datum učlanjenja: 06.06.2005
Poruke: 2.371
Hvala: 370
591 "Hvala" u 193 poruka
dinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamendinke je pravi dragi kamen
Default

@MorenoArdohain
Dobro bre pusti coveka da prvo nauci MySQL, nemoj odmah te razne Kasandre, Ljovisne, Madres egoistas ...
__________________
Caught in a Web|Blogodak
With great power comes great responsibility!
dinke je offline   Odgovorite uz citat
Staro 14. 12. 2010.   #10
MorenoArdohain
Knowledge base
Wrote a book
 
Avatar MorenoArdohain
 
Datum učlanjenja: 16.06.2005
Lokacija: Novi Sad
Poruke: 1.437
Hvala: 37
131 "Hvala" u 82 poruka
MorenoArdohain će postati "faca" uskoroMorenoArdohain će postati "faca" uskoro
Default

Dzabe uci MySQL ako nece moci da mu izgura zahteve
__________________
Năo quero mais seguir um só caminho

Poslednja izmena od MorenoArdohain : 14. 12. 2010. u 01:58. Razlog: gramatika
MorenoArdohain je offline   Odgovorite uz citat
Odgovori


Alati teme
Način prikaza

Pravila pisanja
Možete ne započinjati nove teme
Možete ne slati odgovore
Možete ne slati priloge
Možete ne izmeniti svoje poruke
vB kôd je Uključen
Smajliji su Uključen
[IMG] kod je Uključen
HTML kôd je Isključen
Pogledajte forum

Slične teme
Tema Početna poruka teme Forum Odgovori Poslednja poruka
Gde i kako smo docekali Novu? 3banchi Opušteno 8 02. 01. 2010. 01:11
Šta bi sa forumom za novu godinu? mangia Obaveštenja, predlozi i pitanja 61 21. 01. 2009. 16:38
javascript - kretanje kroz tabelu bodi dilber Sva početnička pitanja 7 27. 08. 2008. 10:45
princip unosa u tabelu [nq] SQL baze podataka - Sponzor: Baze-Podataka.net 10 06. 03. 2007. 14:09
Problem sa upisom u tabelu bokey SQL baze podataka - Sponzor: Baze-Podataka.net 6 12. 09. 2006. 14:44


Vreme je GMT +2. Trenutno vreme je 05:32.


Blogodak - Domaci blogovi na jednom mestu Caught in a web - web dev blog
Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2017, 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.