Open Source Erfgoed Software: Meresco

In Schudden voor gebruik – Nationale strategie voor landelijke voorzieningen voor digitaal erfgoed (zie Openbare Review Nationale Strategie Digitaal Erfgoed) wordt gezegd:

“Het ICT-maatwerk heeft in de voorbije jaren veel kunnen betekenen voor instellingen en hun klanten, maar leidt nu ook tot beperkingen bij de ontwikkeling van een goed functionerend informatienetwerk. Er moet daarom nu meer aandacht uitgaan naar gestandaardiseerde en toegankelijke basisvoorzieningen, om daar bovenop eenvoudiger en voordeliger maatwerktoepassingen te kunnen maken.

80/20
Ja! In de Erfgoedsector kan 80% van de software gedeeld worden. Je doet zoveel mogelijk samen, zonder dat je wordt beperkt in je vrijheid om je eigen ding te realiseren. 20% maatwerk daar bovenop is het interessante deel waarmee je je onderscheidt en waar besteding van het budget te rechtvaardigen is, omdat het meerwaarde oplevert.

Nu al beschikbaar
Wat dat betreft is er goed nieuws. In de afgelopen jaren heeft Seecr al veel gemeenschappelijke software ontwikkeld voor het publiceren en toegankelijk maken van grote hoeveelheden data. Deze software is:

  • beschikbaar onder Open Source licentie;
  • onder copyright van erfgoedinstellingen;
  • gesmeed tot een geheel van herbruikbare componenten;
  • als source gepubliceerd op GitHub;
  • als binaire packages installeerbaar op Debian of RedHat;
  • bewezen technologie: productierijp en grootschalig inzetbaar.

Bewezen technologie
Vandaag de dag draaien grote landelijke netwerken op deze software. In het domein van onderwijs, erfgoed, openbare en wetenschappelijke bibliotheken. Deze bevatten zeer veel gecombineerde data en hebben dagelijks een groot publiek van institutionele gebruikers en eindgebruikers.

bron Elsbeth Kwantbron: Elsbeth Kwant
In bovenstaande afbeelding van Elsbeth Kwant geeft de oranje kleur in stam en wortels aan waar deze software aanwezig is. Deze data wordt al dagelijks gebruikt en onder elkaar uitgewisseld.

Verbetering componenten
Herbruikbare componenten bedenk je niet, die groeien. Ze ontstaan als gevolg van hergebruik: de eerste maakt iets, de volgende past het aan en bij de derde kun je gaan spreken van een herbruikbaar component. Als dat enkele jaren doorgaat, ontstaat er een enorme hoeveelheid aan meer generieke en steeds betere componenten. Dit is precies wat met deze software de afgelopen jaren is gebeurd en wat dagelijks plaatsvindt.

Copyright en licenties
Een open source licentie is mooi, maar daarmee heb je nog geen controle over wat er met die software gebeurt, want die ligt bij de copyright eigenaar. Het copyright van deze software ligt bij grote spelers uit de erfgoed sector waaronder Stichting Beeld en Geluid, de Koninklijke Bibliotheek, de Koninklijke Nederlandse Academie van Wetenschappen (KNAW) en Stichting Kennisnet.

Publicatie en packaging
De publicatie en packaging is de afgelopen jaren om niet gedaan door Seecr. De binaire packages kunnen in enkele minuten geïnstalleerd worden. In een handomdraai heb je dan een eigen netwerk waar je een eigen toepassing op kunt bouwen zonder je zorgen te hoeven maken over de gemeenschappelijke delen. Een goed voorbeeld hiervan is Narcis die door DANS wordt onderhouden.

Heeft deze software al een naam? Ja! In 2007 hebben wij met vier partijen die hiermee begonnen zijn de naam Meresco bedacht. Onder die naam is het sindsdien gepubliceerd en onderhouden tot op de dag van vandaag: zie github.com/seecr?query=meresco

Wat is er met deze software allemaal mogelijk? In een volgende blog zal ik hier dieper op in gaan.

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.

WaaS 2.0 aansluiting op NBC+

Stichting Bibliotheek berichtte recent dat in de komende maanden de landelijke diensten volledig worden geïntegreerd in WaaS 2.0. Het gaat hierbij onder andere om de content en functionaliteiten op www.bibliotheek.nl: de pagina’s over e-books, jeugd, literatuur en WelkBoek. Ook wordt landelijk zoeken op basis van de NBC+ opgeleverd.

Hiermee wordt de door Seecr ontwikkelde zoekmachine de motor achter deze functies.

Voordelen aansluiting NBC+
De aansluiting van WaaS 2.0 op het Zoekplatform biedt tal van nieuwe mogelijkheden en functies. Naast bronnen zoals kranten, e-books en de consumentengids, worden ook alle lokale bronnen van bibliotheken opgenomen in het landelijk Zoekplatform en zullen er in de toekomst nog meer volgen, zoals bijvoorbeeld de Digitale Collectie.

Tegelijk komen ook centrale functies voor iedereen beschikbaar. Wat lokaal vaak niet mogelijk is, kan centraal wel worden geregeld. Denk bijvoorbeeld aan deduplicatie en het uniformeren van metadata. Het mooie is dat het dan over al deze bronnen heen gebeurt in plaats van binnen één collectie.

Uniformeren van auteurs
Een voorbeeld van een nieuwe functie is het uniformeren van auteurs en onderwerpen. Verschillende bronnen hebben vaak een eigen manier om te refereren aan auteurs. Op basis van de verzamelde gegevens, gaan wij de identifiers over dezelfde auteurs op elkaar afbeelden. We werken hierbij onder meer met Wikipedia, GTAA, NTA en Viaf. Al deze data is/wordt als Linked Open Data gepubliceerd.

Een analoog verhaal geldt voor onderwerpen of trefwoorden. Iedereen heeft zo zijn eigen classificatiesysteem, vaak meerdere binnen dezelfde collectie. Het verzamelen van de gegevens en het bij elkaar zoeken van de overeenkomsten is in volle gang. De planning is om in 2015 grote stappen te kunnen zetten.

Vooruitblik
Wij zijn enthousiast over de aansluiting van WaaS 2.0 op het NBC+. Een goed startpunt van een mooie doorontwikkeling van het Zoekplatform die het voor elke bibliotheek mogelijk maakt om het hele Nederlandse Erfgoed te relateren aan haar eigen collectie.

Meten is weten

Hoe snel is het systeem? Hoeveel bezoekers kunnen tegelijkertijd het systeem benaderen? Bij nieuwe systemen, maar ook bij systemen waar we veel veranderingen in aan hebben gebracht, voeren we een performance test uit. Een test om vast te stellen wat het prestatieniveau van het systeem is. En om inzicht te krijgen in het verschil tussen de actuele en vereiste responsetijden.

Verschillende manieren van testen
Het aantal queries per seconde en de responsetijd van de query zijn de belangrijkste gegevens voor ons. Om hiervan een realistisch beeld te krijgen, testen we dit bij een gemiddelde belasting, een piekbelasting en een overbelasting van het systeem. Hoeveel kan het systeem daadwerkelijk aan?

Een test doen we op de tiende seconde nauwkeurig. Hiervoor hebben wij een eigen programma ontwikkeld, zodat we er 100% zeker van zijn dat we betrouwbare resultaten kunnen presenteren.

Vertekend beeld
Een veel gemaakte fout is de performance test thuis uitvoeren of vanaf een plek met een snelle internetverbinding. Die test geeft vaak een vertekend beeld. Daarom testen wij altijd via onze server, om zo een netwerkverbinding uit te sluiten. Voor één van onze klanten bijvoorbeeld staat het systeem in Engeland. Zou je dit via een internetverbinding testen, dan kan het verlies  wel tot 300 ms per query zijn.

Gebruikerservaring
Een applicatie of website staat of valt met een goede performance. De grote datastromen, waar we vaak mee te maken hebben voor onze opdrachtgevers, mogen geen reden zijn voor een te traag systeem. Vaak voelen we wel aan of een systeem nog optimaal werkt. Maar voor de echte cijfers is het van belang om regelmatig een performance test uit te voeren. Wil je tevreden gebruikers, dan is het van belang dat de performance van het desbetreffende systeem optimaal is.