Jak na vlastní fulltextové vyhledávání?

22.4.2012 22:00 | Přečteno: 3793× | Tábor

Aktuálně jsem postaven před problém, jak vytvořit relativně kvalitní fulltextové vyhledávání na vlastním webu. Pravdou je, že existuje řada služeb online, které fulltext na web umí přidat. Mezi možné kandidáty patří Google který mě osobně nevyhovuje, neboť prvním výsledkem ve vyhledávání je vždy placená reklama. Ačkoliv postoj google chápu, tak je to nejlepší způsob, jak poslat návštěvníka ke konkurenci.

Druhá, hodně doporučovaná možnost je Atomz který po cca 2 měsících zkoušení nefunguje tak, jak bych chtěl. Ačkoliv jsem v nastavení na atomz zvolil indexovat 1x týně, tak po měsíci jsem zistil, že stejně nic neindexuje. Jediná šance je se na atomz hlásit a vždy obnovovat index. Bohužel, toto je problém. Často zadám do Atomzu hledat něco, co na webu mám ale Atomz to nenajde. Bohužel takovéhle vyhledávání mi hodně nevyhovuje.

Mrkněte sami, jak to s Atomzem vlastně vypadá

Tento zápisek má v podstatě posloužit k rozvíření diskuze an téma vlastního fulltextu. Na webu mám inplementovaný http://www.taboreni.cz/sitemap.xml a z něj bych asi nejraději vycházel. Asi bych dle sitemaps celý web třeba 1x za 24 hodin grabnum wgetem a nějak "zpracoval" obsah a uložil do databáze. Pak bych měl tabulku v DB která by vždy obsahovala html titulek, H nadpisy, textový obsah a URL... a teď je jen otázka, jak postavit vyhledávací script.

Chtěl bych, aby hledání probíhalo fultextově, nezáleželo na diakritice (ATOMZ diakritiku neumí a tak vyhledává špatně), rád bych aby se upřednostnil titulek, pak nadpisy Hx a nakonec obsah webu.

Nemáte nějaké nápady a zkušenosti?

       

Komentáře

[ʚĭɞ 🍉]

Jyxo?

[Člověk z Horní Dolní]

Outsourcuj to do Indie.

[Adam]

Sa smejes ale ono pri CAPTCHA to funguje

[retroslava]

Třeba http://postgres.cz/wiki/Instalace_PostgreSQL#Instalace_Fulltextu ?

[Johny z Podoli]

to už jsem viděl, bohužel mám firebird (interbase)

[bazil]

No nevím, jak ve Firebirdu, nicméně v MySQL se to řeší buď: přidáním fulltextu nad sloupcem, což se může negativně projevit na výkonu dotazů nad danou tabulkou nebo (podle mě lepší řešení): se vytvoří v DB jedna tabulka navíc, každý text v DB má na ni vazbu a při každé úpravě textu se musí upravit i tabulka. Potom se vybuduje fulltext nad touto tabulkou. Prioritizace nadpisů by se dala zařídit vlastním sloupcem pro nadpisy v tabulce pro vyhledávání.

Nevýhodou tohoto řešení je vyšší režije při aktualizaci textu v DB (ale to se děje jen při vkládání nového článku, nebo úpravě starého), naopak výhodou je, že se zachová rychlost selectů nad stávajícími tabulkami s texty (při normálním prohlížení webu nejčastější dotaz) a zároveň se získá fulltextový klíč pro vyhledávací skript, který je tedy poté trochu pomalejší, ale zase vyhledávací select se nebude pouštět tak často.

[marbu]

Kdybych si s tím chtěl hrát, zkusil bych provozovat vlastní instanci lucene, sphinx nebo nějakého jiného open source search engine.

[limit_false]

Taky bych doporučil Sphinx. Ze začátku to bude trocha pruda, ale fungovalo to celkem rozumně, později se ladily jenom váhy a možná občas příliš pomalé dotazy.

[Ondra]

Mathias Hasselmann - Full Text Search Engines, Part I

Michal Hruby - FTS engines - memory usage

[Josef Kufner]

Kdysi na Rootovi a tuším, že i tady, vyšlo pár článků. Je to ale už hodně dávno... cca kolem roku 2005. Leoš tu tou dobou také řešil něco kolem Lucene.

• http://www.root.cz/clanky/princip-jednoducheho-fulltextu-1/
• http://www.root.cz/clanky/princip-jednoducheho-fulltextu-2/

[dad]

my pouzivame mnogosearch

[mess]

SELECT * FROM articles WHERE title LIKE %neco% AND content LIKE %neco%;

[Johny z Podoli]

nojo, kdyby těch tabulek nebyly desítky, sloupců stovky a hromada dat není z databáze ale je generovaná onfly scrpty a podobně bohužel...

[Migi]

Off Topic:

Nevim už kde, ale nedavno jsem četl jakysi članek doporučující rodičům webové stránky s katalogy táborů. Takové ty články "kam poslat děti na prazdniny at maji rodiče pokoj".

Ten tvůj portál byl na prvním místě a dlužno říci že ze všech zmíněných webů působil naprosto nejšpičkověji.

Takže gratuluju k úspěchu a drceni konkurence .

[JK]

Nepomuze starsi clanek? Cestinu jsem resil prevodem diakritiky na znaky bez diakritiky a s vyhledavanim jsem spokojen.

[Aleš Janda]

http://search.seznam.cz/vlastni - ale vrchní reklama je tam taky (může se však strefovat do jiných slov než Google).

Anebo jsem kdysi zkoušel rozběhnout Sphinx, přičemž každé slovo se lemmatizovalo (tím se do značné míry vyřešilo skloňování a diakritika).

[Jan Grmela]

Možná Amazon CloudSearch?

[pek]

Používám sphider, ale to je spíš pro menší weby.

[Sajfi]

Ja si teď po večerech hraju s Sherlockem z nasi Ceske kotliny a je to moc hezká hračka .

[xkucf03]

K té diakritice: skutečně je to nutné? Předpokládám, že v databázi máš obsah s diakritikou, takže jde o to, jak budou hledat uživatelé. Je lepší 1) vyhledávat i nesmysly a zatěžovat irelevantními výsledky uživatele, kteří si „dali tu práci“ se zadáváním hledaného textu s diakritikou nebo 2) dávat špatné výsledky uživatelům, kteří jsou líní/neschopní zadat hledaný text včetně háčků a čárek?

[Käyttäjä 11133]

3) podle toho jestli hledaný řetězec obsahuje nebo neobsahuje diakritiku vyhledávat v indexu s diakritikou, nebo ne (často potřebuju něco najít z blackberry, hledání pouze s diakritikou mě irituje )

[Josef Kufner]

Obdobný problém je například se skloňováním a s překlepy. Jako rozumné se mi jeví přiřadit přesné shodě lepší skóre a částečné shodě (překlep, chybějící diakritika) nebo jinému tvaru stejného slova přiřadit skóre o něco horší. Takže irelevantní výsledky budou až za relevantními a líný uživatel dostane, co chtěl.

V praxi se mi osvědčilo (z pohledu uživatele) i vyhledávání podle začátků slov. Krásná ukázka toho je na wowhead.com.

[Roman Schulz]

Taky bych doporučil Sphinx, je snadno konfigurovatelný, indexace může probíhat pomocí zadaného SQL dotazu. Používáme ho i na velkých projektech k naprosté spokojenosti

[joka x3m]

Stiahnut obsah webu rekurzivne cez perl, natlacit texty do db, 2 stlpce, jeden s diakritikou, druhy bez, zapnut index pre fulltext na stlpci bez diakritiky, pri hladani ocistit diakritiku a zvazit jednoduchy fulltext select alebo rozsireny. Robil som specialne parsovanie webu, a vsetko mi funguje presne tak ako ja chcem :) ak chces napis na kalus bodka jozef zavinac gmail bodka com a mozem ti dat blizsie info o tom, nie je to az tak komplikovane ak tvoja db podporuje fulltext :)

[Kvakor]

A pokud nejsou data čistý text (což většinou nejsou, buď je to (X)HTML nebo nějaký značkovací jazyk redakčího systému), tak se musí text prvně převést. Když je zdroj nějak strukturovaný, je ještě možné vytahat "zvýrazněné" části bokem do separátního sloupce, když jsem něco takového kdysi dělal, tak tam šlo všechno z <strong>, <em>, vnitřku nadpisů a toho, co se vkládalo do klíčových slov v hlavičce.

Zákazník chtěl ještě podporu skoňování a časování, ale protože se mi nepovedlo najít volně dostupná data, tak se to nakonec neřešilo. Stejně dodnes nevím, jak to elegantně řešit, návrh byl pro každé slovo, které se najde v "sloňovací/časovací" tabulce, provést dotazy na všechny další slova se stejným identifikátorem. V praxi to mohlo znamenat zhruba zdeseti-zdvacetinásobení dotazů, protože se počítalo i zahrnutí nespisovných tvarů (typu "myšmi/myšma/myšima/myšema/myšmami/myšmama"). Docela by mně zajímalo, jak tohle řeší hoši v Seznamu

[xkucf03]

Stejně dodnes nevím, jak to elegantně řešit, návrh byl pro každé slovo, které se najde v "sloňovací/časovací" tabulce, provést dotazy na všechny další slova se stejným identifikátorem. V praxi to mohlo znamenat zhruba zdeseti-zdvacetinásobení dotazů

Proto se to řeší tak, že se do indexu ukládají pouze slova v základním tvaru a dotazy se převádějí opět na základní tvar (pokud např. nejsou v uvozovkách).

[Kvakor]

To by šlo, sice by generování zabralo šíleně času, ale vyhledávání by to moc nezpomalilo. Ale tenkrát jsem to už neřešil, protože bych nakonec mohl skončit u implementovani plnohodnotného vyhledavaciho enginu jen kvůli pár stránkám

[Ladicek]

Obvykle úplně stačí jenom odřezávat přípony, na to není ani potřeba slovník, seznam českých přípon se dá najít někde v ispellu.