3.1. Proprietăți ACIDE slabe
Pentru o lungă perioadă de timp, consistența datelor a fost o vaca sacră pentru arhitecți și dezvoltatori. Toate bazele de date relaționale au oferit un anumit nivel de izolare, fie prin blocarea actualizării și blocarea citirilor, fie prin jurnalele de anulare. Odată cu apariția unor cantități uriașe de informații și a sistemelor distribuite, a devenit clar că era imposibil să se asigure un set tranzacțional de operațiuni pentru aceștia, pe de o parte, și să se obțină disponibilitate ridicată și timp de răspuns rapid, pe de altă parte.
Mai mult, chiar și actualizarea unei înregistrări nu garantează că orice alt utilizator va vedea instantaneu modificări în sistem, deoarece modificarea poate avea loc, de exemplu, în nodul master, iar replica este copiată asincron în nodul slave, cu care un alt utilizator. lucrări. În acest caz, el va vedea rezultatul după o anumită perioadă de timp. Aceasta se numește eventual consistență și la asta se îndreaptă acum toate cele mai mari companii de internet din lume, inclusiv Facebook și Amazon. Aceștia din urmă declară cu mândrie că intervalul maxim în care utilizatorul poate vedea date inconsistente nu este mai mare de o secundă. Un exemplu de astfel de situație este prezentat în figură:
Întrebarea logică care se pune într-o astfel de situație este ce să faci cu sistemele care impun în mod clasic cerințe mari asupra atomicității-coerenței operațiunilor și, în același timp, au nevoie de clustere distribuite rapid - financiare, magazine online etc.? Practica arată că aceste cerințe nu mai sunt relevante: iată ce a spus un designer al sistemului financiar bancar: „Dacă am aștepta cu adevărat finalizarea fiecărei tranzacții în rețeaua globală de bancomate (ATM-uri), tranzacțiile ar dura atât de mult încât clienții ar fugi de furie. Ce se întâmplă dacă tu și partenerul tău retrageți bani în același timp și depășiți limita? „Veți primi amândoi banii, iar noi îi vom remedia mai târziu.”
Un alt exemplu este rezervarea la hotel prezentată în imagine. Magazinele online a căror politică de date presupune o eventuală consecvență sunt obligate să ofere măsuri în cazul unor astfel de situații (rezolvarea automată a conflictelor, rollback operațional, actualizare cu alte date). În practică, hotelurile încearcă întotdeauna să păstreze un „pool” de camere libere în caz de urgență, iar aceasta poate fi o soluție la o situație controversată.
De fapt, proprietățile ACID slabe nu înseamnă că nu există deloc. În cele mai multe cazuri, o aplicație care lucrează cu o bază de date relațională folosește o tranzacție pentru a schimba obiecte legate logic (comandă - articole de comandă), ceea ce este necesar, deoarece acestea sunt tabele diferite. Cu proiectarea corectă a modelului de date într-o bază de date NoSQL (un agregat este o comandă împreună cu o listă de articole de comandă), puteți obține același nivel de izolare atunci când schimbați o singură înregistrare ca într-o bază de date relațională.
3.2. Sisteme distribuite, fără resurse partajate (nu partajați nimic)
Din nou, acest lucru nu se aplică graficelor bazelor de date, a căror structură, prin definiție, nu se răspândește bine în nodurile îndepărtate.
Acesta este poate principalul laitmotiv al dezvoltării bazelor de date NoSQL. Odată cu creșterea avalanșă a informațiilor în lume și nevoia de a le procesa într-un timp rezonabil, a apărut problema scalabilității verticale - creșterea vitezei procesorului s-a oprit la 3,5 GHz, viteza de citire de pe disc crește, de asemenea, la un ritm lent, plus prețul unui server puternic este întotdeauna mai mult decât prețul total al mai multor servere simple. În această situație, bazele de date relaționale convenționale, chiar și grupate pe o serie de discuri, nu sunt capabile să rezolve problema vitezei, scalabilității și debitului.
Singura cale de ieșire din situație este scalarea orizontală, când mai multe servere independente sunt conectate printr-o rețea rapidă și fiecare deține/procesează doar o parte din date și/sau doar o parte din solicitările de citire-actualizare. În această arhitectură, pentru a crește capacitatea de stocare (capacitate, timp de răspuns, debit), trebuie doar să adăugați un nou server la cluster - și atât. Sharding, replicare, fault tolerance (rezultatul va fi obtinut chiar daca unul sau mai multe servere nu mai raspunde), redistribuirea datelor in cazul adaugarii unui nod se ocupa chiar de baza de date NoSQL.
Voi prezenta pe scurt principalele proprietăți ale bazelor de date NoSQL distribuite:
Replicare - copierea datelor în alte noduri la actualizare. Permite ambele să obțină o scalabilitate mai mare și să crească disponibilitatea și siguranța datelor. Se obișnuiește să se subdivizeze în două tipuri:
master-slave :
și peer-to-peer : 
Primul tip presupune o scalabilitate bună pentru citire (se poate întâmpla de la orice nod), dar scrierea nescalabilă (doar către nodul principal). Există, de asemenea, subtilități cu asigurarea disponibilității constante (în cazul unui accident principal, fie manual, fie automat, unul dintre nodurile rămase este alocat la locul său). Al doilea tip de replicare presupune că toate nodurile sunt egale și pot servi atât cereri de citire, cât și de scriere.
Sharding este împărțirea datelor pe noduri:
Sharding a fost adesea folosit ca o „cârjă” pentru bazele de date relaționale pentru a crește viteza și debitul: aplicația utilizator a partiționat datele în mai multe baze de date independente și, atunci când utilizatorul a solicitat datele corespunzătoare, a accesat o anumită bază de date. În bazele de date NoSQL, sharding-ul, ca și replicarea, se face automat de baza de date însăși, iar aplicația utilizator este separată de aceste mecanisme complexe.
3.3. Bazele de date NoSQL sunt în mare parte open source și create în secolul 21
Pe al doilea motiv, Sadalaj și Fowler nu au clasificat bazele de date cu obiecte ca NoSQL (deși http://nosql-database.org/ le include în lista generală), deoarece au fost create în anii 90 și nu au câștigat niciodată prea multă popularitate. . .
Mișcarea NoSQL câștigă popularitate într-un ritm gigantic. Cu toate acestea, acest lucru nu înseamnă că bazele de date relaționale devin vestigiale sau ceva arhaice. Cel mai probabil vor fi folosite și folosite ca înainte în mod activ, dar tot mai multe baze de date NoSQL vor acționa în simbioză cu ele. Intrăm într-o eră a persistenței poligloților, o eră în care diferite depozite de date sunt folosite pentru nevoi diferite. Acum nu există monopolul bazelor de date relaționale ca sursă de date necontestată. Din ce în ce mai mult, arhitecții aleg stocarea în funcție de natura datelor în sine și de modul în care vrem să le manipulăm, de ce volume de informații sunt așteptate. Și astfel totul devine mai interesant.
Mai jos vom încerca să înțelegem funcționarea unei baze de date distribuite folosind SGBD-ul NoSQL Cassandra ca exemplu...