This work is licensed under a
Creative Commons Attribution-NonCommercial-ShareAlike 4.0
International License.
Een heel korte uitleg: SQL databases hebben stricte voorwaarden op datatypen en consistentie. Om snelheid te winnen en/of naar grotere netwerken te kunnen schalen zijn deze voorwaarden minder strikt in NoSQL.
Tegenwoordig is één van de meest fundamentele vragen, bij het maken van een applicatie, de keuze van het type database om data in op te slaan, SQL of NoSQL (not only SQL). De conventionele SQL ofwel relationele databases, waar we in de vorige hoofdstukken mee zijn gestart, zijn het resultaat van decenia lange evolutie van technologie, goede practische toepassing en grondig testen in toepassingen in de echte wereld. Relationele databases zijn ontworpen om transacties foutloos te laten verlopen voor zeer specifieke (vooral bedrijfs-) applicaties. Het nadeel van de relationele databases is dat de datastructuren van te voren vast moeten worden gelegd, juist om de betrouwbaarheid van de gegevens te kunnen toetsen. Omdat de gegevens in een relationele database ten alle tijden consistent moeten zijn (b.v. in banken mag geen geld zomaar van een rekening verdwijnen ) is het lastig om de gegevens over een heel groot netwerk te verdelen.
NoSQL databases zijn ontwikkeld om de restricties van relationele databases te omzeilen, omdat er toepassingen zijn waar er meer flexibiliteit nodig is en waar de snelheid van het aanleveren van gegevens belangrijk is. Bijvoorbeeld bij Facebook is de hoeveelheid gegevens gigantisch en kan bijvoorbeeld een bericht van een deelnemer behalve tekst ook andere media bevatten. De gegevens kunnen bij Facebook niet meer op één server(zelfs niet op één locatie) worden bewaard. Als bezoeker van Facebook wil je niet heel lang wachten op het tonen van informatie op je scherm. Onder andere Google, Amazon, Yahoo en Facebook zochten daarom een, voor hun meer geschikte, manier om voor hun enorme websites data op te slaan. In tegenstelling tot SQL databases kunnen NoSQL databases over honderden of duizenden servers worden verdeeld.
Een minder strikte structuur van de data, ofwel het gebruik van NoSQL databases, is gewenst in de volgende situaties:
Om de voordelen van NoSQL te realiseren moet er wel iets worden geofferd. NoSQL systemen hebben gewoonlijk niet hetzelfde niveau van data consistentie als SQL databases. Relationele database hebben juist snelheid en schaalbaarheid ingeleverd om aan de hoge consistentie vastgelegd in de ACID voorwaarden voor betrouwbare transacties. Op wikipedia worden ook een paar voorbeelden van hoe het fout kan gaan gegeven.
De ACID voorwaarden zorgen ervoor dat bewerkingen Atomair zijn (alle delen van een transactie lukken, of ze lukken allemaal niet), Consistent (Alle gebruikers zien de zelfde data), GeÏsoleerd (transacties concurreren niet) en Duurzaam (als een transactie is uitgevoerd overleven de gegevens een server uitval).
NoSQL databases hebben deze ACID voorwaarden grotendeels overboord gegooid. Voor jou als Facebook bezoeker is het niet belangrijk of een bericht dat wordt aangepast door een vriend direct binnenkomt of dat het oude bericht pas over een uur wordt vervangen. De informatie is dan op dat oude moment dus niet de juiste. Het kan zelfs zo zijn dat jij pas zijn derde versie te zien krijgt terwijl je al die tijd online bent. Voor beurstransacties zou iets dergelijks onverantwoordelijk zijn, ieder verhandeling van aandelen heeft effect op de waarde van een aandeel. Als jij als beurshandelaar er pas na een half uur achter komt dat een aandeel één euro is gekelderd terwijl je na een daling van 10 cent al had willen verkopen dan zal je van zo'n vertraging niet vrolijk worden.
Kortom SQL en NoSQL databases hebben verschillende eigenschappen, die afhankelijk van de applicatie de juiste keus kunnen zijn. Een mix van deze databases zou ook nog tot een mogelijkheid behoren. Alle veranderingen gaan richting een relationele database om connsistentie te garanderen. Vanuit deze database kunnen dan NoSQL databases worden gevormd die gebruikers snel van relevante maar niet tijdige informatie kunnen voorzien. Het is dus geen vraag als bijvoorbeeld neem ik schroevendraaier van merk A of merk B, maar meer een vraag als heb ik een kruiskop of een platte schroevendraaier nodig voor deze schroef. Ofwel, wat is het juiste instrument voor het werk?
Het fundamentele verschil tussen SQL en NoSQL is niet erg moeilijk. Zij hebben beide een verschillende filosofie over hoe data moet worden opgeslagen en opgevraagd.
Bij SQL databases heeft alle data een van te voren vastgelegde niet te veranderen structuur (=schema). Een attribuut heeft een vast dataype en een entiteit een vaste set van attributen. Bijvoorbeeld een attribuut mag alleen een geheel getal zijn. Het doel van deze structuur is om een database te kunnen normaliseren om onder andere redundantie te kunnen voorkomen. Daarnaast biedt deze structuur een relatief eenvoudige mogelijkheid om over tabellen heen gegevens te kunnen combineren.
Bij NoSQL,kan data worden opgeslagen in meer vrije vorm. Een attribuut kan in principe ieder datatype bevatten en een entiteit kan een verschillend aantal attributen bevatten. In de verschillende NoSQL databases vind je vier algemene modellen om data op te slaan:
De SQL (stuctured query language) die wordt gebruikt in de relationele databases geeft eenduidig de mogelijkheid om gegevens op te slaan of op te halen uit de database. Deze taal is zeer gestandariseerd. Hoewel verschillende databasemanagementsystemen kunnen verschillen in de precieze wijze van de SQL instructie (b.v., window functions) is de basis hetzelfde.
In tegenstelling, elke NoSQL database heef zo'n beetje een eigen syntax om de gegevens op te slaan of op te halen. CouchDB, bijvoorbeeld , gebruikt opdrachten in de vorm van JSON, opgestuurd via HTTP, om documents te creëren of op te halen uit de database. MongoDB stuurt JSON objecten over een binair protocol via een command-line instructie of via een programma bibliotheek.
Sommige NoSQL producten gebruiken een SQL-achtige taal, hoewel redelijk beperkt, om met de data te werken. Bijvoorbeeld Apache Cassandra, een column store database), heeft een eigen SQL-achtige taal, Cassandra Query Language or CQL. Sommige van de CQL instructies komen zo uit SQL, zoals de SELECT en INSERT instructie. Er is echter geen manier om gegevens samen te voegen (JOIN) of om subqueries (zie de cursus SQL) uit te voeren.
Gewoonlijk is de keuze voor NoSQL databases een “shared-nothing” architectuur. In een “shared-nothing” architectuur zijn er vele clusters van servers in het netwerk en opereert ieder cluster onafhankelijk van de andere. Als één cluster wordt bevraagd hoeft niet aan andere clusters worden gevraagd of de informatie al dan niet mag worden opgeslagen of verzonden. De verwerking van opdrachten, door klanten verstuurd, worden zeer snel verwerkt. Het dichtsbijzijnde of meest toepasselijke cluster voert de opdracht uit. Synchronisatie ( = gelijkschakelen ) van de clusters vindt wel op regelmatige basis plaats zodat data uiteindelijk consistent wordt. Dit betekent wel dat niet op alle clusters op ieder moment dezelfde informatie aanwezig is ofwel: het geheel is niet consistent.
Andere voordelen van “shared-nothing” zijn veerkracht en uitbreiding. Uitbreiding van het netwerk kan eenvoudig worden gedaan door een nieuw cluster te plaatsen en deze te sysnchroniseren met de andere clusters. Als één van de clusters uitvalt kunnen andere clusters gewoon doorgaan. Bijna alle data (vanaf de laatste synchronisatie voor uitval) is aanwezig, zelfs als er minder clusters zijn om de opdrachten van klanten te verwerken.
Merk wel op dat een “shared-nothing” er niet alleen voor NoSQL databases is. Ook de conventionele relationele databases kunnen via verschillende clusters worden aangeboden, maar de consistentie van de gegevens wordt dan wel geofferd. Doordat er tijd is tussen de synchronisaties van de databases op de verschillende locaties zijn de gegevens dus niet altijd hetzelfde.
Als NoSQL zoveel vrijheden biedt, waarom bannen we de rationele database dan niet helemaal uit? Het antwoord is simpel: Vele applicaties hebben de beperkingen, consistentie en betrouwbaarheid nodig die rationele databases bieden. In zulke gevallen zijn de “voordelen” van NoSQL zelfs nadelen. Een ander nadeel is dat de NoSQL systemen relatief nieuw zijn, daar waar relationele databases al een evolutie van 40 jaar achter de rug hebben.
Ook al sla je data in een meer vrije vorm op, er is toch bijna altijd een noodzaak om grenzen aan de vorm te stellen om de gegevens nuttig te maken. Als je NoSQL databases gebruikt dienen deze grenzen te worden afgedwongen door de code in de applicatie. In SQL kun je dat grotendeels overlaten aan het database management programma. De ontwikkelaar van de applicatie heeft nu de verantwoordelijkheid. Bijvoorbeeld: De ontwikkelaar kan binnen een applicatie een bepaalde vorm afdwingen, maar een andere applicatie die dezelfde database gebruikt ziet die vorm niet.
Sommige NoSQL oplossingen geven wel optionele datatypering en controle mechanismen daarop. Apache Cassandra, bijvoorbeeld, heeft een moeras van eigen datatypen die doen denken aan datatypen in relationele databases.
NoSQL databases ruilen strenge of directe consistentie in voor snellere toegang en prestatie. De traditionele databases houden streng vast aan de ACID voorwaarden De ACID voorwaarden worden anders afgehandeld in NoSQL databases. In plaats van directe consistentie over het netwerk is er een uiteindelijke consistentie, omdat er tijd nodig is om de data over het netwerk te kopiëren (synchronisatie). Gegevens toegevoegd op één server komt uiteindelijk overal beschikbaar, maar je weet alleen niet precies wanneer.
De wijze waarop betekenis is gegeven aan SQL transacties, ofwel het atomair zijn, zodat alle of geen enkele stap in een transactie wordt uitgevoerd, is typisch niet aanwezig in NoSQL. Als er slechts “één bron van waarheid” moet zijn, zoals bij een bank, dan werkt de NoSQL plosing niet erg goed. Je wilt niet dat de balans op je bankrekening verschilt afhankelijk van welke geldautomaat je hebt gebruikt.
Somige NoSQL databases hebben mechanismen om dit probleem deels te kunnen omzeilen. Bijvoorbeeld, MongoDB heeft garanties voor consistentie van individuele bewerkingen, maar niet voor de database als geheel. In Microsoft Azure CosmosDB kun je een niveau van consistentie selecteren voor iedere opdracht. Je kunt dus het gedrag bepalen dat het meest past bij je wensen. In het algemeen moet je er van uit gaan dat in NoSQL de data pas uiteindelijk consistent is.
De meeste NoSQL systemen zijn in de basis gelijk, maar hebben een compleet verschillende aanpak in de codering. Elk systeem heeft zijn eigen vraagtaal en datamangement.
Een gevolg hiervan is een mogelijk hoge mate van koppeling tussen de logica in de applicatie en de database. Dit is geen probleem als je niet van NoSQL systeem hoeft te veranderen, maar kan een struikelblok zijn als je in de loop der tijd moet wisselen van database.
Als je bijvoorbeeld van MongoDB naar CouchDB (of andersom) wilt overstappen dan moet er meer gebeuren dan alleen de gevens overzetten. Je moet delen van je applicatie herschrijven omdat de syntax om de database te benaderen anders is.
vaardighedenNog een probleem bij het gebruik van NoSQL is het gebrek aan professionals. Er is een redelijk grote markt aan talentvolle personen met betrekking tot SQL databases, terwijl deze markt NoSQL nog aan het ontluiken is.
De andere kant op: Indeed.com rapporteerde in het najaar van 2017 dat het aantal vacatures over de laatste 3 jaar, voor de conventionele SQL databases, MySQL, Microsoft SQL Server, Oracle Database, hoger is dan het aantal vacatures voor MongoDB, Couchbase en Cassandra. De vraag naar NoSQL groeit, maar is slechts een fractie van de arbeidsmarkt voor SQL.
We kunnen verwachten dat de verschillen tussen SQL en NoSQL systemen in de toekomst zullen verdwijnen. Vele SQL databases kunnen nu al overweg met JSON documenten als datatype, en kunnen die ook bevragen. Sommige hebben zelfs ingebakken manieren om voorwaarden aan JSON data te stellen, zodat dezelfde consistentie kan worden afgedwongen als bij de gewone datatypen.
Aan de andere kant worden er aan NoSQL databases niet alleen SQL-achtige instructie talen toegevoegd, maar ook de andere mogelijkheden die de traditionele databases bieden. MarkLogic en RavenDB, twee document databases, beloven aan de ACID voorwaarden te voldoen.
Hier en daar zijn er aanwijzingen dat de volgende generaties van database systemen beide zijden zullen overbruggen en dus zowel NoSQL als SQL functionaliteit zullen bieden. De komende jaren zullen echter pure SQL en NoSQL oplossingen nog hun eigen plaats innemen in data systemen.
We zullen het garagebedrijf Nieuwenhuis gebruiken om het verschil tussen een aanpak in SQL en NoSQL dataopslag duidelijk te maken. In het opzetten van het Entiteit Relatie Model hebben we voor de orderverwerking de volgende volledig genormaliseerde entiteiten gemaakt: klant, order, order_product en product (We laten de medewerker even buiten beschouwing). In de bijbehorende tabel klant komt geen attribuut order voor. In de tabel order vinden we wel een verwijzing naar de klant via attribuut klantid, maar vinden we geen producten. De koppeling tussen producten en de order vindt plaat in de tabel order_product waarzowel de verwijzing naar de order via attribuut orderid als de verwijzing naar het product via attribuut productid aanwezig is.
De tabellen hiernaast in de box "opslag in SQL database" tonen de gegevens van klant 1, de door klant 1 geplaatste order met id 1 en de daarin aanwezige producten met id 1 en 3. In een applicatie zal de JOIN query:
SELECT * FROM ((klant INNER JOIN `order` ON `order`.klantid=klant.id) INNER JOIN order_product ON `order_product`.orderid= `order`.id) INNER JOIN product ON `order_product`.productid= `product`.id WHERE `order`.id='1';
moeten worden uitgevoerd om de gegevens te koppelen. Heeft garagebedijf Nieuwenhuis nu miljoenen klanten en een veelvoud daarvan aan orders met heel veel producten in de orders dan kan het uitvoeren van die query een flinke tijd in beslag nemen. Tijd die voor een klant als hinderlijk zal worden ervaren.
Dit probleem zou dan kunnen worden opgelost door te denormaliseren. De hele relatie uit de bovenstaande query wordt opgeslagen in een NOSQL database als één record in de vorm van een JSON document (zie de box JSON document). Ofwel alle gegevens van de klant staan in één document. Als een klant nu zijn gegevens opvraagt hoeft slechts gezocht te worden naar één plek in de database in plaats van meerdere plekken in meerdere tabellen. Dit kan aanzienlijke tijdwinst opleveren.
Aan de anderkant is het nu wel lastiger voor een applicatie om bijvoorbeeld de omzetgegevens op te vragen. De documenten van alle klanten moeten onderzocht worden of er een eigenschap order aanwezig is. Dit is dan weer een tragere actie dan alleen de order_product tabel te bevragen.
{ ... } = waarden definitie van een object (record) van een entiteit (tabel);"sleutel":"waarde" = De sleutel is een attribuut behorende bij de entiteit met een bijbehorende simpele waarde in een record;"sleutel":{waarde} = De sleutel is een attribuut behorende bij de entiteit met bijbehorend object van een andere entiteit
waarmee dit object een relatie heeft;"sleutel":[{waarde1},...,{waarde2}] = De sleutel is een attribuut behorende bij de entiteit met
bijbehorend een lijst objecten van een andere entiteit waarmee dit object een relatie heeft.SELECT * FROM (klant INNER JOIN uitleen ON uitleen.klantid=klant.id) INNER JOIN boek ON uitleen.boekid= boek.id WHERE klant.id=142233