SQL vs. NoSQL – Què heu d’utilitzar per al vostre següent projecte?

Una de les preguntes més freqüents: quina base de dades he d’utilitzar …


SQL significa un llenguatge de consulta estructurada. Va ser desenvolupat per primera vegada a la dècada de 1970 per un equip d’investigadors d’IBM, les bases de dades NoSQL, d’altra banda, van ser utilitzades per primera vegada el 1998 per Carlo Strozzi.

La diferència més habitual entre aquests dos sistemes de bases de dades (DB) és que SQL és relacional i NoSQL no relacional.

Aprofundim en aquestes dues bases de dades per informar millor la vostra decisió quan més endavant considereu una base de dades del vostre projecte.

Estructura de la base de dades

Parlem d’estructuració.

SQL

SQL la base de dades té una estructura d’esquema definida.

Un esquema conté taules i cada taula conté un nombre definit de columnes. Això significa que un usuari no pot actualitzar la taula més enllà del nombre de columnes especificades a la taula. Això és especialment útil quan cal mantenir la integritat de les dades i també per assegurar-se del tipus de dades que es desa a la base de dades.

Es pot relacionar cada taula d’una base de dades SQL. és a dir, podeu tenir relacions entre taules. Aquestes relacions poden ser Un a Molts, Molts a Molts o Un a Un. El tipus de relació que implementeu depèn del que necessiteu.

Per exemple, pensem en la hipotètica situació; tenim una empresa amb usuaris i els usuaris poden fer comandes de productes. Aleshores, podríem decidir que els usuaris poden crear múltiples comandes, però cada comanda només pot ser creada per un usuari. Aquesta seria una de moltes relacions, és a dir, d’un usuari a moltes comandes. Per tant, l’estructura de la taula de les dues taules serà similar a la següent.

Al nostre DB podríem tenir una taula d’usuaris, estructurada com es mostra a continuació,

usuaris_table
—————————————————-
íd. | nom | correu electrònic
—————————————————–
1 Idris [correu electrònic protegit]

A més, podríem tenir una taula de comandes

comandes_table
———————————————————————————
íd. | user_id | número d’ordre
———————————————————————————
1 1 20000001

El user_id de la taula de comandes, facilita assenyalar cada comanda de la taula de comandes amb l’usuari al qual pertany. En el cas d’una relació One to One, podríem tenir la comanda_id també a la taula d’usuaris si decidim obtenir l’usuari mitjançant el seu identificador de comanda relacionat..

Per a situacions, Moltes a Moltes, sol intervenir-hi una taula addicional, anomenada taula pivot. Això permet que diversos registres es puguin mapejar entre ells. Utilitzant la instància anterior. Tindríem,

usuaris_table
————————————————————————————-
íd. | nom | correu electrònic
————————————————————————————-
1 Idris [correu electrònic protegit]

i la taula de comandes serà

comandes_table
———————————————————
íd. | número d’ordre
———————————————————
1 2000001

i, a continuació, la taula Pivot conservarà tant els ID com a claus estrangeres.

users_orders_table
——————————————————————————
íd. | comanda_id | ID d’usuari
——————————————————————————
1 1 1

Basant-se en aquesta estructura proporcionada per SQL, podeu escriure unides còmodament entre taules que proporcionaran dades de diferents taules unides en una sola consulta..

NoSQL

NoSQL les bases de dades es van crear per ser més flexibles que les bases de dades SQL, per contenir quantitats més grans de dades.

A les bases de dades NoSQL, no hi ha cap esquema ni taules predefinides. Hi ha col·leccions i, a cada col·lecció, hi ha documents. Això us permet guardar dades de diferents formes a mesura que es presentin. Podeu triar tenir diversos documents variats amb diversos camps en una col·lecció. També és possible forjar manualment les relacions entre les col·leccions. Tanmateix, no són adequats per a aquest propòsit. En el seu lloc, podríeu desar tot el que calgui per a una sola consulta a la mateixa col·lecció.

Si sou una persona SQL, podeu pensar en les col·leccions com a taules i documents com a files amb les taules. Tanmateix, no hi ha restriccions a les columnes de dades que podeu afegir amb la taula.

Tornant a la nostra hipotètica instància definida anteriorment d’una empresa amb usuaris i comandes.

Es pot definir una col·lecció d’usuaris com a,

{id: 1, nom: ‘idris’, correu electrònic: ‘[correu electrònic protegit]‘}

I es pot definir la col·lecció de comandes com a,

{id: 1, número de comanda: 2000001, user_id: 1}

Tot i això, en aquest cas, volem evitar haver-nos d’unir manualment a ambdues col·leccions (cosa que no hauríem de fer, en aquest cas). Podem desar les entrades a la col·lecció que més llegeixi. He decidit (per exemple) que serà la col·lecció de comandes.

{id: 1, número_ordre: 200001, usuari {id: 1, nom: ‘idris’, correu electrònic: ‘[correu electrònic protegit]‘}}

En aquest cas, ja no necessitem llegir de la col·lecció d’usuaris i només llegir de la col·lecció d’ordres, que ara conté totes les dades que necessitem.

Una cosa clau a destacar aquí: Si creeu una aplicació que faci moltes lectures que no pas escriure, és probable que sigui més adequat per a vosaltres una opció NoSQL. Com que podríeu guardar les dades totes a la mateixa col·lecció i podríeu llegir-lo des d’aquesta font còmodament per obtenir totes les dades necessàries.

Tanmateix, per a una aplicació que requereixi moltes escriptures (aproximadament 10.000 escriptures per segon) a aquesta escala, no és bona idea tenir l’opció NoSQL on cal escriure les mateixes dades a diverses ubicacions. En aquesta situació, és probable que sigui més adequada una opció SQL, si teniu relacions existents a totes les taules i no cal escriure les mateixes dades de manera repetida a diverses ubicacions, l’actualització de dades en una ubicació pot estar disponible per a altres taules a la sortida. relació. Això, per descomptat, no vol dir que cadascuna d’aquestes bases de dades no pugui gestionar escala.

Escala

Anem a explorar el funcionament de l’escalat.

SQL

Les DB SQL no es poden escalar horitzontalment, sinó només verticals. Què vol dir això fins i tot?

Escalar horitzontalment significa dividir dades d’una base de dades a diverses bases de dades per facilitar la càrrega. Tanmateix, les dades SQL no es poden dividir en bases de dades separades a causa de la seva estricta naturalesa. El que és adequat per escalar una base de dades SQL és augmentar l’espai de CPU, memòria i disc del servidor DB existent, i això vol dir escalar-lo verticalment.

escalada horitzontal

escalat vertical


NoSQL

Les DB NoSQL es poden escalar tant horitzontalment com verticalment. Això es deu a la flexibilitat del seu emmagatzematge de dades. Per tant, això permet dividir les seves dades en diverses bases de dades, com és el cas de l’escalació horitzontal. També es pot escalar verticalment si es requereix.

Una cosa clau a destacar aquí: A l’hora d’escalar, tant les bases de dades SQL com les NoSQL es poden escalar de manera efectiva. Tanmateix, per a les bases de dades SQL, l’escalat vertical pot ser una limitació; un servidor DB únic tindrà una limitació a la quantitat de potència informàtica que pugui transportar.

També és important tenir en compte que, per a la majoria de les aplicacions que creareu, és possible que no arribeu al màxim de la capacitat informàtica del vostre servidor, però és útil tenir-ho en compte. Tanmateix, per a aplicacions de grans empreses que implementen SQL, una opció popular per superar aquesta limitació és Sharding.

Què és el Sharding?

El fet de dividir és el procés de trencar les grans taules en trossos petits, que es coneixen com a fragments. La compartició es pot fer particionant horitzontalment una base de dades. Això no s’ha de confondre amb l’escalat horitzontal i vertical. Les particions horitzontals es refereixen al procés d’emmagatzematge de files d’una taula en diversos nodes de base de dades. El particionat vertical, d’altra banda, requereix guardar les columnes d’una taula en diferents nodes. Això permet a la base de dades escalar de manera eficaç i augmentar el rendiment.

Exemples de bases de dades

SQL

  • MySQL: una base de dades de codi obert molt popular. La base de dades escollida fàcilment per a molts desenvolupadors de PHP, però, també es pot utilitzar amb Node.js, C #, C ++, Java, Perl, Ruby i Python.
  • MSSQL – Microsoft SQL proporciona molta estabilitat ja que el seu desenvolupament és directament de Microsoft, que també ofereix una mica de suport pel que fa a la recuperació de desastres.
  • MariaDB: els creadors de MySQL van ser construïts a MySQL amb la intenció de mantenir MariaDB com a versió gratuïta per a sempre..
  • PostgresSQL: una base de dades de codi obert molt popular. El seu orgull és la base de dades de codi obert més avançada del món
  • Oracle: normalment s’adapta a les solucions empresarials d’Oracle amb algunes limitacions a la seva versió gratuïta.

NoSQL

  • MongoDB – Probablement el DB NoSQL més conegut, comú entre els desenvolupadors d’aplicacions que treballen amb la pila MERN (MongoDB, Express, React, Node) o la pila MEAN (MongoDB, Express, Angular, Node).
  • Firebase: introduït el 2011 i adquirit per Google el 2014, està sent utilitzat àmpliament pels desenvolupadors d’aplicacions web i mòbils.
  • Apache Couch DB: un DB NoSQL basat en documents que emmagatzema dades com a JSON.
  • Redis: es tracta de NoSQL DB, probablement més conegut pel seu ús per emmagatzemar dades amb temps opcional per viure. També és conegut per la seva velocitat.

Conclusió

Podeu crear qualsevol tipus d’aplicació amb una base de dades SQL o NoSQL. Depèn dels vostres requisits. Si teniu en compte una base de dades on tingueu més lectures i menys escriptures, un NoSQL pot ser una bona opció. Si us plau, considereu la creació d’una aplicació amb més escriptures que lectures, un SQL pot ser la millor solució. Quant a l’escalabilitat, quan l’aplicació arriba a una escala molt massiva, podeu acabar utilitzant els dos fitxers de dades.

Tags:

  • Base de dades

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