In de open source wereld zijn Apache Lucene en Solr de vaakst genoemde oplossingen om een zoekmachine te bouwen. Het probleem is dat deze geen ‘web crawler’ bevatten, namelijk een systeem dat webpagina’s opvraagt, de inhoud indexeert en de aanwezige links op hun beurt verwerkt, net zoals Google doet. Apache Nutch is een zusterproject van Lucene dat zich op dit terrein waagt, namelijk een “Google” voor intern gebruik. In deze post gaan we eens kijken hoe je Nutch opzet en gebruikt. Merk op dat dit een technische uitleg zal zijn.

• initiële URL’s worden aan Nutch gegeven, bijv. de lijst met websites die je wenst te indexeren (inject)
• en dan doorloopt Nutch een aantal maal het proces (dit wordt de depth genoemd)

• generatie van lijst van URLs die moet behandeld worden (generate)
• pagina’s ophalen (fetch)
• inhoud van de pagina’s verwerken (parse). Hierbij kunnen zowel gewone html pagina’s geïndexeerd worden als documenten (PDF, DOC, …)
• de Nutch DB update (updatedb)
• opslag van de resultaten in Solr (solrindex)

Hier kan je een voorbeeldscript vinden dat alle stappen samenbrengt. Je kan ook gebruiken maken van het ‘crawl’-commando dat de stappen combineert, maar dan heb je minder zicht op de verschillende stappen van het proces.

• http.agent.name : welke browser agent string wordt er door doelwebsites gezien zodat je op die sites een crawler kan toelaten en ook een verschil kan maken tussen crawler-traffiek en gewone traffiek.
• parser.character.encoding.default : welke encoding er moet gebruikt worden als deze ontbreekt (bijv. utf-8).
• storage.data.store.class : welke backend er wordt gebruikt, bijv. org.apache.gora.hbase.store.HBaseStore voor Hbase.
• plugin.includes : Nutch heeft een plugin architectuur die het mogelijk maakt om bepaalde functionaliteit toe te voegen. Er zijn een aantal plugins die standaard geconfigureerd zijn. In het geval van de tests werden volgende plugins gebruikt

protocol-httpclient|urlfilter-regex|parse-(html|tika)|index-(basic|anchor|more)|urlnormalizer-(pass|regex|basic)|scoring-opic

• db.ignore.external.links : geeft aan of de crawler buiten de initieel aangegeven websites links mag volgen.
• file.content.limit & http.content.limit: hoe groot mogen de geïndexeerde bestanden of webpagina’s zijn. Dit moet overeenkomen met wat je als groottebeperking opgeeft in de onderliggende databank.

Backend

De HBase backend kan ook getuned worden maar dat is eigenlijk een topic op zich. Je kan hier en hier wat  informatie vinden. Het belangrijkste is dat er genoeg geheugen beschikbaar is.

• URLfilter-regex

Je kan URL’s filteren en bepalen welke URL’s in aanmerking komen en welke niet. In het configuratiebestand “regex-urlfilter.txt” kan je dit met behulp van reguliere expressies configureren. URL’s die voldoen aan de expressie kan je dan uitsluiten door er ‘-‘ voor te zetten of expliciet toevoegen door ‘+’. Zo zal de regel

-index.php/Help:.*

Wikimedia links met de hulppagina’s niet indexeren of kan je bijvoorbeeld instellen dat het url-pad niet dieper mag zijn dan 7 niveau’s:

"-.*/(?:[^/]+/){7,}

Je kan een regel toevoegen aan het bestand en dan testen met:

 <installatiedir>/bin/nutch plugin urlfilter-regex org.apache.nutch.urlfilter.regex.RegexURLFilter

Je geeft dan een url in en krijgt dan het resultaat of deze al dan niet gefilterd wordt.

• URLNormalizer-regex

De opgehaalde URL’s kan je normalizeren naar een bepaalde vorm. Dit is vooral handig als je bijvoorbeeld een site indexeert waarvan documenten op verschillende locaties terugkomen maar met een verschillend pad. Dit was in de tests het geval met een website gebaseerd op IBM Lotus Domino. De url naar een document hangt af van het pad langswaar je er naar toe gaat.

Eenzelfde document heeft bijvoorbeeld als urls (met zijn identifier als laatste parameter):

http://website/databank.nsf/<id1>/<id>?OpenDocument
http://website/databank.nsf/<id2>/<id>?OpenDocument

Als je dan weet dat er een URL bestaat om het document rechtstreeks op te vragen door

http://website/databank.nsf/View/<id>

dan kan je de bovenstaande urls normalizeren met behulp van volgende expressies

> bin/nutch readdb -url http://website.com/pagina

key: http://website.com/pagina
baseUrl: http://website.com/pagina
status: 2 (status_fetched)
fetchInterval:  83000
fetchTime:      1360246212783
prevFetchTime:  1360162351060
....
title:  Title

> date -u -d @1360246212
Thu Feb  7 14:10:12 UTC 2013

Het fetchInterval zal worden toegevoegd aan de moment dat de pagina opnieuw wordt opgevraagd, in dit geval 83000 seconden of 23 uur. Zo zal je dus elke dag de pagina’s kunnen vernieuwen.

Voor een recrawl kan je je bijvoorbeeld beperken tot 2 iteraties van het crawlproces. Zo worden bestaande pagina’s opnieuw overlopen en eventueel nieuwe links gedetecteerd. Deze worden dan in de volgende iteratie ook mee geïndexeerd. Het heeft ook als gevolg dat je index nog verder groeit als er bij vorige iteraties nog extra links werden gedetecteerd. Zo werd in de test een index van 80 000 pagina’s er snel eentje van 220 000 pagina’s.

Pagina’s die verdwijnen worden niet uit de Solr-index verwijderd. In Nutch 1.6 was er hiervoor een aparte job, voor Nutch 2.x is dit momenteel voorzien in de trunk en zal dit met de nieuwe versie beschikbaar zijn.

Gezien de indexatietijd redelijk beperkt is kan je er ook voor opteren om telkens een nieuwe crawl uit te voeren en de vorige index steeds te wissen.

Conclusie

Met de end-to-end implementatie van deze test is duidelijk dat er heel wat komt kijken bij de implementatie van een zoekoplossing, niet alleen voor de pure installatie/configuratie maar ook voor het iteratieve onderhoud zoals het opsporen/weren van ongewenste URLs.  Het ter beschikking stellen van de nodige Solr functionaliteit (zoals omgaan met meertaligheid, facetten, autocompletion, spellingscontrole, …) neemt ook een heel stuk van de implementatie in beslag. Dan spreken we nog niet over het nut van statistiek achteraf, zodat de zoekmachine meer kan aangepast worden naar de noden van de eindgebruiker. De implementatie van een zoekmachine is in dit aspect geen project maar een continu proces.

Nutch 2.1 is nog wat ruw, vooral op documentatievlak en ontbreekt ook nog een aantal belangrijke features zoals het schoonmaken van de Solr-index bij het verdwijnen van pagina’s. Maar het is alleszins een bruikbaar systeem. De nodige competenties gaan echter verder dan Nutch alleen want als je een NoSQL backend zoals HBase gebruikt heb je daar uiteraard ook kennis van nodig en met Solr heb je enorme mogelijkheden tot je beschikking.

Een gebruiker van een dergelijke zoekmachine kan alleen maar beter worden van een systeem dat alle interne websites ter beschikking stelt. Daar staat natuurlijk tegenover dat dit niet zo evident is om dit op een gebruiksvriendelijke manier aan te brengen. De aangeboden functionaliteit van een crawler is ook beperkt tot de gegevens die beschikbaar zijn in de webpagina. Standaard zal je dus de inhoud van de pagina in de index stoppen met wat metadata (zoals datum, content-type, url). Wil je meer specifieke informatie zoals de auteur van de tekst dan kan je dit niet met de crawler (tenzij je een specifiek veld hebt en de nodige logica om de auteur uit een metadata veld te halen op de pagina). Daarom dat een content management systeem dat zelf zijn inhoud in de zoekmachine stopt meer rijke informatie kan ter beschikking stellen.