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.

 

Kunstkenner Arthur Brand: ‘De beste uitvinding van de mensheid is de zoekfunctie’

Afgelopen woensdag mochten we Arthur Brand beluisteren op TedxEde. Arthur is de man die onder andere verloren gewaande paardenbeelden van Hitler terugvond, en joodse roofkunst in de collectie van de Koninklijke Familie. Op het congres vroeg hij het publiek: ‘Hoe is het mogelijk dat simpele mensen als ik, dit soort dingen op het spoor kunnen komen?’ Samengevat: door de zoekfunctie!
 

Speurtocht door archieven

Op het goed bezochte event maakte hij ons deelgenoot hoe zijn speurtocht tot succes leidde. De paarden zouden naar verluid zijn vernietigd tijdens het beleg van Berlijn. Door onderzoek in archiefmateriaal kwam hij op het spoor van een filmfragment, dat net voor die slag was gemaakt. Ze bleken niet meer op hun plaats te staan… want al door Hitler afgevoerd naar veiliger oorden. Latere foto’s uit archieven van Russen, pronkend met de paarden, bevestigde dat ze nog heel waren.
We vroegen hem na afloop, hoe belangrijk digitale archieven zijn voor de kunstwereld.

Geen wereld zonder databases

‘Ik kan je tientallen voorbeelden geven waaruit blijkt dat voor ons digitale archieven cruciaal zijn voor het oplossen van vervalsingen en kunstroof.

Arthur Brand, kunstkenner en speurder

Ik kan me geen wereld voorstellen zonder die databases. Iemand heeft eens gezegd: ‘De beste uitvinding van de mensheid is de zoekfunctie op je computer.’ Daar ben ik het helemaal mee eens.  Zouden die er niet zijn, dan is de kunst drijfzand. Dertig procent van de kunstmarkt bestaat al uit vervalsingen. De illegale kunstmarkt vormt na drugs en wapens, de derde grootste illegale geldstroom ter wereld. Er gaat zes miljard euro in om, per jaar. Als we niet meer kunnen teruggrijpen op waar het stuk is geweest, door wie het is verkocht, en hoe vaak, dan stort de kunstmarkt in.’

Vervalste namen

Arthur illustreert een veel voorkomende manier van vervalsen: de naam van de schilder veranderen. ‘Voor de Tweede Wereldoorlog knoeide iedereen maar aan met toeschrijvingen. Mensen hadden bij gebrek aan databases, nauwelijks vergelijkingsmateriaal. Niemand kon het controleren of een werk van de school van Rembrandt werd geüpgrade als een werk van Rembrandt zelf na zoveel jaar, door de vervalsing van de naam. Nu kunnen we foto’s naast elkaar zetten.’

Kunstroof

In de periode 1933 – 1945 vond de grootste kunstroof uit de Europese geschiedenis plaats door de Duitse agressor. Nog steeds zijn veel kunstobjecten in het bezit van mensen die daardoor vuile handen hebben gemaakt. Arthur Brand spoort ze op.  ‘Zo waren we op zoek naar een gestolen schilderij van een joodse familie. We hadden echter alleen een hele slechte foto. In een Duits archief vonden we een film, waarop hetzelfde schilderij stond. Toen hadden we beter zicht op hoe het eruit zag. En konden we het vinden. Zo wordt een database opeens een sleutel voor doorslaggevend bewijs. Negentig procent van ons werk bestaat uit het doorzoeken van databases. Zonder kunnen we ons werk niet doen.’

Even de koppen bij elkaar

collage_agile_openOp een Open Space Conferentie – die geen vooraf bepaalde invulling kent – mogen deelnemers werken aan wat aan de oppervlakte komt. Dit wordt aangedragen op post-it’s en op de muur geplakt, in tijdsloten. Of de behoeften al dan niet gedeeld zijn, blijkt vanzelf. Lijkt het aanbod elders toch relevanter, leuker of spannender? Dan vlinder je verder naar een ander groepje. Hier geldt immers ‘the Law of Two Feet’.

Op de Agile Open Space Conferentie in Lunteren hebben we een groepje deelnemers meegenomen op een queeste naar het Nederlandstalige equivalent van exotische vaktermen. Niet zozeer uit taalpurisme, maar vanwege de relatie tussen taal en persoonlijke ontwikkeling. We besloten in een tijdslot met een groepje ons boerenverstand los te laten op Agile, Kanban, XP en Scrum. Deze stoere, en voor buitenstaanders tevens nietszeggende termen, schuren aan bekendere begrippen uit de industrie: ‘produce to order’, ‘stock to order’ en ‘just-in-time management’. Wat ook weer ronkend Engels is. Het zoeken naar Nederlandstalige equivalenten leverde gedeelde momenten van verbazing en verwondering op. U kunt ze hier in een simpel overzichtje bekijken. Graag zouden we op het spoor komen van bijpassende oude spreekwoorden bij de materie. Waarom? Omdat die zoektocht helpt om de echte waarden en normen te vinden, die onder dit verbale laagje zitten. We dragen graag bij aan een gezonde en voor iedereen begrijpelijke samenwerkings-ecologie.

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.

Samenwerkingsverband Kenniscentrum Oorlogsbronnen

In het NIOD Instituut voor Oorlogs-, Holocaust- en Genocidestudies is donderdag 15 januari jl. het Kenniscentrum Oorlogsbronnen gelanceerd. Dit samenwerkingsverband van verschillende erfgoedorganisaties, archieven en ontwikkelaars gaat werken aan de bundeling van activiteiten, (digitale) producten en diensten rondom de Tweede Wereldoorlog en de Holocaust. Het NIOD is coördinator van dit programma en wordt bijgestaan door Digitaal Erfgoed Nederland (DEN). Hieronder volgt een interview met Erik die namens Seecr deelneemt in dit project.

Hoe was de lancering van dit samenwerkingsverband?
Er was veel energie en enthousiasme bij de mensen. Vooral de speech van Puck Huitsing was hartverwarmend: over instellingsgrenzen en collectiegrenzen heen kijkend naar hoe je samen al je data en diensten kunt aanbieden aan gebruikers die geen boodschap hebben aan die grenzen maar iets willen weten over de oorlog. Er heerste een sfeer van dat die samenwerking nu eindelijk gaat lukken. Ook waren er mensen van DEN en de link naar “Schudden voor gebruik” was heel sterk aanwezig. Dit is de manier waarop we met erfgoed om moeten gaan in Nederland.”

Jouw rol in het geheel zal zijn: deelnemer/adviseur over het
werkpakket zoeken en vinden. Kun je een omschrijving geven wat
de werkzaamheden inhouden?
Er waren bij de werkgroep zoeken, vinden en verrijken zeer diverse mensen met veel kennis en ervaring op de terrein en het gesprek o.l.v. Ivo Zandhuis was al snel op hoog niveau. Mijn bijdrage zal er vooral uit bestaan om kennis en ervaringen te delen die we hebben opgedaan met de netwerken voor onderwijs (Edurep/ECK), bibliotheken (NBC+), Europeana (Beeld en Geluid/nationale aggregator). Verder zal ik ook mijn visie hierover onder de aandacht brengen en proberen uit te leggen wat “Schudden voor gebruik” nu in de praktijk betekent. Ik zal hierin vooral Ivo ondersteunen met raad en daad.”

De eerste stap in 2015 is dat in verschillende werkgroepen verkenningen worden uitgevoerd naar gedeelde beleidsspeerpunten, al voor handen zijnde diensten en producten en strategieën om collecties beter vindbaar te maken voor de gebruiker. Ben jij bij deze stap al actief betrokken? En zo ja, waar ga jij je mee bezighouden?
Mijn werkgroep zoeken, vinden en verrijken heeft in de eerste sessie al bedacht dat het “drielagenmodel” uit “Schudden voor gebruik” erg uitgeversgeorienteerd is, ofwel aanbodgericht: er is één stroom van data-eigenaar naar publiek. Maar we willen het publiek engageren en daarom hebben we in de eerste bijeenkomst al een ronde pijl door het drielagenmodel getekend. Dit heeft Ivo gepresenteerd in het plenaire overleg en het bleek heel goed geschoten. Alle andere werkgroepen hadden vergelijkbare ideeën over het feit dat er ook data van gebruikers terug gaat richting de instellingen. Ik zal denk ik vooral goed letten op de uitwerking hiervan.”

Wat zijn jouw verwachtingen ten aanzien van dit project?
Ik hoop dat er een korte bondige visie komt te liggen waarmee in 2016 direct, in kleine projecten, aan de slag gegaan kan worden. Ook hoop ik dat men ziet wat er allemaal al is en op welke manier dat praktisch hergebruikt kan worden. Zo gaat het budget naar nieuwe mooie dingen en niet naar nog weer eens ontwikkeling van nieuwe tools.”

Heeft Seecr een eigen rol of is er veel samenwerking met andere partijen?
Hopelijk dat we kunnen laten zien dat we met de software die er al is aan de back-office kant snel een netwerk neergezet kan worden. Ik kijk uit naar samenwerking met creatieve partijen die er mooie eind-gebruikerstoepassingen op kunnen maken.

Verwacht je nog interessante technische uitdagingen in het project?
Ik zie er op dit moment niet één die al niet eerder opgelost is. Maar tegelijk twijfel ik er niet aan dat ze er zullen komen want als het ambitieniveau van dit project gehaald wordt, gaanwe grenzen opzoeken en dingen anders doen. Het zou gek zijn als daar geen technische uitdagingen bij aan het licht zouden komen.”

Ben je enthousiast over dit initiatief?
“Al
10 jaar hoop ik op dit soort thematische netwerken, want het kan al lang. Dat het nu ook daadwerkelijk lijkt te gebeuren op een terrein wat zo versnipperd en tegelijk zo interessant en relevant is als de oorlogsbronnen lijkt een kantelpunt te zijn; er is iets in beweging gezet.

De wil en energie is er. Ik hoop dat we dat kunnen mobiliseren en kunnen vasthouden. Ik hoop ook dat er minder concurrentie tussen instellingen en bedrijven komt want er is genoeg te doen voor iedereen. Hoe meer we samenwerken hoe minder dubbel gedaan wordt en hoe meer leuke, nieuwe ontwikkelingen opgepakt kunnen worden. Ik ben enthousiast en kijk uit naar een waardevolle samenwerking!”

Meer weten? Klik hier voor meer informatie.

Performance index Lucene

Al lange tijd is de performance van onze index (Lucene) een hot item bij Seecr. De standaard performance van Lucene voor normale query’s en drilldown is prima. Maar over de performance van de join-functionaliteit zijn wij niet tevreden. Daarom zijn we al over gestapt op onze eigen manier van joinen, om de snelheid te kunnen garanderen. (Lees meer hierover in ons eerder verschenen artikel)

Het resultaat van onze eigen code werd vanaf het begin al gecached om het snel en acceptabel te maken. Zodra een gebruiker dezelfde zoekvraag opnieuw stelde stond het resultaat meteen klaar in de cache.

Naarmate we steeds meer records en gebruikers kregen, begonnen er wat problemen te ontstaan. De servers gebruikten meer geheugen en de query’s werden trager.  Een automatische refresh van al onze records instellen, zodat er elke vijf minuten nieuwe records geïndexeerd worden, zou het systeem nog trager maken. Dat kunnen we ons niet permitteren. Ik ben in de code gedoken om te achterhalen waarom het systeem op deze manier reageerde.

Compacter opslaan
Al snel ontdekte ik dat de caches die gemaakt worden voor onze eigen join-code veel geheugen gebruiken. Een goede oplossing hiervoor dacht ik te hebben gevonden in de vorm van compacter opslaan. Het gebruik ging voor één query van 300Mb naar 2Mb; een enorme verbetering. Maar helaas was de oplossing niet zo simpel. Sterker nog, de query’s leken hierdoor om de zoveel tijd nog trager dan dat ze al waren.

Wat bleek nu, het maken van de cache was erg veel duurder geworden. Vandaar dus dat de query’s soms nog trager waren. Tijdens een brainstorm met mijn collega’s werd het idee geopperd om het eens te testen zonder enige vorm van caching. Misschien was het verzamelen van alle gegevens wel zo snel dat het maken van een cache niet opweegt tegen die snelheid.

Dat vond ik het proberen waard. De code heb ik opnieuw geschreven en inderdaad, het verzamelen van alle gegevens was ook erg snel zonder caching. Toch was het niet voldoende om volledig zonder te kunnen.

Minder committen
Tot dit moment werd Lucene eens in de 1000 records of om de 10 seconden gecommit. Binnen maximaal zoveel seconden waren wijzigingen daardoor zichtbaar. Was dit misschien iets te veel van het goede? Zo belangrijk was het niet dat wijzigingen zichtbaar moesten worden. Records worden zelfs maar een paar keer in de zoveel tijd toegevoegd en zeker niet elke 10 seconden.

Daarom hebben we hier verandering in gebracht. We committen nog maar elke 5 minuten of elke 100.000 records. Dit had een positief resultaat; de query’s waren nog maar maximaal eens in de 5 minuten trager. De gebruiker merkte hier dus behoorlijk minder van.

Maar na een tijdje kwamen er klachten dat het systeem vaak traag reageerde. Eens in de 5 minuten committen is toch niet voldoende. Hier moest toch een goede oplossing voor zijn te vinden. Ik heb besloten om over te gaan om een andere vorm van caching. Eén waarin we simpelweg het eindresultaat van de join-query wordt bewaard. Deze vorm gebruikte weinig geheugen, maar moest wel elke keer alles opnieuw berekenen; dit tegenover de oude vorm die alleen het gewijzigde deel opnieuw berekende. Deze nieuwe caches konden dan ook na elke commit opnieuw gemaakt worden.

Nog steeds waren wie hiermee niet waar we wilden zijn. Doordat we zo weinig committen werden de commits uiteraard wat duurder. Tot onze verbazing gebeurde het dat dit tot wel 8 seconden kon duren. Veel te lang als de query daarop moet wachten. En als we onze automatische refresh aanzetten werden er elke vijf minuten records toegevoegd en bereikten we hier dus helemaal niets mee. Nog steeds was het om de 5 minuten veel te traag, ondanks dat we al zoveel geoptimaliseerd hadden. Een behoorlijke tegenvaller.

Multi threading
Het was lastig om ook dit nog op te lossen. We konden geen goede optimalisaties voor Lucene bedenken. Totdat ik ineens bedacht dat Lucene multi-threaded is. Dat ik daar niet eerder aan heb gedacht. Want zolang een record geïndexeerd wordt, kan er niet gezocht worden. Dit merk je uiteraard meteen als een commit 8 seconden duurt. Als ik dat nou eens kon veranderen.

Ons indexeer- en zoekproces heb ik gesplitst naar twee verschillende threads. Eén thread om te indexeren en de andere om te zoeken. Tijdens het indexeren is het nu ook mogelijk om te kunnen zoeken. Ook als de writer-thread 8 seconden staat te committen. Eindelijk leek het erop dat we weer een goede performance hebben behaald.

Dé oplossing
De processen gebruiken weer een normale hoeveelheid geheugen en door middel van ons monitoringsysteem kunnen we zien dat de responsetijden weer acceptabel zijn. In onderstaande grafiek is te zien wat het effect van de laatste verbetering was op onze productieomgeving. Deze grafiek toont de gemiddelde responsetijd. Duidelijk is te zien dat we 22 januari gereleased hebben. Alle hogere pieken, die veroorzaakt werden door die 8 seconden commit tijd, zijn verdwenen. Grafiek

Voor nu ben ik heel tevreden met deze oplossing. Al ben ik wel met een nieuw experiment gestart om te kijken of we hier nog meer uit kunnen halen dan nu al mogelijk is. Je kunt maar beter goed voorbereid zijn op eventuele veranderingen in gebruik.