Názory k článku Princip jednoduchého fulltextu s příklady v SQL a PHP (2)
-
Jejda...kdyby to tak fungovalo i nad takovymi 50-100 GB dat, to bych to mohl pouzit taky :)
Ad levostranne doplneni: Muzu pouzit SQL wildcards: "LIKE '%lina'". Problem je s indexy, ze...pokud bych potreboval urychlit hledani indexem s zolikem na zacatku, musel bych si ukladat i rotovane slovo. Nicmene pokud rezie zpracovani tabulky slov je dostatecne mala oproti zpracovani tabulky vyskytu, nebude to tak kriticke. (Jeste ze muzeme pracovat ve vazebni tabulce slova<->clanky jen s IDcky :) Jinymi slovy: pri prohledavani narocnem kvuli velkym textum a mnoha clankum spise nez kvuli velkemu poctu dotazu vadi mene nez v opacnem pripade.
Potencialni stop slova? Tipoval bych ta, ktera se vyskytuji v temer kazdem clanku...alias mala selektivita. Proste spocitam procentuelne, kolikrat se slovo "nebo" vyskytuje v clancich a kdyz zjistim, ze v 95%, klidne si ho muzu dovolit vynechat, protoze u funkce relevance zalozene na kvalitativnim hodnoceni (primarni razeni podle poctu ruznych obsazenych slov dotazu) mi moc nepomuze... U jine relevance by mohl byt samozrejme potrebny jiny postup.
Je mozne, ze mi to uz ale poradne nemysli...mel bych jit spat. Vetsi cast domaciho ukolu ted rozhodne dusevne nezvladnu...
Zdravim...
(Kaaczu taky :) -
Pokud máte 50-100GB a potřebujete je prohledávat, tak se můžete ozvat nám. Určitě něco vymyslíme :)
»Jyxo -
anonymníBohuzel tento pristup zkolabuje pokud budete chtit pouzit pravo-leve rozsireni (tj. *term*). Jak psal pan Hegenbart jedna z moznosti je ulozit do B-stromu vsechny rotace. Dalsi moznosti jsou tzv. Suffixove stromy. Zde je ovsem pomerne neefektivni perzistence. Z nasich luhu a haju jmenujme pristup:
M. Krátký, T. Skopal, and V. Snášel: Multidimensional Term Indexing for Efficient Processing of Complex Queries. Kybernetika, Journal of the Academy of Sciences of the Czech Republic, (3):381-396, 2004.
Ten pouziva neuplne zname datove struktury, nicmene tento problem relativne efektivne resi.
Vubec mi v clanku chybi reference. V oblasti Information Retrieval bylo napsano velke mnozstvi knih a clanku. Je skoda, ze se autor snazi objevit jiz existujici svetadil a nehleda inspiraci v existujicich pracech. -
anonymnísory za OT, ale od zmeny v designu roota chybi v horni liste se seznamem serveru odkaz na palmserver.cz. Na ostatnich serverech iinfa je to OK. Redakce ani jednoho ze zminovanych serveru na muj mail nereaguji, tak jim to zkuste pripomenout i vy ostatni, treba se probudi.
At zije abclinuxu.cz :))) -
Dalibor Šrámek (neregistrovaný)V tabulce FT_Index jsem opominul vytvoření indexů nad cizími klíči:
CREATE INDEX FT_Index_IdWord_FK ON FT_Index (IdWord);
CREATE INDEX FT_Index_IdArticle_FK ON FT_Index (IdArticle);
(Příklady budou fungovat i bez nich, ale po naplnění větším objemem dat by se hledání velice zpomalilo.) -
anonymníBohuzel tento pristup zkolabuje pokud budete chtit pouzit pravo-leve rozsireni (tj. *term*). Jak psal pan Hegenbart jedna z moznosti je ulozit do B-stromu vsechny rotace. Dalsi moznosti jsou tzv. Suffixove stromy. Zde je ovsem pomerne neefektivni perzistence. Z nasich luhu a haju jmenujme pristup:
M. Krátký, T. Skopal, and V. Snášel: Multidimensional Term Indexing for Efficient Processing of Complex Queries. Kybernetika, Journal of the Academy of Sciences of the Czech Republic, (3):381-396, 2004.
Ten pouziva neuplne zname datove struktury, nicmene tento problem relativne efektivne resi.
Vubec mi v clanku chybi reference. V oblasti Information Retrieval bylo napsano velke mnozstvi knih a clanku. Je skoda, ze se autor snazi objevit jiz existujici svetadil a nehleda inspiraci v existujicich pracech. -
Martin Koníček (neregistrovaný)Opravdu pěkný článek, jsem docela rád že se někdo chytil na můj komentář, že kritizovat umí každý, ale tvořit málokdo a našel se i člověk, jež krom kritiky navrhl i jak to vylepšit.
Problém ovšem je, že udělat opravdu rozumné vyhledávání je otázkou opravdu na knihu. Tyto dva články rozebírají takřka jen teorii, ale implementace by byla opravdovým oříškem.
Podle mě by bylo fajn, kdyby se tu někde objevila funkční knižnice tokenizátoru, která by si rozumně poradila i s češtinou. Mě by na to stačil alespoň seznam českých koncovek, kdyby ho někdo měl byl bych mu opravdu vděčný, už mám i seznam synonym a podobných věcí.
To na co ale narážím nejvíce je omezený počet zdrojů na vytvoření vyhledávání. Ono totiž není dost dobře možné naprogramovat dobré vyhledávání za rozumný čas. Podle mě je škoda, že se na to nemyslí už v databázích, protože tam kdyby existoval rozumný fulltext by to bylo nejrychlejší a nejlepší. Jistou možností nad kterou v poslední době uvažuji je napsání nějakého tokenizátoru přímo do databáze a zbytek řešit přes triggery a SQL kód. Nevýhodou je, že MySQL je dost slabá na takové použití a pochybuji, že někdo bude menší projekty programovat pro něco jiného. -
Dalibor Šrámek (neregistrovaný)Fulltext s převáděním českých slov na základní tvar podle slovníku a podporou synonym poskytuje například modul tsearch2 do PostgreSQL - viz tady na Rootu http://www.root.cz/clanky/fulltextovani-v-postgresql-modul-tsearch2/
S tou implementací bych to tak složitě neviděl. Když jsem kód ukázkový kód pro článek testoval, vytvořil jsem indexátor dopsáním méně než 10 řádků v PHP. Konstrukce dotazů pro nejjednodušší případy všechna slova v dotazu OR nebo všechna AND nejspíš nezabere o moc větší počet.
ČLÁNKY DO MAILU