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
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.
Apache Cassandra onderscheidt zich door een reeks krachtige kenmerken die het tot een robuuste gedistribueerde NoSQL-database maken.
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:
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.
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.
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.
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:
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.
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:
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).
Cassandra biedt verschillende voordelen die het aantrekkelijk maken voor bepaalde soorten toepassingen en gebruiksscenario’s:
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.
Ondanks de vele voordelen van Cassandra zijn er ook enkele nadelen en overwegingen waar rekening mee moet worden gehouden:
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.