Dotaz: Jakou db pouzit na vlastni "vyhledavac"?

[martina]

ahoj,

 

poradte mi jakou technologii, db a jazyk pouzit na tohle:

 

"databaze" obsahujici kolem 10M clanku (delka textu 1-4 A4) (cast plaintext, cast html)

 

hw: xeon, 32gb ram, 3tb disk (raid1 - lepsiho nic neni)

 

a potrebuji udelat neco, co bude schopne hledat v tom duplicity/kopie. proste, zadam clanek (nebo aspon tri ctyri vety z nej) a potrebuji do par vterin mit vypsane bud presne nebo velmi podobne shody (tj. aby prosly i veci kde je vic mezer mezi slovy, atd.)

 

nemyslim si, ze mysql/pgsql a fulltext je na tohle dobre reseni.

 

mate nejaky tip? treba lucene?

 

dekuji,

martina

Odpovědi

[psholty2]

Inverted index

[psholty2]

A este asi budes potrebovat "Document Retrieval", mrkni na NLP lekcie na coursera.org (week 7 - Information retrieval), je tam popisany aj ten inverted index, potom v week 7 - ranked information retrieval je skore, asi tf-idf je najbeznejsie

[martina]

diky, kouknu na to

[FooBar]

Muzes rozvest, proc nemyslis, ze mysql/pgsql a jejich fulltext neni vhodny reseni? S MySQL fulltextem zkuenosti nemam, ale postgres fulltext by na tohle sel pouzit zcela trivialne.

[FooBar]

*"proc myslis, ze je", samozrejme

[martina]

no, mam strach, ze nebude to stihat vykonem (viz hw nahore). oproti nejakemu reseni na miru. tzn. povazuji fulltext u sql db za prilis obecne reseni (ale netusim, nikdy jsem takovou vec neresila).

ono, pokud bych z kazdeho clanku vybrala par vet (delsi nez 6 slov, kvuli hledani duplicit) a projela to oproti db, bylo by to pro me dostacujici. myslis, ze by tohle slo v pgdb s tim, ze budou vysledky temer okamzite?

[Ivan]

No nevim. Podle me mas spatny poradi. Nejdriv se resi pozadavky na SW, algoritmus, konktretni SW produkt a teprve az nekonec se resi sizing. Jestli to pgSQL(anebo neco jinyho) utahne anebo ne, to se neda rict - nikdo nema tvoje data. To muze ukazat jedine test.

[FooBar]

Nemam jedinej duvod si myslet, ze budou problemy -- prijde mi, ze ted resis jen premature optimization, coz je naprosta cesta do pekel.

Ve zkratce:

1. Ziskej data.
2. Rozhoduj se.

Nedelej to obracene. Nerozhoduj se na zaklade nepodlozenejch predpokladu o vykonu, a az budes ziskavat data na zaklade kterejch se budes rozhodovat, nezapomen si overit nekym zkusenejsim ze tam nejsou nejaky prehlednuty chyby (omylem chybejici index nebo tak neco veselyho).

Jako rule of thumb bych naprosto nevidel problem v FT vyhledavani nad ~40M normostranama, ale samozrejme zalezi na hromade dalsich faktoru, jako napriklad ocekavana charakteristika zateze.

[rADOn]

Pokud ti jde jen o nejaky ty mezery a podobny volovinky tak by stacilo nejak znormalizovat tu databazi. Pokud chces decentni vykon a opravdovej fulltext tak mrkni na sphinx. Vezme si nejaky misto na barely, ale lita jako drak. "Fulltext" v databazich je tak neco mezi tim, funkcne slabota ale zase je to jednoduchy na rozbehani. (sphinxka je docela elektrarna)

[Michal]

Na fulltext db se mi osvedcilo Lucene (Java API) a Solr (HTTP/REST API postavene nad Lucene enginem). Velice dobre konfigurovatelne, jsou tam ruzne filtry, dalsi lze napsat, atd. Hledat duplikaty tam jde velice jednoduse, a to i v pripade ze nejde o 100% shodu.

[Michal Karas]

Když už jsou zmíněny tyto technologie, tak bych přidal i ElasticSearch, který je také postavený na Lucene a přijde mi, že v poslední době je minimálně stejně populární jako Solr.

[ML]

Já jsem si zvyk na http://sphinxsearch.com/ , celekm fajn. :)