Văd multă confuzie cu privire la locul și scopul numeroaselor soluții de baze de date noi („baze de date NoSQL”) în comparație cu soluțiile de baze de date relaționale care există de mulți ani. Așadar, permiteți-mi să încerc să explic diferențele și cele mai bune cazuri de utilizare pentru fiecare dintre ele.
În primul rând, haideți să clarificăm aceste soluții de baze de date în două grupe:
1) Bazele de date relaționale, care pot fi numite și sisteme de gestionare a bazelor de date relaționale (RDBMS) sau baze de date SQL. Cele mai populare dintre acestea sunt Microsoft SQL Server, Oracle Database, MySQL și IBM DB2. Aceste RDBMS sunt utilizate în principal în scenariile marilor întreprinderi, cu excepția MySQL, care este utilizat în principal pentru a stoca date pentru aplicații web, de obicei ca parte a popularei stive LAMP (Linux, Apache, MySQL, PHP/ Python/ Perl).
2) Baze de date nerelaționale, numite și baze de date NoSQL, cele mai populare fiind MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis și Neo4j. Aceste baze de date sunt, de obicei, grupate în patru categorii: Key-value stores, Graph stores, Column stores și Document stores (a se vedea Tipuri de baze de date NoSQL).
Toate bazele de date relaționale pot fi utilizate pentru a gestiona aplicații orientate spre tranzacții (OLTP), iar majoritatea bazelor de date non-relaționale care se află în categoriile Document stores și Column stores pot fi, de asemenea, utilizate pentru OLTP, ceea ce sporește confuzia. Bazele de date OLTP pot fi considerate baze de date „operaționale”, caracterizate prin tranzacții frecvente, scurte, care includ actualizări și care ating o cantitate mică de date și în care concurența a mii de tranzacții este foarte importantă (exemple: aplicații bancare și rezervări online). Integritatea datelor este foarte importantă, astfel încât acestea suportă tranzacții ACID (Atomicitate, Consistență, Izolare, Durabilitate). Acest lucru se opune depozitelor de date, care sunt considerate baze de date „analitice”, caracterizate prin interogări lungi și complexe, care ating o cantitate mare de date și necesită multe resurse. Actualizările sunt puțin frecvente. Un exemplu este analiza vânzărilor din ultimul an.
Bazele de date relaționale lucrează de obicei cu date structurate, în timp ce bazele de date nerelaționale lucrează de obicei cu date semistructurate (de exemplu, XML, JSON).
Să analizăm mai în detaliu fiecare grup:
Baze de date relaționale
O bază de date relațională este organizată pe baza modelului relațional al datelor, așa cum a fost propus de E.F. Codd în 1970. Acest model organizează datele în unul sau mai multe tabele (sau „relații”) de rânduri și coloane, cu o cheie unică pentru fiecare rând. În general, fiecare tip de entitate descrisă într-o bază de date are propriul său tabel, rândurile reprezentând instanțe ale acelui tip de entitate, iar coloanele reprezentând valorile atribuite instanței respective. Având în vedere că fiecare rând dintr-un tabel are propria cheie unică, rândurile dintr-un tabel pot fi legate de rânduri din alte tabele prin stocarea cheii unice a rândului cu care trebuie să fie legat (această cheie unică fiind cunoscută sub numele de „cheie străină”). Codd a arătat că relații de date de o complexitate arbitrară pot fi reprezentate folosind acest set simplu de concepte.
Principal toate sistemele de baze de date relaționale folosesc SQL (Structured Query Language) ca limbaj de interogare și întreținere a bazei de date.
Motive pentru dominația bazelor de date relaționale sunt: simplitatea, robustețea, flexibilitatea, performanța, scalabilitatea și compatibilitatea în gestionarea datelor generice.
Dar pentru a oferi toate acestea, bazele de date relaționale trebuie să fie incredibil de complexe din punct de vedere intern. De exemplu, o instrucțiune SELECT relativ simplă ar putea avea zeci de căi potențiale de execuție a unei interogări, pe care un optimizator de interogări le-ar evalua în momentul execuției. Toate acestea sunt ascunse utilizatorilor, dar sub capotă, RDBMS determină cel mai bun „plan de execuție” pentru a răspunde la cereri, folosind lucruri precum algoritmi bazați pe costuri.
Pentru bazele de date mari, în special cele utilizate pentru aplicații web, principala preocupare este scalabilitatea. Pe măsură ce tot mai multe aplicații sunt create în medii care au sarcini de lucru masive (de exemplu, Amazon), cerințele de scalabilitate ale acestora se pot schimba foarte repede și pot crește foarte mult. Bazele de date relaționale se scalează bine, dar, de obicei, numai atunci când această scalare are loc pe un singur server („scale-up”). Atunci când capacitatea acelui singur server este atinsă, trebuie să „scale-out” și să distribuiți această sarcină pe mai multe servere, trecând la așa-numita calcul distribuit. Acesta este momentul în care complexitatea bazelor de date relaționale începe să cauzeze probleme în ceea ce privește potențialul lor de scalare. Dacă încercați să vă extindeți la sute sau mii de servere, complexitatea devine copleșitoare. Caracteristicile care fac bazele de date relaționale atât de atrăgătoare sunt aceleași care, de asemenea, reduc drastic viabilitatea lor ca platforme pentru sisteme distribuite de mari dimensiuni.
Baze de date nerelaționale
O bază de date NoSQL oferă un mecanism de stocare și recuperare a datelor care este modelat prin alte mijloace decât relațiile tabelare utilizate în bazele de date relaționale.
Motivațiile pentru această abordare includ:
- Simplitatea proiectării. Faptul că nu trebuie să se confrunte cu „nepotrivirea de impedanță” dintre abordarea orientată pe obiecte pentru scrierea aplicațiilor și tabelele și rândurile bazate pe scheme ale unei baze de date relaționale. De exemplu, stocarea tuturor informațiilor despre comenzile clienților într-un singur document, spre deosebire de necesitatea de a îmbina mai multe tabele, ceea ce duce la mai puțin cod de scris, depanat și întreținut
- O mai bună scalare „orizontală” la clustere de mașini, ceea ce rezolvă problema atunci când numărul de utilizatori simultani crește vertiginos pentru aplicațiile care sunt accesibile prin intermediul web și al dispozitivelor mobile. Utilizarea documentelor face mult mai ușoară extinderea, deoarece toate informațiile pentru comanda acelui client sunt cuprinse într-un singur loc, spre deosebire de a fi răspândite în mai multe tabele. Bazele de date NoSQL distribuie automat datele pe servere fără a necesita modificări ale aplicației (auto-sharding), ceea ce înseamnă că acestea distribuie în mod nativ și automat datele pe un număr arbitrar de servere, fără ca aplicația să fie conștientă de componența grupului de servere. Datele și sarcina de interogare sunt echilibrate automat între servere, iar atunci când un server cade, acesta poate fi înlocuit rapid și transparent, fără întreruperea aplicației
- Control mai fin asupra disponibilității. Serverele pot fi adăugate sau eliminate fără ca aplicația să fie oprită. Majoritatea bazelor de date NoSQL suportă replicarea datelor, stocând mai multe copii ale datelor în cluster sau chiar în mai multe centre de date, pentru a asigura o disponibilitate ridicată și recuperarea în caz de dezastru
- Pentru a capta cu ușurință toate tipurile de date „Big Data”, care includ date nestructurate și semistructurate. Permițând o bază de date flexibilă care poate găzdui cu ușurință și rapid orice nou tip de date și nu este perturbată de modificările structurii conținutului. Acest lucru se datorează faptului că baza de date de documente este lipsită de schemă, ceea ce vă permite să adăugați în mod liber câmpuri la documentele JSON fără a fi nevoie să definiți mai întâi modificările (schema-on-read în loc de schema-on-write). Puteți avea documente cu un număr diferit de câmpuri față de alte documente. De exemplu, o fișă de pacient care poate să conțină sau nu câmpuri care enumeră alergiile
- Speed. Structurile de date utilizate de bazele de date NoSQL (de exemplu, documentele JSON) diferă de cele utilizate în mod implicit în bazele de date relaționale, ceea ce face ca multe operații să fie mai rapide în NoSQL decât în bazele de date relaționale datorită faptului că nu trebuie să se unească tabelele (cu prețul creșterii spațiului de stocare din cauza duplicării datelor – dar spațiul de stocare este atât de ieftin în zilele noastre încât, de obicei, acest lucru nu reprezintă o problemă). De fapt, majoritatea bazelor de date NoSQL nici măcar nu acceptă îmbinările
- Cost. Bazele de date NoSQL utilizează, de obicei, clustere de servere de bază ieftine, în timp ce RDBMS tind să se bazeze pe servere și sisteme de stocare proprietare costisitoare. De asemenea, licențele pentru sistemele RDBMS pot fi destul de costisitoare, în timp ce multe baze de date NoSQL sunt open source și, prin urmare, gratuite
Adecvarea particulară a unei anumite baze de date NoSQL depinde de problema pe care trebuie să o rezolve.
Bazele de date NoSQL sunt din ce în ce mai mult utilizate în aplicațiile web de date mari și în timp real. Ele au devenit populare odată cu introducerea web-ului, când bazele de date au trecut de la un maxim de câteva sute de utilizatori pe o aplicație internă a companiei la mii sau milioane de utilizatori pe o aplicație web. Sistemele NoSQL sunt, de asemenea, denumite „Not only SQL” pentru a sublinia faptul că ele pot suporta și limbaje de interogare de tip SQL.
Multe magazine NoSQL compromit consistența (în sensul teoremei CAP) în favoarea disponibilității și toleranței la partiții. Printre motivele care blochează adoptarea magazinelor NoSQL se numără utilizarea unor limbaje de interogare de nivel scăzut, lipsa interfețelor standardizate și investițiile uriașe în SQL existent. De asemenea, majoritatea depozitelor NoSQL nu dispun de tranzacții ACID reale sau acceptă tranzacții doar în anumite circumstanțe și la anumite niveluri (de exemplu, la nivel de document). În cele din urmă, RDBMS sunt, de obicei, mult mai simplu de utilizat, deoarece au interfețe grafice, în timp ce multe soluții NoSQL folosesc o interfață de linie de comandă.
Compararea celor două
Una dintre cele mai severe limitări ale bazelor de date relaționale este că fiecare element poate conține doar un singur atribut. Dacă folosim exemplul unei bănci, fiecare aspect al relației unui client cu o bancă este stocat ca elemente de rânduri separate în tabele separate. Astfel, detaliile de bază ale clientului se află într-un tabel, detaliile contului în alt tabel, detaliile împrumutului în alt tabel, investițiile într-un alt tabel și așa mai departe. Toate aceste tabele sunt legate între ele prin utilizarea unor relații, cum ar fi cheile primare și cheile străine.
Bazele de date nerelaționale, în special magazinele cheie-valoare sau perechile cheie-valoare ale unei baze de date, sunt radical diferite de acest model. Perechile cheie-valoare vă permit să stocați mai multe elemente legate între ele într-un singur „rând” de date din același tabel. Punem cuvântul „rând” între ghilimele pentru că un rând aici nu este cu adevărat același lucru cu rândul dintr-un tabel relațional. De exemplu, într-un tabel nerelațional pentru aceeași bancă, fiecare rând ar conține detaliile clientului, precum și detaliile contului, ale împrumutului și ale investiției acestuia. Toate datele referitoare la un client ar fi în mod convenabil stocate împreună ca o singură înregistrare.
Aceasta pare o metodă evident superioară de stocare a datelor, dar are un dezavantaj major: magazinele cu valori cheie, spre deosebire de bazele de date relaționale, nu pot impune relații între elementele de date. De exemplu, în baza noastră de date cheie-valoare, detaliile clientului (numele, securitatea socială, adresa, numărul de cont, numărul de procesare a împrumutului etc.) ar fi toate stocate ca o singură înregistrare de date (în loc să fie stocate în mai multe tabele, ca în modelul relațional). Tranzacțiile clientului (retrageri din cont, depuneri în cont, rambursări de împrumuturi, comisioane bancare etc.) ar fi, de asemenea, stocate ca o altă înregistrare unică de date.
În modelul relațional, există o metodă încorporată și infailibilă de a asigura și de a aplica logica și regulile de afaceri la nivelul bazei de date, de exemplu, că o retragere este imputată în contul bancar corect, prin chei primare și chei străine. În cazul magazinelor de tip cheie-valoare, această responsabilitate revine în mod direct logicii aplicației și mulți oameni se simt foarte inconfortabil să lase această responsabilitate crucială doar în seama aplicației. Acesta este unul dintre motivele pentru care bazele de date relaționale vor continua să fie utilizate.
Cu toate acestea, atunci când vine vorba de aplicații bazate pe web care utilizează baze de date, aspectul aplicării riguroase a logicii de afaceri nu este adesea o prioritate de top. Prioritatea cea mai mare este capacitatea de a deservi un număr mare de solicitări ale utilizatorilor, care sunt de obicei interogări doar de citire. De exemplu, pe un site precum eBay, majoritatea utilizatorilor pur și simplu navighează și se uită prin articolele postate (operații doar de citire). Doar o mică parte dintre acești utilizatori plasează efectiv oferte sau rezervă articolele (operațiuni de citire-scriere). Și nu uitați că este vorba de milioane, uneori miliarde, de vizualizări de pagini pe zi. Administratorii site-ului eBay sunt mai interesați de un timp de răspuns rapid pentru a asigura o încărcare mai rapidă a paginilor pentru utilizatorii site-ului, decât de prioritățile tradiționale de aplicare a regulilor de afaceri sau de asigurare a unui echilibru între citire și scriere.
Bazele de date cu model relațional pot fi ajustate și configurate pentru a rula operațiuni de citire la scară largă prin intermediul depozitării de date și, astfel, pot deservi potențial un număr mare de utilizatori care interoghează o cantitate mare de date, în special atunci când se utilizează arhitecturi MPP relaționale precum Analytics Platform System, Teradata, Oracle Exadata sau IBM Netezza, care toate suportă scalarea. După cum s-a menționat anterior, depozitele de date se deosebesc de bazele de date tipice prin faptul că sunt utilizate pentru o analiză mai complexă a datelor. Acest lucru diferă de baza de date tranzacțională (OLTP), a cărei utilizare principală este de a sprijini sistemele operaționale și de a oferi raportare zilnică, la scară mică.
Cu toate acestea, adevărata provocare este lipsa de scalabilitate a modelului relațional atunci când are de-a face cu aplicații OLTP, sau cu orice soluție cu multe scrieri individuale, care este domeniul arhitecturilor SMP relaționale. Acesta este punctul în care modelele non-relaționale pot străluci cu adevărat. Acestea pot distribui cu ușurință sarcinile de date pe zeci, sute și, în cazuri extreme (gândiți-vă la căutarea Google), chiar mii de servere. Având în vedere că fiecare server gestionează doar un mic procent din totalul cererilor din partea utilizatorilor, timpul de răspuns este foarte bun pentru fiecare utilizator în parte. Deși acest model de calcul distribuit poate fi construit pentru bazele de date relaționale, este foarte greu de implementat, în special atunci când există multe scrieri (adică OLTP), necesitând tehnici precum sharding, care necesită de obicei o codificare semnificativă în afara logicii de afaceri a aplicației. Acest lucru se datorează faptului că modelul relațional insistă asupra integrității datelor la toate nivelurile, care trebuie menținută, chiar și atunci când datele sunt accesate și modificate de mai multe servere diferite. Acesta este motivul pentru care modelul non-relațional este arhitectura aleasă pentru aplicațiile web, cum ar fi cloud-computing și rețelele sociale.
Acum, pe scurt, RDBMS-urile suferă din cauza lipsei de scalare orizontală pentru sarcini mari de tranzacționare (milioane de citiri-scrieri), în timp ce bazele de date NoSQL rezolvă sarcinile mari de tranzacționare, dar cu prețul integrității datelor și al îmbinărilor.
Rețineți că multe soluții vor folosi o combinație de baze de date relaționale și non-relaționale (a se vedea Ce este persistența poliglotă?).
Rețineți, de asemenea, că s-ar putea să nu aveți nevoie de performanța unei baze de date nerelaționale și, în schimb, să mergeți doar cu stocarea fișierelor în HDFS și utilizarea Apache Hive va fi suficientă (Apache Hive este o infrastructură de depozit de date construită pe Hadoop pentru a furniza rezumarea, interogarea și analiza datelor pe care le oferă prin intermediul unui limbaj de tip SQL numit HiveQL).
Și pentru a încheia într-o notă care adaugă la confuzie, avem o altă categorie în formare numită NewSQL: NewSQL este o clasă de RDBMS moderne care încearcă să ofere aceeași performanță scalabilă a sistemelor NoSQL pentru sarcinile de lucru OLTP de citire-scriere, menținând în același timp garanțiile ACID ale unui sistem tradițional de baze de date relaționale. Dezavantajele sunt că nu sunt destinate interogărilor de tip OLAP și nu sunt adecvate pentru baze de date de peste câțiva terabytes. Printre exemple se numără VoltDB, NuoDB, MemSQL, SAP HANA, Splice Machine, Clustrix și Altibase.
O imagine care arată categoriile în care se încadrează multe dintre produse:
Un grafic excelent care arată cum se încadrează toate tehnologiile în cloud-ul Azure este cel din Understanding NoSQL on Microsoft Azure:
Sfârșitul pentru utilizarea unei soluții NoSQL este dacă aveți o aplicație OLTP care are mii de utilizatori și are o bază de date foarte mare care necesită o soluție scale-out și/sau utilizează date JSON, în special dacă aceste date JSON au diverse structuri. De asemenea, aveți avantajul unei disponibilități ridicate, deoarece soluțiile NoSQL stochează mai multe copii ale datelor. Rețineți doar că pentru performanță este posibil să sacrificați consistența datelor, precum și capacitatea de a alătura date, de a utiliza SQL și de a face actualizări rapide în masă.
Mai multe informații:
MySQL vs MongoDB
MySQL vs MongoDB
MySQL vs MongoDB. MongoDB: Privind bazele de date relaționale și non-relaționale
10 lucruri pe care ar trebui să le știți despre bazele de date NoSQL
Introducere la bazele de date
Diferența dintre SQL și NoSQL : Comparație
Diferențele dintre bazele de date SQL și NoSQL explicate cu câteva exemple de baze de date
NoSQL, NewSQL sau RDBMS: How To Choose
NewSQL – RDBMS on Steroids
Baze de date NoSQL vs NewSQL Choose the Right Tool for the Right Job
SQL vs NoSQL: doriți să aveți în mod implicit o stocare relațională
Oracle apără bazele de date relaționale împotriva concurenților NoSQL
Înțelegerea NoSQL pe Microsoft Azure
Cunoașteți avangarda noilor baze de date relaționale
La SQL sau NoSQL? Aceasta este întrebarea bazelor de date
CAP Theorem: Revisited
Ce este cu adevărat nou cu NewSQL?
MongoDB vs MySQL: Un studiu comparativ asupra bazelor de date
Caracteristici și diferențe între bazele de date MySQL și NoSQL