Voor de opslag van grote hoeveelheden sociale media data is het belangrijk om een goede opslag strategie te hebben. Hierbij moeten een aantal keuzes gemaakt worden. Dit hoofdstuk behandelt deze keuzes en een aantal technieken die van belang zijn bij de opslag van de data en geeft daarmee antwoord op deelvraag vier.
6.1. Keuze van database
Voor de te ontwikkelen applicatie is een database nodig waarin gemakkelijk enkele miljoenen tweets per dag opgeslagen kunnen worden. Dit is onder andere gebaseerd op de limieten van de Twitter API. Twee tot drie miljoen tweets per dag komt neer op ongeveer 16Gb aan data als wordt uitgegaan van ongeveer 8Kb per tweet1. Verder is het belangrijk dat de database ook bij een plotselinge explosieve toename van het aantal schrijfquery’s stabiel blijft werken.
Er is gekozen om te onderzoeken wat de mogelijkheden hierin zijn van de relatief nieuwe NoSQL-databases. Hoewel het ook mogelijk is om het opslag probleem op te lossen met een traditionele relationele database, bieden NoSQL-databases vaak goedkopere oplossingen voor het werken met grote hoeveelheden data. NoSQL-1 Dit is gebaseerd op de document grootte van
tekstbestanden met tweets in Windows 7.
databases zijn meestal opensource (en dus gratis) en zijn niet afhankelijk van dure infrastructuur om hoge prestaties te behalen. Dit komt omdat veel NoSQL-databases “horizontaly scalable”
zijn. Dit wil zeggen dat, om de prestaties van de database te verhogen, gemakkelijk nieuwe (goedkope) servers geplaatst kunnen worden.
NoSQL-databases worden onder andere gebruikt door Google en Facebook voor de opslag van grote hoeveelheden data (Perdue 2012)
Onder NoSQL-databases zijn verschillende categorieën2. Twitter gebruikt de NoSQL-database “Cassandra” (King 2010), dit is een zogenaamde “column-store”. In een wide-column-store bestaat elke record uit een rij die verwijst naar een soort boomstructuur.
Een andere categorie NoSQL-databases zijn de zogenaamde “stores”. In document-stores bestaat iedere record uit een sleutel die verwijst naar een document. Figuur 6.3 laat een voorbeeld zien van een record in een document-store en in een wide-column-document-store. Document-stores zijn ideaal voor het opslaan van data uit verschillende bronnen waarbij documenten vaak sterk van elkaar verschillen (een tweet is niet hetzelfde als een Facebook update).
2 Een overzicht kan gevonden worden op http://
nosql-database.org/
Figuur 6.3. voorbeeld record in document-store en wide-column-store Er zijn verschillende document-stores
beschikbaar, waaronder CouchDB en MongoDB.
Het verschil in deze databases wordt duidelijk aan de hand van de zogenaamde CAP theorie (Gilbert, Lynch 2002). CAP staat voor Consistency, Availability en Partition-tolerance.
Volgens de theorie moet een database (of ander software pakket) altijd kiezen voor twee van
deze drie begrippen. De focus van CouchDB ligt op Availability en Partition-tolerance. MongoDB kiest voor Consistency” en Availability. In figuur 6.4 wordt de positie van CouchDB en MongoDB weergegeven in deze theorie. Het komt er op neer dat, in tegenstelling tot MongoDB, CouchDB databases die verspreid zijn over verschillende servers altijd blijven werken, zolang een van de
26 | Opslag van sociale media data
servers online is. MongoDB database servers zijn afhankelijk van één master-server voor alle schrijf query’s (Anderson 2010). CouchDB heeft dus een groot voordeel omdat de infrastructuur soms onzeker kan zijn tijdens grootschalige rampen. Hierdoor kunnen servers offline gaan.
Als de master-server van MongoDB offline is kan geen sociale media data meer verzameld worden, zolang een van de CouchDB servers online is kan de data wel verzameld worden. Ook als door de plotselinge toename van het aantal schrijf-query’s tijdens een incident een van de CouchDB servers crasht, kan de verloren capaciteit gemakkelijk, en zonder onderbrekingen, door een andere server worden overgenomen.
CouchDB biedt ook een goed gedocumenteerde REST API waardoor deze database gemakkelijk geïmplementeerd kan worden.
Figuur 6.4. CAP theorie en de positie van CouchDB en MongoDB
CouchDB biedt alle voordelen van een NoSQL-database, waar onder MapReduce. CouchDB wordt onder andere gebruikt voor opslag van de data die gegenereerd wordt door de CMS module van de Large Hadron Collider. Dit gaat om ongeveer 10PB aan data per jaar (1PB is ongeveer 1 miljoen GB) (Finley 2010). Daarmee voldoet CouchDB dus ruimschoots aan de eis van maximaal 16Gb per dag. Bovendien kan, wanneer hogere eisen gesteld worden, de performance
van CouchDB gemakkelijk verhoogd worden door horizontal-scalability toe te passen, er kan simpelweg een extra server geplaatst worden.
6.2. Representatie van documenten in de database
Nu een database gekozen is, moet een keuze gemaakt worden hoe de sociale media data het beste in deze database opgeslagen kan worden. In CouchDB wordt data opgeslagen in documenten. Dit is een groot verschil met traditionele relationele databases waarin data als rijen in tabellen wordt opgeslagen. De tabellen definiëren een vaste structuur (kolommen) voor iedere rij. In CouchDB is dit niet het geval en kan ieder document verschillen. Bovendien kent CouchDB geen tabellen. Dit is een voordeel omdat daardoor gemakkelijk de verschillende metadata van bijvoorbeeld Twitter of Facebook updates kan worden opgeslagen. Om dergelijke data op te slaan in een tabel in een relationele database zou de data eerst “genormaliseerd” moeten worden, wat vooral nadelig wordt wanneer een nieuwe bron wordt toegevoegd aan de applicatie.
Het normalisatie-algoritme moet dan worden aangepast. Door CouchDB te gebruiken kunnen zonder problemen nieuwe bronnen en nieuwe typen documenten toegevoegd worden.
Voor de te ontwikkelen applicatie worden de volgende document-typen erkend: Updates (bijvoorbeeld Tweets of Facebook updates), Profiles (bijvoorbeeld Twitter of Facebook profielen) en Events (de gebeurtenis waar een update aan gekoppeld is). Omdat zogenaamde irrelevante updates verwijderd moeten worden, is het logisch om de profielen als een sub-document op te slaan in het Update sub-document, zoals weergegeven in figuur 6.5. Wanneer de profielen als aparte documenten opgeslagen zouden worden dan is het lastig om uit te zoeken welke profielen, die bij een irrelevante update horen, verwijderd kunnen worden, omdat een dergelijk profiel misschien ook gekoppeld is aan een update die wel relevant is.
Opslag van sociale media data | 27 Figuur 6.5. Verschillen in representatie bij het verwijderen van documenten
6.3. Terug vinden van data
De opgeslagen sociale media data moet ook teruggevonden kunnen worden in de database.
Dit wordt gedaan door zogenaamde “views”
te maken. In CouchDB worden views gemaakt met de zogenaamde “map” en “reduce”
functies, ook wel MapReduce genoemd. Deze functies worden opgeslagen in de database in speciale documenten, de zogenaamde “design-documents”. Voor de te ontwikkelen applicatie zijn drie design-documents nodig voor de drie verschillende document-typen (Updates, Profiles en Events).
6.3.1. MapReduce
De map-functie in de view maakt het mogelijk om berichten te indexeren op hashtags of woorden in het bericht. Zo kunnen alle berichten die het woord “moerdijk” bevatten gemakkelijk teruggevonden worden. De reduce-functie telt aan de hand van de voorwaarden, die gesteld zijn in de map-functie, het aantal documenten, of telt waarden uit deze documenten bij elkaar op. Zo kan bijvoorbeeld snel gezien worden hoe vaak het woord “moerdijk” voorkomt in een grote verzameling berichten. Omdat de verwerking en berekening van de map- en reduce-functies op de achtergrond gebeurt, hoeft bij het uitlezen van de resultaten nooit gewacht te worden totdat de functies verwerkt zijn voor alle documenten, dit zorgt dus voor een betere performance.
Elke performance winst heeft echter ook een nadeel. Omdat de verwerking op de achtergrond gebeurt, kan het zijn dat nieuwe documenten nog niet zijn meegenomen in de resultaten.
Er kan gekozen worden om te wachten tot alle nieuwe documenten verwerkt zijn, dit kan aanzienlijke vertraging opleveren wanneer een grote hoeveelheid nieuwe documenten wordt toegevoegd. MapReduce-views zijn een krachtig middel, maar kennen ook beperkingen. Zo is het lastig om documenten te filteren op meerdere zoektermen (bijvoorbeeld: “moerdijk” én
“chemiepack”), of om documenten te vinden die een woord bevatten dat lijkt op “chemiepack~”
(bijvoorbeeld: “chemie-pack” of “chemipack”).
Er zijn wel mogelijkheden om geavanceerde reduce-functies te schrijven die dergelijke functionaliteit bieden (Hellan 2009). Een andere oplossing is het gebruik van een geavanceerde zoekmachine.
6.3.2. Zoeken en filteren met ElasticSearch
Om de MapReduce-views aan te vullen is een krachtige zoekmachine nodig die gekoppeld kan worden met de CouchDB database. Apache Lucene is een Zoekmachine, geschreven in Java, die geavanceerde query’s mogelijk maakt. Er zijn verschillende zoekmachines ontstaan op basis van Apache Lucene, waaronder ElasticSearch.
ElasticSearch biedt een kant en klare oplossing om CouchDB databases te indexeren. Bovendien maakt ElasticSearch net als CouchDB gebruik van een goed gedocumenteerde REST API. De koppeling tussen ElasticSearch en de CouchDB database zorgt ervoor dat alle veranderingen in de database op de achtergrond automatisch geïndexeerd worden door ElasticSearch.
ElasticSearch maakt het mogelijk om berichten
28 | Opslag van sociale media data
te filteren op woorden, combinaties van woorden en uitsluitingswoorden. Zo kunnen bijvoorbeeld berichten over schade en slachtoffers gefilterd worden. Meer over de verschillende filter thema’s is te lezen in hoofdstuk 7.
6.4. Database performance
Om de performance van de CouchDB database verder te verhogen moeten het aantal lees-en schrijfquery’s zoveel mogelijk beperkt worden.
Schrijfquery’s kunnen beperkt worden door gebruik te maken van een buffer. Deze buffer verzamelt bijvoorbeeld Tweets voordat ze in de database geschreven worden. Wanneer een bepaalde hoeveelheid berichten verzameld is in de buffer, worden deze met een query tegelijk in de database geschreven. Figuur 6.6 laat de cyclus van het vullen en legen van de buffer zien. Leesquery’s kunnen op eenzelfde manier worden beperkt door gebruik te maken van cache. De resultaten van een leesquery worden in deze cache opgeslagen en getoond in de applicatie. Na een vastgestelde tijd worden de resultaten in de cache vernieuwd. Dit zorgt er onder andere voor dat de te ontwikkelen applicatie zonder problemen door een grote hoeveelheid gebruikers tegelijkertijd gebruikt kan worden.
Figuur 6.6. Vullen en legen van de buffer
6.5. Voorwaarden en richtlijnen voor opslag van sociale media data
Een aantal sociale media stellen voorwaarden aan het gebruik van hun APIs. Voornamelijk Twitter, Facebook, Google+ en Youtube hebben
strikte regels die ontwikkelaars moeten naleven wanneer zij de APIs van deze sociale media willen gebruiken. In grote lijnen geldt voor alle applicaties die gebruik maken van de APIs dat ze voorzichtig moeten zijn met het opslaan van data die verkregen wordt met de APIs. De privacy en wensen van een gebruiker moeten zoveel mogelijk gerespecteerd worden. Als een gebruiker bijvoorbeeld een Tweet verwijdert dan dient deze Tweet ook te verdwijnen uit de database of de cache van de applicatie die gebruik maakt van de Twitter API. Voor de Youtube en Facebook APIs geldt ook dat informatie over gebruikers niet mag worden opgeslagen. In de voorwaarden van Twitter staat ook dat geografische informatie, tenzij deze verbonden is aan een Tweet, niet mag worden opgeslagen en dat data verkregen via de Twitter API niet mag worden opgeslagen in een cloud-based service.
6.6. Conclusie
Dit hoofdstuk geeft antwoord op deelvraag 4: “Hoe kan de gevonden informatie efficiënt worden opgeslagen”. Er is antwoord gegeven op deze vraag door eerst een keuze te maken voor een database die in staat zal zijn om grote hoeveelheden sociale media data op te slaan.
Uiteindelijk is gekozen voor de NoSQL-database CouchDb omdat deze database gemakkelijk te implementeren is en omdat deze database niet afhankelijk is van een enkele master-server. De keuze voor een NoSQL-database heeft gevolgen voor de representatie van de data en de manier waarop de data teruggevonden kan worden. Een van de voordelen van CouchDB is MapReduce, hiermee kan op een efficiënte manier informatie gehaald worden uit grote hoeveelheden data door het optellen van waarden aan de hand van opgestelde criteria. De performance en efficiëntie van de database wordt verder verbeterd door gebruik te maken van een buffer en cache.
Filteren en analyseren van sociale media data | 29