[ Milan M. Radovic @ 25.11.2010. 11:16 ] @
testirao sam bazu ubacivsi nasumicni md5 u jednu kolonu... napravivsi izvestan broj zapisa, ta jedna jedina kolona je naravno bila primarni kljuc mada za tim i nema potrebe skoro... cisto testa radi.

Primetio sam da se cak i jednostavni upiti tipa SELECT col1 where hes LIKE '%blabla%' .... izuzetno sporo izvrsavaju.
Generalno cim tabela predje 2 miliona zapisa, nastaje drasticno usporavanje. Imate li nekih predloga... da li menjati bazu ili sta raditi?

Dopunio sam je jednom do 5 miliona redova sto je kolicinski u nekim situacijama realno - posebno ako je rec o statistikama poseta (slozenijim).... i otprilike traje minut upit!
[ bogdan.kecman @ 25.11.2010. 11:24 ] @
aj napisi

1. koja verzija mysql-a
2. na kom os-u se vrti
3. SHOW CREATE TABLE - te tabele koja je u pitanju
3. EXPLAIN SELECT ... upita o kom je rec

ovako, ja sam bacio pasulj i mislim da je problem izmedju monitora i stolice
[ Milan M. Radovic @ 25.11.2010. 12:33 ] @
Problem je sto sam taj test uradio na kompu koji je sad kuci a pisem s posla, nemam net, jer sam se prekljuce preselio...

OS je Debian Lenny, i u paketu imam i mysql-server, zasad mogu toliko da kazem.
Tabela je MyISAM, i ima jednu jedinu kolonu tipa VARCHAR(32)... to je sve...cisto testa radi.

* Mada moram priznati da isti taj upit na windowsu radi jedno 5 puta sporije... ali to nije cudno zar ne :) (dobro, necemo sad Advocacy ovde...)

Kad dodjem kuci, uradicu jedan update stvari verovatno na ubuntuovom live-cd-u ovog puta na masini sa Intel CoreQuad 2.3GHz, 6GB ... pa cemo videti detaljnije, updatovacu... znam da je ovo malo informacija.
[ bogdan.kecman @ 25.11.2010. 12:41 ] @
1. stavi mysql binary sa dev.mysql.com (binary koji stize uz debian nije ni za ...)
2. ako testiras, kreni odma sa 5.5
3. na windozi radi sporije u 5.1 i starijim verzijama ali nije problem do windoza nego do mysql-a koji ne ume da radi kako treba na windozi, 5.5 radi prilicno isto na windozi i na linuxu (i ostalim sistemima ... solaris, aix i ekipa)
4. create table t1 (x varchar(32) primary key not null) engine=myisam; - ovo je ocajna tabela za bilo kakav benchmark, sta ocekujes da ti tu radi brzo? ako oces brz insert radi bulk insert, ako hoces brz read povecaj key cache, ali generalno - sa tom tabelom ne mozes da naprvis nikakav realni benchmark .. (dodatno, kada je myisam u pitanju, uradi char(32) umesto varchar i imaces znacajno ubrzanje)
[ Milan M. Radovic @ 25.11.2010. 14:15 ] @
Citat:
bogdan.kecman: 1. stavi mysql binary sa dev.mysql.com (binary koji stize uz debian nije ni za ...)
2. ako testiras, kreni odma sa 5.5
3. na windozi radi sporije u 5.1 i starijim verzijama ali nije problem do windoza nego do mysql-a koji ne ume da radi kako treba na windozi, 5.5 radi prilicno isto na windozi i na linuxu (i ostalim sistemima ... solaris, aix i ekipa)
4. create table t1 (x varchar(32) primary key not null) engine=myisam; - ovo je ocajna tabela za bilo kakav benchmark, sta ocekujes da ti tu radi brzo? ako oces brz insert radi bulk insert, ako hoces brz read povecaj key cache, ali generalno - sa tom tabelom ne mozes da naprvis nikakav realni benchmark .. (dodatno, kada je myisam u pitanju, uradi char(32) umesto varchar i imaces znacajno ubrzanje)


Znas li neki dobar sajt sa ovakvim korisnim uputstvima koje si ti dao, mislim za optimizaciju i slicne stvari... u vezi mysql-a?
[ bogdan.kecman @ 25.11.2010. 14:28 ] @
znam :D

www.mysql.rs :)

imas tamo sa info strane linkove na neke bitnije postove (optimizacija servera, greske etc) ... npr optimizacija mysql servera je koristan post :)
[ Milan M. Radovic @ 26.11.2010. 08:32 ] @
Citat:
bogdan.kecman: znam :D

www.mysql.rs :)

imas tamo sa info strane linkove na neke bitnije postove (optimizacija servera, greske etc) ... npr optimizacija mysql servera je koristan post :)
Puno zahvaljujem!
Mislim... da ne prelazim na MsSql, mnogi ga hvale al meni to MS ne uliva poverenje... mislim gadi mi se..
[ bogdan.kecman @ 26.11.2010. 08:45 ] @
mssql je odlican sql server danas ... (do skoro je bio teski krs ali su ga ukrotili i to ok radi) tako da nije za bacanje ..

e sad, mysql nema sve opcije koje ima mssql (bice i to uskoro ako da larry), ali ovo sto radi je na istom hw-u sigurno isto brzo kao mssql ili brze, ne moz da bude sporije nikako ... pogledaj tamo kod mene na blogu ima dosta toga .. ima sa strane tamo jos nekih korisnih linkova na strane blogove .. mada ono najvaznije imas vec kod mene, ostalo su detalji, uvek mozes i ovde da kukas da nesto ne radi pa cemo srediti ...

samo da bi dobio pomoc moraces da se potrudis i sam, tako da uvek
- sta si tacno hteo da postignes
- sta si tacno i kako probao

dakle repeatable test case koji ja mogu da copy/paste kod mene na sistemu, a ne da ja citam tvoje pitanje, zamisljam sta si hteo da uradim, pravim tvoj test case i onda ti resavam problem .. moze i to al, mene za to placaju debele pare :D
[ djoka_l @ 26.11.2010. 09:37 ] @
@bogdan.kecman Da li zaista MySql može da koristi indeks kada je upit tipa LIKE '%deo_stringa%' ? Ovo baš i nije uobičajeno. Oracle, na primer, za ovo ne bi koristio indeks...

U našoj aplikaciji, za upite tipa LIKE '%nesto' (znači, kada treba da nađemo sufiks stringa) koristimo polje koje je indeksirano, ali je string napisan unatraške, pa onda upit ide po tom drugom indeksiranom polju a upit se pretvara u LIKE 'otsen%' (otsen = nesto ali unazad :) )
[ bogdan.kecman @ 26.11.2010. 09:55 ] @
Citat:
Da li zaista MySql može da koristi indeks kada je upit tipa LIKE '%deo_stringa%' ? Ovo baš i nije uobičajeno.


jok, nema teorije za %bilosta da koristi index, to mislim da nijedan storage engine na svetu ne ume (mada nisam bas exper za sve njih :D), ako sam negde napisao da moze daj please reci gde da idem da se izvinjavam :)

za bilosta% koristi index (sto je jos i dobra fora posto veliki broj storage engine-a ne koristi ni u tom slucaju)

Citat:
Oracle, na primer, za ovo ne bi koristio indeks...


bas tako, ne oracle, ne bi niko ...

e sada, sto se %nesto% tice, osim te fore koju ti koristis (koja je prilicno cesta na zalost) ima fora da koristis full text index kod MyISAM-a (ako da larry bice i na InnoDB uskoro, znam da innodb tim radi na tome, sta ce biti sa tim nemam pojma)
[ djoka_l @ 26.11.2010. 10:03 ] @
Citat:
bogdan.kecman: ok, nema teorije za %bilosta da koristi index, to mislim da nijedan storage engine na svetu ne ume (mada nisam bas exper za sve njih :D), ako sam negde napisao da moze daj please reci gde da idem da se izvinjavam :)


Pa nisi ti napisao, ali je od toga počelo:

Citat:
Milan M. Radovic: testirao sam bazu ubacivsi nasumicni md5 u jednu kolonu... napravivsi izvestan broj zapisa, ta jedna jedina kolona je naravno bila primarni kljuc mada za tim i nema potrebe skoro... cisto testa radi.

Primetio sam da se cak i jednostavni upiti tipa SELECT col1 where hes LIKE '%blabla%' .... izuzetno sporo izvrsavaju.
Generalno cim tabela predje 2 miliona zapisa, nastaje drasticno usporavanje. Imate li nekih predloga... da li menjati bazu ili sta raditi?
!


Upravo zbog toga sam pomno pratio diskusiju misleći da ću doživeti prosvetljenje!
[ bogdan.kecman @ 26.11.2010. 12:15 ] @
Citat:
djoka_l: Upravo zbog toga sam pomno pratio diskusiju misleći da ću doživeti prosvetljenje!


sorry - nema prosvetljenja danas :(

nisam uopste ni video da radi covek like %xx% .. zato volim lepo ono .. evo create, evo sql query, evo explain - zasto je sporo ..

na zalost ako like pocinje sa % ne postoji matematika (osim full txt search ali on ima drugaciju sintaksu) kojom bi mogao da se koristi index - dakle full table scan ne gine :(

btw, bez obzira sta ko ima da kaze na tu temu - baza u kojoj je potreban upit LIKE %xx% je lose dizajnirana.
[ w3bl0rd @ 29.11.2010. 07:36 ] @
Citat:
btw, bez obzira sta ko ima da kaze na tu temu - baza u kojoj je potreban upit LIKE %xx% je lose dizajnirana.


Osim ako je u pitanju search :))
[ bogdan.kecman @ 29.11.2010. 07:57 ] @
Citat:
w3bl0rd: Osim ako je u pitanju search :))


I dalje je lose dizajnirana, dakle search se ne radi tako

[ w3bl0rd @ 29.11.2010. 10:45 ] @
A na koji način bi onda napravio search?
[ bogdan.kecman @ 29.11.2010. 14:35 ] @
zavisi od zahteva, ili tako sto iskoristis vec postojeci full text search index ili tako sto ga implementiras sam (tako sto pravis dictionary etc..) ... ako pogledas bilo koji forum software on ti daje da biras da li hoces da koristis FTS sa MyISAM tabelom ili da koristis njegov search. Nijedan ne radi like %$X% posto ce to da radi table scan sto na bilo kojoj bazi koja ima vise od jednog korisnika znaci "dovidjenja upotrebljivost". Ima mnogo nacina / teorija kako se radi search bez koristenja postojeceg FTS-a (posto je isti nemoguce koristiti ako se ne koristi MyISAM, a MyISAM ima mnoooogo mana tako da se ne preporucuje na bilo kom sistemu koji ima konkurentno pisanje)...

dakle za bilo koju tabelu koja ima vise od par desetina redova - LIKE zaboravi, cak i u $1% varijanti a u %$1 pogotovo
[ Shinhan @ 30.11.2010. 07:20 ] @
Kratak odgovor za search: Sphinx

Ima i drugih alternativa naravno, ovo koristimo mi.
[ bogdan.kecman @ 30.11.2010. 07:32 ] @
Sphinx je odlican storage engine sa FTS podrskom ... mnogo je bolji od MyISAM-a (posto ga nije tako lako koruptovati a i crash safe je) ... nije toliko dobar kao InnoDB, ali obzirom da InnoDB nema FTS Sphinx je "drop-in" resenje .. elem kad pricamo vec o 3rd party engine-ima .. FTS ima i ARIA (nekad Maria) a koliko sam cuo InnoDB ce ga imati uskoro ...

inace, za one koji ne bi menjali storage engine (InnoDB je ipak tata mata za druge stvari) koristan link: http://qwik.jp/senna/
[ w3bl0rd @ 30.11.2010. 07:38 ] @
Baš sphinx i trebam koristiti na novom projektu, do sad još nisam radio full text search pa me zato i zanima. Dal to znači da se upit za search drukčije postavlja? Ma nevažno moram proći prije dokumentaciju pa onda razglabat :)
Uf ja sam radio sa innoDB mislio sam da se sphinx nadoveže na innoDB samo, a sphinx je znači u stvari storage engine posebni? Bit će veselja :))
[ bogdan.kecman @ 30.11.2010. 07:56 ] @
Mozes sphinx da "naslonis" na innodb imas ODLICAN STEP BY STEP ovde: http://www.ibm.com/developerworks/library/os-php-sphinxsearch/

sphinx SE je samo interface prema externim aplikacijama ... ja ga generalno zovem "Storage engine" posto kao jeste mada je to samo "interface" prema externom setu alata

za MyISAM FTS imas http://dev.mysql.com/doc/refman/5.5/en/fulltext-search.html dakle upit radis na primer:

Code:

SELECT id, body, MATCH (title,body) AGAINST
    -> ('Security implications of running MySQL as root'
    -> IN NATURAL LANGUAGE MODE) AS score
    -> FROM articles WHERE MATCH (title,body) AGAINST
    -> ('Security implications of running MySQL as root'
    -> IN NATURAL LANGUAGE MODE);


ovde ti "score" vraca "koliko je match dobar", tako da mozes da sortiras po score tako da ti "bolji" rezultati budu napred

[ bogdan.kecman @ 30.11.2010. 08:07 ] @
brzo za sphinx

imas nesto tipa "data layer" gde su podaci (tj indexi), imas 2 procesa, searchd i indexer,
indexer puni taj "data layer" tako sto povuce podatke koje hoces da indexiras (innodb, myisam, postgresql, oracle, odbc source, xml source ..);
rezultate vadis tako sto se okacis na searchd i pricas sa njim .. dakle nista mysql, select ovo ono ...

data layer se koliko se ja secam cuva u mysql bazi (mada moze i externo) - no nisam 100% siguran bolje da Shinhan potvrdi

sada ti mozes da pristupis podacima kroz sphinxSE a mozes da se kacis direkt na searchd

to ti je "teorija" .. praxa, Shinhan ce mozda da se otvori i da napise :D ... ja sam probao sphinx odavno, znam da ga cudo klijenata koristi, ja licno nisam nikad ..
[ w3bl0rd @ 30.11.2010. 09:14 ] @
MyISAM me ne zanima pošto mi trebaju relacije i transakcije... Hvala puno ovo mi je dosta rasvjetlilo neke stvari, ako Shinhan ima što za dodati bit ću vrlo zahvalan :))
[ bogdan.kecman @ 30.11.2010. 17:02 ] @
proverih sa drugarima koji to koriste, data layer se cuva zasebno u fajlovima van mysql-a ..

ako neko ima vremena da se smori da napise step by step uputstvo sa malo price okolo bilo bi iskusno, no, onaj link sto sam ostavio je poprilicno jednostavan za ispratiti...
[ Shinhan @ 01.12.2010. 07:40 ] @
Onaj primer je super za početak, mi radimo malo komplikovanije.

Ako ti je index malo veći onda indexiranje može da potraje pa je rešenje korišćenje delta indexa, pa onda indexer često (mislim da je svakih par minuta) popunjava delta index razlikama između prošlog indexiranja i realnog stanja i onda to merge sa glavnim indexom da bi downtime bio što manji. Ima to opis u sphinxovoj dokumentaciji. Takođe, obrati pažnju na to kakav format polja očekuje sphinx, mi smo trebali da konvertujemo neka polja da bi ih on mogao koristiti mislim DATETIME u TIMESTAMP.

Što se tiče pretrage, možeš dodati i sortiranje (recimo ja u sortiranju moram plaćene oglase iznad neplaćenih).
[ w3bl0rd @ 01.12.2010. 08:16 ] @
ok, Hvala. Vrijeme je da krenem na posao, pa ako negdje zapnem javim.