Databases schalen zonder grenzen: een blik op Apache Cassandra

12 januari 2024

Berry Vos

In de snel veranderende wereld van gegevensbeheer is Apache Cassandra een ware pionier gebleken. Met haar unieke architectuur en schaalbaarheid heeft dit gedistribueerde NoSQL-databasesysteem een grote invloed gehad op onze kijk op grootschalige gegevensverwerking. In dit artikel nemen we een kijkje in de fascinerende wereld van Cassandra. Ik laat je zien waarom het een belangrijke tool kan zijn voor moderne toepassingen die snelheid, schaalbaarheid en betrouwbaarheid vereisen.

Inhoud

  1. Inzoomen op Apache Cassandra
  2. Kenmerken
  3. Architectuur
  4. Het datamodel
  5. Datareplicatie
  6. Belangrijke voordelen van Cassandra
  7. Uitdagingen en overwegingen
  8. Conclusie

Inzoomen op Apache Cassandra

Apache Cassandra werd oorspronkelijk ontwikkeld door Facebook om te voorzien in de groeiende behoefte aan een robuuste en schaalbare oplossing voor gegevensopslag. Het project begon in 2008 en werd geïnitieerd door Avinash Lakshman en Prashant Malik, een software-engineer en een technisch manager bij Facebook.

Cassandra is ontwikkeld om Facebook te voorzien van een geschikt gegevensopslagsysteem voor de immense hoeveelheid gegevens die gebruikers genereerden. Traditionele relationele databases bleken niet genoeg te kunnen schalen om aan deze eisen te voldoen.

Cassandra werd ontworpen voor situaties waarin schaalbaarheid, hoge beschikbaarheid en tolerantie voor storingen cruciaal waren. Het maakte gebruik van een gedistribueerde architectuur en een gedecentraliseerd datamodel om gegevens over verschillende nodes in een cluster te verdelen.

In 2009 werd Cassandra opengesteld als een open-sourceproject en gedoneerd aan de Apache Software Foundation. Sindsdien heeft het een actieve gemeenschap en is het uitgegroeid tot een van de meest populaire en wijdverspreide NoSQL-databases ter wereld.

Tegenwoordig wordt Apache Cassandra gebruikt door tal van organisaties en bedrijven om grote hoeveelheden gegevens op te slaan en te beheren in een schaalbare en betrouwbare omgeving.

Kenmerken van Cassandra

Apache Cassandra onderscheidt zich door een reeks krachtige kenmerken die het tot een robuuste gedistribueerde NoSQL-database maken.

  • Schaalbaarheid: Cassandra kan eenvoudig horizontaal worden geschaald door simpelweg extra knooppunten (nodes) toe te voegen aan het cluster. Dit maakt het geschikt voor grote, groeiende datasets.
  • Hoge mate van beschikbaarheid: Door het gebruik van een gedistribueerde architectuur en replicatie over meerdere nodes, kan Cassandra beschikbaar blijven, zelfs als sommige nodes uitvallen.
  • Gegevensreplicatie: Cassandra maakt gebruik van een masterless architectuur waarbij gegevens worden gerepliceerd over verschillende nodes in het cluster. Hierdoor kunnen lees- en schrijfoperaties worden uitgevoerd op elke node, wat bijdraagt aan de hoge beschikbaarheid.
  • Lineaire Schaalbaarheid: Met toevoeging van extra nodes aan het cluster neemt de schaalbaarheid lineair toe. Dit betekent dat de prestaties verbeteren naarmate er meer nodes worden toegevoegd.
  • Storingstolerantie: Cassandra is ontworpen om tolerant te zijn voor node-uitval, netwerkproblemen en andere storingen. Het blijft operationeel en consistent, zelfs in het geval van dergelijke gebeurtenissen.
  • Flexibel Datamodel: Cassandra maakt gebruik van een column-family model dat flexibiliteit biedt bij het opslaan van gegevens. Dit betekent dat elke rij in een tabel verschillende kolommen kan hebben, zonder dat ze dezelfde structuur hoeven te hebben.
  • Snelle Lees- en Schrijfoperaties: Cassandra is geoptimaliseerd voor snelle schrijfoperaties en kan ook efficiënt leesoperaties uitvoeren, vooral bij gebruik van een goede datamodellering.
  • Ondersteuning voor Transacties: Cassandra ondersteunt transacties op verschillende niveaus, hoewel het niet hetzelfde niveau van transactieondersteuning biedt als relationele databases.
  • Geografische Verspreiding: Cassandra is ontworpen om gegevens over verschillende geografische locaties te repliceren, waardoor het geschikt is voor wereldwijde toepassingen.
  • Community en Ondersteuning: Cassandra heeft een actieve open-sourcegemeenschap en wordt ondersteund door de Apache Software Foundation, wat betekent dat het regelmatig wordt bijgewerkt en verbeterd.

Architectuur

Cassandra gebruikt een zogenaamde ringarchitectuur, waarbij de kleinste logische eenheid een node is. Er wordt partitioning toegepast om queries te optimaliseren en de data zo efficiënt over de nodes te kunnen verdelen.

Dat werkt als volgt: elke rij heeft een partition key. Deze partition key wordt gehasht zodat deze een uniek token krijgt. Elke node heeft een tokenreeks toegewezen gekregen, wat er dus voor zorgt dat elke rij met dezelfde partition key op dezelfde node wordt opgeslagen. Gevolg hiervan is dat queries erg snel en efficiënt de data kunnen ophalen. Het spreekt voor zich dat de partition key dus met beleid moet worden gekozen.

De architectuur van Cassandra bestaat uit de volgende componenten:

  1. Node

Zoals eerder al aangegeven is de node de kleinste logische eenheid. Een node is een instantie van een Cassandra-database die draait op een (virtuele) machine en bevat de feitelijke data. De nodes zijn georganiseerd volgens de ring-netwerktopologie (elk knooppunt (of apparaat) in het netwerk is rechtstreeks verbonden met precies twee andere knooppunten, waardoor een gesloten lus of ring ontstaat, zonder centraal knooppunt). De nodes zijn dus onafhankelijk en hebben allen dezelfde rol.

  1. Rack

Een Cassandra-rack is een logische groepering van knooppunten binnen de ring. Met andere woorden, een rack is een verzameling van servers. De database gebruikt racks om ervoor te zorgen dat replica’s zijn verdeeld over verschillende logische groeperingen. Hierdoor kan het bewerkingen naar meer dan een knooppunt sturen. Meerdere knooppunten, elk op een apart rack, bieden een grotere fouttolerantie en beschikbaarheid.

 

  1. Datacenter

Een datacenter is een logische verzameling van racks. Het datacenter moet minstens één rack bevatten. Je zou kunnen zeggen dat een datacenter een groep nodes is die gerelateerd en geconfigureerd zijn binnen een cluster voor replicatiedoeleinden. Hierdoor helpt het om de latency te verminderen en voorkomt het dat transacties worden beïnvloed door andere workloads en gerelateerde effecten. Bovendien kan de replicatiefactor ook worden ingesteld om naar meerdere datacenters te schrijven. Hierdoor kan Cassandra extra flexibiliteit bieden in architectonisch ontwerp en organisatie.

  1. Cluster

Een cluster bestaat uit een of meer datacenters en vormt de buitenste laag van de Cassandra-architectuur. Een database bestaat uit een of meer clusters. De architectuur is schematisch als volgt voor te stellen:

Het datamodel van Cassandra

Cassandra maakt gebruik van de Cassandra Query Language (CQL) waarmee databaseschema’s gecreëerd en gewijzigd kunnen worden en de data uitgevraagd kan worden. De data wordt vastgelegd in een cluster van Cassandranodes waarbij gebruik wordt gemaakt van:

Keyspaces: Op het hoogste niveau bestaat het NoSQL-datamodel van Cassandra uit gegevenscontainers, zogenaamde keyspaces. Een keyspace definieert hoe een dataset wordt gerepliceerd (het aantal kopieën per cluster). Keyspaces zijn vergelijkbaar met het een schema in een relationele database en bevat doorgaans veel tabellen.

Tabellen: Tabellen worden gedefinieerd binnen de keyspaces. Tabellen bestaan uit partitions, die uit rijen bestaan die vervolgens uit kolommen bestaan. Aan een Cassandratabel kunnen “on the fly” nieuwe kolommen worden toegevoegd, zonder down-time.

Partitions: Partitions worden bepaald door de verplichte primary key die alle rijen in Cassandra moeten hebben om de node waar de rij in een cluster is vastgelegd te kunnen bepalen. Alle prestatiegerichte query’s bevatten die partitiesleutel in de query.

Rijen: Een rij bestaat een een aantal kolommen die worden geïdentificeerd aan de hand van de primary key, die bestaat uit de partition key en eventuele extra clustering keys.

Kolommen: Kolommen, ten slotte, definiëren de gegevensstructuur binnen een tabel. Er zijn verschillende soorten kolommen, zoals Boolean, double, integer en tekst.

Het gegevensmodel van Apache Cassandra is gebaseerd op en geoptimaliseerd voor het uitvoeren van queries (query based modelling). Dit houdt in dat de structuur en organisatie van gegevens wordt bepaald door het gebruik van de gegevens door de applicatie (datatoegang en uit te voeren queries) waarmee vervolgens de database wordt ontworpen. In het kort: Gegevens worden gemodelleerd rond specifieke query’s.

Query’s worden idealiter ontworpen om toegang te krijgen tot één tabel, wat impliceert dat alle betrokken entiteiten in dezelfde tabel staan om snel toegang tot de gegevens krijgen. Een tabel kan één of meer entiteiten hebben, afhankelijk van wat het beste past bij een query. Entiteiten hebben doorgaans onderling relaties met elkaar, maar query’s betrekken die gerelateerde entiteiten weer bij elkaar. Daardoor kan een bepaalde entiteit in meerdere tabellen worden opgenomen. Omdat Cassandra geen ingebouwde ondersteuning biedt voor automatische referentiële integriteit of transacties tussen meerdere tabellen, moet de applicatie deze consistentie handhaven.

Datareplicatie

Het kan voorkomen dat een hardware- of netwerkstoring voor problemen zorgt bij het ophalen of wegschrijven van data. De database is dan onbereikbaar. Cassandra ondervangt dit door replica’s van de data op verschillende nodes weg te schrijven om zo de betrouwbaarheid te vergroten en fouttolerant te zijn.

Replicatiefactor

De replicatiefactor in Cassandra verwijst naar het aantal kopieën (replica’s) van gegevens dat wordt opgeslagen op verschillende nodes in een Cassandra-cluster. Wanneer gegevens worden geschreven naar een Cassandra-tabel, wordt de data verdeeld over de nodes op basis van de gekozen partition key. De replicatiefactor bepaalt hoeveel van deze knooppunten kopieën van de gegevens zullen opslaan.

Als bijvoorbeeld de replicatiefactor is ingesteld op 3, betekent dit dat de gegevens op drie verschillende knooppunten worden gerepliceerd. Dit zorgt voor redundantie en betekent dat zelfs als een knooppunt uitvalt, de gegevens nog steeds beschikbaar zijn op de andere twee replica’s.

De keuze van de replicatiefactor heeft invloed op de prestaties, schaalbaarheid en betrouwbaarheid van het Cassandra-cluster. Een hogere replicatiefactor biedt meer veerkracht tegen knooppuntuitval, maar kan ook leiden tot grotere opslag- en netwerkbelasting.

Consistency level

Consistency levels stellen de mate van gegevensconsistentie in. Ze bepalen hoeveel nodes moeten reageren op een lees- of schrijfactie voordat deze als succesvol wordt beschouwd.

Er zijn verschillende consistency levels, zoals:

  • One: Hierbij moet minstens één node reageren voor een operatie om als succesvol te worden beschouwd. Dit is het laagste consistentieniveau en biedt minder garanties voor consistentie.
  • Quorum: Dit is “X/2 + 1”, waarbij “X” het totale aantal nodes in het cluster is. Hier moet de (kleinste) meerderheid van de nodes reageren voor een operatie om als succesvol te worden beschouwd. Dit biedt een hoger niveau van consistentie.
  • All: Alle nodes in het cluster moeten reageren voor een operatie om als succesvol te worden beschouwd. Dit biedt het hoogste niveau van consistentie, maar kan leiden tot hogere latency.
  • Local quorum: Hierbij moet de meerderheid van de nodes in de lokale datacenter reageren. Dit is nuttig in geografisch verspreide clusters.
  • Each quorum: Elk datacenter moet een quorum hebben om als succesvol te worden beschouwd. Dit is nuttig in clusters met meerdere datacenters.

Het kiezen van het juiste consistency level is afhankelijk van de specifieke eisen van de toepassing. Hogere levels bieden meer garanties voor consistentie, maar kunnen leiden tot hogere latency en vereisen meer nodes om te reageren. Het is een compromis tussen consistentie, beschikbaarheid en partitioneringstolerantie (het zogenaamde CAP-theorema).

Belangrijke voordelen van Cassandra

Cassandra biedt verschillende voordelen die het aantrekkelijk maken voor bepaalde soorten toepassingen en gebruiksscenario’s:

  • Hoge Beschikbaarheid en Fouttolerantie:
    Door de gedistribueerde architectuur en replicatiestrategieën biedt Cassandra hoge beschikbaarheid en is het bestand tegen node- of zelfs datacenterstoringen zonder dat dit de beschikbaarheid van de service in gevaar brengt.
  • Schaalbaarheid:
    Cassandra kan gemakkelijk horizontaal worden geschaald door eenvoudigweg nieuwe nodes toe te voegen aan het cluster. Dit maakt het mogelijk om grote hoeveelheden gegevens te beheren en zeer hoge doorvoersnelheden te bereiken.
  • Lineaire Schaalbaarheid:
    De prestaties van Cassandra schalen lineair met het toevoegen van nodes. Hierdoor kunnen grotere belastingen worden verwerkt door simpelweg meer hardware toe te voegen.
  • Geen Single Point of Failure:
    Door de gedistribueerde aard van Cassandra heeft het geen single point of failure. Zelfs als een node of een deel van het cluster uitvalt, blijft de service beschikbaar.
  • Snelle Lees- en Schrijfprestaties:
    Dankzij de gedistribueerde architectuur en het feit dat gegevens worden geoptimaliseerd voor lees- en schrijfbewerkingen, kan Cassandra zeer snelle prestaties leveren, met name bij het schrijven van gegevens.
  • Flexibele Datamodellering:
    Cassandra ondersteunt een flexibel datamodel dat ongestructureerde gegevens kan behandelen. Hierdoor is het geschikt voor een breed scala aan toepassingen.
  • Tunabele Consistentie:
    Cassandra biedt de mogelijkheid om de mate van consistentie te tunen op basis van de vereisten van de toepassing. Dit betekent dat ontwikkelaars kunnen kiezen tussen hoge beschikbaarheid met iets lagere consistentie of strengere consistentie met mogelijk iets lagere beschikbaarheid.
  • Geografische Distributie:
    Cassandra ondersteunt het verspreiden van gegevens over verschillende datacenters, waardoor het geschikt is voor toepassingen die wereldwijd moeten opereren.
  • Gemakkelijk te Beheren:
    Cassandra wordt geleverd met handige beheertools en heeft een actieve gemeenschap die ondersteuning biedt. Bovendien biedt het automatische replicatie en failover.

Het spreekt vanzelf dat de voordelen van Cassandra het meest tot hun recht komen bij toepassingen met specifieke vereisten, zoals hoge beschikbaarheid, schaalbaarheid en tolerantie voor storingen. Voor andere soorten toepassingen kunnen er mogelijk betere keuzes zijn, afhankelijk van de specifieke behoeften.

Uitdagingen en overwegingen

Ondanks de vele voordelen van Cassandra zijn er ook enkele nadelen en overwegingen waar rekening mee moet worden gehouden:

  • Complexiteit van Gegevensmodellering:
    Het ontwerpen van een effectief gegevensmodel voor Cassandra kan uitdagend zijn, vooral voor mensen die niet bekend zijn met het gedistribueerde en niet-relationele karakter van de database. Een goed begrip van de toepassing en de te ondersteunen querypatronen is essentieel.
  • Beperkte Query-mogelijkheden:
    Cassandra is geoptimaliseerd voor snelle toegang tot individuele rijen op basis van de partition key. Complexe query’s die meerdere partities of geavanceerde aggregatiefuncties vereisen, kunnen lastig te implementeren zijn.
  • Consistentiecompromissen:
    Cassandra biedt tunable consistency, wat betekent dat ontwikkelaars moeten kiezen tussen hoge beschikbaarheid met iets lagere consistentie of strengere consistentie met mogelijk iets lagere beschikbaarheid. Het kan lastig zijn om hierin een balans te vinden.
  • Opslag Overhead:
    Cassandra heeft overhead vanwege de manier waarop het gegevens repliceert en verspreidt om fouttolerantie te bieden. Dit kan leiden tot een hogere opslagvereiste in vergelijking met sommige andere databases.
  • Leervermogen en Training:
    Om het volledige potentieel van Cassandra te benutten, is enige mate van expertise vereist. Dit kan extra tijd en inspanning vergen om te leren en te implementeren.
  • Slechte Ondersteuning voor Ad-hoc Query’s:
    Cassandra is niet ontworpen voor complexe ad-hoc query’s die typisch worden ondersteund door relationele databases met krachtige SQL-querymogelijkheden.
  • Niet Geschikt voor Alle Gebruiksscenario’s:
    Hoewel Cassandra uitblinkt in specifieke gebieden zoals hoge beschikbaarheid en schaalbaarheid, is het mogelijk niet de beste keuze voor alle soorten toepassingen. Relationele databases kunnen bijvoorbeeld beter geschikt zijn voor toepassingen met complexe query-eisen.
  • Initiële Implementatiekosten:
    De initiële implementatie en configuratie van een Cassandra-cluster kan complex zijn en vereist mogelijk meer inspanning dan bij sommige andere databases.

Conclusie

Concluderend kunnen we zeggen dat Cassandra een krachtige gedistribueerde database is die uitblinkt in hoge beschikbaarheid, schaalbaarheid en tolerantie voor fouten. Het is een uitstekende keuze voor toepassingen met specifieke vereisten, zoals snelle gegevenstoegang en betrouwbaarheid, met name in scenario’s waar traditionele relationele databases tekortschieten.

Echter, het is belangrijk om te erkennen dat het ontwerpen van een effectief gegevensmodel en het configureren van de database vereist dat ontwikkelaars vertrouwd zijn met de gedistribueerde aard van Cassandra. Met de juiste expertise en planning kan Cassandra een waardevolle toevoeging zijn aan de technologiestack van een organisatie, en kan het een cruciale rol spelen bij het ondersteunen van schaalbare, betrouwbare toepassingen.

Het laatste nieuws