Zoekindex Lucene verder geoptimaliseerd

Meresco, onze library van search en retrieval software, gebruikt Lucene voor de zoekindex. Lucene is ontwikkeld in Java; onze code is geschreven in Python. Python biedt verschillende mogelijkheden om deze Java code te gebruiken. De open source Software Foundation Apache biedt de mogelijkheid de Java code beschikbaar te maken binnen Python. Dit kan met PyLucene (http://lucene.apache.org/pylucene/).

Opvallend

Tot voor kort maakte we alleen maar gebruik van PyLucene om onze indexen aan te spreken. Op onze software draait continu een monitoring systeem, dat ons inzicht geeft in performance. We merkten steeds vaker dat er geheugen ‘kwijt’ was. Een ander opvallend fenomeen was dat het nodig werd de indexen eens in de zoveel tijd te herstarten, omdat deze anders ‘Out of memory’ gingen. Duidelijk: er was iets aan de hand, en we doken erin. Ondanks veel memory profiling en het bekijken van heap-dumps, die laten zien waaruit het gebruikte geheugen was opgebouwd, kwamen we niet tot een bevredigende conclusie waarom de garbage collector zijn werkt niet goed deed. Java objecten, waarvan wij zagen dat die wel konden worden opgeruimd, werden níet opgeruimd.

Zagen wij iets over het hoofd? Hadden we echt een geheugenlek? Of had de garbage collector te veel te doen om dit binnen de gewenste tijden op te kunnen ruimen?

Aankijken

Ondertussen bleven onze indexen groeien, alsook het aantal queries aan de indexen. Tot we uiteindelijk voor sommige indexen meerdere keren per dag een ‘out of memory error’-melding kregen. Om wat ruimte te scheppen, zetten we het automatisch bijwerken van de indexen daarom uit, en voerden we die handmatig uit op rustige momenten van de dag. Dit gaf voorlopig ruimte, maar dat is geen duurzame oplossing. Tijd voor actie dus.

Actie

Wij hebben een tijdje gebruik gemaakt van het open source enterprise search platform Solr, dat in Java is geschreven. Solr maakt gebruik van de zoekindex-functionaliteit van Lucene, en biedt een http-service aan om queries te stellen. Wat zou er gebeuren als wij ook deze strategie zouden volgen? We zouden Lucene in Java gaan draaien, de ‘native’ taal. Het combineren van garbage in Python en Java komt dan niet meer voor en lost eventuele problemen die we daarmee hebben op. We waren ook heel benieuwd wat er met de performance zou gebeuren.

We schreven onze eigen code om naar Java, bovenop Lucene, en plaatsten er een http-service voor. Na een aantal dagen Java code schrijven, met in het achterhoofd dat het ons zowiezo zou helpen bij het vinden van een oplossing, lukte het ons om weer een werkende versie te krijgen.

Performance testen

De code installeerden we op een acceptatie server met veel data. De eerste testresultaten waren erg bemoedigend. Ze gaven aan dat de indexen zelfs meer dan dubbel zo snel waren geworden. Dat was een beter resultaat dan we verwacht hadden. Maar de grote vraag: is ons geheugenprobleem opgelost, was nog niet beantwoord. We lieten daarom een duurtest los op de oplossing. We bestookten het systeem urenlang met een continue load, waarvan we wisten dat het oude systeem daar al snel onder zou bezwijken. En jawel: er kwamen geen geheugenproblemen meer voor.

Gemiddelde responstijden voor en na release op 16 december

Gemiddelde responstijden voor en na release (op 16 december 2015)

In de roos

Het leek er sterk op dat we ons probleem opgelost hadden. Ons vermoeden dat het in puur Java beter zou moeten gaan, klopte. Als klap op de vuurpijl kregen we er ook nog een enorme performance verbetering bij.

Uiteindelijk hebben we deze aanpak een tijdje laten meedraaien op de acceptatie-omgeving om er zeker van te zijn dat de werking probleemloos was. Intussen is het alweer een tijdje gereleased naar een productie omgeving, waar het nu vlekkeloos draait.

 

Meer erfgoed objecten verrijkt met juiste geografische aanduidingen

De afgelopen maanden hebben verbeteringen in de ErfGeo API en de ErfGeo Verrijkingenservice bij de Digitale Collectie (ontwikkeld door Seecr), ervoor gezorgd dat veel meer erfgoed objecten nu kunnen worden verrijkt met de juiste geografische concepten en coördinaten.

Om deze vooruitgang aan te tonen, zijn steekproeven genomen en beoordeeld. Daaruit blijkt dat ongeveer de helft van de records locatieinformatie bevat. Voor die records met locatieinformatie werd in 67% van de gevallen een match gevonden met de ErfGeo API. Op dit moment levert dat nog in in 4.5% van de gevallen een verkeerde match op.

Relevante aanpassingen die bijdragen aan het verschil t.o.v. de vorige keer:

  1. Aan de graph van https://api.histograph.io zijn Nederlandstalige landnamen toegevoegd en Nederlandstalige namen van grote steden in het buitenland.
  1. Vanuit de Digitale Collectie ErfGeo Enrichment service wordt nu exact gezocht op https://api.histograph.io in plaats van ‘fuzzy’.
  1. De term ‘Nederland’ wordt niet meer als zoekvraag gesteld: te vaak leverde dit het plaatsje Nederland in Overijssel. Bovendien voegt het nauwelijks iets toe (of zou het zelfs misleidend zijn) om de geo-coördinaten van het land Nederland bij het record op te nemen (in elk geval in de context waarmee we nu werken).
  1. Records die al geo-coördinaten bevatten, worden niet geprobeerd verder te verrijken.

Intussen blijven we zoeken naar manieren om het aantal verkeerde matches nog verder naar beneden te krijgen. Een voorbeeld van locatieaanduidingen die nog niet goed matchen zijn namen van rivieren en meren, zoals “Oosterschelde”, “Grevelingen”, etc., omdat de HistoGraph wel de straatnamen kent die daarmee overeenkomen, maar nog niet de wateren met die naam.

 

Van full naar para, of: parkeerlogica en ICT

We reizen vaker af naar onze klanten, dan andersom. En omdat we één parkeerplaats hebben voor bezoekers, delen we die plek soepel met de medehuurder van ons pand. Analoog aan die logica gingen we over van KVM, oftewel full-virtualisatie, naar para-virtualisatie met LXC, wat staat voor Linux Containers. Daarmee kunnen we verschillende Virtual Machines een kernel laten delen, en geheugenruimte beschikbaar stellen zonder vooraf een reservering te maken. Zodoende leggen we onszelf geen beperkingen op. Lekker light-weight nu we in tien minuten een Virtuele Machine erbij kunnen maken, snel kunnen omswitchen als er een update moet plaatsvinden, nieuwe releases willen doen, een demo maken, of meerdere versies tegelijk installeren. Bijkomend voordeel: hardware wordt efficiënter ingezet, en het bespaart energie, dus het milieu.

NWO-strategie en Seecr

Vandaag wordt de meerjarenstrategie tot 2018 van het NWO aangeboden aan staatssecretaris Sander Dekker.  Ik kreeg een uitnodiging om dit bij te wonen, vanmiddag in het Gemeentemuseum Den Haag.

Wetenschap en het MKB

De afgelopen jaren heb ik verschillende interessante mensen ontmoet bij het NWO. Mensen die op een hele positieve manier op waren naar de koppeling tussen wetenschap en bedrijfsleven.  Het idee dat toepassing van wetenschap vooral door bedrijven plaats vindt, ligt hier aan ten grondslag.

Deelname van Seecr

Ook was er een prettige voorkeur voor het MKB.  Als klein bedrijf is Seecr daar natuurlijk heel blij mee.  We hebben veel geleerd en gedaan in het NWO Catchplus programma. Dit heeft onder andere geleid tot een hele mooie standaard: http://www.openannotation.org.  Deze passen wij nu toe in de nieuwste aggregators van de Digitale Collectie.

In 2013 hebben we meegedaan aan een onderzoeksweek met “ICT with Industry“.  Samen met topwetenschappers hebben we ons een week gelang gebogen over een door Seecr ingebrachte casus. Dit was buitengewoon inspirerend!  Dank ook special voor Rosemarie van der Veen-Oei voor haar enthousiaste koppelen!

Perspectief

In 2014 kreeg ik het verzoek van het STW om als commissielid programmavoorstellen te beoordelen in de Perspectiefronde 2013/2014 High Tech Systemen en Materialen.  Zo kreeg ik een goed beeld van hoe zo’n proces gaat en op welke manier NWO en STW hun strategie uitvoeren. De drive om gemeenschapsgeld op zo concreet mogelijke manier te laten bijdragen aan diezelfde gemeenschap, is mooi om te zien!

Vandaar dat ik heel benieuwd ben naar vanmiddag, en de komende drie jaar.

Autocomplete met Solr (Dutch)

Autocomplete is een functie die al langere tijd beschikbaar is in de systemen die met Meresco gebouwd worden, maar bij Seecr en haar opdrachtgever Kennisnet bestond de behoefte aan een duidelijk overzicht van de verschillende methodes voor een autocomplete functie.

Meresco levert die functies via Solr. Hieronder analyseren we vier methodes van autocomplete die door Solr 4.0 worden aangeboden op basis van de volgende criteria.

De methode:

  1. geeft aanvulling op velden met één waarde (bijvoorbeeld: datum=01052013) of met meerdere waarden (bijvoorbeeld: tags=leuk, spannend).
  2. kan achteraan , maar ook vooraan of middenin aanvullen: “auto”, “mobiel” en “autobiel” leveren “automobiel” op.
  3. geeft aanvullingen binnen een zoekresultaat (bijvoorbeeld: aanvulling binnen het resultaat van de vorige zoekvraag) of op de gehele index.
  4. geeft (exacte) aantallen voor de te verwachten resultaten.
  5. kan snel aanvullen uit een lijst met zeer veel verschillende waarden (>100.000).
  6. werkt op een standaard index, of op een apart te bouwen index.

De vier methodes voor autocomplete in Solr (en Meresco) werken op basis van:

  1. De Facet-functie
  2. Alle Termen in de Index
  3. De Suggester Component
  4. Een N-Grammen Index

De Facet-functie
Met behulp van de standaard facet-functie kunnen alleen achteraan aanvullingen gegenereerd worden. Dit werkt erg efficiënt, ook binnen zoekresultaten. Het mooie er van is dat bij elke term het te verwachten aantal resultaten getoond kan worden. Met erg veel termen wordt het echter wel trager.

Voordelen:
–       Geeft aanvullingen in velden met meerdere waarden.
–       Geeft aanvullingen binnen een zoekresultaat.
–       Geeft exacte aantallen voor de te verwachten resultaten.
–       Te gebruiken met een standaard index.

Nadelen:
–       Kan alleen achteraan aanvullen.
–       Wordt minder snel bij zeer veel verschillende waarden.

Alle Termen in de Index
Deze methode geeft aanvullingen op basis van alle geïndexeerde waarden in een index. Het ondersteunt aanvullen achteraan, vooraan en middenin. Maar alleen achteraan werkt snel, ook bij zeer veel waarden in de index.

Voordelen:
–       Geeft aanvullingen in velden met meerdere waarden.
–       Kan achteraan, vooraan en middenin aanvullen.
–       Te gebruiken met een standaard index.
–       Werkt efficiënt met zeer veel verschillende waarden.

Nadelen:
–       Vooraan en middenin aanvullen werkt niet efficiënt.
–       Alleen een benadering van het aantal te verwachten resultaten.
–       Kan geen aanvullingen geven binnen een zoekresultaat.

De Suggester Component
Via de Suggester component kan een aanvulling gedaan worden door het aan te vullen woord te zien als woord waarvoor spellingscontrole gedaan moet worden. Dit werkt efficiënt voor aanvulling achteraan, vooraan en middenin door middel van een speciale index. Het mooie van deze oplossing is dat er verschillende algoritmen kunnen worden gekozen om de aanvulling te produceren.

Voordelen:
–       Geeft aanvullingen in velden met meerdere waarden.
–       Kan achteraan, vooraan en middenin aanvullen.
–       Werkt efficiënt met zeer veel verschillende waarden.

Nadelen:
–       Kan geen aanvullingen geven binnen een zoekresultaat.
–       Geen informatie over het aantal te verwachten resultaten.
–       Er moet een speciale index (tree) voor onderhouden worden.

Een N-Grammen Index
Deze oplossing wijkt sterk af van de andere. De aanvullingen gaan op basis van een query op een speciale index van delen van woorden. Het woord “snel” wordt hierin geïndexeerd als “sn”, “ne” en “el”. Omdat dit een normale zoekopdracht is, geeft dit geen aanvullingen terug, maar moet dit gecombineerd worden met de facet-functie of het ophalen van opgeslagen waarden. Het mooie aan deze oplossing is dat het gemakkelijk uitgebreid kan worden met speciale spellingcheckers of fonetische suggesties.

Voordelen:
– Kan achteraan, vooraan en middenin aanvullen.
– Geeft exacte aantallen voor de te verwachten resultaten in combinatie met de facet-functie.
– Werkt binnen een zoekresultaat.
– Werkt efficiënt met zeer veel verschillende termen.

Nadelen:
– Niet geschikt voor velden met meerdere waarden.
– Er moet een speciale n-gram index voor worden opgebouwd.

Samenvatting
In onderstaande tabel worden de voor en nadelen naast elkaar gezet. Daaruit is duidelijk op te maken dat de verschillende methodes heel verschillend scoren op onze criteria.

  Facet-functie Termen Suggester N-Grammen
Meerdere waarden per veld

+

+

+

Achteraan

Vooraan

Middenin

+

+

+/-

+/-

+

+

+

+

+

+

Binnen een zoekresultaat

+

+

Exacte aantallen

+

+

Veel verschillende waarden

+

+

+

Index

standaard

standaard

tree

n-gram

Conclusie
Uit de resultaten komt naar voren dat voor een bepaalde toepassing een specifieke methode beter werkt dan andere. In twee gevallen is er ook een speciale index nodig om het goed, en efficiënt, te laten werken. Het kiezen van de juiste autocomplete methode is daarom dus een zaak van grondige analyse van de wensen.