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 |
|
Alati teme | Način prikaza |
|
03. 12. 2012. | #1 |
novi član
Na probnom radu
Datum učlanjenja: 17.05.2012
Poruke: 18
Hvala: 4
0 "Hvala" u 0 poruka
|
Optimizacija baze - neki savet
Radim neku aplikaciju i zelim sto bolje da je testiram...
Zato sam ubacio 220 miliona unosa. Upit se izvrsava samo nad jednom tabelom. Pre toga stavio sam indeks na polje po kome se vrsi pretraga ono koje je u WHERE. To polje je VARCHAR. E sad.. Prvi put kada trazim nesto rezultat mi vrati za nekih 3 min. A svaki sledeci upit izvrsava za 0.04 sec i slicno... Mislio sam da ovaj index da ce ubrza i prvi put vracanje podataka... Jel ima neko savet, ili link na netu kako da optimizujem bazu, tj tabelu da mi uvek vrati za sto krace vreme.. Pored dodeljivanja Index-a koloni, uradio sam i optimizaciju na sledeci nacin OPTIMIZE TABLE `tabela` Zanima me sta jos mogu da ucinim? Poslednja izmena od etelteam : 03. 12. 2012. u 14:20. |
03. 12. 2012. | #2 |
Ivan Dilber
Sir Write-a-Lot
|
to sto je drugi upit brzi je zbog cache-iranja, nema veze sa indexima...
Dodaj EXPLAIN ispred tvog sql upita da bi dobio vise podataka o tome kako se izvrsava upit i da li zaista koristi index ili ne. Nesto vise od toga tesko da mogu da ti pomognem posto nisi napisao koji je upit u pitanju
__________________
Leadership is the art of getting people to want to do what you know must be done. |
03. 12. 2012. | #3 |
VD IT Direktora
Invented the damn thing
Datum učlanjenja: 08.06.2005
Lokacija: Beograd
Poruke: 2.118
Hvala: 503
1.307 "Hvala" u 282 poruka
|
Pa ima veze i sa indexima. Index je znatno lakše i brže iskeširati nego celu tabelu, a i manji je tako da je veća verovatnoća da će biti keširan prilikom idućih upita.
__________________
blog |
03. 12. 2012. | #4 |
profesionalac
Professional
Datum učlanjenja: 08.11.2010
Poruke: 211
Hvala: 68
78 "Hvala" u 32 poruka
|
Ukoliko planiras da ti korisnici rade pretragu na 22m redova, zaboravi na bazu.
Ja koristim Search Lucene i odlican je http://lucene.apache.org/core/ Postoji klasa skoro za sve jezike. Poslednja izmena od tasmaniski : 03. 12. 2012. u 14:34. |
14. 01. 2013. | #5 |
novi član
Na probnom radu
Datum učlanjenja: 17.05.2012
Poruke: 18
Hvala: 4
0 "Hvala" u 0 poruka
|
I dalje pitanje oko optimizacije baze... Pretraga i iscitavanje podataka iz tabele koja se updejtuje na 2-3 min...
Imam tabelu sa 2 miliona unosa. Neka se zove tabela 1. Takodje imam i tabelu arhiva, u kojoj preko crona stavljam podatke starije od 6 meseci. U ovoj prvoj znaci imam 2 miliona unosa. I sada imam neki module u kome radim statistiku. Pretrazivanje vrsim po jednom polju koji je primarni kljuc i index. Napomena : tabela se updejtuje na 2-3 min. Kada izaberem statistiku za danasnji dan (imam danasnji dan, nedelja, mesec, 6 meseci) ucitavanje traje oko 40 sekunde. I grupa korisnika bi trebalo da gleda statistiku. Jedno od resenja je bilo i sql particije ali su one u WHERE upit podrzane od verzije 5.6, koja je u razvojnoj fazi. http://lucene.apache.org/core/ -> ovo resenje je u razmatranje za sada. Vise me zanima dal moze jos nesto da se ucini po pitanju baze i pretrage. |
14. 01. 2013. | #6 | |
expert
Grand Master
|
Citat:
kolega, koji je tad bio mnogo iskusniji, mi rece da ovo nije dobar pristup medjutim - statistika radi i dan danas inace, razmotri i neke druge baze, mislim da postgre ima particije |
|
03. 12. 2012. | #7 |
Ivan Dilber
Sir Write-a-Lot
|
^ @jablane: ovo o cemu on prica (prvi upit spor, drugi brz) je mysql query cache, naprosto se kesira rezultat upita i kad postavis isti taj upit ponovo, on ti ga vrati iz memorije.. (koliko ja znam) nema veze sa tim jel indexirana pretraga ili ne..
a posto mu pretaga traje 3 min. u lokalu verovatno upit ni ne koristi indexe ili je index prevelik da stane u cache
__________________
Leadership is the art of getting people to want to do what you know must be done. Poslednja izmena od ivanhoe : 03. 12. 2012. u 17:40. |
03. 12. 2012. | #8 |
expert
Grand Master
Datum učlanjenja: 11.04.2010
Poruke: 998
Hvala: 141
959 "Hvala" u 153 poruka
|
http://dev.mysql.com/doc/refman/5.1/...-defaults.html my-huge.cnf
Probaj sa http://dev.mysql.com/doc/refman/5.1/...in-select.html znači... Kôd:
SELECT SQL_NO_CACHE id, ime FROM tabela; Postavi query koji koristiš, i postavi output od EXPLAIN EXTENDED... |
03. 12. 2012. | #9 |
Super Moderator
Knowledge base
Datum učlanjenja: 21.03.2006
Lokacija: Kragujevac
Poruke: 1.878
Hvala: 291
1.345 "Hvala" u 355 poruka
|
Čak i da je isključen query keš, kada se isti upit ponovi dva puta zaredom, drugi upit će u većini slučajeva biti brži nego prvi. Fora je što i sam sql povuče neke ključeve i tabele u memoriju, i file system nešto pomalo kešira itd. itd. i rezultat obično uvek bude brži nego prvog puta.
|
|
|