Ghidul definitiv pentru bazele de date NoSQL

Nu există nicio îndoială că modul în care aplicațiile web tratează datele s-a schimbat semnificativ în ultimul deceniu. Se colectează mai multe date și mai mulți utilizatori accesează aceste date simultan decât oricând. Aceasta înseamnă că scalabilitatea și performanța reprezintă o provocare mai mult decât oricând pentru bazele de date relaționale care sunt bazate pe scheme și, prin urmare, pot fi mai greu de scalat.

Evoluția NoSQL

Problema scalabilității SQL a fost recunoscută de companiile Web 2.0 cu nevoi uriașe de date și infrastructură, cum ar fi Google, Amazon și Facebook. Au venit cu propriile soluții la problemă - tehnologii precum BigTable, DynamoDB și Cassandra.

Acest interes în creștere a dus la o serie de sisteme de management al bazelor de date NoSQL (DBMS), cu accent pe performanță, fiabilitate și coerență. Un număr de structuri de indexare existente au fost reutilizate și îmbunătățite cu scopul de a îmbunătăți performanța de căutare și citire.

În primul rând, au existat tipuri de baze de date NoSQL proprietare (sursă închisă) dezvoltate de marile companii pentru a satisface nevoile lor specifice, cum ar fi BigTable de la Google, despre care se crede că este primul sistem NoSQL, și DynamoDB de la Amazon.

Succesul acestor sisteme proprietare a inițiat dezvoltarea unui număr de sisteme similare de baze de date open-source și proprietare, cele mai populare fiind Hypertable, Cassandra, MongoDB, DynamoDB, HBase și Redis.

Ce face NoSQL diferit?

O diferență cheie între bazele de date NoSQL și bazele de date relaționale tradiționale este faptul că NoSQL este o formă de stocare nestructurată .

Aceasta înseamnă că bazele de date NoSQL nu au o structură de tabel fixă ​​precum cele găsite în bazele de date relaționale.

Avantajele și dezavantajele bazelor de date NoSQL

Avantaje

Bazele de date NoSQL au multe avantaje în comparație cu bazele de date tradiționale, relaționale.

O diferență majoră, de bază, este că bazele de date NoSQL au o structură simplă și flexibilă. Sunt fără schemă.

Spre deosebire de bazele de date relaționale, bazele de date NoSQL se bazează pe perechi cheie-valoare.

Unele tipuri de stocare ale bazelor de date NoSQL includ depozit de coloane, depozit de documente, depozit de valori cheie, depozit de grafice, depozit de obiecte, depozit XML și alte moduri de stocare de date.

De obicei, fiecare valoare din baza de date are o cheie. Unele magazine de baze de date NoSQL permit dezvoltatorilor să stocheze obiecte seriate în baza de date, nu doar simple valori de șir.

Bazele de date NoSQL open-source nu necesită taxe costisitoare de licențiere și pot rula pe hardware ieftin, făcând implementarea lor rentabilă.

De asemenea, atunci când lucrați cu baze de date NoSQL, fie că sunt open-source sau proprietare, extinderea este mai ușoară și mai ieftină decât atunci când lucrați cu baze de date relaționale. Acest lucru se datorează faptului că se realizează prin scalarea orizontală și distribuția sarcinii pe toate nodurile, mai degrabă decât tipul de scalare verticală care se face de obicei cu sistemele de baze de date relaționale, care înlocuiește gazda principală cu una mai puternică.

Dezavantaje

Desigur, bazele de date NoSQL nu sunt perfecte și nu sunt întotdeauna alegerea potrivită.

În primul rând, majoritatea bazelor de date NoSQL nu acceptă caracteristici de fiabilitate care sunt suportate nativ de sistemele de baze de date relaționale. Aceste caracteristici de fiabilitate pot fi rezumate ca atomicitate, consistență, izolare și durabilitate. Aceasta înseamnă, de asemenea, că bazele de date NoSQL, care nu acceptă aceste caracteristici, schimbă consistența pentru performanță și scalabilitate.

Pentru a sprijini caracteristicile de fiabilitate și coerență, dezvoltatorii trebuie să implementeze propriul cod proprietar, ceea ce adaugă mai multă complexitate sistemului.

Acest lucru ar putea limita numărul de aplicații care se pot baza pe baze de date NoSQL pentru tranzacții sigure și de încredere, cum ar fi sistemele bancare.

Alte forme de complexitate găsite în majoritatea bazelor de date NoSQL includ incompatibilitatea cu interogările SQL. Aceasta înseamnă că este nevoie de un limbaj de interogare manual sau proprietar, adăugând și mai mult timp și complexitate.

NoSQL vs baze de date relaționale

Acest tabel oferă o scurtă comparație a caracteristicilor dintre NoSQL și bazele de date relaționale:

Trebuie remarcat faptul că tabelul prezintă o comparație la nivel de bază de date , nu diferitele sisteme de gestionare a bazelor de date care implementează ambele modele. Aceste sisteme oferă propriile tehnici proprii pentru a depăși unele dintre problemele și deficiențele ambelor sisteme și, în unele cazuri, îmbunătățesc semnificativ performanța și fiabilitatea.

Tipuri de depozit de date NoSQL

Magazin valori cheie

În tipul de magazin Key Value, este folosit un tabel hash în care o cheie unică indică un articol.

Cheile pot fi organizate în grupuri logice de chei, necesitând doar ca cheile să fie unice în cadrul propriului grup. Acest lucru permite chei identice în grupuri logice diferite. Următorul tabel prezintă un exemplu de magazin cheie-valoare, în care cheia este numele orașului, iar valoarea este adresa pentru Universitatea Ulster din acel oraș.

Unele implementări ale stocului de valori cheie oferă mecanisme de stocare în cache, care le îmbunătățesc foarte mult performanța.

Tot ceea ce este necesar pentru a face față articolelor stocate în baza de date este cheia. Datele sunt stocate sub formă de șir, JSON sau BLOB (Obiect Binar Mare).

Unul dintre cele mai mari defecte ale acestei forme de bază de date este lipsa de consistență la nivel de bază de date. Acest lucru poate fi adăugat de către dezvoltatori cu propriul lor cod, dar așa cum am menționat anterior, acest lucru adaugă mai mult efort, complexitate și timp.

Cea mai faimoasă bază de date NoSQL care este construită pe un magazin de valori cheie este DynamoDB de la Amazon.

Magazin de documente

Depozitele de documente sunt similare cu depozitele de valori cheie prin faptul că sunt fără schemă și se bazează pe un model cheie-valoare. Prin urmare, ambele au multe dintre aceleași avantaje și dezavantaje. Ambelor le lipsește consistența la nivelul bazei de date, ceea ce face loc aplicațiilor pentru a oferi mai multe caracteristici de fiabilitate și consecvență.

Există totuși diferențe cheie între cele două.

În Document Stores, valorile (documentele) furnizează codificarea datelor stocate. Aceste codificări pot fi XML, JSON sau BSON (JSON codificat binar).

De asemenea, se pot face interogări bazate pe date.

Cea mai populară aplicație de bază de date care se bazează pe un Magazin de documente este MongoDB.

Magazin de coloane

Într-o bază de date Column Store, datele sunt stocate în coloane, spre deosebire de a fi stocate în rânduri, așa cum se face în majoritatea sistemelor de gestionare a bazelor de date relaționale.

Un depozit de coloane este format din una sau mai multe familii de coloane care grupează în mod logic anumite coloane din baza de date. O cheie este utilizată pentru a identifica și indica un număr de coloane din baza de date, cu un atribut keyspace care definește domeniul de aplicare al acestei chei. Fiecare coloană conține tupluri de nume și valori, ordonate și separate prin virgulă.

Column Stores au acces rapid de citire/scriere la datele stocate. Într-un depozit de coloane, rândurile care corespund unei singure coloane sunt stocate ca o singură intrare pe disc. Acest lucru asigură un acces mai rapid în timpul operațiunilor de citire/scriere.

Cele mai populare baze de date care folosesc magazinul de coloane includ BigTable, HBase și Cassandra de la Google.

Baza graficului

Într-o bază de date Graph Base NoSQL, este utilizată o structură grafică direcționată pentru a reprezenta datele. Graficul este format din muchii și noduri.

Formal, un grafic este o reprezentare a unui set de obiecte, unde unele perechi de obiecte sunt conectate prin legături. Obiectele interconectate sunt reprezentate prin abstracții matematice, numite vârfuri, iar legăturile care leagă unele perechi de vârfuri se numesc muchii. Un set de vârfuri și muchiile care le leagă se spune că sunt un grafic.

Aceasta ilustrează structura unei baze de date de bază de graf care utilizează margini și noduri pentru a reprezenta și stoca date. Aceste noduri sunt organizate prin unele relații între ele, care sunt reprezentate de muchii dintre noduri. Atât nodurile, cât și relațiile au unele proprietăți definite.

Bazele de date grafice sunt cele mai utilizate în aplicațiile de rețele sociale. Bazele de date grafice permit dezvoltatorilor să se concentreze mai mult pe relațiile dintre obiecte decât pe obiectele în sine. În acest context, ele permit într-adevăr un mediu scalabil și ușor de utilizat.

În prezent, InfoGrid și InfiniteGraph sunt cele mai populare baze de date grafice.

Sisteme de gestionare a bazelor de date NoSQL

Pentru o comparație scurtă a bazelor de date, următorul tabel oferă o comparație scurtă între diferitele sisteme de gestionare a bazelor de date NoSQL.

MongoDB are o schemă de stocare flexibilă, ceea ce înseamnă că obiectele stocate nu trebuie neapărat să aibă aceeași structură sau câmpuri. MongoDB are, de asemenea, unele funcții de optimizare, care distribuie colecțiile de date, rezultând o îmbunătățire generală a performanței și un sistem mai echilibrat.

Alte sisteme de baze de date NoSQL, cum ar fi Apache CouchDB, sunt, de asemenea, baze de date de tip magazin de documente și partajează o mulțime de caracteristici cu MongoDB, cu excepția că baza de date poate fi accesată folosind API-urile RESTful.

REST este un stil arhitectural care constă dintr-un set coordonat de constrângeri arhitecturale aplicate componentelor, conectorilor și elementelor de date, în World Wide Web. Se bazează pe un protocol de comunicații fără stat, client-server, stocabil în cache (de exemplu, protocolul HTTP).

Aplicațiile RESTful folosesc solicitări HTTP pentru a posta, a citi date și a șterge date.

În ceea ce privește bazele de date pe coloane, Hypertable este o bază de date NoSQL scrisă în C++ și se bazează pe BigTable de la Google.

Hypertable acceptă distribuirea depozitelor de date între noduri pentru a maximiza scalabilitatea, la fel ca MongoDB și CouchDB.

Una dintre cele mai utilizate baze de date NoSQL este Cassandra, dezvoltată de Facebook.

Cassandra este o bază de date a magazinului de coloane care include o mulțime de caracteristici care vizează fiabilitatea și toleranța la erori.

În loc să ofere o privire aprofundată asupra fiecărui DBMS NoSQL, Cassandra și MongoDB, două dintre cele mai utilizate sisteme de gestionare a bazelor de date NoSQL, vor fi explorate în următoarele subsecțiuni.

Cassandra

Cassandra este un sistem de gestionare a bazelor de date dezvoltat de Facebook.

Scopul din spatele Cassandra a fost de a crea un DBMS care nu are un singur punct de eșec și oferă disponibilitate maximă.

Cassandra este în mare parte o bază de date a magazinului de coloane. Unele studii s-au referit la Cassandra ca fiind un sistem hibrid, inspirat de BigTable de la Google, care este o bază de date a magazinului de coloane, și DynamoDB de la Amazon, care este o bază de date cheie-valoare.

Acest lucru se realizează prin furnizarea unui sistem cheie-valoare, dar cheile din Cassandra indică un set de familii de coloane, bazându-se pe sistemul de fișiere distribuit BigTable de la Google și pe caracteristicile de disponibilitate ale Dynamo (tabel hash distribuit).

Cassandra este concepută pentru a stoca cantități uriașe de date distribuite pe diferite noduri. Cassandra este un DBMS conceput pentru a gestiona cantități masive de date, răspândite pe mai multe servere, oferind în același timp un serviciu de înaltă disponibilitate, fără un singur punct de eșec, ceea ce este esențial pentru un serviciu mare precum Facebook.

Principalele caracteristici ale Cassandrei includ:

• Nici un singur punct de eșec. Pentru ca acest lucru să fie realizat, Cassandra trebuie să ruleze pe un grup de noduri, mai degrabă decât pe o singură mașină. Asta nu înseamnă că datele de pe fiecare cluster sunt aceleași, dar software-ul de management este. Când are loc o defecțiune într-unul dintre noduri, datele de pe acel nod vor fi inaccesibile. Cu toate acestea, alte noduri (și date) vor fi în continuare accesibile.
• Distributed Hashing este o schemă care oferă funcționalitate tabelă hash într-un mod în care adăugarea sau eliminarea unui slot nu schimbă semnificativ maparea cheilor la sloturi. Acest lucru oferă capacitatea de a distribui sarcina către servere sau noduri în funcție de capacitatea acestora și, la rândul său, de a minimiza timpul de nefuncționare.
• Interfață client relativ ușor de utilizat . Cassandra folosește Apache Thrift pentru interfața sa client. Apache Thrift oferă un client RPC în mai multe limbi, dar majoritatea dezvoltatorilor preferă alternative open-source construite pe Apple Thrift, cum ar fi Hector.
• Alte caracteristici de disponibilitate. Una dintre caracteristicile Cassandrei este replicarea datelor. Practic, oglindește datele către alte noduri din cluster. Replicarea poate fi aleatorie sau specifică pentru a maximiza protecția datelor prin plasarea într-un nod într-un alt centru de date, de exemplu. O altă caracteristică găsită în Cassandra este politica de partiționare. Politica de partiționare decide unde pe ce nod să plaseze cheia. Acest lucru poate fi, de asemenea, aleatoriu sau în ordine. Când se utilizează ambele tipuri de politici de partiționare, Cassandra poate găsi un echilibru între echilibrarea încărcării și optimizarea performanței interogărilor.
• Consecvență. Caracteristici precum replicarea fac coerența dificilă. Acest lucru se datorează faptului că toate nodurile trebuie să fie actualizate în orice moment cu cele mai recente valori sau în momentul în care este declanșată o operație de citire. În cele din urmă, însă, Cassandra încearcă să mențină un echilibru între acțiunile de replicare și acțiunile de citire/scriere, oferind dezvoltatorului această posibilitate de personalizare.
• Acțiuni de citire/scriere. Clientul trimite o solicitare unui singur nod Cassandra. Nodul, conform politicii de replicare, stochează datele în cluster. Fiecare nod efectuează mai întâi modificarea datelor în jurnalul de comitere, apoi actualizează structura tabelului cu modificarea, ambele efectuate sincron. Operația de citire este de asemenea foarte asemănătoare, o solicitare de citire este trimisă unui singur nod, iar acel singur nod este cel care determină ce nod deține datele, conform politicii de partiționare/plasare.

MongoDB

MongoDB este o bază de date fără schemă, orientată spre documente, scrisă în C++. Baza de date se bazează pe depozitul de documente, ceea ce înseamnă că stochează valori (denumite documente) sub formă de date codificate.

Alegerea formatului codificat în MongoDB este JSON. Acest lucru este puternic, deoarece, chiar dacă datele sunt imbricate în documente JSON, vor fi în continuare interogabile și indexabile .

Subsecțiunile care urmează descriu unele dintre caracteristicile cheie disponibile în MongoDB.

cioburi

Sharding este partiţionarea şi distribuirea datelor pe mai multe maşini (noduri). Un shard este o colecție de noduri MongoDB, spre deosebire de Cassandra, unde nodurile sunt distribuite simetric. Utilizarea fragmentelor înseamnă, de asemenea, capacitatea de a scala orizontal pe mai multe noduri. În cazul în care există o aplicație care utilizează un singur server de bază de date, aceasta poate fi convertită în cluster sharded cu foarte puține modificări la codul original al aplicației, deoarece modul în care sharding-ul este realizat de MongoDB. software-ul este aproape complet decuplat de API-urile publice expuse la nivelul clientului.

Limbajul de interogare Mongo

După cum sa discutat mai devreme, MongoDB folosește un API RESTful. Pentru a prelua anumite documente dintr-o colecție db, este creat un document de interogare care conține câmpurile cu care documentele dorite ar trebui să se potrivească.

Acțiuni

În MongoDB, există un grup de servere numite routere. Fiecare acționează ca un server pentru unul sau mai mulți clienți. În mod similar, clusterul conține un grup de servere numite servere de configurare. Fiecare deține o copie a metadatelor care indică ce fragment conține ce date. Acțiunile de citire sau scriere sunt trimise de la clienți către unul dintre serverele de router din cluster și sunt direcționate automat de către acel server către shard-urile corespunzătoare care conțin datele cu ajutorul serverelor de configurare.

Similar cu Cassandra, un shard din MongoDB are o schemă de replicare a datelor, care creează un set de replică a fiecărui shard care deține exact aceleași date. Există două tipuri de scheme de replică în MongoDB: replicarea Master-Slave și replicarea Replica-Set. Replica-Set oferă mai multă automatizare și o mai bună gestionare a defecțiunilor, în timp ce Master-Slave necesită intervenția administratorului uneori. Indiferent de schema de replicare, în orice moment dintr-un set de replică, doar un fragment acționează ca fragment primar, toate celelalte fragmente de replica sunt fragmente secundare. Toate operațiunile de scriere și citire merg la fragmentul primar și apoi sunt distribuite uniform (dacă este necesar) celorlalte fragmente secundare din set.

În graficul de mai jos, vedem arhitectura MongoDB explicată mai sus, arătând serverele de router în verde, serverele de configurare în albastru și shard-urile care conțin nodurile MongoDB.

Trebuie remarcat faptul că sharding (sau partajarea datelor între shard-uri) în MongoDB este complet automată, ceea ce reduce rata de eșec și face din MongoDB un sistem de gestionare a bazelor de date extrem de scalabil.

Structuri de indexare pentru baze de date NoSQL

Indexarea este procesul de asociere a unei chei cu locația unei înregistrări de date corespunzătoare într-un SGBD. Există multe structuri de date de indexare utilizate în bazele de date NoSQL. Următoarele secțiuni vor discuta pe scurt unele dintre cele mai comune metode; și anume, indexarea B-Tree, indexarea T-Tree și indexarea O2-Tree.

Indexarea B-Tree

B-Tree este una dintre cele mai comune structuri de index în DBMS-uri.

În arborii B, nodurile interne pot avea un număr variabil de noduri copii într-un interval predefinit.

O diferență majoră față de alte structuri de arbore, cum ar fi AVL, este că B-Tree permite nodurilor să aibă un număr variabil de noduri copii, ceea ce înseamnă mai puțină echilibrare a arborilor, dar mai mult spațiu irosit.

B+-Tree este una dintre cele mai populare variante de B-Tree. B+-Tree este o îmbunătățire față de B-Tree care necesită ca toate cheile să se afle în frunze.

Indexarea T-Tree

Structura de date a T-Trees a fost concepută prin combinarea caracteristicilor de la AVL-Trees și B-Trees.

Arborii AVL sunt un tip de arbori de căutare binari cu auto-echilibrare, în timp ce arborii B sunt dezechilibrati și fiecare nod poate avea un număr diferit de copii.

Într-un T-Tree, structura este foarte asemănătoare cu AVL-Tree și B-Tree.

Fiecare nod stochează mai mult de un tuplu {cheie-valoare, pointer}. De asemenea, căutarea binară este utilizată în combinație cu nodurile cu mai multe tuple pentru a produce stocare și performanță mai bune.

Un T-Tree are trei tipuri de noduri: Un T-Nod care are un copil drept și stânga, un nod frunză fără copii și un nod cu jumătate de frunză cu un singur copil.

Se crede că arborii T au performanțe generale mai bune decât arborii AVL.

O2-Indexarea arborilor

Arborele O2 este practic o îmbunătățire față de arbori roșu-negru, o formă de arbore de căutare binar, în care nodurile frunzelor conțin tuplurile {key value, pointer}.

O2-Tree a fost propus pentru a îmbunătăți performanța metodelor actuale de indexare. Un arbore O2 de ordinul m (m ≥ 2), unde m este gradul minim al arborelui, satisface următoarele proprietăți:

• Fiecare nod este fie roșu, fie negru. Rădăcina este neagră.
• Fiecare nod frunză este colorat în negru și constă dintr-un bloc sau o pagină care conține perechi „valoare cheie, indicator-înregistrare”.
• Dacă un nod este roșu, atunci ambii copii ai săi sunt negri.
• Pentru fiecare nod intern, toate căile simple de la nod la nodurile frunze descendente conțin același număr de noduri negre. Fiecare nod intern deține o singură valoare cheie.
• Nodurile-leaf sunt blocuri care au între ⌈m/2⌉ și m perechi „cheie-valoare, înregistrare-pointer”.
• Dacă un arbore are un singur nod, atunci trebuie să fie o frunză, care este rădăcina arborelui și poate avea între 1 și m elemente de date cheie.
• Nodurile frunzelor sunt dublu legate în direcții înainte și înapoi.

Aici, vedem o comparație simplă a performanței între O2-Tree, T-Tree, B+-Tree, AVL-Tree și Red-Black Tree:

Ordinea arborelui T, a arborelui B+ și a arborelui O2 utilizat a fost m = 512.

Timpul este înregistrat pentru operațiunile de căutare, inserare și ștergere cu rate de actualizare variind între 0%-100% pentru un index de 50 de milioane de înregistrări, operațiunile ducând la adăugarea a încă 50 de milioane de înregistrări la index.

Este clar că, cu un raport de actualizare de 0-10%, B-Tree și T-Tree au rezultate mai bune decât O2-Tree. Cu toate acestea, odată cu creșterea raportului de actualizare, indicele O2-Tree are rezultate semnificativ mai bune decât majoritatea celorlalte structuri de date, structurile B-Tree și Red-Black Tree suferă cel mai mult.

Cazul pentru NoSQL?

O introducere rapidă în bazele de date NoSQL, evidențiind domeniile cheie în care bazele de date relaționale tradiționale sunt insuficiente, duce la prima concluzie:

Deși bazele de date relaționale oferă consistență, ele nu sunt optimizate pentru performanță ridicată în aplicațiile în care datele masive sunt stocate și procesate frecvent.

Bazele de date NoSQL au câștigat multă popularitate datorită performanței ridicate, scalabilității ridicate și ușurinței de acces; cu toate acestea, încă le lipsesc caracteristici care oferă consistență și fiabilitate.

Din fericire, o serie de SGBD-uri NoSQL abordează aceste provocări oferind noi funcții pentru a îmbunătăți scalabilitatea și fiabilitatea.

Nu toate sistemele de baze de date NoSQL funcționează mai bine decât bazele de date relaționale.

MongoDB și Cassandra au performanțe similare și, în cele mai multe cazuri, mai bune decât bazele de date relaționale în operațiunile de scriere și ștergere.

Nu există o corelație directă între tipul de magazin și performanța unui SGBD NoSQL. Implementările NoSQL suferă modificări, astfel încât performanța poate varia.

Prin urmare, măsurătorile de performanță între tipurile de baze de date din diferite studii ar trebui să fie întotdeauna actualizate cu cele mai recente versiuni ale software-ului bazei de date, pentru ca acele numere să fie exacte.

Deși nu pot oferi un verdict definitiv asupra performanței, iată câteva puncte de reținut:

• Indexarea tradițională B-Tree și T-Tree este folosită în mod obișnuit în bazele de date tradiționale.
• Un studiu a oferit îmbunătățiri și îmbunătățiri prin combinarea caracteristicilor mai multor structuri de indexare pentru a crea O2-Tree.
• O2-Tree a depășit alte structuri în majoritatea testelor, în special cu seturi de date uriașe și rapoarte mari de actualizare.
• Structura B-Tree a oferit cea mai slabă performanță dintre toate structurile de indexare abordate în acest articol.

Lucrări suplimentare pot și ar trebui făcute pentru a îmbunătăți consistența SGBD-urilor NoSQL. Integrarea ambelor sisteme, NoSQL și baze de date relaționale, este o zonă de explorat în continuare.

În cele din urmă, este important să rețineți că NoSQL este o completare bună la standardele de baze de date existente, dar cu câteva avertismente importante. NoSQL schimbă caracteristici de fiabilitate și coerență pentru performanță și scalabilitate absolute. Aceasta o face o soluție specializată, deoarece numărul de aplicații care se pot baza pe baze de date NoSQL rămâne limitat.

Partea de sus? Specializarea s-ar putea să nu ofere multă flexibilitate, dar atunci când doriți să realizați o lucrare specializată cât mai rapid și eficient posibil, nu aveți nevoie de un cuțit elvețian. Ai nevoie de NoSQL.