Boolean search na innodb

[cvele]

Ok ovo jeste malo... khm... mozda cak i nemoguce...

Dakle zbog mogucnosti koriscenja stranih kljuceva sve tabele su innodb tipa ali sada se ukazala potreba za boolean pretragama :/

Stvari kojima sam razmisljao su sledece:
1. Deljenje tabele na dva dela (da ne objasnjavam zasto... ali nije moguce)
2. Particionisanje tabele na dva dela... moguce ali imam osecaj da cu se ubiti kasnije pokusavajuci da prebacim procedure na production server i nisam siguran kako bi to uopste radilo ako su dva dela razlicitog tipa :/
3. Pokusaj da se boolean zameni like iskazima... overkill big overkill, tabela je ogromna tako da je preformance katastrofa


Ogranicenja... nemogu koristiti extenzije za mysql poput http://www.sphinxsearch.com
tabele moraju ostati innodb

Ima li nesto sto sa prevideo ? google mi nerece nista, ali nista osim na par mesta gde ljudi daju linkove ka sphinx

Neka pomoc ?

[ivanhoe]

mislis na boolean fulltext search ?

mozes da napravis pomocne tabele, jednu sa spiskom nadjenih reci, drugu sa referencama na recorde gde se reci pojavljuju, i onda iz njih radis klasican select sa join-om...

[marinowski]

Ako je u pitanju fulltext search, na flickru su to resili ovako: imaju bazu sa innodb tabelama u kojima nema fulltext indekse. Tu bazu repliciraju, ali kopije nisu innodb tipa, vec MyISAM na kojima jesu postavili fulltext indekse.

Na ovaj nacin izbegavaju problem pada performansi pri istovremenom citanju i pisanju iz baze (u innodb samo insertuju, iz MyISAM samo selectuju). Sa ovom elegantnom cakom su zaobisli problem nepostojanja fulltext indexa na innodb tabelama, a koristene su samo out-of-the-box mogucnosti MySQL-a.

Znam da tebi to treba za jedan server, ali reko' da napisem, mozda bude korisno posto nije ocigledno da kod replikacije mozemo menjati tip tabela.

[cvele]

covek svakim danom nauci nesto novo

@zigor
razmisljao sam o tome ali ne dovoljno ozbiljno, recimo sada sam prvi put saznao da mysql ima triggere

dakle finalno resenje ce biti kreiranje nove myisam tabele koja ce se puniti preko trigera

[Ilija Studen]

Originalno napisao cvele

dakle finalno resenje ce biti kreiranje nove myisam tabele koja ce se puniti preko trigera

Nešto slično koristim i kod activeCollaba s tom razlikom što se ne koriste trigeri već aplikacija insertuje podatke pri čuvanju objekta (INSERT ili UPDATE - jedna od lepih stvari kod dobro rešenog ORM-a je što možeš da izvedeš tako nešto bez hakeraja, samo se negde u stablu nasleđivanja uglaviš i dodaš šta ti treba).

Ovaj pristup ima veliku prednost jer možeš da akumuliraš pretražive podatke iz celog sistema na jedno mesto. Samo treba na neki način da održiš referencu na izvorni podatak i da znaš kako da matchevani row iz indexa prebaciš u odgovarajući row iz originalne tabele.

Dobro je znati da tako nešto može da bude rešeno na nivou baze. Doduše, MySQL5 je teška egzotika (mnogo veća od PHP5), ali ako radiš nešto custom gde možeš da kontrolišeš platformu mislim da je to prilično fino rešenje.

@zigor: ako ovo za mešanje enginea kod replikacija radi ulepšao si mi dan Sad samo da u neko dogledno vreme dodam podršku da skripta može da koristi dve različite konekcije za dve različite operacije (čitanje i pisanje) i problem rešen.

[cvele]

da radi se o potpuno custum resenju kome ce platforma biti server specijalno podignut samo za tu aplikaciju, tako da mogu da pustim masti na volju i koristim svu egzotiku koju zelim

@ilija
nikako da se nateram da prevedem ono cudo nisam zaboravio

[Dejan Topalovic]

Moze MySQL svasta jos...

Postoji cak i partitioning, table splitting (na fixed i dynamic row size), kompresovanje radi brzeg selektovanja, triggers, views, stored procedures, events, podjela database direktorija na vise hard diskova radi boljih I/O performansi, dinamicko podesavanje buffera i session varijabli ... i td.

@cvele: U praksi jos nisam imao potrebu za necim ovakvim kao sto ti imas sad, ali vjerujem da bi razdvajanje na dvije tabele (jedna InnoDB i jedna MyISAM), kao sto je vec predlozeno, rijesilo tvoj problem...

Trenutno mi ne pada neko bolje rjesenje na pamet.

[kodi]

Slucajno sam danas naleteo na sledeci text

We used to use MyISAM for fulltext, duplicating the data in the InnoDB master table. Once the query rate grew sufficiently high and the data size grew past a gigabyte or so it became completely unacceptable on performance grounds, taking more than half of our database server capacity and still not working well. We abandoned it and switched to Lucene. By that point we were in the top thousand sites on the net, so it had survived pretty well.

I'm also as MySQL Support Engineer but these views are from my Wikipedia role, not the MySQL one.

James Day

ostatak texta (innoDB vs myisam)
http://mysqldatabaseadministration.b...reference.html

[ivanhoe]

mysql se u principu ne snalazi najbolje kad tabela poraste preko ~1.4GB (moja odokativna procena), dodje do naglog pada perfomansi... mi smo krenuli da splitujemo tabele zbog toga, sto resi problem (mada naravno nije bas zgodno za search)

[kodi]

Originalno napisao ivanhoe

mysql se u principu ne snalazi najbolje kad tabela poraste preko ~1.4GB (moja odokativna procena), dodje do naglog pada perfomansi... mi smo krenuli da splitujemo tabele zbog toga, sto resi problem (mada naravno nije bas zgodno za search)

govorsi za myisam ili uopsteno?