ACID versus baze de date BASE - dummies

Un semn distinctiv al sistemelor de baze de date relaționale este ceva cunoscut sub numele de conformitatea cu ACID. După cum probabil ați ghicit, ACID este un acronim - literele individuale, destinate să descrie o caracteristică a tranzacțiilor individuale de baze de date, pot fi extinse așa cum este descris în această listă:

• Atomicitate: reuși sau eșuează complet. Succesul parțial nu este permis.

• Consistența: În timpul tranzacției bazei de date, RDBMS progresează de la o stare validă la alta. Statul nu este niciodată invalid.

• Izolarea: Tranzacția bazei de date a clientului trebuie să aibă loc separat de alți clienți care încearcă să efectueze tranzacții cu RDBMS.

• Durabilitate: Operațiunea de date care a făcut parte din tranzacție trebuie să se reflecte în stocarea nevolatilă (memorie a computerului care poate prelua informații stocate, chiar dacă nu este alimentată ca un hard disk) tranzacția este finalizată cu succes. Eșecurile tranzacției nu pot lăsa datele într-o stare parțial angajată.

Anumite cazuri de utilizare pentru RDBMS-uri, cum ar fi procesarea tranzacțiilor online, depind de tranzacțiile compatibile ACID între client și RDBMS pentru ca sistemul să funcționeze corect. Un exemplu excelent de tranzacție care respectă ACID este transferul de fonduri de la un cont bancar la altul.

Aceasta se împarte în două tranzacții baze de date, în care contul inițial indică o retragere, iar contul de destinație prezintă un depozit. Evident, aceste două tranzacții trebuie să fie legate între ele pentru a fi valabile, astfel încât, în cazul în care oricare dintre acestea eșuează, întreaga operațiune trebuie să nu reușească să asigure că ambele solduri rămân valabile.

Hadoop însăși nu are niciun concept de tranzacții (sau chiar înregistrări, de pildă), deci nu este în mod clar un sistem compatibil cu ACID. Gândindu-se în mod special la proiectele de stocare și prelucrare a datelor în întregul ecosistem Hadoop, niciuna dintre ele nu este compatibilă în întregime cu ACID. Cu toate acestea, acestea nu reflectă proprietățile pe care le vedeți adesea în magazinele de date NoSQL, deci există un precedent pentru abordarea Hadoop.

Un concept cheie în spatele depozitelor de date NoSQL este că nu fiecare aplicație are nevoie cu adevărat de tranzacții compatibile cu ACID. Relaxarea pe anumite proprietăți ACID (și îndepărtarea de modelul relațional) a deschis o multitudine de posibilități, care au permis unor magazine de date NoSQL să obțină o scalabilitate masivă și performanță pentru aplicațiile lor de nișă.

În timp ce ACID definește caracteristicile cheie necesare procesării fiabile a tranzacțiilor, lumea NoSQL necesită caracteristici diferite pentru a permite flexibilitate și scalabilitate.Aceste caracteristici opuse sunt capturate inteligent în acronimul BASE:

• B asical A valabil: Sistemul este garantat a fi disponibil pentru interogarea tuturor utilizatorilor. (Nu există nici o izolare aici)

• S State: Valorile stocate în sistem se pot schimba din cauza modelului eventual de consistență, după cum este descris în următoarea secțiune.

• E ventual Consistent: Pe masura ce datele sunt adaugate sistemului, starea sistemului este repetata treptat in toate nodurile. De exemplu, în Hadoop, atunci când un fișier este scris în HDFS, replicile blocurilor de date sunt create în noduri de date diferite după scrierea blocurilor de date originale. Pentru perioada scurtă înainte ca blocurile să fie reproduse, starea sistemului de fișiere nu este consecventă.

BASE-ul de acronime este puțin controversat, deoarece majoritatea magazinelor de date NoSQL nu abandonează complet toate caracteristicile ACID - cu alte cuvinte, nu este conceptul polar opus pe care îl presupune numele. De asemenea, caracteristicile Soft State și Eventually Consistent se ridică la același lucru, dar punctul este acela că, prin relaxarea consecvenței, sistemul poate să scadă orizontal (multe noduri) și să asigure disponibilitatea.

Nici o discuție despre NoSQL ar fi completă fără a menționa teorema CAP, care reprezintă cele trei tipuri de garanții pe care arhitecții urmăresc să le furnizeze în sistemele lor:

• Consistență: Similar cu C în ACID, toate nodurile sistemul ar avea aceeași viziune a datelor în orice moment.

• Disponibilitate: Sistemul răspunde întotdeauna la cereri.

• Toleranța partițiilor: Sistemul rămâne online dacă apar probleme de rețea între nodurile sistemului.

Teorema CAP afirmă că, în sistemele distribuite în rețea, arhitecții trebuie să aleagă două dintre aceste trei garanții - nu puteți promite utilizatorilor dvs. toate cele trei. Aceasta vă oferă trei posibilități:

• Sistemele care utilizează tehnologii relaționale tradiționale nu sunt în mod normal tolerante la partiție, astfel încât să poată garanta coerența și disponibilitatea. Pe scurt, dacă o parte a acestor sisteme tradiționale de tehnologii relaționale este offline, întregul sistem este offline.

• Sistemele în care toleranța partiționării și disponibilitatea sunt de o importanță primară nu pot garanta coerența, deoarece actualizările (acel distrugător de consistență) pot fi făcute pe ambele părți ale partiției. Valorile-cheie ale magazinelor Dynamo și CouchDB și magazinul Cassandra pentru coloane și familii sunt exemple populare de sisteme de toleranță a partiționării / disponibilității (PA).

• Sistemele în care toleranța partiționării și consistența au o importanță primară nu pot garanta disponibilitatea deoarece sistemele returnează erorile până când starea partiționată este rezolvată.

  Stocurile de date bazate pe Hadoop sunt considerate sisteme CP ( c onsistent și p tolerant la artiști). Datele stocate redundant pe multe noduri slave, pot fi tolerate întreruperi la porțiuni mari (partiții) ale unui cluster Hadoop. Hadoop este considerat consecvent deoarece are un magazin central de metadate (NameNode), care păstrează o vizualizare unică și consistentă a datelor stocate în cluster.