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
Želite da se reklamirate ekskluzivno na ovoj poziciji? Javite se

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 15. 06. 2012.   #1
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
275 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default Dizajn search baze podataka?

Oh well...
To sto pisem ovde znaci da sam bas zapao u corsokak

Imao sam 'search' na sajtu koji je do sada sa MyISAM tabelama funkcionisao zadovoljavajuce [ili pak ja nisam primetio da se zapucava]

Problem je nastao kada sam sve tabele konvertovao u InnoDB

No, hajde da se vratimo na pocetak - dizajn tabela:

Imamo standardno dve tabele - words-index i positions-of-words.

words-index tabela:
WordID - naravno unique key
Word - unique polje [dakle isto index]

positions-of-words tabela:
ArticleID - index
WordID - index

kada se radi pretraga - pokupim WordID-eve od datih reci, i onda ide query:

SELECT ArticleID, WordID, COUNT(WordID) AS pogodaka FROM positions-of-words WHERE WordID IN (... spisak WordID-eva...) GROUP BY ArticleID HAVING pogodaka>=4 ORDER by ArticleID DESC LIMIT 0, 12;

ova cetvorka gore je broj reci [varira od broja WordID-eva].

sta query radi:
- nadje sve ArticleID-eve koji sadrze navedene reci (WordID IN (...))
- grupise ih po ArticleID (GROUP BY ArticleID) - ovo nazivam 'ukrštanje'
- generise polje 'pogodaka' koje oznacava koliko je zadatih reci nadjeno u datom zajednickom artiklu (COUNT(WordID) AS pogodaka) - odnosno u ukrstenoj grupi odozgo
- odstranjuje sa liste artikle koji ne sadrze sve reci pretrage (HAVING pogodaka>=)

sve ovo lepo radi dok neko ne pretrazi rec (WordID) koja se u nalazi u 100.000 artikla - jer to znaci da je i u 'positions-of-words' tabeli ima u 100.000 row-a.
I tu stvar zapne - po minut-dva mu treba da pohvata ceo index za datu rec. Jos ako pretrazi dve-tri takve reci u istom upitu - eto ludila.

Evidentan problem ovde je taj sto on mora sav index artikla za datu rec da fetchuje - da bi ih ukrstio sa indexom artikla druge reci [trece, cetvrte...] - da bi mogao da nadje zajednicke artikle...
To je ogromna kolicina podataka.

EXPLAIN daje sledece:
Kôd:
+----+-------------+---------------------+-------+---------------+--------------+---------+------+-------+-------------+
| id | select_type | table               | type  | possible_keys | key          | key_len | ref  | rows  | Extra       |
+----+-------------+---------------------+-------+---------------+--------------+---------+------+-------+-------------+
|  1 | SIMPLE      | positions-of-words  | index | WordID        | ArticleID    | 4       | NULL | 57691 | Using where |
+----+-------------+---------------------+-------+---------------+--------------+---------+------+-------+-------------+
A nemam ideju kako da ih 'ukrstim' a da ne fetchujem sav index za date reci... to je zapravo i nemoguce pri ovom dizajnu tabela.

InnoDB je naravno zahtevao da se doda UNIQUE ID KEY u tabeli 'positions-of-words'. Dodao sam, to je ubrzalo stvari malo, bar za manje koriscene reci, ali kod mnogo koriscenih reci i dalje izvrsava upit po par minuta.
Buffer pool size je naravno setovan na 70% RAM-a, i ceo index je u RAM memoriji [Buffer pool hit rate 1000 / 1000].

I dalje mi nije jasno zasto se sa MyISAM tabelom ovo sve izvrsavalo za svega par sekundi.

Moze li neko bar da mi da neku smernicu - u kom pravcu da kopam.
Ako je query los - postoji li neki drugi nacin da 'preklopim' indexe od svake reci u search frazi... ili je ceo koncept los?
__________________
Vesti | MyCity | Igrice | Zaštita od virusa

Poslednja izmena od Peca : 15. 06. 2012. u 15:23.
Peca je offline   Odgovorite uz citat
Staro 15. 06. 2012.   #2
biske
Иван Бишевац
Qualified
 
Avatar biske
 
Datum učlanjenja: 28.08.2008
Lokacija: Зубин Поток
Poruke: 176
Hvala: 109
208 "Hvala" u 18 poruka
biske is on a distinguished roadbiske is on a distinguished roadbiske is on a distinguished road
Pošaljite poruku preko Skype™ za biske
Default

Зашто си мењао из MyISAM у INNO DB?
Први је одличан код упита који углавном читају податке а други је новији и бољи у смислу да подржава интегритет података и бољи је код интензивног уписа података.
За поређење погледај:
http://www.kavoir.com/2009/09/mysql-...-and-cons.html
biske je offline   Odgovorite uz citat
Staro 15. 06. 2012.   #3
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
275 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

menjao sam da bih izbegao LOCK cele tabele kada se iz nje nesto brise
mislis da je prelazak na InnoDB bila losa ideja?
__________________
Vesti | MyCity | Igrice | Zaštita od virusa

Poslednja izmena od Peca : 15. 06. 2012. u 15:27.
Peca je offline   Odgovorite uz citat
Staro 16. 06. 2012.   #4
biske
Иван Бишевац
Qualified
 
Avatar biske
 
Datum učlanjenja: 28.08.2008
Lokacija: Зубин Поток
Poruke: 176
Hvala: 109
208 "Hvala" u 18 poruka
biske is on a distinguished roadbiske is on a distinguished roadbiske is on a distinguished road
Pošaljite poruku preko Skype™ za biske
Default

Citat:
Originalno napisao Peca Pogledajte poruku
menjao sam da bih izbegao LOCK cele tabele kada se iz nje nesto brise
mislis da je prelazak na InnoDB bila losa ideja?
Одговор на твоје питање треба тражити у статистици. Тј. треба да погледаш да ли процентуално имаш више уписа или читања у базу.

Мада као што и сам кажеш претходно ти је радило добро са претрагом, а сада слабо ради, тако да је очигледно погрешан приступ. Ово нема пуно везе са технологијом, не треба ти експерт да ти каже шта је логичније.

Можеш ли мало боље да опишеш ситуацију око брисања и закључавања целе табеле, шта је ту био проблем. Јел време које се чека да се операција брисања изврши? Колико је то критично? Ако ти то брисање није толико хитно онда треба да се вратиш на претходно пошто је MyISAM одличан за претраге и Full Text Search.
biske je offline   Odgovorite uz citat
Staro 16. 06. 2012.   #5
mangia
Pukovnik u penziji
Grand Master
 
Datum učlanjenja: 11.10.2006
Lokacija: Banjaluka, BiH
Poruke: 941
Hvala: 209
585 "Hvala" u 137 poruka
mangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoromangia će postati "faca" uskoro
Pošaljite poruku preko MSN za mangia Pošaljite poruku preko Skype™ za mangia
Default

Provjeri i koliki je ibdata fajl i pokušaj sa opcijom innodb_file_per_table tako da svaka tabela bude zaseban fajl.

Imao sam slučajeve da baza uspori do iznemoglosti samo zato što je ovaj fajl reda 50GB
__________________
mangiaphoto | BLOGERAJBLOG | ServerAdminBlog
mangia je offline   Odgovorite uz citat
Staro 16. 06. 2012.   #6
ivanhoe
Ivan Dilber
Sir Write-a-Lot
 
Avatar ivanhoe
 
Datum učlanjenja: 18.10.2005
Lokacija: Bgd
Poruke: 5.320
Hvala: 104
2.344 "Hvala" u 583 poruka
ivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svimaivanhoe je ime poznato svima
Pošaljite poruku preko Skype™ za ivanhoe
Default

Sto se brzine ovog upita tice, problem je u ovom ORDER BY, trebalo bi pokusati da se napravi tako da baza koristi index za sortiranje (prema explainu ne koristi ga trenutno).

Probaj da napravis UNIQUE KEY (`articleID`, `wordID`) ili obrnuto sa (`wordID`, `articleID`), pa vidi da li ce onda explain da ti da "using index". Takodje prebaci brojanje da bude COUNT(*), u mysql manualu preporucuju da se ne navodi polje da bi mogle da se odrade sve optimizacije...

Ali u svakom slucaju neces moci da dostignes performanse koje ima full-text search jer on koristi specijalan index optimizovan za tu vrstu pretrage...

Imas par mogucnosti:
- da vratis myisam, ali ubacis replikaciju na kojoj ces raditi search, da izbegnes lock tabele (po meni to ti je previse komplikacija)
- da predjes na Lucene, Solr ili tako neki specijalizovani search engine
- da koristis memcached da iskesiras podatke iz baze u jedan lookup hash za sve reci i artikle
- da umesto ove 2 tabele koje koristis napravis jednu myIsam tabelu sa spiskom svih reci i articleID-jem za svaku i da onda koristis full-text search na njoj
__________________
Leadership is the art of getting people to want to do what you know must be done.
ivanhoe je offline   Odgovorite uz citat
"Hvala" ivanhoe za poruku:
Staro 16. 06. 2012.   #7
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
275 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

baza 99% vremena koristi u statusu 'Sending data' [to sam zaboravio da kazem] - sto mi govori da ORDER nije problem.
sta vise, mislim da se ORDER tek na kraju izvrsi, posle HAVING, a tada mu ostane svega par rezultata koje treba da poredja.

ibdata fajl je 31 GB - ali fora je sto su meni [na celom serveru] samo te dve tabele u InnoDB formatu, pri cemu je ova druga 80 puta veca od prve - pa cak i da ih razdvojim - dobio bi jedan fajl od 1GB i drugi opet od 30GB - nista ne bih postigao

slucaj 'zakljucavanja tabele' se javlja sto se cesto [tipa na svakih 10 sekundi] menja sadrzaj nekog artikla - pa samim tim treba i izbaciti iz ove druge tabele reci koje su bile u tom artiklu - i dodati nove.
tada [pri brisanju] zbog myisam implementacije, tabela sama od sebe biva zakljucana, pa SELECT [na koji cekaju posetioci] ne bi smeo da ceka puno [mada mi se cini da nisu ni cekali puno].
to brisanje je background proces - i moze da se 'odlozi' - samo nisam siguran da moze da se napravi tako da query DELETE stane u sred izvrsavanja da bi SELECT prosao istog trena - a to meni sustinski treba zapravo [ako bi se vratio na myisam]

sve vise razmisljam o myisam full text search... to mi se cini kao mozda zaokruzeno resenje, bez mnogo glavobolja...
__________________
Vesti | MyCity | Igrice | Zaštita od virusa

Poslednja izmena od Peca : 16. 06. 2012. u 19:15.
Peca je offline   Odgovorite uz citat
Staro 16. 06. 2012.   #8
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
275 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

Citat:
Originalno napisao ivanhoe Pogledajte poruku
Probaj da napravis UNIQUE KEY (`articleID`, `wordID`) ili obrnuto sa (`wordID`, `articleID`), pa vidi da li ce onda explain da ti da "using index".
probacu ovo, deluje logicno, posto upit kombinuje ta dva polja preko GROUP BY...
__________________
Vesti | MyCity | Igrice | Zaštita od virusa

Poslednja izmena od Peca : 16. 06. 2012. u 22:10.
Peca je offline   Odgovorite uz citat
Staro 16. 06. 2012.   #9
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
275 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

postoji li neki nacin [query] da eliminisem duplikate za ta dva polja, posto je ipak uleteo dupli unos za jedan artikal

EDIT:
nadjoh: ALTER IGNORE TABLE...
__________________
Vesti | MyCity | Igrice | Zaštita od virusa

Poslednja izmena od Peca : 16. 06. 2012. u 22:41.
Peca je offline   Odgovorite uz citat
Staro 24. 06. 2012.   #10
Peca
Super Moderator
Knowledge base
 
Datum učlanjenja: 02.10.2006
Lokacija: Niš
Poruke: 1.618
Hvala: 263
275 "Hvala" u 104 poruka
Peca će postati "faca" uskoroPeca će postati "faca" uskoroPeca će postati "faca" uskoro
Default

sta bi trebao da pokaze EXPLAIN da bih bio siguran da on sada koristi ovaj novi UNIQUE KEY?
i dalje pod Extra pise Using where... :/
doduse, naveo je ovaj novi kljuc pod possible_keys...
__________________
Vesti | MyCity | Igrice | Zaštita od virusa

Poslednja izmena od Peca : 24. 06. 2012. u 16:41.
Peca 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


Vreme je GMT +2. Trenutno vreme je 00:21.


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.