wyszukiwarka, wydajna, z prawdziwego zdarzenia ;) Opcje

[chmolu]

Witam,

wiem, że takie tematy już były, ale nie znalazłem w nich żadnych konkretów.

Jak podeszlibyście do problemu zbudowania mechanizmu wyszukiwarki dla systemu, który nierzadko może obsługiwać spore ilości danych (w wielu tabelach)?

Interesuje mnie wszystko na ten temat - linki, artykuły, tutoriale.

Spotkałem się już w kilku aplikacjach z rozwiązaniem, które wyglądało mniej więcej tak:
treść tabeli, np. articles jest dzielona na słowa, np tekst:

To jest przykładowa treść artykułu

Zostanie podzielony na tablicę:

[PHP] pobierz, plaintext 
<?php
array('jest', 'przykładowa', 'treść', 'artykułu');
?>
[PHP] pobierz, plaintext 

Słowo "to" jest traktowane jako tzw. common word i pomijane.

Te słowa są wrzucane do osobnej tabeli, która ma mniej wiecej taką strukturę:

Kod

word_id
word_text

Do tego jest jeszcze jedna tabela, która łączy artykuł ze słowami:

Kod

article_id
word_id

Rozwiązanie ciekawe, ale zastanawia mnie, jak to jest z jego wydajnością. O ile liczba słów jest ograniczona, to druga tabela może się nieźle rozrosnąć. Pisał już ktoś coś takiego? Jakie są wasze sposoby na problem wyszukiwarki w CMSach?

[Sedziwoj]

pawkow to rozwiązanie jest kiepskie, ponieważ przy pojawieniu się nowego artykułu, nie masz możliwości usunięcia bufora. A jakbyś to robił, to by było takie samo obciążenie, jak przy użyciu samego LIKE. Przy każdym wybraniu musiał byś rozdzielać dane, co też generuje obciążenie.
Jeszcze sam nie wnikałem w ten problem, ale przy tym co się chwile zastanowiłem, to chyba najlepsze rozwiązanie to
word | id_article
przy czym unikalne jedynie mogło by być połączenie obu.
Przy założeniach szukania samego artykułu bez cytatu.
Bo chyba jednak problem nie może być rozwiązany aby był mało obciążający pamięciowo i obliczeniowo.

[Mikz]

pawkow to rozwiązanie jest kiepskie, ponieważ przy pojawieniu się nowego artykułu, nie masz możliwości usunięcia bufora. A jakbyś to robił, to by było takie samo obciążenie, jak przy użyciu samego LIKE. Przy każdym wybraniu musiał byś rozdzielać dane, co też generuje obciążenie.
Jeszcze sam nie wnikałem w ten problem, ale przy tym co się chwile zastanowiłem, to chyba najlepsze rozwiązanie to
word | id_article
przy czym unikalne jedynie mogło by być połączenie obu.
Przy założeniach szukania samego artykułu bez cytatu.
Bo chyba jednak problem nie może być rozwiązany aby był mało obciążający pamięciowo i obliczeniowo.

Sedziwoj, nie jestem przekonany co do tego co mówisz. Znaczy oczywiście nie pozbywamy się obciążającego LIKE'a, ale można zrobić relację many-to-many zamiast takiej dziwnej kolumny z separatorami | i przy ponownym wyszukiwaniu takim zapytaniem z LIKE określić w WHERE tylko te rekordy których czas utworzenia lub modyfikacji jest późniejszy niż czas utworzenia rekordu wyszukiwania. To tak bez wdawania się w niepotrzebne szczegóły.
Za to problem który widzę to dodatkowe obciążenie bazy przy zapisywaniu wyników wyszukiwania, literówki popełnione przez wyszukujących i tak dalej

pawel_ - dzięki za ten skrypt, a właściwie za metodę z tymi słownikami (IMG:style_emoticons/default/smile.gif)


Odnośnie budowania indeksu słów, takie rozwiązanie stosuje np. phpBB.

[Sedziwoj]

Sedziwoj, nie jestem przekonany co do tego co mówisz. Znaczy oczywiście nie pozbywamy się obciążającego LIKE'a, ale można zrobić relację many-to-many zamiast takiej dziwnej kolumny z separatorami | i przy ponownym wyszukiwaniu takim zapytaniem z LIKE określić w WHERE tylko te rekordy których czas utworzenia lub modyfikacji jest późniejszy niż czas utworzenia rekordu wyszukiwania. To tak bez wdawania się w niepotrzebne szczegóły.
Za to problem który widzę to dodatkowe obciążenie bazy przy zapisywaniu wyników wyszukiwania, literówki popełnione przez wyszukujących i tak dalej

pawel_ - dzięki za ten skrypt, a właściwie za metodę z tymi słownikami (IMG:style_emoticons/default/smile.gif)


Odnośnie budowania indeksu słów, takie rozwiązanie stosuje np. phpBB.

Ogólnie ta kreska | miała oznaczać rozdzielenie nazw kolumn, nie łączenie stringa.
Zresztą po latach wracając do tematu wiem że korzysta się z FTS, czy to tsearch2 w Postgresql <8.3 (od 8.3 rozszerzenie dołączyło do rdzenia bazy), czy to FTS w MySQL, czy Lucene (to jest sposób indeksowania, kody do obsługi są w różnych językach i pracują na jednym indeksie plikowym, bardzo fajne, tylko jak 2lata temu testowałem to wydajność kodu w PHP była żenująca, ale w java to śmigało jak głupie).