Key-Value & Document Databases (PDF)

KEY-VALUE-DATABASES Structurele aspecten Eenvoudig key-value-database bestaat uit een dictionary die is opgebouwd uit een verzameling van records die een (sleutel, waarde)-structuur hebben. De waarde van het sleutelveld moet uniek zijn...

KEY-VALUE-DATABASES Structurele aspecten Eenvoudig key-value-database bestaat uit een dictionary die is opgebouwd uit een verzameling van records die een (sleutel, waarde)-structuur hebben. De waarde van het sleutelveld moet uniek zijn Kan samengesteld zijn uit meerdere velden Waardeveld moet ongeïnterpreteerde waarde bevatten die een willekeurige lengte en inhoud mag hebben. (waarde wordt niet geïnterpreteerd door dbms) Waarde heeft geen specifieke structuur Dumpen: deze database is bedoeld om zeer snel data weg te schrijven. De verantwoordelijkheid voor interpretatie ligt bij de applicatie. Geen faciliteiten om verwantschappen tussen records expliciet te modelleren. Als je dit wil doen moet dit via applicatiecode Gedragsaspecten De interactie gebeurt via een heel eenvoudige API (Application Program Interface) CRUD-operatoren (Creation, Retrieval, Update, Deletion) § get(sleutel): zoekfunctie geeft waarde terug. Sleutel wordt als parameter meegegeven § put(sleutel, waarde): toevoegfunctie, voegt een nieuw record met sleutel “sleutel” en waarde “waarde” toe aan de dictionary. § delete(sleutel): verwijderfunctie, verwijdert het record met sleutel “sleutel”. Er is geen functie voor UPDATE om de gegevens aan te passen à verwijder, put Bieden geen faciliteiten voor ad-hoc-opzoekingen en data-analyse. Werkt snel door het bijhouden van een index Voorbeeld samengestelde sleutel: bezoekersidentificatie ‘BID’ en tijdstipindicatie ‘tijdstip’ instructies: Get (B2, 15/1 : 14u02): wat voor bezoeker heeft deze locatie dan bezocht? Put (B3, 15/1 : 14u05, 'zaal 1, Wauw!') Delete (B1, 15/1 : 14u02) 50 Opslagaspecten Men verkiest beschikbaarheid boven consistentie à AP-ontwerp (Beschikbaarheid/Partitietolerantie). Om de beschikbaarheid te garanderen wordt er gewerkt met een gedistribueerde dataopslag. Elk record wordt een aantal keer gerepliceerd en op gebalanceerde wijze gedistribueerd over het secundair geheugen. Voorbeelden: Dynamo, Voldemort, Tokyo Cabinet, Redis, MemcachedDB, Scalaris DOCUMENTDATABASES Structurele aspecten § Opgebouwd uit documenten, bestaande uit componenten die elk een naam en waarde hebben. § Elk document heeft een sleutelcomponent met unieke waarde, uniek voor de volledige database. § Elke component heeft een unieke naam binnen het document. § De documenten hebben geen vaste structuur (dus geen vast databaseschema): § elk document kan een andere structuur hebben de structuur van een document kan gemakkelijk gewijzigd worden een component zonder waarde kan je gewoon weglaten (geen null- of defaultwaarden nodig) een document kan een complexe datastructuur hebben (kan ingebedde documenten bevatten en kan refereren aan (de sleutelwaarde van) andere documenten) § document worden gespecificeerd volgens een gestandaardiseerd gegevensformaat zoals JSON (JavaScript Object Notation) of XML (Extensible Markup Language). § Bij sommige systemen kunnen documenten gegroepeerd worden in benoemde documentcollecties. Bij sommige van die systemen kan een document tot meerdere documentcollecties behoren. Geen behoefte aan NULL waarden of defaultwaarden (bij ontbrekende info laat je het gewoon weg) Voorbeelden: CouchDB, MongoDB en RavenDB Voorbeeld Registratiesnelheid is niet het probleem nu, maar de grote variëteit aan datastructuren à bezoekersopinie registreren in een documentdatabase (JSON) 5 documenten: Links (2 doc’s): info over bezoekers Rechts (3 doc’s): opinieregistraties Elk document heeft een uniek sleutel: id In het bovenste links inbedded adresdocument § inbedded indien klein doc In he bovenste rechts een reference naar bezoekers § meerdere opiniedoc van dezelfde bezoeker kunnen zijn (onnodige duplicaten vermijden) 51 Gedragsaspecten Alle interacties moeten via API gebeuren. Operaties geavanceerder à CRUD § create: nieuw doc met insert-operator § retrieval: zoekoperatoren met find-operator § update: aanpassen met update-operator § deletion: remove-operator Opslagaspecten § meestal AP-ontwerp (Beschikbaarheid/Partitietolerantie). § beschikbaarheid wordt gerealiseerd d.m.v. gedistribueerde dataopslag: de data worden een aantal keer gerepliceerd. § Meestal 'meester-slaaf'-replicatie: Elk gegeven wordt naar één hardware-knoop, de 'meesterknoop' voor dat gegeven genoemd, weggeschreven. De meesterknoop is daarna verantwoordelijk voor het asynchroon (niet- gelijklopend) repliceren van het gegeven naar de slaafknopen. Het gegeven kan zowel gelezen worden vanaf de meesterknoop als vanaf een slaafknoop. Als je leest van een slaafknoop is consistentie niet gegarandeerd. § Gebalanceerde distributie: De hardware-knopen worden gegroepeerd in zogenaamde shards. Elke shard is verantwoordelijk voor het beheer van een deel van de documenten (met 'meester- slaaf'-replicatie). De documenten worden zodanig verdeeld over de shards dat elke shard een gelijke bezetting krijgt in verhouding tot zijn opslag- en verwerkingscapaciteit. (Sharding maakt de bevraging en het beheer van een database complexer.) § De documenten worden gewoonlijk gesorteerd opgeslagen op basis van de waarden van een geschikte component, voor efficiënte uitvoering van de belangrijkste (zoek)operaties. 52 KOLOMGEORIËNTEERDE DATABASES Structurele aspecten § Qua complexiteit kan je het databasemodel voor kolomgeoriënteerde databases plaatsen tussen het databasemodel voor key-value-databases en het databasemodel voor documentdatabases. § Net als bij het relationeel databasemodel worden de data gestructureerd in relaties die je kan voorstellen als tabellen. § Bij relationele databases: in de rijgeoriënteerde relatie stelt elke rij een entiteit voor. De relatie heeft een vast relatieschema die de attributen van alle entiteiten uit de relatie beschrijft. § Bij kolomgeoriënteerde databases: in de kolomgeoriënteerde relatie stelt elke rij slechts een component (attribuut) van een entiteit voor. § De entiteitscomponenten worden gewoonlijk gegroepeerd in kolomfamilies. De regel daarbij is dat je componenten samenbrengt in dezelfde kolomfamilie als die frequent samen worden opgevraagd of aangepast. § Elke kolomfamilie heeft een vaste structuur: een attribuut Rij_id die de rijsleutel (niet uniek!) genoemd wordt (om te zien welke rijen betrekking hebben op dezelfde entiteit) een attribuut Kolomnaam voor de naam van de component een attribuut Kolomwaarde voor de waarde van de component doorgaans ook een attribuut Versie voor versiebeheer (om de geschiedenis van aanpassingen bij te houden) § Er is geen vast databaseschema waarin vastgelegd is welke componenten moeten zijn opgenomen in een kolomfamilie. Als gegevens ontbreken, neem je de betreffende component niet op. § Heb je een meerwaardige component dan voeg je voor elke waarde een rij toe aan de kolomfamilie. (zie in voorbeeld: meerdere rijen voor 'naam' van 'B2' in kolomfamilie 'Bezoeker' en voor 'commentaar' van 'O2' in kolomfamilie 'Opinie‘) § Refereren is mogelijk door een rijsleutel als kolomwaarde mee te geven. (zie in voorbeeld: component 'bezoeker_id‘ in kolomfamilie 'Opinie‘) Dergelijke rijsleutelwaarden worden niet gecontroleerd of consistent gehouden door het dbms. § Versie: geschiedenis bijhouden Voorbeelden: MonetDB, Vertica, HBase, Hypertable, Cassandra en Druid Gedragsaspecten werken via API § Get (Kolomfamilie, Rij_id, Kolomnaam, Versie) : zoekfunctie geeft rijen terug uit kolomfamilie waarvoor rij_id § Insert (Kolomfamilie, Rij_id, Kolomnaam, Versie, waarde) : attribuutwaarde wordt meegegevn § Delete (Kolomfamilie, Rij_id, Kolomnaam, Versie, waarde): 53 SQL-based eenvoudige selects (Creation, Retrieval, Update, Deletion) § SELECT taal FROM Bezoeker WHERE naam = 'Yana': geef taal van bezoeker Yana § SELECT commentaar FROM Opinie WHERE score < 5: geef commentaren waarbij score < 5 § SELECT COUNT(*) FROM Opinie WHERE dag = '15/1/2016': geef aantal opinieregistraties op die datum § Zoekopdrachten worden versneld d.m.v. indexen: elke kolomfamilie is geïndexeerd met een samengestelde index over haar attributen 'Rij_id', 'Kolomnaam' en 'Versie'. Daarnaast kan een DBA zelf indexen aanmaken. Je hebt daarbij de mogelijkheid om een index te bouwen over een component (van een entiteit). Het dbms neemt dan in deze index enkel de rijen op die de component als 'Kolomnaam' hebben. Zo kan je bijvoorbeeld een index bouwen voor de 'plaats'-component van de kolomfamilie 'Opinie'. § Als je slechts informatie van een beperkt aantal componenten (attributen) nodig hebt, verloopt het zoeken in een kolomgeoriënteerde database veel efficiënter dan zoeken in een relationele database. Het dbms hoeft dan immers geen volledige tuples in te lezen en verwerken, maar kan zich beperken tot de data van de betreffende component. § Als er veel componenten (attributen) zijn waarvoor de data ontbreken, wat het geval is bij sterk gevarieerde dataformaten, is schrijven naar een kolomgeoriënteerde database efficiënter dan schrijven naar een relationele database. Opslagcapaciteiten § meestal AP-ontwerp (Beschikbaarheid/Partitietolerantie). § beschikbaarheid wordt gerealiseerd d.m.v. gedistribueerde dataopslag: § meestal één databestand per kolomfamilie § evt. worden de rijen uit de kolomfamilietabel alfabetisch- lexicografisch geordend opgeslagen, volgens de attributen Rij_id, Kolomnaam en Versie. § verder kan elk bestand via een soort van horizontale fragmentatie worden opgedeeld in tablets, die gerepliceerd en gedistribueerd worden over de hardware-knopen van het telecommunicatie- netwerk. Er kunnen duizenden hardware-knopen zijn. VERGELIJKING Prestatie hoe snel zijn schrijf- en leesoperaties?(velocity) Schaalbaarheid kan je het volume aan data gemakkelijk uitbreiden? (volume) Flexibiliteit kan de structuur van de data gemakkelijk worden aangepast? (variety) Complexiteit hoe complex is het databasemodel? Functionaliteit hoe uitgebreid zijn de datamanipulatie- en zoekfaciliteiten? 54 Keuze van databasetechnologie voor 'big' data: afhankelijk van de toepassing. Kiezen voor systeem met CP-strategie of AP-strategie? § Er bestaat veel variatie in de mate waarin consistentie (C) en beschikbaarheid (A) worden afgedwongen. § Algemeen geldt dat hoe groter de C is, hoe kleiner de A is en omgekeerd, maar een strikte opdeling in CP- of AP-systemen heeft praktisch gezien geen zin. Als consistentie belangrijk is: § Kies een NoSQL-systeem waarin AClD- transacties worden ondersteund § Dit zal wel gepaard gaan met tragere uitvoeringstijden. § Voorbeelden van dergelijk systemen zijn Oracle Berkeley DB en Aerospike. OVERIGE ASPECTEN VAN BIG DATA-OPLOSSINGEN Big data: § Grote datavolumes § Grote variëteit aan datastructuren § Snelle verwerkingstijden § Niet-gegarandeerde waarheidsgetrouwheid stelt ook uitdagingen op het vlak van volgende aspecten: § Dataverwerking § Datapresentatie § Juridische aspecten Dataverwerking: data-analyse, recommender systems, decision support systems,... Gedistribueerde dataverwerking: § Schaalbaar telecommunicatienetwerk waarbij de hardwareknopen tegelijkertijd elk een deel van de analysetaken op zich nemen. Door de schaalbaarheid kan je gemakkelijk nieuwe knopen en dus ook extra rekenkracht toevoegen. § Conventionele taken van een data-analyseopdracht zodanig te reorganiseren dat ze gemakkelijk kunnen worden opgesplitst in deeltaken, die dan elk aan een andere knoop kunnen worden aangeboden. Alle knopen verwerken parallel hun deeltaak, waarna de resultaten worden samengebracht. § Als een knoop faalt en zijn deeltaak niet kan uitvoeren, wordt deze deeltaak automatisch overgenomen door een andere knoop. Conventionele data-analysetaken moeten dus zodanig gereorganiseerd worden dat ze gemakkelijk kunnen worden opgesplitst in deeltaken. Voorbeeld: Google MapReduce Datapresentatie : § Vaak is tekstuele representatie ongeschikt § Visuele dataweergave (datavisualisatie, een specialiteit op zich) is vaak meer aangewezen. 55 juridische aspecten: § Bescherming van persoonlijke data (GDPR,…) § e-privacy (wat te doen met klikstroomdata en gps-data?), § Sectorspecifieke wetgeving (bijvoorbeeld de wetgeving voor de medische sector, telecommunicatiesector en energiesector), § Anti-discriminatie en ethische kwesties (het is bijvoorbeeld belangrijk dat de 'big' data- analyse geen personen discrimineert), § Concurrentieregelgeving (mogen 'big' data-analyses worden gebruikt om bepaalde klanten een voordeligere prijs voor hetzelfde product aan te bieden?) en § Eigendom van de data (wie is eigenaar van de inkomende data en de verwerkte data?) NEWSQL Dezelfde schaalbaarheid en lees-& schrijfprestaties als NoSQL-systemen, maar daarnaast toch ACID-compliance als SQL-systemen § Gebaseerd op het relationeel databasemodel § SQL-querytaal als primaire interface § Zeer veel, kortdurende, repetitieve acties die elk slechts een klein deel van de data aanspreken Voorbeelden: H-Store/VoltDB, Google Spanner, ClustrixDB, MemSQL, ScaleBase 56