SQL vs. NoSQL – wat moet u gebruik vir u volgende projek?

Een van die vrae wat die meeste gevra word – watter databasis moet ek gebruik …


SQL staan ​​vir Structured Query Language. Dit is die eerste keer in die 1970’s ontwikkel deur ‘n span IBM-navorsers. NoSQL-databasisse, daarenteen, is in 1998 vir die eerste keer deur Carlo Strozzi gebruik.

Die mees algemene verskil tussen hierdie twee databasisse (DB) is dat SQL relasioneel is en NoSQL nie-relasioneel.

Kom ons gaan diep in hierdie twee databasisse in om u besluit beter in te lig wanneer u ‘n databasis vir u projek oorweeg.

Databasisstruktuur

Kom ons praat oor strukturering.

SQL

SQL databasis het ‘n definitiewe skemastruktuur.

‘N Skema bevat tabelle, en elke tabel bevat ‘n definitiewe aantal kolomme. Dit beteken dat ‘n gebruiker nie die tabel kan bywerk bo die aantal kolomme wat in die tabel gespesifiseer is nie. Dit is veral handig as u data-integriteit moet handhaaf en ook seker moet maak van die soort data wat in u databasis gestoor word.

Elke tabel in ‘n SQL-databasis kan met mekaar verband hou. dit wil sê, u kan verhoudings tussen tabelle hê. Hierdie verhoudings kan een tot baie, baie tot baie of een tot een wees. Die tipe verhouding wat u voer, hang af van wat u benodig.

Laat ons byvoorbeeld die hipotetiese situasie oorweeg; ons het ‘n onderneming met gebruikers, en gebruikers kan bestellings maak vir produkte. Dan kan ons besluit dat gebruikers veelvuldige bestellings kan skep, maar elke bestelling kan slegs deur een gebruiker geskep word. Dit is ‘n verhouding tot baie, dit wil sê een gebruiker wat baie bestellings het. Die tabelstruktuur vir beide tabelle lyk dus soos hieronder.

In ons DB kan ons ‘n tabel met gebruikers hê, soos hieronder uiteengesit,

users_table
—————————————————-
id | naam | e-pos
—————————————————–
1 Idris [Email protected]

Ons kan ook ‘n bestellingstafel hê

orders_table
———————————————————————————
id | gebruiker_id | bestellingnommer
———————————————————————————
1 1 20000001

Die user_id op die bestellingstabel maak dit maklik om elke bestelling op die bestellingstafel te karteer vir die gebruiker waaraan hy behoort. In die geval van ‘n een-tot-een-verhouding, kan ons die order_id ook op die gebruikers-tafel hê as ons besluit om die gebruiker deur die verwante bestel-ID te kry.

Vir baie tot baie situasies is daar gewoonlik ‘n ekstra tafel, genaamd ‘n spilpunt, betrokke. Hierdeur kan verskeie rekords aan mekaar gekarteer word. Gebruik bogenoemde voorbeeld. Ons sou,

users_table
————————————————————————————-
id | naam | e-pos
————————————————————————————-
1 Idris [Email protected]

en die besteltafel sal wees

orders_table
———————————————————
id | bestellingnommer
———————————————————
1 2000001

en dan sal die Pivot-tabel albei ID’s as vreemde sleutels bevat.

users_orders_table
——————————————————————————
id | bestel_id | USER_ID
——————————————————————————
1 1 1

Op grond van hierdie struktuur wat deur SQL voorsien word, kan u gemaklik samevoegings tussen tabelle skryf wat data van verskillende tabelle wat in een navraag saamgevoeg is, sal voorsien.

NoSQL

NoSQL databasisse is gebou om meer buigsaam te wees as SQL DB’s, ook om groter hoeveelhede data te bevat.

In NoSQL DB’s is daar geen vooraf gedefinieerde skemas of tabelle nie. Daar is versamelings, en in elke versameling is daar dokumente. Hiermee kan u data in verskillende vorms stoor soos dit kom. U kan kies om verskillende dokumente met verskillende velde in een versameling te hê. Dit is ook moontlik om verhoudings tussen versamelings met die hand te smee. Hulle is egter nie geskik vir so ‘n doel nie. In plaas daarvan kan u alles wat nodig is vir ‘n enkele navraag in dieselfde versameling stoor.

As u ‘n SQL-persoon is, dink u aan versamelings as tabelle en dokumente as rye met die tabelle. Daar is egter geen beperkings op die kolomme van data wat u by die tabel kan voeg nie.

Gaan terug na ons vroeëre gedefinieerde hipotetiese voorbeeld van ‘n maatskappy met gebruikers en bestellings.

‘N Gebruikersversameling kan gedefinieer word as,

{id: 1, naam: ‘idris’, e-pos: ‘[Email protected]‘}

En die Order Collection kan gedefinieer word as,

{id: 1, bestelnummer: 2000001, gebruiker_id: 1}

In hierdie geval wil ons egter vermy dat u by beide versamelings hoef aan te sluit (wat ons nie behoort te doen nie, in hierdie geval). Ons kan inskrywings stoor in die versameling wat die meeste gelees word. Ek het besluit (vir hierdie voorbeeld) dat dit die Orde-versameling sal wees.

{id: 1, bestelnummer: 200001, gebruiker {id: 1, naam: ‘idris’, e-pos: ‘[Email protected]‘}}

In hierdie geval hoef ons nie meer uit die gebruikersversameling te lees nie, en slegs uit die bestellingsversameling te lees, wat nou al die data bevat wat ons benodig.

‘N Belangrike ding om hier op te let: As u ‘n app bou wat baie lees dan skryf, is ‘n NoSQL-opsie waarskynlik meer geskik vir u. Omdat u almal op dieselfde versameling kon stoor, en u gemaklik uit daardie bron kan lees om al die nodige data te bekom.

Vir ‘n toepassing wat baie skrywe benodig (ongeveer 10.000 skrywe per sekonde) op daardie skaal, is dit egter nie ‘n goeie idee om ‘n NoSQL-opsie te hê waar u dieselfde data op verskeie plekke moet skryf nie. In hierdie situasie is ‘n SQL-opsie waarskynlik meer geskik, waar daar verhoudinge bestaan ​​met al die tabelle, en dieselfde data nie herhaaldelik na meer as een plek geskryf hoef te word nie; die opdatering van data op een plek kan beskikbaar wees vir ander tabelle via die uitgang verhouding. Dit beteken natuurlik nie dat elkeen van hierdie databasisse nie skaal kan hanteer nie.

skalering

Kom ons kyk hoe skaal werk.

SQL

SQL DB’s kan nie horisontaal geskaal word nie, maar slegs vertikaal. Wat beteken dit selfs??

Horisontaal skaal beteken dat data van een DB in meer as een databasis verdeel word om die las te vergemaklik. SQL-data kan egter nie op aparte DB’s verdeel word nie, vanweë die streng aard daarvan. Om ‘n SQL DB te skaal, is om die CPU, geheue en skyfruimte van die bestaande DB-bediener te vergroot, en dit is wat dit beteken om dit vertikaal te skaal.

horisontale skaal

vertikale skaal


NoSQL

NoSQL DB’s kan horisontaal en vertikaal geskaal word. Dit is te danke aan die buigsaamheid in die datastoor. Dit laat dus toe dat sy data op verskeie databasisse verdeel word, soos die geval is met horisontale skaal. Dit kan ook vertikaal geskaal word indien nodig.

‘N Belangrike ding om hier op te let: As dit kom by skaal, kan beide SQL- en NoSQL-databasisse effektief geskaal word. Vir SQL DB’s kan vertikale skaal egter ‘n beperking wees; ‘n enkele DB-bediener sal ‘n beperking hê op die hoeveelheid rekenaarkrag wat dit kan dra.

Dit is ook belangrik om daarop te let dat u vir die meeste toepassings wat u sal bou, moontlik nie die maksimum van u rekenaar se rekenaarvermoë haal nie, maar dit is nuttig om dit in gedagte te hou. Vir die toepassing van groot sake-ondernemings wat SQL implementeer, is Sharding egter ‘n gewilde opsie om hierdie beperking te beëindig.

Wat is Sharding?

Afskerming is die proses om die groot tafels in klein stukke te breek, wat na verwys word as skerwe. Beskermings kan gedoen word deur ‘n horisontale verdeling van ‘n databasis. Dit moet nie verwar word met horisontale en vertikale skaal nie. Horisontale verdeling verwys na die proses om rye van ‘n tabel in verskeie databasisknope te stoor. Vertikale verdeling moet daarenteen kolomme van ‘n tabel op verskillende nodes gestoor word. Dit stel die databasis in staat om effektief te skaal en prestasies te verhoog.

Voorbeelde van databasis

SQL

  • MySQL – ‘n Baie gewilde open source databasis. Maklik die databasis van keuse vir baie PHP-ontwikkelaars kan egter ook saam met Node.js, C #, C ++, Java, Perl, Ruby en Python gebruik word..
  • MSSQL – Microsoft SQL bied baie stabiliteit, aangesien die ontwikkeling direk vanaf Microsoft is, wat ook ondersteuning bied in terme van rampherstel.
  • MariaDB – Dit is op MySQL gebou deur die makers van MySQL, met die doel om MariaDB as ‘n gratis ewige weergawe te hou.
  • PostgresSQL – ‘n Baie gewilde open-source databasis. Is trots op die wêreld se mees gevorderde open source databasis
  • Oracle – Dit is gewoonlik aangepas vir Oracle se ondernemingsoplossings, met ‘n paar beperkings op die gratis weergawe.

NoSQL

  • MongoDB – waarskynlik die bekendste NoSQL DB, algemeen onder toepassingsontwikkelaars wat met MERN-stapel werk (MongoDB, Express, React, Node) of MEAN-stapel (MongoDB, Express, Angular, Node).
  • Firebase – wat in 2011 bekendgestel is en in 2014 deur Google aangekoop is, word wyd gebruik deur ontwikkelaars van web- en mobiele toepassings.
  • Apache Couch DB – ‘n Dokumentgebaseerde NoSQL DB wat data as JSON stoor.
  • Redis: Dit is NoSQL DB, waarskynlik die bekendste vir die gebruik daarvan om data met opsionele tyd te bewaar. Dit is ook bekend vir sy snelheid.

Afsluiting

U kan enige vorm van toepassings met ‘n SQL- of NoSQL-databasis skep. Dit hang af van u vereistes. As u ‘n databasis oorweeg waar u meer lees en minder skryf, kan ‘n NoSQL ‘n goeie opsie wees. As u dit egter oorweeg om ‘n app te bou met meer skryfstukke as wat gelees word, is ‘n SQL miskien die beste oplossing. As u app skaalbaar is, kan u albei DB’s gebruik as u app op ‘n baie groot skaal begin.

Tags:

  • databasis

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