Hlavní navigace

Názory k článku
Princip jednoduchého fulltextu s příklady v SQL a PHP (1)

uživatel si přál zůstat v anonymitě
1. 2. 2005 8:15 Nový

optimalizace rychlosti

celé vlákno
Dekuji za hezky clanek. Chtel bych se zeptat, jak se da pouzity algoritmus zrychlit. Urcite by se dala optimalizovat primo implementace, ale samotny algoritmus? Jsem jen zvedavy. Predem diky
Dalibor Šrámek
Dalibor Šrámek (neregistrovaný)
1. 2. 2005 12:25 Nový

Re: optimalizace rychlosti

celé vlákno
Pokud máte na mysli vyhledávání (a ne indexování), pak bych řekl, že algoritmus v této jednoduché podobě je značně efektivní. Implementace by ale šla zrychlit ještě hodně. Například nahrazením běžné relační databáze jako úložiště indexu vlastním řešením optimalizovaným pro dané datové struktury a cachováním velkého množství dat v RAM (včetně celého slovníku).
uživatel si přál zůstat v anonymitě
1. 2. 2005 16:40 Nový

Re: optimalizace rychlosti

celé vlákno
Vyhledavani je dostatecne efektivni, ale totez si myslim i o "generovani invertovaneho souboru" a proto jsem se ptal na nej:) Uvedený algoritmus rozhodně není optimalizován na výkon - cílem byla jeho snadná pochopitelnost. Mozna jste myslel konkretni implementaci algoritmu... Nazornost implementace na ukor kvality kvuli snadnemu pochopeni a obecnosti beru jako samozrejmost.
Dalibor Šrámek
Dalibor Šrámek (neregistrovaný)
2. 2. 2005 9:53 Nový

Re: optimalizace rychlosti

celé vlákno
Máte pravdu. Měl jsem na mysli zejména dvě hlavní brzdy: vyhledávání každého slova ve slovníku zvláštním dotazem a jednotlivé inserty. Odstranění těchto problémů ale lze považovat jen za jinou implementaci stejného algoritmu.
uživatel si přál zůstat v anonymitě
1. 2. 2005 16:41 Nový

Re: optimalizace rychlosti

celé vlákno
Vyhledavani je dostatecne efektivni, ale totez si myslim i o "generovani invertovaneho souboru" a proto jsem se ptal na nej:) Uvedený algoritmus rozhodně není optimalizován na výkon - cílem byla jeho snadná pochopitelnost. Mozna jste myslel konkretni implementaci algoritmu... Nazornost implementace na ukor kvality kvuli snadnemu pochopeni a obecnosti beru jako samozrejmost.
uživatel si přál zůstat v anonymitě
2. 2. 2005 9:23 Nový

Re: optimalizace rychlosti

celé vlákno
len tak podla toho ako pozeram je spomalenie na select a ak neexistuje tak insert. Podla ma by bolo uzitocne a rychle pouzit hash, a asi aj dobre ho ukladat do db ako identifikator unikatnosti. potom uz len staci pouzit replace (alebo insert bez osetrenia chyby) co by mohlo byt rychlejsie ako cakanie na vysledok selectu.
vlko II
2. 2. 2005 9:34 Nový

Re: optimalizace rychlosti

celé vlákno
no podla mojho nazoru by mohlo urychlit pouzitia hash na slova a v tabulke ho pouzivat ako identifikator. Potom namiesto select slovo ak nie insert slovo staci pouzit replace (v not mysql insert bez osetrenia chyby) co je rychlejsie ako select insert.
uživatel si přál zůstat v anonymitě
1. 2. 2005 9:33 Nový

PHP?

Pro začínající programátory v SQL a PHP mohl autor zmínit, že někdy je výhodné přesunou aplikační logiku do databáze a indexování (v tomhle konkrétním případě :-) ) implementovat pomocí triggerů a uložených procedur přímo v databázi. Jsou databáze, kde lze psát uložené procedury nejenom v SQL, ale i v C nebo v Javě.
uživatel si přál zůstat v anonymitě
1. 2. 2005 11:06 Nový

Mysql

celé vlákno
Proc nepouzit primo fulltext index v mysql? Staci jen zrusit diakritiku. Mysql 4 ma skvelou podporu fulltextu vcetne logickych operatoru a hledani jen casti slov apod.
Ondrej Ivanič
1. 2. 2005 11:30 Nový

Re: Mysql

celé vlákno
Veď to je práve ten problém fulltextu v MySQL. Osobne sa mi nezdá mať dáta v DB dvakrát: raz s diakritikou a druhý raz bez nej aby si s tým poradil fulltext.

Zatiaľ som ešte nerobil web kde by som ocenil výhodu fulltextu. Radšej som siahol po vyhľadávaní v klúčových slovách, označeniach produktov, ...
Dalibor Šrámek
Dalibor Šrámek (neregistrovaný)
1. 2. 2005 12:14 Nový

Re: Mysql

celé vlákno
V první řadě je článek o principu nikoliv o konkrétní realizaci. Příklady kódu vlastně jen popisují, jak to funguje. Mám za to, že pochopení, jak něco obecně funguje je užitečné třeba pro nastavení konkrétní aplikace/knihovny, která věc realizuje, a nakonec i pro člověka, který je jen uživatelem již hotové aplikace.

Nevím, proč redakce přiřadila textu nálepku MySQL. Obecnější nálepka SQL by byla lepší. A takhle jde udělat fulltext třeba i v SQLite...
uživatel si přál zůstat v anonymitě
1. 2. 2005 13:49 Nový

Re: Mysql

celé vlákno
Mam zato, ze fulltext v MySQL umoznuje vyhledavani vyrazu v delce minimalne 4 znaky a vice, coz v je v dnesnim svete zkratek docela problem - tj. uzitna hodnota je dle meho soudu dost nizka.
Jakub Vrána aura:60
1. 2. 2005 15:19 Nový

Re: Mysql

celé vlákno
Dá se to nastavit, ale na freewebu (a ani na leckterém komerčním hostingu) se s tím asi neprosadíte :-).
uživatel si přál zůstat v anonymitě
2. 2. 2005 2:11 Nový

Re: Mysql

celé vlákno
Mysql 4.0 umi i jen jeden znak...
uživatel si přál zůstat v anonymitě
2. 2. 2005 10:11 Nový

Re: Mysql

celé vlákno
Prima. Zkuste to na nejakem hostingu, jak dlouho se tam ohrejete. :-P
uživatel si přál zůstat v anonymitě
2. 2. 2005 11:14 Nový

zdrojovy kod v clancich

Ahoj chlapi,
pod clanek k novymu rootu nejdou pridavat komentare, tak to soupnu sem, protoze se to sem taky hodi:
Mrzi mne, za ac mam monitor siroky 1600 pixelu, musim si posuvnikama rolovat zdrojovy kod v pidiokynku nejakych 470 pixelu... :-(

Tak to je tak vse, jinak clanek jako takovy je SUPER !!
uživatel si přál zůstat v anonymitě
5. 2. 2005 14:45 Nový

ukazky kodu

ukazky kodu su velmi zle vyriesene, tie scrollbary su otravne a chyba farebne odlisenie, najlepsie syntax highlighting ako bol na starom dobrom root-e,

inak clanok je fajn
Dalibor Šrámek
Dalibor Šrámek (neregistrovaný)
8. 2. 2005 8:13 Nový

Errata - indexy cizích klíčů

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.)
Akela
Akela (neregistrovaný)
21. 9. 2005 9:08 Nový

Tsearch2

Otazka je ci je taketo riesenie pod PostgreSQL lepsie ako tsearch2. Osobne mam rozbehany tsearch na 1.5 Gb tabulke s 170000 zaznamamy. Priemerna velkost textu je 5 KB. Ked tabulka natiahnuta v pamati, tak sa daju dosiahnut casi pod 4 sec.
Zaujimalo by ma porovnanie tohoto riesenia vs tsearch2.
Zasílat nově přidané příspěvky e-mailem