[db] full text-search functionaliteit databases.

[Alarmnummer]

Ik ben een beetje aan het rondkijken naar full text-search functionaliteit in de bekendere databases (my sql. ms sql etc) en ik zie dat er best ondersteuning voor is. Mijn vraag is in hoeverre de bestaande functionaliteit te kort schiet, en welke andere problemen (misschien performance) ontstaan. Ik hoor namelijk regelmatig geklaag, maar ik heb de indruk dat het best voldoet voor simpele toepassingen. Je kunt boolean queries gebruiken, meerdere columns in een enkele index plaatsen, werken met wildcards. Dus voor simpele dingen lijkt het me dat er genoeg functionaliteit beschikbaar is.

Dus wie heeft ervaring met de full-text search functionaliteit van de bekendere databases, en tegen welke problemen lopen jullie aan?

[ Voor 15% gewijzigd door Alarmnummer op 25-04-2005 11:27 ]

[EfBe]

sqlserver's full text search is wel OK, je hebt alleen de MS Search service nodig, die weer de index service start, en verder loopt de filesize nogal snel uit de klauwen. Maar indien diskspace geen bezwaar, dan doet hij het prima. Het onderhoud is 0.0, aangezien de service zichzelf onderhoudt (mits goed geconfigureerd) dus na wat instelwerkzaamheden heb je er verder geen kind aan.

Indien de data niet echt groot is zou ik gewoon met LIKE %pattern% gaan zoeken, dat scheelt weer configuratie stress. Overigens is er GEEN ISP die fulltextsearch ondersteunt, dus een eigen server is vereist.

[P_de_B]

EfBe schreef op maandag 25 april 2005 @ 14:41:

Er zijn wel ISP's die het ondersteunen hoor

[whoami]

EfBe schreef op maandag 25 april 2005 @ 14:41:
Indien de data niet echt groot is zou ik gewoon met LIKE %pattern% gaan zoeken, dat scheelt weer configuratie stress. Overigens is er GEEN ISP die fulltextsearch ondersteunt, dus een eigen server is vereist.

Werkt een LIKE %pattern% ook op een TEXT field ?

[P_de_B]

Volgens mij niet, je moet met PATINDEX gaan werken.

[whoami]

Verder heb ik eigenlijk niet echt 'echte' ervaring met Full Text Search in Sql Server, ik heb het wel eens opgezet, ik heb er wel eens mee gespeeld, maar ik heb dus geen 'real hands on' ervaring ermee binnen een 'echt' project.
Wat ik me nu ook wel afvraag is in hoeverre Sql Server het ondersteunt om resultaten terug te geven die niet 100% matchen met het 'zoekwoord' binnen dit full text searching gedoe.

[chem]

Grootste nadeel van MySQL's implementatie is dat < 3 char-woorden geskipped worden. Dit maakt het niet voor alle toepassingen geschikt, helaas.

[-FoX-]

EfBe schreef op maandag 25 april 2005 @ 14:41:
Indien de data niet echt groot is zou ik gewoon met LIKE %pattern% gaan zoeken, dat scheelt weer configuratie stress. Overigens is er GEEN ISP die fulltextsearch ondersteunt, dus een eigen server is vereist.

LIKE %pattern% biedt niet echt een oplossing voor fulltext searches. Als ik in een zoek-textbox "Voornaam Achternaam" invul, en deze 2 velden worden in aparte kolommen bijgehouden in de database, dan heb je niet zoveel aan je LIKE expressie.

Wat ik me overigens afvraag hoe dergelijke zoekopdrachten meestal afgehandeld worden? Ga je in je logica de 2 termen opsplitsen, ieder afzonderlijk zoeken en die zoekresultaten mergen en naar de gebruiker doorspelen? Of zijn er betere oplossingen mogelijk?

[Alarmnummer]

EfBe schreef op maandag 25 april 2005 @ 14:41:
sqlserver's full text search is wel OK, je hebt alleen de MS Search service nodig, die weer de index service start, en verder loopt de filesize nogal snel uit de klauwen.

Wat je de verhouding tussen de tekst (in de normale records) en de index?

Indien de data niet echt groot is zou ik gewoon met LIKE %pattern% gaan zoeken, dat scheelt weer configuratie stress. Overigens is er GEEN ISP die fulltextsearch ondersteunt, dus een eigen server is vereist.

Is een Like niet bagger traag? En dat met die ISP is idd ook een goed punt.

[Alarmnummer]

-FoX- schreef op maandag 25 april 2005 @ 15:15:
[...]
Wat ik me overigens afvraag hoe dergelijke zoekopdrachten meestal afgehandeld worden? Ga je in je logica de 2 termen opsplitsen, ieder afzonderlijk zoeken en die zoekresultaten mergen en naar de gebruiker doorspelen? Of zijn er betere oplossingen mogelijk?

Betere oplossing is mogelijk. Gewoon een fullblown searchengine zoals Lucene erachter zetten Dat is ook de reden dat ik dit topic ben gestart trouwens.

[whoami]

Alarmnummer schreef op maandag 25 april 2005 @ 15:18:
[...]


Is een Like niet bagger traag? En dat met die ISP is idd ook een goed punt.

Een LIKE %pattern% is zowiezo traag, want dan kan er geen index gebruikt worden.
LIKE pattern% kan dan wel weer een index gebruiken.

't Hangt er vanaf hoeveel records je in een tabel hebt, en hoe groot (fillfactor) die columns zijn waarin je zoekt.

[elmer25]

Alarmnummer schreef op maandag 25 april 2005 @ 11:22:
Ik ben een beetje aan het rondkijken naar full text-search functionaliteit in de bekendere databases...

Ik weet dat Oracle meerdere varianten full text indexen heeft. Voor een search engine kun je eens kijken naar de CTX-CAT index (http://www.oracle.com/tec...htdocs/ctxcat_primer.html). Op zich een hele goede full text index, met als enige nadeel dat bij wijzigingen in de tabel de index automatisch bijgewerkt wordt (middels een trigger). Bij grote tabellen kan de index update nogal kostbaar worden qua tijd.

Je hebt, neem ik aan, nog geen definitieve keuze qua database gemaakt? Dat zou het nl. wat eenvoudiger maken om de opties naast elkaar te zetten.

[Verwijderd]

chem schreef op maandag 25 april 2005 @ 15:06:
Grootste nadeel van MySQL's implementatie is dat < 3 char-woorden geskipped worden. Dit maakt het niet voor alle toepassingen geschikt, helaas.

Dat is niet het grootste nadeel, volgens mij is dit zelfs configureerbaar (vanaf 4.1 dacht ik), wat zou betekenen dat jouw grootste nadeel niet meer zou bestaan. Verder kan je de search redelijk tweaken, de 50% threshold is te disablen, mooier zou zijn dat je dit bijvoorbeeld op 80% oid zou kunnen zetten, maar dat is volgens mij niet mogelijk.

[edit]
Kan dus vanaf 4.0 al zie: http://dev.mysql.com/doc/mysql/en/fulltext-fine-tuning.html

[ Voor 9% gewijzigd door Verwijderd op 25-04-2005 15:33 ]

[chem]

Mjah, maar dat is dus alleen per mysql-server in te stellen, en niet per connection...

Maar goed, het is al beter dan 3.23.x waar het alleen tijdens het compilen kon

Zelf ben ik nog steeds erg tevreden over Xapian/Omega; al weet ik dat de setup vreselijk complex is voor de meeste gevallen en sommige SQL servers wellicht dezelfde performance kunnen bieden.

[Verwijderd]

De woordlengte is inderdaad per dbserver alleen maar in te stellen en daarmee heb je eigenlijk een van de grootste nadelen van de search. Het disablen van de threshold kan per query dacht ik.

[Alarmnummer]

elmer25 schreef op maandag 25 april 2005 @ 15:30:
Je hebt, neem ik aan, nog geen definitieve keuze qua database gemaakt? Dat zou het nl. wat eenvoudiger maken om de opties naast elkaar te zetten.

Er is geen behoefte om een database keuze te nemen voor dit probleem. Wij werken intern veel met Ms SQL (met veel plezier) en ik wil sowieso weten wat deze in huis heeft.

En verder wil ik in het algemeen een beetje een beeld krijgen wat de zoekfunctionaliteit is van de bekendere databases, zodat je niet een fullblown searchengine achter een db zet als het al direct in de db zit.

[elmer25]

Alarmnummer schreef op maandag 25 april 2005 @ 16:02:
[...]

Er is geen behoefte om een database keuze te nemen voor dit probleem. Wij werken intern veel met Ms SQL (met veel plezier) en ik wil sowieso weten wat deze in huis heeft...

Oke, dat je nog geen keuze kunt of wilt maken heb ik begrip voor. Maar wat is dan precies je vraag / probleem?
In je 1e post schrijf je

Mijn vraag is in hoeverre de bestaande functionaliteit te kort schiet

te kort schiet waarvoor? Zoals anderen hierboven ook al aangeven, als je wilt zoeken in een paar honderd of duizend records, heb je waarschijnlijk helemaal geen full text index (fti) nodig. Als je daarentegen wilt zoeken in 100-duizenden of miljoenen records ontkom je er niet aan. Daarbij speelt ook het gebruik van de database een grote rol. Als er veel updates/inserts gedaan worden moet je je afvragen of je met een standaard fti voldoende hebt. Misschien moet je dat een aparte tabel maken die slechts eens per uur/dag bijgewerkt wordt waar je dan weer de fti op legt.

Of ben je misschien gewoon benieuwd naar mogelijkheden en opties van fti's? In dat geval zijn de uitgangspunten die ik schets waarschijnlijk helemaal niet bekend.

[Alarmnummer]

elmer25 schreef op maandag 25 april 2005 @ 16:16:
[...]
Oke, dat je nog geen keuze kunt of wilt maken heb ik begrip voor.

Ik hoef geen keuze te maken omdat er geen directe behoefte is een full text search te realiseren. Ons bedrijf zit de laatste tijd wat meer in de zoekhoek, en de vraag komt wel eens voorbij: kunnen jullie ook door databases zoeken? Uiteraard kan dat. Maar voordat ik zeg... kom maar hier en we maken een afspraak, heb ik veel liever een goed beeld van wat er al geimplementeerd is en op basis hiervan een klant advies geven. Als we voor een 1/10 deel in sql server iets kunnen configureren dat voldoet, ipv de klant met een (dure) oplossing op te zadelen, dan ben je imho niet goed bezig.

Maar wat is dan precies je vraag / probleem?

Ik wil een beeld van wat andere developers vinden van de zoekfunctionaliteit die is geimplementeerd in de databases die ze gebruiken. Wat vinden jullie er goed aan, slecht aan, missen jullie etc etc.

Of ben je misschien gewoon benieuwd naar mogelijkheden en opties van fti's? In dat geval zijn de uitgangspunten die ik schets waarschijnlijk helemaal niet bekend.

Ik ben idd nieuwschierig naar de mogelijkheden. Er is op dit moment nog geen directe behoefte, maar ik wil een beeld krijgen. Niet dat ik straks een tijd bezig ben met iets te bedenken, terwijl er al kant en klare oplossingen zijn.

[elmer25]

Alarmnummer schreef op maandag 25 april 2005 @ 16:22:
Ik wil een beeld van wat andere developers vinden van de zoekfunctionaliteit die is geimplementeerd in de databases die ze gebruiken. Wat vinden jullie er goed aan, slecht aan, missen jullie etc etc.

Oke, dan kan ik je mijn ervaringen met de Oracle fti's delen. We hebben hier een tabel met 4 tot 5 miljoen records, waarin dagelijks 50 tot 100 duizend mutaties in plaatsvinden (inserts/updates/deletes). In eerste instantie hadden we voor de zoekfunctionaliteit een CTX-CAT index gemaakt. Deze index is echt bloedje snel met zoeken, en ook dingen als zoeken op "voornaam achternaam" en dan ook records vinden waarin alleen "achternaam" staat gaat hiermee erg goed. Het enige nadeel is het bijwerken van de index. In ons geval kon dat 0,5 tot 1 seconde duren, op zich niet lang, maar als het met elke mutatie moet gebeuren... afin, je begrijpt dat dat niet werkt.

We gebruiken nu een CONTEXT index. Deze index is qua performance vergelijkbaar, alhoewel ik soms de indruk krijg dat de CTX_CAT toch net iets sneller is (maar dat kan ook aan het tunen van de db liggen). Zoeken op "voornaam achternaam" gaat lastiger omdat je dat als "voornaam AND achternaam" naar de database moet sturen, je moet er dus als programmeur meer voor doen.
Het grote voordeel zit in het bijwerken van de index. Dat gaat middels een stored procedure die met een job op vaste intervallen (bij ons 5 minuten) gedraait wordt. Het updaten zelf duurt ook 0,5 tot 1 seconde, maar dus niet meer voor elke mutatie.

Oke dan, ik hoop dat je er wat aan hebt.

[T-MOB]

Alarmnummer schreef op maandag 25 april 2005 @ 16:22:
Ik wil een beeld van wat andere developers vinden van de zoekfunctionaliteit die is geimplementeerd in de databases die ze gebruiken. Wat vinden jullie er goed aan, slecht aan, missen jullie etc etc.

Alleen wat ervaring met mysql hier. Het grootste nadeel aan de fulltext-search vind ik daar dat er alleen naar volledige woorden wordt gekeken. Als ik zoek op "appel boom" worden geen resultaten getoond waar alleen "appelboom" in wordt genoemd. Terwijl ik dat wel zou willen. Gevolg is dat je alsnog logica moet gaan verzinnen en/of met LIKEs aan de slag moet waardoor het nut van de fulltext search voor een groot deel verloren gaat.

[EfBe]

whoami schreef op maandag 25 april 2005 @ 14:45:
[...]
Werkt een LIKE %pattern% ook op een TEXT field ?

Tuurlijk.

[EfBe]

Alarmnummer schreef op maandag 25 april 2005 @ 15:18:
[...]
Wat je de verhouding tussen de tekst (in de normale records) en de index?

ja. Hij maakt catalogs aan voor de full text search en die kunnen nogal oplopen qua grootte. Een van de redenen waarom sommige ISP's (ok niet alle) geen sqlserver fulltextsearch ondersteunen.

[...]
Is een Like niet bagger traag? En dat met die ISP is idd ook een goed punt.

Like is niet een van de snelsten, daarom is het alleen geschikt wanneer je niet zoveel data te doorzoeken hebt. Mn forum gebruikt het nog, maar met 14000 messages begint het te traag te worden (3 seconden voor een resultset) en ga dan ook binnenkort over op een term-based search engine, of een selflearning search engine, moet nog even uitzoeken welke de minste rotzooi oplevert. (de self learning is initieel wat trager, maar levert geen mega indexes op van alle mogelijke termen waar men wellicht toch niet op zoekt, maar vergt wat meer onderhoudt)

[alienfruit]

Ik gebruik of mijn oude zoektechnologie (context-based) of anders http://www.dtsearch.com/PLF_engine_2.html

[Verwijderd]

Ik ben recentelijk enthousiast geworden over de mogelijkheden die Oracle standaard meelevert onder de noemer "Oracle Text". Deze module biedt geavanceerde functionaliteit op het gebied van documentclassificatie. Maar ook de eenvoudiger zoekmogelijkheden zijn tot in de puntjes afgewerkt en veelvoorkomende problemen zijn afgevangen.

Om een voorbeeld te noemen, het normaliseren van woorden met speciale karakters. Als ik het woord "financien" zonder trema intype, wil ik in de resultaten ook de entries terugzien waarin dit woord geschreven is als "financiën". Bij het zoeken in Engelstalige teksten is dit meestal geen issue. In het Nederlands is het een kleine onvolkomenheid als het niet werkt. Maar in andere talen zoals Duits en Spaans is dit een belangrijk issue.

Als je je indexen goed configureert, wordt dit in Oracle Text netjes ondervangen. In hoeverre andere databases deze functionaliteit aanbieden, weet ik niet, maar ik heb zo mijn twijfels.