de Nandhini Saravanan

Bazele bazelor de date NoSQL – și de ce avem nevoie de ele

Un ghid pentru începători către lumea NoSQL

Organizarea datelor este o sarcină foarte dificilă. Când spunem organizare, categorisim lucrurile în funcție de tipul și funcția acestuia.

O opțiune este RDBMS este ca o foaie Excel – clasificați datele sub formă de tabele. Puteți forma relații între tabele.

A interogare pune la îndoială baza de date, care vă oferă în schimb un răspuns relevant. Acest limbaj de interogare este SQL sau Limbaj de interogare structurat.

De exemplu,

select * from Employee_Data;

selectează toate datele despre angajați din tabelul Angajați_Date.

Bazele de date relaționale urmează a schemă, un plan detaliat al modului în care funcționează mesele dvs.

Folosiți Amazon, Facebook și atâtea aplicații de rețea. Acestea lansează actualizări, adaugă noi funcționalități și chiar module suplimentare. Deci, cum se schimbă schema de fiecare dată? Nu este nevoie de timp pentru astfel de companii uriașe să își dedice timpul și munca pentru schimbarea schemei?

Aici e locul SQL nu a putut funcționa.

Contra de RDBMS

Bazele de date relaționale nu sunt la fel de rele pe cât oamenii descriu în zilele noastre. Acestea sunt încă utilizate de o mulțime de organizații. Introducerea NoSQL în imagine este de a umple spațiile în care RDBMS nu mai poate fi de folos.

Vă voi arăta exemple, astfel încât să aveți o înțelegere clară.

1. RDBMS nu poate gestiona „Varietatea datelor”.

Cantitatea de date nestructurate continuă să crească anual, iar gestionarea acestora este dificilă. RDBMS nu poate forța toate tipurile de date într-o schemă unificată de tabele.

Silozuri de date sunt, de asemenea, o problemă pentru dezvoltatori.

Conform Țintă tehnică, A siloz de date este un depozit de date care rămâne sub controlul unui departament. Este izolat de restul organizației.

Aceasta înseamnă că atunci când există mai multe silozuri pentru aceleași date, conținutul lor este probabil să difere. Se creează confuzie asupra depozitului care reprezintă cea mai actualizată versiune.

Creșterea datelor din anul 2013 până în 2020 este vizibilă în imaginea de mai jos.

În anul 2020 vor fi generate aproximativ 44 de octeți Zeta de date.

Manipularea unor date atât de diverse, care nu sunt legate între ele, ar putea fi mult mai dificilă în RDBMS.

Exemplu: Este dificil să stocați detaliile unui pacient, care are condiții corporale diferite. Clasificarea unor astfel de date diverse este dificilă în RDBMS.

2. Dificil de schimbat tabelele și relațiile.

Modificarea relațiilor dintre tabele sau adăugarea unui nou tabel ar putea afecta relațiile existente. Aceasta înseamnă schimbarea schemei.

Schimbarea schemei ar fi ca eliminarea celei existente și conceperea unei noi scheme.

Adăugarea unei noi funcționalități ar necesita toate elementele pentru a susține noua structură. Schimbarea este inevitabilă.

Exemplu: Fiecare coloană suplimentară are nevoie de toate rândurile anterioare pentru a avea valori pentru acea coloană. În timp ce în Cassandra (o bază de date NoSQL), puteți adăuga o coloană la anumite partiții de rând.

3. RDBMS urmează proprietățile ACID ale bazei de date.

Proprietățile ACID ale unei baze de date sunt Atomicitate, Consistență, Izolare și Durabilitate. ‌

Atomicitate – O abordare „totul sau nimic”. Dacă orice declarație din tranzacție eșuează, întreaga tranzacție este anulată.

Coerență – Tranzacția trebuie să îndeplinească toate protocoalele definite de sistem. Nici o tranzacție finalizată pe jumătate

Izolare – Nicio tranzacție nu are acces la nicio altă tranzacție care se află într-o stare intermediară sau neterminată. Fiecare tranzacție este independentă.

Durabilitate – Asigură că odată ce o tranzacție se angajează în baza de date, aceasta este păstrată prin utilizarea copiilor de rezervă și a jurnalelor de tranzacții.

Proprietățile ACID nu sunt flexibile.

De exemplu, urmează RDBMS Normalizare sau un singur punct de adevăr concept. Pentru fiecare modificare pe care o faceți, ar trebui să vă asigurați proprietăți ACID stricte. integritatea entității și integritate referențială se aplică și reguli.

Teorema CAP

Conform Wikipedia, Teorema CAP (Teorema lui Brewer) afirmă că este imposibil ca un magazin de date distribuit să facă acest lucru simultan furnizează mai mult de două din următoarele trei garanții:

Coerență: Ca C în ACID.

Disponibilitate: ‌Resursele ar trebui să fie întotdeauna disponibile. Ar trebui să existe un răspuns fără eroare.

Toleranță partiție: Nu există un singur punct (sau nod) de eșec.

Este dificil să îndeplinești toate cele trei condiții. Trebuie să faceți un compromis între cei trei.

BAZĂ pentru salvare!

‌NoSQL se bazează pe un model mai moale cunoscut sub numele de model BASE. BAZA (Basical Adisponibil, Sde multe ori stat, Econsistenta ventuala).

Disponibil practic: Garantează disponibilitatea datelor. Va exista un răspuns la orice solicitare (poate fi și eșec).

Stare moale: Starea sistemului s-ar putea schimba în timp.

Coerență eventuală: Sistemul va deveni în cele din urmă consecvent odată ce nu mai primește intrare.

Bazele de date NoSQL renunță la cerințele A, C și / sau D și, în schimb, îmbunătățesc scalabilitatea.

NoSQL

Acesta este momentul în care NoSQL a venit în ajutor.Nu numai SQL ” sau baze de date „non-relaționale”.

Caracteristicile NoSQL:

• Schemă gratuită
• În cele din urmă consecvent (ca în proprietatea BASE)
• Replicarea stocurilor de date pentru a evita un singur punct de eșec.
• Poate gestiona varietatea de date și cantități uriașe de date.

Tipuri de baze de date NoSQL

Bazele de date NoSQL se încadrează în patru categorii principale:

Magazine cu valori cheie – Riak, Voldemort și Redis

Magazine largi de coloane – Cassandra și HBase.

Baze de date de documente – MongoDB

Baze de date grafice – Neo4J și HyperGraphDB.

Cuvintele din partea dreaptă sunt exemple de tipuri de tipuri de baze de date NoSQL.

1. Magazinele de valori cheie

Un magazin de valori cheie folosește un masa de hash în care există o cheie unică și a indicatorul la un anumit element de date.

Imaginați-vă că magazinele de valori cheie sunt ca un director telefonic în care numele individului și numerele lor sunt mapate împreună.

Magazinele cu valori cheie nu au limbajul de interogare implicit. Primiți date folosind obține, pune și șterge comenzi. Acesta este motivul pentru care are performanta ridicata.

Aplicații: Util pentru stocarea comentariilor și a informațiilor despre sesiune. InterestPinterest folosește Redis pentru a stoca liste de utilizatori, adepți, persoane care nu urmăresc, forumuri.

2. Depozite largi de coloane

Într-o bază de date de stocare a coloanelor, coloanele din fiecare rând sunt conținute în acel rând.

Fiecare familia de coloane este un container de rânduri într-un tabel RDBMS. cheie identifică rândul format din mai multe coloane.

Rândurile nu trebuie să aibă acelasi numar de coloane. Coloanele pot fi adăugate la orice rând în orice moment, fără a fi nevoie să le adăugați la alte rânduri. Este un magazin de rânduri partiționat.

Cum stochează date o bază de date coloană?

Aplicații: Spotify folosește Cassandra pentru a stoca atributele și metadatele profilului utilizatorului.

3. Bazele de date ale documentelor

StoresMagazinele de documente utilizează documente JSON, XML sau BSON (codare binară a JSON) pentru a stoca date.

Este ca o bază de date valoare-cheie, dar un depozit de documente constă din date semi-structurate.

Un singur document este de a stoca înregistrările și datele sale.

aceasta nu susține relațiile sau se alătură.

Dacă dorim să stocăm detaliile clientului și comenzile acestora, putem folosi magazinele de documente pentru ao face.

Aplicații: ‌SEGA folosește MongoDB pentru gestionarea a 11 milioane de conturi în joc construite pe MongoDB.

4. Baze de date grafice

‌Nodurile și relațiile sunt elementele esențiale ale bazelor de date grafice. A nod reprezintă o entitate. A relaţie reprezintă modul în care sunt asociate două noduri.

‌În RDBMS, adăugarea unei alte relații duce la multe schimbări de schemă.

Baza de date grafice necesită stocarea datelor o singură dată (noduri). Diferitele tipuri de relații (margini) sunt specificate datelor stocate.

Relațiile dintre noduri sunt predeterminate, adică nu sunt determinate la momentul interogării.

Traversare relații persistente sunt mai rapide.

Este dificil să schimbi relația dintre două noduri. Ar rezulta modificări regresive în baza de date.

Exemplu: Această imagine este cum MySQL funcționează acolo unde trebuie să efectueze multe operații pentru a găsi un rezultat corect pentru Alice.

‌O bază de date cu grafice, care predetermină relațiile.

Acestea sunt câteva dintre informațiile de bază de care veți avea nevoie pentru a începe explorarea NoSQL. Noi baze de date sunt inventate pentru utilizări specifice.

Aflați tipul de date pe care îl generează aplicația dvs. și apoi este ușor să alegeți baza de date potrivită.

Scriu povești despre Lecții de viață, codificare și tehnologie. Pentru a citi mai multe, urmează-mă Stare de nervozitate și Mediu.