4.1 Beschrijving

Apache Cassandra is een gedistribueerd databasebeheersysteem dat behoort tot de klasse van NoSQL-systemen en is ontworpen om zeer schaalbare en betrouwbare opslag van enorme gegevensarrays te creëren die worden gepresenteerd in de vorm van een hash.

Aanvankelijk werd het project ontwikkeld in de ingewanden van Facebook en in 2009 overgedragen onder de vleugels van de Apache Software Foundation, deze organisatie blijft het project ontwikkelen. Industriële oplossingen op basis van Cassandra worden ingezet om diensten te leveren aan bedrijven als Cisco, IBM, Cloudkick, Reddit, Digg, Rackspace, Huawei, Netflix, Apple, Instagram, GitHub, Twitter en Spotify. In 2011 had het grootste servercluster dat een enkele database bedient onder Cassandra meer dan 400 machines en meer dan 300 TB aan gegevens.

Het is geschreven in de Java-taal en implementeert een gedistribueerd hash-systeem vergelijkbaar met DynamoDB, dat een bijna lineaire schaalbaarheid biedt met een toenemend gegevensvolume. Het maakt gebruik van een gegevensopslagmodel dat is gebaseerd op een familie van kolommen, dat verschilt van systemen zoals MemcacheDB, die gegevens alleen opslaan in een sleutel-waardepaar, door de mogelijkheid om hashes op te slaan met verschillende niveaus van nesting.

Behoort tot de categorie fouttolerante DBMS: de gegevens die in de database zijn geplaatst, worden automatisch gerepliceerd naar verschillende knooppunten van een gedistribueerd netwerk of zelfs gelijkmatig verdeeld over meerdere datacenters. Wanneer een node uitvalt, worden de functies direct overgenomen door andere nodes, het toevoegen van nieuwe nodes aan het cluster en het updaten van de Cassandra-versie gebeurt on-the-fly, zonder extra handmatige tussenkomst en herconfiguratie van andere nodes.

Het wordt echter ten zeerste aanbevolen om sleutels (labels) opnieuw te genereren voor elk knooppunt, inclusief bestaande, om de kwaliteit van de taakverdeling te behouden. Het genereren van sleutels voor bestaande knooppunten kan worden vermeden in het geval van een meervoudige toename van het aantal knooppunten (2 keer, 3 keer, enzovoort).

4.2 Gegevensmodel

In Cassandra-terminologie werkt een applicatie met een keyspace, wat overeenkomt met het concept van een databaseschema in het relationele model. Deze sleutelruimte kan meerdere kolomfamilies bevatten, wat overeenkomt met het concept van een relationele tabel.

Kolomfamilies bevatten op hun beurt kolommen (kolom), die worden gecombineerd met behulp van de sleutel (rijsleutel) in het record (rij). De kolom bestaat uit drie delen: naam (kolomnaam), tijdstempel (timestamp) en waarde (waarde). De kolommen binnen een record zijn geordend. In tegenstelling tot een relationele database zijn er geen beperkingen of records (en in termen van de database zijn dit rijen) kolommen bevatten met dezelfde namen als in andere records - nee.

Kolomfamilies kunnen van verschillende soorten zijn, maar in dit artikel zullen we dit detail weglaten. Ook in de nieuwste versies van Cassandra werd het mogelijk om query's uit te voeren voor het definiëren en wijzigen van gegevens (DDL, DML) met behulp van de CQL-taal, evenals het maken van secundaire indices.

De specifieke waarde die is opgeslagen in cassandra wordt geïdentificeerd door:

  • keyspace is een binding met de applicatie (domein). Hiermee kunt u gegevens van verschillende applicaties op hetzelfde cluster hosten;
  • een kolomfamilie is een binding met een query;
  • sleutel is een binding met een clusterknooppunt. De sleutel bepaalt op welke nodes de opgeslagen kolommen terechtkomen;
  • kolomnaam is een binding met een attribuut in het record. Hiermee kunt u meerdere waarden in één item opslaan.

Elke waarde is gekoppeld aan een tijdstempel, een door de gebruiker opgegeven nummer dat wordt gebruikt om conflicten tijdens het opnemen op te lossen: hoe groter het nummer, hoe nieuwere kolom wordt beschouwd en overschrijft bij vergelijking oude kolommen.

4.3 Gegevenstypen

Per gegevenstype: sleutelruimte en kolomfamilie zijn tekenreeksen (namen); tijdstempel is een 64-bits getal; en de sleutel, kolomnaam en kolomwaarde is een reeks bytes. Cassandra heeft ook het concept van gegevenstypen. Deze typen kunnen (optioneel) worden opgegeven door de ontwikkelaar bij het maken van een kolomfamilie.

Voor kolomnamen wordt dit een comparator genoemd, voor waarden en sleutels wordt dit een validator genoemd. De eerste definieert welke bytewaarden zijn toegestaan ​​voor kolomnamen en hoe ze moeten worden geordend. De tweede is welke bytewaarden geldig zijn voor kolom- en sleutelwaarden.

Als deze gegevenstypen niet zijn ingesteld, slaat Cassandra de waarden op en vergelijkt ze als bytereeksen (BytesType), aangezien ze in feite intern worden opgeslagen.

De gegevenstypen zijn:

  • BytesType : elke bytereeks (geen validatie)
  • AsciiType : ASCII-tekenreeks
  • UTF8Type : UTF-8-tekenreeks
  • IntegerType : getal met willekeurige grootte
  • Int32Type : nummer van 4 bytes
  • LongType : 8-byte nummer
  • UUIDType : UUID-type 1 of 4
  • TijdUUIDType : Type 1 UUID
  • DateType : 8-byte tijdstempelwaarde
  • BooleanType : twee waarden: true = 1 of false = 0
  • FloatType : 4-byte drijvende-kommagetal
  • DoubleType : 8-byte drijvende-kommagetal
  • DecimalType : een getal met een willekeurige grootte en een drijvende komma
  • CounterColumnType : Teller van 8 bytes

In cassandra zijn alle gegevensschrijfbewerkingen altijd herschrijfbewerkingen, dat wil zeggen, als een kolom met dezelfde sleutel en naam die al bestaat in de kolomfamilie komt en het tijdstempel groter is dan degene die is opgeslagen, dan wordt de waarde overschreven . De geregistreerde waarden veranderen nooit, alleen nieuwere kolommen komen binnen met nieuwe waarden.

Schrijven naar cassandra gaat sneller dan lezen. Dit verandert de aanpak die in het ontwerp wordt gevolgd. Als we cassandra beschouwen vanuit het oogpunt van het ontwerpen van een gegevensmodel, dan is het gemakkelijker om een ​​kolomfamilie voor te stellen, niet als een tabel, maar als een gematerialiseerde weergave - een structuur die de gegevens van een complexe query vertegenwoordigt, maar deze opslaat in schijf.

In plaats van te proberen op de een of andere manier gegevens samen te stellen met behulp van query's, is het beter om te proberen alles wat nodig is voor deze query op te slaan in de doelfamilie. Dat wil zeggen, het is noodzakelijk om niet vanuit de kant van relaties tussen entiteiten of relaties tussen objecten te benaderen, maar vanuit de kant van vragen: welke velden moeten worden geselecteerd; in welke volgorde de records moeten gaan; welke gegevens met betrekking tot de belangrijkste samen moeten worden opgevraagd - dit alles zou al in de kolomfamilie moeten zijn opgeslagen.

Het aantal kolommen in een record is theoretisch beperkt tot 2 miljard. Dit is een korte uitweiding en meer details zijn te vinden in het artikel over ontwerp- en optimalisatietechnieken. En laten we ons nu verdiepen in het proces van het opslaan van gegevens in Cassandra en het lezen ervan.