Een tijdje geleden vroeg ik jullie op deze blog naar input over website search oplossingen. Een maand later is een korte update misschien op zijn plaats?
Laat ons eerst de oplossingen even overlopen die in de comments van mijn eerdere blogpost werden voorgesteld: pvandewyngaerde linkte naar Xapian en Strigi. Over Strigi kunnen we kort zijn: het is een desktop search en geen website search, volgende dus. De andere link was inderdaad direct veelbelovender: Xapian is een open source search library in c++. Omega is een voorbeeld-implementatie van Xapian in perl. Ik vond niet veel documentatie over Omega, dus even geïnstalleerd en mee gespeeld. Eerste probleem: alle configuratie zit in txt-files, niet van dien aard dat onze business-collega’s daar direct mee aan de slag kunnen. Tweede probleem: crawlen van websites wordt niet ondersteund. Omega gaat er namelijk van uit dat je website lokaal (op dezelfde machine) staat en indexeert statische html via het filesysteem. Voor echte crawling verwijst de wiki naar wget (zo heb je je site toch lokaal) of htdig. Niet handig om het zachtjes uit te drukken en “as such” dus toch niet echt bruikbaar voor onze doeleinden.
Luc stelde Nutch voor. Nutch is een broertje van het quasi alomtegenwoordige Lucene; open source, ook onder de rokken van de Apache foundation en ook java. Nutch is een mooi uitgangspunt voor een website search, maar features als stemming en logical operators worden niet ondersteund. Configuratie is heel flexibel (want via tekstfiles), maar er is anderzijds ook hier geen ‘leuke webinterface’ om de boel te administreren. In mijn nota’s (maar ik vind niet direct terug waar ik die info gevonden heb) lees ik tenslotte dat Nutch out of the box geen ‘collections’ ondersteund. Alles wordt dus in 1 index bewaard, wat voor onze implementatie (een 10-tal sites in 2 of 3 talen die we ook apart willen kunnen bevragen) nodig was.
Omdat ik ook maar een onwetend eenzaat in een groot telecom-bedrijf zonder eigen (web-)developers ben, schreven we een tijd geleden ook een paar bedrijven aan met de vraag een oplossing voor ons te formuleren en budgetteren. We kregen 4 offertes, 2 voor custom-built solutions en 2 product-gebaseerde voorstellen. De 2 “build” oplossingen gingen beiden uit van Lucene als “core”, de ene met Nutch, de andere met Compas (een high-level api voor Lucene met integratie van Spring, Hibernate, JDBC, …) erbovenop. Omwille van de risico’s verbonden aan custom development (scope-bepaling, functionele analyse en development van de administratie-schermen om er maar enkele te noemen) en omwille van de strikte deadline besloten we om niet te opteren voor nog te ontwikkelen oplossingen.
In het andere voorstel kwamen we gelukkig een oude bekende tegen: Searchblox is een op Lucene gebaseerde mid-market search-oplossing. Crawling en indexing, de search-interface (incl. stemming en fuzzy search), een goeie backend voor administratie, een REST-api en de mogelijkheid om met xslt de business logica van de presentatie van zoekresultaten te wijzigen, zijn standaard functionaliteiten die in 1 eenvoudig te deployen WAR zitten. U raadt het al; omwille van doorlooptijd, geboden functionaliteit en kostprijs opteerden we uiteindelijk inderdaad voor Searchblox. Benieuwd wat dat gaat geven!