ACID versus BASE Data Stores - dummies

Et kendetegn ved relationelle databasesystemer er noget kendt som ACID-overholdelse. Som du måske har gættet, er ACID en akronym - de enkelte bogstaver, der er beregnet til at beskrive en karakteristik af individuelle database transaktioner, kan udvides som beskrevet i denne liste:

• Atomicity: Databasetransaktionen skal helt lykkes eller helt fejler. Delvis succes er ikke tilladt.

• Konsistens: Under databasetransaktionen går RDBMS fra en gyldig tilstand til en anden. Staten er aldrig ugyldig.

• Isolation: Klientens database transaktion skal ske isoleret fra andre klienter, der forsøger at handle med RDBMS.

• Holdbarhed: Datoperationen, der var en del af transaktionen, skal afspejles i ikke-flygtig lagring (computerhukommelse, der kan hente lagrede oplysninger, selvom den ikke drives - som en harddisk) og fortsætter efter transaktionen afsluttes med succes. Transaktionsfejl kan ikke overlade dataene i en delvist begået tilstand.

Visse anvendelsessager til RDBMS'er, som online transaktionsbehandling, afhænger af ACID-kompatible transaktioner mellem klienten og RDBMS for at systemet kan fungere korrekt. Et godt eksempel på en ACID-kompatibel transaktion er en overførsel af midler fra en bankkonto til en anden.

Dette opdeles i to databasetransaktioner, hvor den oprindelige konto viser en tilbagetrækning, og destinationskonto viser et depositum. Disse to transaktioner skal naturligvis være bundet sammen for at være gyldige, så hvis en af ​​dem fejler, må hele operationen ikke sikre, at begge saldi forbliver gyldige.

Hadoop selv har intet begreb om transaktioner (eller endda optegnelser, for den sags skyld), så det er helt klart ikke et system, der er surt. Tænker mere specifikt om datalagring og -processer i hele Hadoop-økosystemet, ingen af ​​dem er også helt sure. Men de gør afspejler egenskaber, som du ofte ser i NoSQL-datalager, så der er noget præcedens for Hadoop-tilgangen.

Et nøglekoncept bag NoSQL datalager er, at ikke alle applikationer virkelig har brug for ACID-kompatible transaktioner. Afslappende på visse ACID-egenskaber (og væk fra relationsmodellen) har åbnet et væld af muligheder, som har gjort det muligt for nogle NoSQL-datalager at opnå massiv skalerbarhed og ydeevne for deres nicheapplikationer.

Mens ACID definerer de nøgleegenskaber, der kræves til pålidelig transaktionsbehandling, kræver NoSQL verden forskellige karakteristika for at muliggøre fleksibilitet og skalerbarhed.Disse modsatte egenskaber er klogt indfanget i akronymet BASE:

• B asically A tilgængelig: Systemet er garanteret at være tilgængeligt for forespørgsel fra alle brugere. (Ingen isolering her.)

• S ofte Stat: De værdier, der er lagret i systemet, kan ændres på grund af den eventuelle konsistensmodel som beskrevet i næste punkt.

• E ventuelt konsistent: Da data tilføjes til systemet, gentages systemets tilstand gradvist på tværs af alle knudepunkter. For eksempel i Hadoop, når en fil er skrevet til HDFS, oprettes replikerne af datablokkerne i forskellige dataduder, efter at de originale datablokke er blevet skrevet. I den korte periode, før blokken gentages, er tilstanden i filsystemet ikke konsistent.

Akronymet BASE er lidt konstrueret, da de fleste NoSQL-datalagre ikke helt overgiver alle ACID-egenskaberne - det er ikke rigtig det polære modsatte koncept, som navnet antyder, med andre ord. Også den bløde tilstand og de vedvarende konsistente egenskaber svarer til det samme, men pointeret er, at ved afslappende konsistens kan systemet horisontalt skala (mange knuder) og sikre tilgængelighed.

Ingen diskussion af NoSQL ville være fuldstændig uden at nævne CAP-sætningen, som repræsenterer de tre slags garantier, som arkitekter sigter at levere i deres systemer:

• Konsistens: I lighed med C i ACID skal alle noder i systemet ville til enhver tid have samme oversigt over dataene.

• Tilgængelighed: Systemet reagerer altid på anmodninger.

• Fordelingstolerance: Systemet forbliver online, hvis der opstår netværksproblemer mellem systemknudepunkter.

I den fælles landbrugspolitiks sætning hedder det, at arkitekter i udvalgte netværkssystemer skal vælge to af disse tre garantier - du kan ikke love dine brugere alle tre. Det efterlader dig de tre viste muligheder:

• Systemer, der bruger traditionelle relationsteknologier er normalt ikke partitionstolerante, så de kan garantere sammenhæng og tilgængelighed. Kort sagt, hvis en del af disse traditionelle relationelle teknologisystemer er offline, er hele systemet offline.

• Systemer hvor partitionstolerance og tilgængelighed er af største vigtighed kan ikke garantere konsistens, fordi opdateringer (den ødelægger af konsistens) kan laves på hver side af partitionen. Nøgleværdien lagrer Dynamo og CouchDB, og kolonnebutikken Cassandra er populære eksempler på partition tolerant / tilgængelighed (PA) systemer.

• Systemer hvor partitionstolerance og konsistens er af største vigtighed kan ikke garantere tilgængelighed, fordi systemerne returnerer fejl, indtil partitioneret tilstand er løst.

  Hadoop-baserede datalager betragtes som CP-systemer ( c onsistent og p artition tolerant). Med data lagret redundant på tværs af mange slave noder, kan udbrud til store dele (partitioner) af en Hadoop-klynge tolereres. Hadoop anses for at være konsekvent, fordi den har en central metadatabutik (NameNode), som opretholder en enkelt, konsistent visning af data, der er lagret i klyngen.