Slimme technologie voor een sterke maakindustrie met 24/7 ononderbroken productie van IIoT-oplossingen voor bedrijven.
Niet elk use case vereist dezelfde aanpak. In deze blog geven we een overzicht van enkele criteria die in aanmerking moeten worden genomen bij het kiezen van één of meerdere databases. We bespreken ook het CAP-theorema als hulpmiddel om gesprekken over consistentie versus beschikbaarheid voor een specifieke database te structureren.
Om een overzicht te krijgen van de enorme hoeveelheid databanktypes die er bestaan, lees onze blog over << het NoSQL-landschap >>.
Ook voor onze eigen producten en toepassingen gebruiken we niet slechts 1 database. Design for failure, performantie en schaalbaarheid staan centraal in onze oplossingen. Bij sAInce.io kiezen we ook de juiste database voor de juiste use case.
Welke criteria zijn belangrijk bij het selecteren van een specifiek databasesysteem of meerdere databasesystemen voor verschillende use cases?
RDBMS zijn uitstekend. Een relationele database is zelfbeschrijvend. Het schema van de database kan worden gedefinieerd met zijn relaties en beperkingen tussen rijen en tabellen.
We kunnen vertrouwen op de functionaliteit van de relationele database (niet op de applicatiecode) om het schema af te dwingen en de referentiële integriteit van de gegevens binnen de database te behouden.
En de meeste van hen schalen behoorlijk goed op. Er is echter een limiet. Horizontaal schalen is niet mogelijk, alleen verticaal. Dus als je onbeperkte schaalbaarheid nodig hebt en een applicatie voor groei bouwt, zul je op een bepaald moment horizontale schaalbaarheid nodig hebben.
Leveranciers zoals Oracle en IBM hebben het afgelopen decennium enorme inspanningen geleverd om hun RDBMS op high-performance en verticaal geschaalde hardware-appliances te laten draaien, zoals Oracle EXADATA en IBM Pure Analytics (voorheen bekend als Netezza). Als je echter wilde opschalen, moest je een grotere hardware-appliance aanschaffen. Schaalbaarheid is dus geen plug-in functionaliteit.
Met horizontale schaalvergroting voeg je nieuwe nodes toe aan het cluster van machines dat je databasesysteem draait en schaal je dienovereenkomstig op. Extra kracht, extra geheugen, extra schijfruimte. Met een paar klikken ben je klaar (als het cloud-gebaseerd is).
Willen we dat onze data 24/7 beschikbaar is, ongeacht wat er gebeurt? In dat geval hebben we een databasesysteem nodig dat kan repliceren tussen verschillende fysieke locaties en dat binnen een seconde kan overschakelen van de ene master naar de andere master.
Of tolereren we enige onbeschikbaarheid? Dan kan een master/slave-systeem mogelijk voldoende zijn voor de taak.
Consistentie is een van de kernaspecten van ACID-compliance. ACID staat voor Atomic, Consistent, Isolated en Durable.
ACID heeft tot doel de geldigheid van data te garanderen, ondanks fouten, stroomuitval of andere defecten. In de context van databases wordt een reeks databasebewerkingen die voldoet aan de ACID-eigenschappen (die kan worden gezien als één logische operatie op de data) een transactie genoemd.
Atomiciteit garandeert dat elke transactie als één geheel wordt behandeld. Ze slaagt volledig of faalt volledig.
Consistentie betekent dat een transactie de database alleen kan brengen van de ene geldige staat naar de andere. Alle beperkingen en relaties die door de database zijn geïmplementeerd, worden nageleefd. Dit voorkomt dat data wordt beschadigd door een illegale transactie.
Isolatie zorgt ervoor dat gelijktijdige transacties de database in dezelfde staat achterlaten als wanneer de transacties sequentieel zouden zijn uitgevoerd. Isolatie is het hoofddoel van concurrency control.
Duurzaamheid garandeert dat zodra een transactie is gecommit, deze gecommit blijft, zelfs bij een systeemstoring.
Stel je een scenario voor met één database-server in Europa en één in de VS, beide gesynchroniseerd. Europese gebruikers gebruiken de server in Europa, Amerikaanse gebruikers de server in de VS. Logisch.
Maar stel dat de communicatie tussen beide servers uitvalt. Willen we consistentie in de data behouden? Weigeren we updates op beide systemen zodat alle data consistent blijft? Of gebruiken we één systeem als waarheid (de master) en wijzen we alle gebruikers daar naartoe? Gebruikers kunnen blijven lezen en schrijven, maar wanneer de communicatie is hersteld, moeten beide systemen opnieuw worden gesynchroniseerd. Hierdoor zullen beide systemen uiteindelijk consistent zijn.
Of offeren we consistentie op en laten we beide systemen actief updates verwerken, waarbij we de updates later proberen te combineren zodra de communicatie is hersteld?
Een soortgelijk redenering geldt voor gedistribueerde data: NoSQL-databases kunnen data intrinsiek distribueren en repliceren over verschillende nodes. Hoe gaan we dan om met consistentie? Wachten we tot alle nodes de transactie hebben bevestigd of passen we een bepaald quorum toe?
Hebben we onmiddellijke consistentie nodig of eventual consistency? In veel use cases is eventual consistency voldoende.
Bijvoorbeeld, Amazon DynamoDB, een bekende key-value store, biedt standaard eventual consistency voor reads en writes, waardoor consistentie wordt opgeofferd ten gunste van beschikbaarheid.
Het is echter mogelijk te kiezen voor sterke consistente reads (niet writes – writes zijn altijd eventually consistent in DynamoDB), waardoor beschikbaarheid wordt opgeofferd. Sterk consistente reads geven een foutmelding bij netwerkvertraging of uitval als de read niet lukt.
In Cassandra, een bekende wide-column store, kan volledig worden geconfigureerd hoe consistentie wordt afgehandeld: dit is gebaseerd op het gekozen consistency-level en het aantal replicas in het cluster. Standaard offert Cassandra ook consistentie op ten gunste van beschikbaarheid: als het systeem de data naar één replica schrijft, wordt de transactie als voltooid beschouwd. Het is echter mogelijk om hogere consistentie te kiezen en beschikbaarheid op te offeren door te eisen dat alle replica nodes voor een partition de write hebben bevestigd voordat de transactie wordt voltooid. Cassandra biedt zo een breed spectrum aan tussenliggende consistentieniveaus door de consistency-configuratie aan te passen
In sommige gevallen willen we niet beperkt worden door een strikt schema en willen we flexibel zijn in de structuur van onze data. In dat geval houden we waarschijnlijk van JSON (JavaScript Object Notation) en willen we een databasesysteem gebruiken dat JSON-objecten native kan opslaan. Misschien willen we dat het systeem zich aan een bepaald JSON-schema houdt bij het opvragen van data, enzovoort.
Maar we willen de flexibiliteit hebben om onze data in elke gewenste structuur op te slaan.
Object stores (ook wel document-georiënteerde stores genoemd) bieden dergelijke functionaliteit. Voorbeelden zijn MongoDB en CosmosDB.
Of misschien willen we een systeem dat ons een strikt schema kan bieden zoals in de RDBMS-wereld, maar tegelijkertijd enige flexibiliteit biedt waarmee we dat strikte schema kunnen omzeilen. In dat geval zouden we kiezen voor een soort hybride DBMS zoals PostgreSQL. PostgreSQL is in zijn kern relationeel van aard, maar biedt zeer krachtige functionaliteiten die het relationele hart uitbreiden, bijvoorbeeld met JSON-ondersteuning.
De tijden dat gebruikers genoegen namen met een vertraging van meer dan 10 seconden voordat het systeem een reactie gaf, liggen ver achter ons. Tegenwoordig willen we snelle data-opvraging en/of snelle data-inname. Afhankelijk van de use case kiezen we het ene of het andere databasesysteem.
In sommige gevallen hebben we microseconde-responstijden nodig, wat niet kan worden bereikt met enkel disk I/O. In die gevallen hebben we een in-memory database nodig die datasets levert die we via RAM-intensieve opslag kunnen benutten.
Wat voor soort data gaan we opslaan? Tijdreeksdata hebben andere vereisten dan stuklijstgegevens, klantgegevens, enzovoort.
IoT-tijdreeksdata vereisen over het algemeen geen updates, maar snelle opslag en opvraging. Als we alle relaties van onze Facebook-vrienden en hun connecties zouden moeten vastleggen, hebben we andere vereisten. We willen snel kunnen navigeren van de ene node naar de andere, en dat binnen al onze potentiële vrienden wereldwijd!
Het type data dat we willen opslaan en het type queries dat we op die data moeten kunnen uitvoeren, heeft dus een grote invloed op onze keuze van database.
Willen we het onderhoud en de ondersteuning van onze databases uitbesteden aan een extern bedrijf? Gaan we onze eigen infrastructuur on-premise voorzien of het systeem hosten op cloud-infrastructuur?
Het ondersteunen van het databasesysteem of -systemen on-premise brengt ook kosten met zich mee: kosten voor opleiding van onze IT-medewerkers, pure hardwarekosten, licenties, enzovoort.
Hetzelfde geldt wanneer we on-premise willen opschalen. We moeten de infrastructuur uitbreiden en onze databasesystemen configureren om de schaal dynamisch uit te breiden. Dit in tegenstelling tot cloud-infrastructuur, waar uitbreiding slechts enkele minuten duurt en zonder downtime kan plaatsvinden.
Het CAP-theorema, een theorie uit de computertechnologie oorspronkelijk ontwikkeld door Eric Brewer, stelt dat een gedistribueerd computersysteem niet tegelijkertijd de optimale staat van alle drie de volgende criteria kan garanderen:
Consistentie
Beschikbaarheid
Partition Tolerance (tolerantie voor partitionering)
Optimale consistentie betekent dat het systeem te allen tijde dezelfde staat heeft. Hierdoor hebben alle clients op elk moment hetzelfde beeld van de staat. Dit betekent dat elke read de meest recente write ontvangt, of een foutmelding.
Optimale beschikbaarheid betekent dat het systeem bestaat en dat updates te allen tijde kunnen worden uitgevoerd. Er is dus geen downtime. Elk verzoek ontvangt een (niet-fout) respons, zonder de garantie dat deze de meest recente write bevat.
Optimale partition tolerance betekent dat als een systeem uit n delen bestaat (ook wel partities genoemd), het blijft functioneren in n delen als de communicatie tussen de n delen wordt onderbroken. Het systeem blijft werken ondanks een willekeurig aantal berichten dat wordt verloren of vertraagd door het netwerk tussen de nodes.
Het CAP-theorema impliceert dat in het geval van een netwerkpartitionering men moet kiezen tussen consistentie en beschikbaarheid.
Dus wanneer een netwerkpartitionering optreedt, moeten we beslissen om:
De operatie te annuleren en zo de beschikbaarheid te verlagen maar de consistentie te waarborgen
De operatie door te voeren en zo beschikbaarheid te bieden maar het risico op inconsistentie te accepteren
Soms wordt het CAP-theorema gebruikt om te laten zien hoe databases ten opzichte van dit driehoekige model scoren. Dit kan enigszins misleidend zijn, omdat de meeste databasesystemen eigenlijk verschillende configuraties hebben waarbij je ofwel beschikbaarheid ofwel consistentie kunt opofferen.
In de onderstaande afbeelding positioneren we de verschillende consistentieconfiguraties die van toepassing zijn op DynamoDB, zoals eerder genoemd. In deze context heeft het CAP theorema dus veel waarde.
De CAP-driehoek is een interessant hulpmiddel om de verschillende configuraties van een bepaald databasesysteem inzichtelijk te maken.
Laten we de tabel die we eerder in een vorige blog over NoSQL-databases hebben gebruikt opnieuw bekijken en uitbreiden met enkele voorbeelden van toepasselijke use cases. Je kunt deze tabel gebruiken als een soort algemene richtlijn.
Zoals eerder gezegd, moet elke use case echter worden behandeld met zijn specifieke vereisten in gedachten. Vul de onderstaande tabel aan met de hierboven genoemde selectiecriteria en je hebt een goed onderbouwde aanpak om te beginnen met het selecteren van de database die bij jouw behoeften past.
