SQL versus NoSQL – Welke moet je gebruiken voor je volgende project?

Een van de meest gestelde vragen – welke database moet ik gebruiken …


SQL staat voor Structured Query Language. Het werd voor het eerst ontwikkeld in de jaren zeventig door een team van IBM-onderzoekers, NoSQL-databases, maar werden in 1998 voor het eerst gebruikt door Carlo Strozzi.

Het meest voorkomende verschil tussen deze twee databases (DB) -systemen is dat SQL relationeel is en NoSQL niet-relationeel.

Laten we diep in deze twee databases duiken om uw beslissing beter te informeren wanneer u de volgende keer een database voor uw project overweegt.

Database structuur

Laten we het hebben over structureren.

SQL

SQL database hebben een duidelijke schemastructuur.

Een schema bevat tabellen en elke tabel bevat een bepaald aantal kolommen. Dat betekent dat een gebruiker de tabel niet kan bijwerken buiten het aantal kolommen dat in de tabel is gespecificeerd. Dit is met name handig wanneer u de gegevensintegriteit wilt behouden en ook wilt zorgen voor het soort gegevens dat in uw database wordt opgeslagen.

Elke tabel in een SQL-database kan gerelateerd zijn. d.w.z. u kunt relaties tussen tabellen hebben. Deze relaties kunnen One to Many, Many to Many of One to One zijn. Het type relatie dat u implementeert, hangt af van wat u nodig heeft.

Laten we bijvoorbeeld eens kijken naar de hypothetische situatie; we hebben een bedrijf met gebruikers en gebruikers kunnen bestellingen plaatsen voor producten. Vervolgens kunnen we besluiten dat gebruikers meerdere bestellingen kunnen maken, maar elke bestelling kan slechts door één gebruiker worden gemaakt. Dit zou een voor veel relaties zijn, d.w.z. een gebruiker voor veel bestellingen. Daarom ziet de tabelstructuur voor beide tabellen er als volgt uit.

In onze database zouden we een gebruikerstabel kunnen hebben, zoals hieronder gestructureerd,

gebruikerstabel
—————————————————-
id | naam | e-mail
—————————————————–
1 Idris [email beveiligd]

We kunnen ook een besteltabel hebben

orders_table
———————————————————————————
id | user_id | bestellingsnummer
———————————————————————————
1 1 20000001

De user_id op de ordertabel maakt het gemakkelijk om elke order op de ordertabel toe te wijzen aan de gebruiker waartoe deze behoort. In het geval van een één-op-één-relatie, kunnen we de order_id ook op de users_table hebben als we besluiten om de gebruiker te krijgen met de bijbehorende order-id.

Voor veel tot veel situaties is er meestal een extra tafel, een draaitabel genaamd, bij betrokken. Hierdoor kunnen meerdere records aan elkaar worden toegewezen. Met behulp van de bovenstaande instantie. Wij zouden hebben,

gebruikerstabel
————————————————————————————-
id | naam | e-mail
————————————————————————————-
1 Idris [email beveiligd]

en de ordertabel zal zijn

orders_table
———————————————————
id | bestellingsnummer
———————————————————
1 2000001

en dan zal de draaitabel zowel ID’s als externe sleutels bevatten.

users_orders_table
——————————————————————————
id | order_id | gebruikersnaam
——————————————————————————
1 1 1

Op basis van deze structuur die door SQL wordt geboden, kunt u gemakkelijk Joins tussen tabellen schrijven die gegevens uit verschillende tabellen bevatten die in één query zijn samengevoegd.

NoSQL

NoSQL databases zijn gebouwd om flexibeler te zijn dan SQL-databases en ook om grotere hoeveelheden gegevens te bevatten.

In NoSQL DB’s is er geen vooraf gedefinieerd schema of tabellen. Er zijn collecties en in elke collecties zijn er documenten. Hierdoor kunt u gegevens in verschillende vormen opslaan zoals ze komen. U kunt ervoor kiezen om meerdere verschillende documenten met verschillende velden in één collectie te hebben. Het is ook mogelijk om handmatig relaties tussen collecties te smeden. Daarvoor zijn ze echter niet geschikt. In plaats daarvan kunt u alles wat nodig is voor een enkele zoekopdracht in dezelfde verzameling opslaan.

Als u een SQL-persoon bent, kunt u collecties beschouwen als tabellen en documenten als rijen met de tabellen. Er zijn echter geen beperkingen voor de kolommen met gegevens die u aan de tabel kunt toevoegen.

Terug naar ons eerder gedefinieerde hypothetische voorbeeld van een bedrijf met gebruikers en bestellingen.

Een gebruikerscollectie kan worden gedefinieerd als,

{id: 1, naam: ‘idris’, e-mail: ‘[email beveiligd]‘}

En de orderverzameling kan worden gedefinieerd als,

{id: 1, ordernummer: 2000001, user_id: 1}

In dit geval willen we echter voorkomen dat we handmatig moeten deelnemen aan beide collecties (wat we in dit geval niet zouden moeten doen). We kunnen items in de collectie opslaan die het meest gelezen worden. Ik heb besloten (voor dit voorbeeld) dat dit de Orders-collectie zal zijn.

{id: 1, ordernummer: 200001, gebruiker {id: 1, naam: ‘idris’, e-mail: ‘[email beveiligd]‘}}

In dit geval hoeven we niet meer voor te lezen uit de gebruikerscollectie en alleen voor te lezen uit de bestellingencollectie, die nu alle gegevens bevat die we nodig hebben.

Een belangrijk ding om hier op te merken: Als u een app bouwt die veel leest dan schrijft, is een NoSQL-optie waarschijnlijk geschikter voor u. Omdat u uw gegevens allemaal in dezelfde verzameling kunt opslaan en u gemakkelijk uit die bron kunt lezen om alle vereiste gegevens te krijgen.

Echter, voor een applicatie die veel schrijfbewerkingen (ongeveer 10.000 schrijfbewerkingen per seconde) op die schaal vereist, is het geen goed idee om een ​​NoSQL-optie te hebben waarbij u dezelfde gegevens naar meerdere locaties moet schrijven. In deze situatie is een SQL-optie waarschijnlijk geschikter, waarbij u relaties hebt die bestaan ​​voor alle tabellen en dezelfde gegevens niet herhaaldelijk naar meerdere locaties hoeven te worden geschreven, het bijwerken van gegevens op één locatie kan beschikbaar zijn voor andere tabellen via de exiting relatie. Dit betekent natuurlijk niet dat elk van deze databases schaal niet aankan.

Schalen

Laten we eens kijken hoe schalen werkt.

SQL

SQL-databases kunnen niet horizontaal maar alleen verticaal worden geschaald. Wat betekent dit eigenlijk??

Horizontaal schalen betekent het splitsen van gegevens van één database in meerdere databases om het laden te vergemakkelijken. SQL-gegevens kunnen echter vanwege hun strikte aard niet worden opgesplitst in afzonderlijke databases. Het juiste voor het schalen van een SQL-database is het vergroten van de CPU, het geheugen en de schijfruimte van de bestaande databaseserver, en dit is wat het betekent om deze verticaal te schalen.

horizontale schaalverdeling

verticale schaalverdeling


NoSQL

NoSQL DB’s kunnen zowel horizontaal als verticaal worden geschaald. Dit komt door de flexibiliteit in de gegevensopslag. Hierdoor kunnen de gegevens daarom worden opgesplitst in meerdere databases, zoals het geval is bij horizontale schaling. Het kan indien nodig ook verticaal worden geschaald.

Een belangrijk ding om hier op te merken: Als het gaat om schalen, kunnen zowel SQL- als NoSQL-databases effectief worden geschaald. Voor SQL DB’s kan verticale schaling echter een beperking zijn; een enkele DB-server heeft een beperking op de hoeveelheid rekenkracht die hij kan dragen.

Het is ook belangrijk om hier op te merken dat voor de meeste applicaties die u gaat bouwen, u mogelijk niet het maximale computervermogen van uw server haalt, maar het is handig om hier rekening mee te houden. Voor grote zakelijke toepassingen die SQL implementeren, is Sharding een populaire optie om deze beperking te omzeilen.

Wat is scherpen?

Sharding is het proces waarbij de grote tafels in kleine stukjes worden gebroken, die shards worden genoemd. Sharding kan worden gedaan door een database horizontaal te partitioneren. Dit moet niet worden verward met horizontale en verticale schaling. Horizontale partitionering verwijst naar het opslaan van rijen van een tabel in meerdere databaseknooppunten. Verticale partitionering vereist daarentegen het opslaan van kolommen van een tabel op verschillende knooppunten. Hierdoor kan de database effectief worden geschaald en worden de prestaties verbeterd.

Database voorbeelden

SQL

  • MySQL – Een zeer populaire open-source database. De database van keuze voor veel PHP-ontwikkelaars kan echter ook gemakkelijk worden gebruikt met Node.js, C #, C ++, Java, Perl, Ruby en Python.
  • MSSQL – Microsoft SQL biedt veel stabiliteit omdat de ontwikkeling rechtstreeks afkomstig is van Microsoft, dat ook enige ondersteuning biedt op het gebied van noodherstel.
  • MariaDB – Dit is gebouwd op MySQL door de makers van MySQL, met de bedoeling MariaDB te behouden als een gratis versie voor altijd.
  • PostgresSQL – Een zeer populaire open-source database. Trots op zichzelf als ‘s werelds meest geavanceerde open source database
  • Oracle – Dit is meestal afgestemd op de bedrijfsoplossingen van Oracle, met enkele beperkingen op de gratis versie.

NoSQL

  • MongoDB – Waarschijnlijk de meest bekende NoSQL DB, gebruikelijk onder applicatieontwikkelaars die werken met MERN-stack (MongoDB, Express, React, Node) of MEAN-stack (MongoDB, Express, Angular, Node).
  • Firebase – Geïntroduceerd in 2011 en overgenomen door Google in 2014, wordt veel gebruikt door ontwikkelaars van web- en mobiele applicaties.
  • Apache Couch DB – Een documentgebaseerde NoSQL DB die gegevens opslaat als JSON.
  • Redis: Dit is NoSQL DB, waarschijnlijk het meest bekend om zijn gebruik bij het opslaan van gegevens met optionele tijd om te leven. Het staat ook bekend om zijn snelheid.

Conclusie

U kunt elk type applicatie maken met een SQL- of NoSQL-database. Het hangt af van uw wensen. Als u een database overweegt waar u meer leest en minder schrijft, is een NoSQL wellicht een goede optie. Als u echter overweegt een app te bouwen met meer schrijf- dan leesbewerkingen, is een SQL wellicht de betere oplossing. Wat betreft schaalbaarheid, wanneer uw app een zeer grote schaal bereikt, gebruikt u mogelijk beide DB’s.

TAGS:

  • Database

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