Realizacija pretrage

[Ilija Studen]

Kakva su vaša iskustva sa izradom pretrage? Q&D (quick and drity ) rešenja kao LIKE mogu da odrade posao za neke manje stvar, međutim meni treba za nešto malo obimnije. Prvo, ima dosta tabela koje se pretražuju (10 - 15 sa bar dva polja po tabelu koja se pretražuju). Uz to će najverovatnije u neko dogledno vreme biti i zahtev da se pretražuju i attachovani fajlovi.

Kako stvari stoje, najverovatnije ću praviti neki index, ali tu opet ima problem sa veličinom jer indeksi imaju ružnu naviku da samo rastu.

No, koja su vaša iskustva? Pros and cons? Neki zanimljivi linkovi?

[jablan]

Naš sistem ima posebne tabele (sa sadržajem koji se pretražuje) koje indeksira MSSQL-ov fulltext search, jednu za CMS objekte, drugu za fajlove. Prva sadrži i informacije o kom se objektu i kom njegovom polju radi. Tabele se pune pri izmeni nekog objekta (prva) i pri uploadovanju nekog fajla na sistem (druga).

[Petar Marić]

Jesi li čuo za Apache Lucene ili Egothor?

Inače Zend_Search iz Zend framework-a koristi upravo Lucene.

Off Topic: Ovakav problem optimizacije se narodski zove "klackalica". Ako želiš bržu pretragu moraš imati veći i kompleksniji index, a ukoliko želiš manji i jednostavniji index imaćeš sporiju pretragu.
Kada napraviš dovoljno dobro rešenje svaki dalji pokušaj optimizacije ti se svodi na "klackalicu".

[Ilija Studen]

@Jablan: Ako sam dobro razumeo, vi imate tip objekta, ID i ime polja kao PK + sadržaj samog objekta? Sviđa mi se taj pristup jer je dovoljno jednostavan, pravi razliku među tipovima objekata i omogućava da se čuvaju dodatne informacije o samim objektima (kojoj kategoriji pripada, da li je javan ili privatan itd itd).

Veličina ne predstavlja problem?

@Petar: Čuo. Postoji i PHP5 implementacija u okviru ZF projekta: Zend Search. Ono što je muka u celoj priči je što ZF nije stabilan, a i treba uložiti dosta vremena da se Zend_Search ubaci u skriptu koju koristim (ne pada mi na pamet da samo zbog toga koristim ceo ZF).

[jablan]

Originalno napisao Ilija Studen

@Jablan: Ako sam dobro razumeo, vi imate tip objekta, ID i ime polja kao PK + sadržaj samog objekta? Sviđa mi se taj pristup jer je dovoljno jednostavan, pravi razliku među tipovima objekata i omogućava da se čuvaju dodatne informacije o samim objektima (kojoj kategoriji pripada, da li je javan ili privatan itd itd).

Dobro si razumeo. Dodatna polja olakšavaju "advanced" pretragu, tj. lako sužavanje po određenim kriterijumima. Npr. ID jezika je jedno od tih pomoćnih polja.

Nisam iz prve ruke upućen u probleme pri eksploataciji, ali veličina ne bi trebalo da predstavlja problem, jer te tabele čuvaju samo aktuelne verzije CMS objekata. Ono što pravi najveći DB footprint kod CMS-ova su prethodne (i obrisane) verzije objekata. Npr. desi se da korisnik jednostavno greškom negde iskopira celo podstablo objekata i posle ga obriše. Dakle, začas može da napravi megabajte đubreta u bazi. Ali to ne dotiče tabele za pretraživanje jer, kao što rekoh, one čuvaju samo aktuelne revizije objekata.

[jablan]

Originalno napisao Petar Marić

Jesi li čuo za Lucene?

Hehe, imaju logo kao beogradska Lasta, samo ružniji.

Možeš li reći još nešto o ovome, npr. kako se integriše u druge platforme. Ne sumnjam da su performanse odlične, ali sam vrlo sumnjičav da se ovakvo rešenje lako može integrisati u neki veći CMS.

[Petar Marić]

Postoji Lucene .NET implementacija.

Što se tiče integracije u veće sisteme jedan od Google Summer of Code projekata za Django projekat je i Merquery - Text Indexing & Search Engine Abstraction Layer for Python čiji je cilj da korišćenje moćnih sistema za indeksiranje i pretragu bude jednostavno kao npr caching framework.

[Ilija Studen]

Super, rešeno Obožavam jednostavna rešenja (tj. rešanja koja se nakon izrade jednostavno koriste):

PHP kôd:

class SomeObject extends BaseApplicationObject {

  // ...

  protected $is_searchable = true;

  protected $searchable_columns = array('title', 'text');

  // ...

} 


To je sva mudrost.