SQL vs. NoSQL – Katerega uporabiti za svoj naslednji projekt?

Eno najpogostejših vprašanj – katero bazo podatkov naj uporabim …


SQL pomeni strukturiran jezik poizvedb. Prvič ga je v 70. letih razvila skupina raziskovalcev IBM-a, baze podatkov NoSQL pa je po drugi strani leta 1998 prvič uporabil Carlo Strozzi.

Najpogostejša razlika med tema dvema sistemoma baz podatkov je, da je SQL relacijski in NoSQL nerelacijski.

Pogumimo se v ti dve zbirki podatkov, da bosta lažje obveščali o svoji odločitvi, ko naslednjič razmišljate o zbirki podatkov za svoj projekt.

Struktura baze podatkov

Pogovorimo se o strukturiranju.

SQL

SQL baze podatkov imajo točno določeno strukturo sheme.

Shema vsebuje tabele in vsaka tabela vsebuje točno določeno število stolpcev. To pomeni, da uporabnik ne more posodobiti tabele nad številom stolpcev, določenih v tabeli. To je še posebej koristno, če morate ohraniti integriteto podatkov in poskrbeti tudi za vrsto podatkov, ki se shranijo v vašo bazo podatkov.

Vsaka tabela v bazi podatkov SQL je lahko povezana. lahko imate odnose med tabelami. Ti odnosi so lahko eden do mnogih, veliko do mnogih ali eden do enega. Vrsta odnosa, ki ga izvajate, je odvisna od tega, kaj potrebujete.

Na primer, upoštevajmo hipotetično situacijo; imamo podjetje z uporabniki in uporabniki lahko naročajo izdelke. Potem bi se lahko odločili, da lahko uporabniki ustvarijo več naročil, vendar lahko vsako naročilo ustvari samo en uporabnik. To bi bilo razmerje med mnogimi, tj. En uporabnik v številnih naročilih. Zato bo struktura tabel za obe tabeli videti podobno kot spodaj.

V našem DB bi lahko imeli tabelo uporabnikov, strukturirano kot spodaj,

tabela uporabnikov
—————————————————-
id | ime | E-naslov
—————————————————–
1 Idris [zaščitena e-pošta]

Prav tako bi lahko imeli tabelo naročil

tabela naročil
———————————————————————————
id | user_id | številka naročila
———————————————————————————
1 1 20000001

Uporabnik_id na tabeli naročil olajša zemljevid vsakega naročila na tabeli naročil uporabniku, ki mu pripada. V primeru razmerja ena do enega bi lahko imeli ukaz_id tudi na tabeli za uporabnike, če se odločimo, da bomo uporabnika dobili po njegovem povezanem ID-ju naročila.

Za situacije v mnogih do mnogih je običajno vključena dodatna tabela, imenovana vrtilna tabela. To omogoča preslikavo več zapisov med seboj. Z uporabo zgornjega primerka. Imeli bi,

tabela uporabnikov
————————————————————————————-
id | ime | E-naslov
————————————————————————————-
1 Idris [zaščitena e-pošta]

in tabela naročil bo

tabela naročil
———————————————————
id | številka naročila
———————————————————
1 2000001

in nato bo v tabeli Pivot obe ID-ju shranjena kot tuja ključa.

users_orders_table
——————————————————————————
id | order_id | Uporabniško ime
——————————————————————————
1 1 1

Na podlagi te strukture, ki jo ponuja SQL, lahko udobno napišete Združitve med tabele, ki bodo v enem poizvedbi zagotavljale podatke iz različnih tabel, združenih skupaj.

NoSQL

NoSQL zbirke podatkov so bile zgrajene tako, da so bolj prožne od baz SQL, tudi da vsebujejo večje količine podatkov.

V DB2 NoSQL ni vnaprej določene sheme ali tabel. Obstajajo zbirke, v vsaki zbirki pa tudi dokumenti. To vam omogoča, da podatke shranjujete v različnih oblikah, ko pridejo. V eni zbirki lahko izberete več različnih dokumentov z različnimi polji. Možno je tudi ročno oblikovanje odnosov med zbirkami. Vendar pa niso primerni za takšen namen. Namesto tega lahko v isto zbirko shranite vse, kar je potrebno za eno poizvedbo.

Če ste oseba SQL, si lahko o zbirkah omislite tabele in dokumente kot vrstice s tabelami. Vendar ni nobenih omejitev za stolpce podatkov, ki jih lahko dodate s tabelo.

Vrnitev na prejšnji hipotetični primerek podjetja z uporabniki in naročili.

Zbirko uporabnikov bi lahko opredelili kot,

{id: 1, ime: ‘idris’, e-pošta: ‘[zaščitena e-pošta]‘}

Zbirka naročil bi se lahko opredelila kot,

{id: 1, številka naročila: 2000001, uporabniški_id: 1}

Vendar se v tem primeru želimo izogniti ročnemu združevanju obeh zbirk (česar v tem primeru ne bi smeli). V zbirko lahko shranimo vnose, ki so najbolj brani. Odločil sem se (za ta primer), da bo zbirka Naročila.

{id: 1, številka naročila: 200001, uporabnik {id: 1, ime: ‘idris’, e-pošta: ‘[zaščitena e-pošta]‘}}

V tem primeru nam ni več treba brati iz Zbirke uporabnikov in samo brati iz Zbirke naročil, ki zdaj vsebuje vse potrebne podatke.

Tu je treba opozoriti na ključno: Če gradite aplikacijo, ki veliko bere kot piše, je možnost NoSQL verjetno bolj primerna za vas. Ker bi lahko imeli vse podatke shranjene v isti zbirki in bi lahko udobno brali iz tega vira, da bi dobili vse potrebne podatke.

Vendar pa za aplikacijo, ki zahteva veliko pisanja (približno 10 000 zapisov na sekundo) v tej lestvici, ni dobro imeti možnosti NoSQL, kjer morate iste podatke zapisati na več lokacij. V tem primeru je verjetno primernejša možnost SQL, kjer imate odnose do vseh tabel in istih podatkov ni treba večkrat zapisati na več lokacij, posodabljanje podatkov na enem mestu je na voljo v drugih tabelah prek izhodnih razmerje. To seveda ne pomeni, da vsaka od teh baz podatkov ne more obravnavati obsega.

Skaliranje

Preučimo, kako deluje skaliranje.

SQL

SQL DB ni mogoče spreminjati vodoravno, ampak le navpično. Kaj to sploh pomeni?

Vodoravno skaliranje pomeni delitev podatkov iz ene baze podatkov v več baz podatkov, da se olajša obremenitev. Podatkov SQL pa zaradi svoje stroge narave ni mogoče razdeliti na ločene DB. Ustrezno določanje obsega SQL DB je povečanje prostora CPU, pomnilnika in diska obstoječega strežnika DB, kar pomeni, da ga vertikalno spreminjate.

vodoravno skaliranje

vertikalno skaliranje


NoSQL

NoSQL DB lahko spreminjamo tako vodoravno kot navpično. To je posledica prilagodljivosti pri njegovem shranjevanju podatkov. To torej omogoča, da se njegovi podatki razdelijo na več baz podatkov, kot je to primer z vodoravnim skaliranjem. Po potrebi se lahko tudi vertikalno spreminja.

Tu je treba opozoriti na ključno: Ko gre za skaliranje, je mogoče tako SQL kot NoSQL Baze podatkov učinkovito spreminjati. Vendar pa je za SQL DB lahko vertikalno skaliranje omejitev; en strežnik DB bo imel omejitev glede količine računalniške moči, ki jo lahko prenese.

Pomembno je tudi tukaj opozoriti, da pri večini aplikacij, ki jih boste izdelali, morda ne boste dosegli največ računalniških zmogljivosti svojega strežnika, vendar je to smiselno upoštevati. Vendar pa je za velike poslovne aplikacije, ki izvajajo SQL, priljubljena možnost za premagovanje te omejitve Sharding.

Kaj je Sharding?

Ostrenje je postopek razbijanja velikih miz na majhne koščke, ki jih imenujemo drobci. Ostrenje je mogoče storiti z vodoravno particijo baze podatkov. Tega ne gre zamenjati z vodoravnim in navpičnim skaliranjem. Vodoravno razdelitev se nanaša na postopek shranjevanja vrstic tabele v več vozlišč baze podatkov. Navpična particija na drugi strani zahteva shranjevanje stolpcev tabele na različna vozlišča. To omogoča, da baza podatkov učinkovito meri in poveča zmogljivost.

Primeri zbirke podatkov

SQL

  • MySQL – Zelo priljubljena odprtokodna baza podatkov. Izbirno zbirko podatkov za številne razvijalce PHP lahko preprosto uporabite tudi pri Node.js, C #, C ++, Java, Perl, Ruby in Python.
  • MSSQL – Microsoft SQL zagotavlja veliko stabilnosti, saj je njegov razvoj neposredno od Microsofta, ki ponuja tudi nekaj podpore v zvezi z obnovo po nesrečah.
  • MariaDB – To so na MySQL izdelali izdelovalci MySQL, ki so nameravali MariaDB obdržati kot brezplačno za vedno različico.
  • PostgresSQL – Zelo priljubljena baza podatkov z odprto kodo. Ponosno se ponaša kot najbolj napredna odprtokodna baza na svetu
  • Oracle – Običajno je prilagojen podjetniškim rešitvam podjetja Oracle z nekaj omejitvami v njegovi brezplačni različici.

NoSQL

  • MongoDB – Verjetno najbolj znan NoSQL DB, ki je pogost med razvijalci aplikacij, ki delajo s skladom MERN (MongoDB, Express, React, Node) ali skladom MEAN (MongoDB, Express, Angular, Node).
  • Firebase – Predstavljen leta 2011, Google pa ga je pridobil leta 2014, široko uporabljajo razvijalci spletnih in mobilnih aplikacij.
  • Apache Couch DB – NoSQL DB, ki temelji na dokumentu in shranjuje podatke kot JSON.
  • Redis: To je NoSQL DB, verjetno najbolj znan po uporabi pri shranjevanju podatkov z izbirnim časom življenja. Dobro je znana tudi po svoji hitrosti.

Zaključek

Ustvarite lahko kakršno koli aplikacijo z bazo podatkov SQL ali NoSQL. Odvisno je od vaših zahtev. Če razmišljate o zbirki podatkov, kjer imate več branja in manj zapisov, bi bil NoSQL dobra možnost. Če pa razmišljate o gradnji aplikacije z več zapisov kot prebranih, je SQL morda boljša rešitev. Če je vaša aplikacija zelo razširjena, lahko na koncu uporabite oba DB-a.

Oznake:

  • Baza podatkov

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