ACID versus BASE-gegevensopslag - dummies

Een kenmerk van relationele databasesystemen is bekend als ACID-conformiteit. Zoals u misschien al vermoedde, is ACID een acroniem - de afzonderlijke letters, bedoeld om een ​​kenmerk van individuele databasetransacties te beschrijven, kunnen worden uitgebreid zoals beschreven in deze lijst:

• Atomiciteit: De databasetransactie moet volledig zijn slagen of volledig falen. Gedeeltelijk succes is niet toegestaan.

• Consistentie: Tijdens de databasetransactie gaat de RDBMS van de ene geldige status naar de andere. De staat is nooit ongeldig.

• Isolatie: De databasetransactie van de client moet geïsoleerd zijn van andere clients die proberen te handelen met de RDBMS.

• Duurzaamheid: De gegevensbewerking die deel uitmaakte van de transactie moet worden weerspiegeld in niet-vluchtige opslag (computergeheugen dat opgeslagen informatie kan ophalen, zelfs wanneer deze niet wordt gevoed - zoals een harde schijf) en blijft bestaan de transactie is voltooid. Transactiefouten kunnen de gegevens niet in een gedeeltelijk gecommitteerde staat achterlaten.

Bepaalde use-cases voor RDBMS's, zoals online transactieverwerking, zijn afhankelijk van ACID-compatibele transacties tussen de client en de RDBMS, zodat het systeem correct functioneert. Een goed voorbeeld van een ACID-conforme transactie is een overboeking van geld van de ene bankrekening naar de andere.

Dit valt uiteen in twee databasetransacties, waarbij de oorspronkelijke account een opname weergeeft en het bestemmingsaccount een storting toont. Vanzelfsprekend moeten deze twee transacties aan elkaar gekoppeld zijn om geldig te zijn, zodat als een van beide mislukt, de hele operatie er niet in slaagt om ervoor te zorgen dat beide saldi geldig blijven.

Hadoop zelf heeft geen concept van transacties (of zelfs records, wat dat betreft), dus het is duidelijk geen ACID-compliant systeem. Als we specifieker denken over gegevensopslag en verwerkingsprojecten in het hele Hadoop-ecosysteem, is geen van beide volledig ACID-compatibel. Ze doen echter eigenschappen weerspiegelen die je vaak ziet in NoSQL-datastores, dus er is een precedent voor de Hadoop-aanpak.

Een belangrijk concept achter NoSQL-datastores is dat niet elke applicatie echt ACID-compatibele transacties nodig heeft. Ontspannen op bepaalde ACID-eigenschappen (en afstand nemen van het relationele model) heeft een schat aan mogelijkheden geopend, waardoor sommige NoSQL-datawinkels enorme schaalbaarheid en prestaties hebben bereikt voor hun nichetoepassingen.

Terwijl ACID de belangrijkste kenmerken definieert die vereist zijn voor een betrouwbare verwerking van transacties, vereist de NoSQL-wereld andere kenmerken om flexibiliteit en schaalbaarheid mogelijk te maken.Deze tegengestelde kenmerken worden slim vastgelegd in het acroniem BASE:

• B asisch A beschikbaar: Het systeem is gegarandeerd beschikbaar voor query's door alle gebruikers. (Geen isolatie hier.)

• S oft State: De waarden die zijn opgeslagen in het systeem kunnen veranderen vanwege het uiteindelijke consistentie model, zoals beschreven in het volgende bullet.

• E ventually Consistent: Naarmate gegevens aan het systeem worden toegevoegd, wordt de status van het systeem geleidelijk gerepliceerd over alle knooppunten. In Hadoop bijvoorbeeld, wanneer een bestand naar de HDFS wordt geschreven, worden de replica's van de gegevensblokken in verschillende gegevensknooppunten gemaakt nadat de oorspronkelijke gegevensblokken zijn geschreven. Gedurende de korte periode voordat de blokken worden gerepliceerd, is de status van het bestandssysteem niet consistent.

Het acroniem BASE is een beetje gekunsteld, omdat de meeste NoSQL-gegevensopslagruimten niet alle de ACID-kenmerken volledig verlaten - het is niet echt het tegengestelde concept dat de naam impliceert, met andere woorden. Ook de Soft State en uiteindelijk consistente kenmerken komen op hetzelfde neer, maar het punt is dat door de consistentie te ontspannen, het systeem horizontaal (veel knooppunten) kan schalen en beschikbaarheid kan garanderen.

Geen enkele bespreking van NoSQL zou compleet zijn zonder de CAP-stelling te noemen, die de drie soorten garanties vertegenwoordigt die architecten in hun systemen willen bieden:

• Consistentie: Vergelijkbaar met de C in ACID, alle knooppunten in het systeem zou op elk moment hetzelfde beeld van de gegevens hebben.

• Beschikbaarheid: Het systeem reageert altijd op verzoeken.

• Partitietolerantie: Het systeem blijft online als netwerkproblemen optreden tussen systeemknooppunten.

De CAP-stelling stelt dat architecten in gedistribueerde netwerksystemen twee van deze drie garanties moeten kiezen - je kunt je gebruikers niet alle drie beloven. Dat geeft u de drie getoonde mogelijkheden:

• Systemen die gebruikmaken van traditionele relationele technologieën zijn normaal gesproken niet verdraagzaam voor partities, dus ze kunnen de consistentie en beschikbaarheid garanderen. Kortom, als een deel van deze traditionele systemen voor relationele technologieën offline is, is het hele systeem offline.

• Systemen waarbij partitietolerantie en beschikbaarheid van primair belang zijn kunnen de consistentie niet garanderen, omdat updates (die de consistentie van de consistentie veroorzaken) aan beide zijden van de partitie kunnen worden aangebracht. De sleutelwaardevermeldingen Dynamo en CouchDB en de column-family store Cassandra zijn populaire voorbeelden van partition tolerant / availability (PA) -systemen.

• Systemen waarop partitietolerantie en consistentie van primair belang zijn kunnen de beschikbaarheid niet garanderen omdat het systeem fouten retourneert totdat de gepartitioneerde status is opgelost.

  Op Hadoop gebaseerde datastores worden beschouwd als CP-systemen ( c onsistent en p artition tolerant). Met gegevens die redundant zijn opgeslagen in veel slave-knooppunten, kunnen storingen in grote hoeveelheden (partities) van een Hadoop-cluster worden getolereerd. Hadoop wordt als consistent beschouwd omdat het een centrale metagegevensopslag heeft (de NameNode) die één enkele, consistente weergave van gegevens die zijn opgeslagen in de cluster onderhoudt.