SQL vs. NoSQL – Ce ar trebui să folosiți pentru următorul dvs. proiect?

Una dintre cele mai frecvente întrebări – ce bază de date ar trebui să folosesc …


SQL înseamnă limbajul de interogare structurat. A fost dezvoltat pentru prima dată în anii ’70 de o echipă de cercetători IBM, bazele de date NoSQL, pe de altă parte, au fost folosite pentru prima dată în 1998 de către Carlo Strozzi.

Cea mai comună diferență între aceste două sisteme de baze de date (DB) este că SQL este relațional și NoSQL este non-relațional.

Haideți să ne adâncim în aceste două baze de date pentru a vă informa mai bine decizia atunci când vi se ia în considerare o bază de date pentru proiectul dvs..

Structura bazei de date

Să vorbim despre structurare.

SQL

SQL baza de date are o structură de schemă definită.

O schemă conține tabele și fiecare tabel conține un număr definit de coloane. Aceasta înseamnă că un utilizator nu poate actualiza tabelul dincolo de numărul de coloane specificate în tabel. Acest lucru este util în special atunci când trebuie să mențineți integritatea datelor și, de asemenea, să vă asigurați de tipul de date care sunt memorate în baza de date.

Fiecare tabel dintr-o bază de date SQL poate fi legat. adică, puteți avea relații între tabele. Aceste relații pot fi una la mulți, mulți la mulți sau la unu la unu. Tipul de relație pe care îl implementezi depinde de ceea ce ai nevoie.

De exemplu, să luăm în considerare situația ipotetică; avem o companie cu utilizatori, iar utilizatorii pot face comenzi pentru produse. Apoi, am putea decide că utilizatorii pot crea mai multe comenzi, dar fiecare comandă poate fi creată doar de un singur utilizator. Aceasta ar fi una până la multe relații, adică un utilizator la multe comenzi. Prin urmare, structura tabelelor pentru ambele tabele va arata similar cu cea de mai jos.

În baza noastră de date am putea avea un tabel de utilizatori, structurat ca mai jos,

users_table
—————————————————-
id | nume | e-mail
—————————————————–
1 Idris [Email protected]

De asemenea, am putea avea un tabel de comenzi

orders_table
———————————————————————————
id | user_id | Numar de ordine
———————————————————————————
1 1 20000001

User_id de pe tabelul de comenzi, face ușor să mapați fiecare comandă din tabelul de comenzi cu utilizatorul din care face parte. În cazul unei relații One to One, am putea avea comanda_id și pe tabla users_the dacă decidem să obținem utilizatorul prin ID-ul de comandă aferent.

Pentru situații, de la multe la multe, este de obicei implicat un tabel suplimentar, numit tabel pivot. Aceasta permite mai multe înregistrări să fie mapate între ele. Folosind instanța de mai sus. Am avea,

users_table
————————————————————————————-
id | nume | e-mail
————————————————————————————-
1 Idris [Email protected]

iar tabelul de ordine va fi

orders_table
———————————————————
id | Numar de ordine
———————————————————
1 2000001

și apoi tabelul Pivot va conține ambele ID-uri ca chei străine.

users_orders_table
——————————————————————————
id | comanda_id | numele de utilizator
——————————————————————————
1 1 1

Pe baza acestei structuri oferite de SQL, puteți scrie confortabil unirile între tabele care vor oferi date din diferite tabele unite împreună într-o singură interogare.

NoSQL

NoSQL bazele de date au fost create pentru a fi mai flexibile decât DB-urile SQL, pentru a conține și cantități mai mari de date.

În DB-urile NoSQL, nu există o schemă sau tabele predefinite. Există colecții și în fiecare colecție există documente. Acest lucru vă permite să salvați date în diferite forme pe măsură ce vin. Puteți alege să aveți mai multe documente diferite cu câmpuri diferite într-o singură colecție. De asemenea, este posibil să falsificați manual relațiile dintre Colecții. Cu toate acestea, acestea nu sunt adecvate pentru acest scop. În schimb, puteți salva tot ceea ce este necesar pentru o singură interogare în aceeași colecție.

Dacă sunteți o persoană SQL, vă puteți gândi la Colecții ca tabele și Documente ca rânduri cu tabelele. Cu toate acestea, nu există restricții la coloanele de date pe care le puteți adăuga cu tabelul.

Revenind la instanța noastră ipotetică definită anterior a unei companii cu utilizatori și comenzi.

O colecție de utilizatori ar putea fi definită ca fiind,

{id: 1, nume: ‘idris’, e-mail: ‘[Email protected]„}

Și Colecția de comenzi ar putea fi definită ca fiind,

{id: 1, număr_comandă: 2000001, user_id: 1}

Cu toate acestea, în acest caz, dorim să evităm să aderăm manual ambelor Colecții (ceea ce nu ar trebui, în acest caz). Putem salva intrări în Colecția care este cel mai citit. Am decis (de exemplu) care va fi colecția Comenzi.

{id: 1, număr_comandă: 200001, utilizator {id: 1, nume: ‘idris’, e-mail: ‘[Email protected]„}}

În acest caz, nu mai este nevoie să citim din Colecția de utilizatori și doar să citim din Colecția de comenzi, care conține acum toate datele de care avem nevoie.

Un lucru cheie de remarcat aici: Dacă construiți o aplicație care face multe lecturi decât scriere, este posibil ca o opțiune NoSQL să fie mai potrivită pentru dvs. Deoarece puteți salva datele dvs. toate salvate în aceeași colecție și puteți citi confortabil din acea sursă pentru a obține toate datele necesare.

Cu toate acestea, pentru o aplicație care necesită o mulțime de scrieri (aproximativ 10.000 de scrieri pe secundă) la acea scară, nu este o idee bună să aveți opțiunea NoSQL unde trebuie să scrieți aceleași date în mai multe locații. În această situație, o opțiune SQL este probabil mai potrivită, în cazul în care aveți relații existente la toate tabelele și aceleași date nu trebuie să fie scrise în mai multe locații în mod repetat, actualizarea datelor într-o singură locație poate fi disponibilă pentru alte tabele prin ieșire relaţie. Desigur, aceasta nu înseamnă că fiecare dintre aceste baze de date nu poate suporta scara.

scalarea

Să explorăm cum funcționează scalarea.

SQL

DB-urile SQL nu pot fi scalate pe orizontală, ci doar pe verticală. Ce înseamnă asta chiar?

Scalarea orizontală înseamnă împărțirea datelor dintr-o bază de date în mai multe baze de date pentru a ușura încărcarea. Cu toate acestea, datele SQL nu pot fi împărțite pe baze de date separate datorită naturii sale stricte. Trebuie să crezi o scară SQL DB pentru a crește spațiul CPU, memorie și disc al serverului DB existent și asta înseamnă să-l scalăm pe verticală.

scalare orizontală

scalare verticală


NoSQL

DB-urile NoSQL pot fi scalate atât pe orizontal cât și pe verticală. Acest lucru se datorează flexibilității în stocarea datelor sale. Prin urmare, acest lucru permite împărțirea datelor sale pe mai multe baze de date, cum este cazul scalării orizontale. Poate fi, de asemenea, scalată vertical dacă este necesar.

Un lucru cheie de remarcat aici: Când vine vorba de scalare, atât bazele de date SQL cât și NoSQL pot fi scalate eficient. Cu toate acestea, pentru DB-urile SQL, scalarea verticală poate fi o limitare; un singur server DB va avea o limitare a cantității de putere de calcul pe care o poate transporta.

De asemenea, este important să rețineți că, pentru majoritatea aplicațiilor pe care le veți construi, este posibil să nu atingeți maximul capacității de calculare a serverului dvs., dar este util să aveți în vedere acest lucru. Cu toate acestea, pentru aplicațiile de afaceri mari care implementează SQL, o opțiune populară pentru a învinge această limitare este prin Sharding.

Ce este Sharding?

Împărțirea este procesul de rupere a tabelelor mari în bucăți mici, care sunt denumite cioburi. Împărțirea se poate face prin partitionarea orizontală a unei baze de date. Aceasta nu trebuie confundată cu scalarea orizontală și verticală. Partiționarea orizontală se referă la procesul de stocare a rândurilor unui tabel în mai multe noduri ale bazei de date. Partajarea verticală, pe de altă parte, necesită salvarea coloanelor unui tabel pe diferite noduri. Acest lucru permite bazei de date să crească eficient și să sporească performanța.

Exemple de baze de date

SQL

  • MySQL – o bază de date open-source foarte populară. Cu ușurință, baza de date la alegere pentru mulți dezvoltatori PHP, poate fi folosită și cu Node.js, C #, C ++, Java, Perl, Ruby și Python.
  • MSSQL – Microsoft SQL oferă multă stabilitate, deoarece dezvoltarea sa este direct de la Microsoft, care oferă, de asemenea, un anumit suport în ceea ce privește recuperarea în caz de dezastre.
  • MariaDB – Aceasta a fost construită pe MySQL de către producătorii de MySQL, intenționând să mențină MariaDB ca versiune gratuită pentru totdeauna.
  • PostgresSQL – o bază de date open-source foarte populară. Se mândrește cu sine ca fiind cea mai avansată bază de date open source din lume
  • Oracle – De obicei, aceasta este adaptată soluțiilor enterprise Oracle, cu unele limitări ale versiunii sale gratuite.

NoSQL

  • MongoDB – Probabil cel mai cunoscut DB NoSQL, frecvent printre dezvoltatorii de aplicații care lucrează cu stivă MERN (MongoDB, Express, React, Node) sau stivă MEAN (MongoDB, Express, Angular, Node).
  • Firebase – introdus în 2011 și achiziționat de Google în 2014, este utilizat pe scară largă de dezvoltatorii de aplicații web și mobile.
  • Apache Couch DB – O DB NoSQL bazată pe documente care stochează date ca JSON.
  • Redis: Acesta este NoSQL DB, probabil cel mai bine cunoscut pentru utilizarea sa în stocarea datelor cu timp opțional pentru a trăi. Este, de asemenea, binecunoscut pentru viteza sa.

Concluzie

Puteți crea orice tip de aplicație fie cu o bază de date SQL sau NoSQL. Depinde de cerințele dvs. Dacă aveți în vedere o bază de date în care aveți mai multe lecturi și mai puține scrieri, un NoSQL ar putea fi o opțiune bună. Dacă totuși, vă gândiți să construiți o aplicație cu mai multe scrieri decât citite, un SQL ar putea fi soluția mai bună. În ceea ce privește scalabilitatea, atunci când aplicația dvs. ajunge la o scară foarte masivă, s-ar putea să utilizați ambele DB-uri.

ETICHETE:

  • Bază de date

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map