SQL vs. NoSQL: een uiteenzetting

SQL vs. NoSQL: een uiteenzetting


Vervang deze tekst door een grafische illustratie van het project.

Project aangeboden door Tim Dhondt voor het behalen van de graad van Bachelor in de New Media and Communication Technology Academiejaar 2012-2013 Stageplaats : Carambla Stagementor : Francis De Brabandere Stagebegeleider : Steven Verborgh


Woord vooraf Ik ben Tim Dhondt en zit op het moment van dit schrijven in mijn laatste jaar NMCT (New Media and Communication Technology) aan Howest in Kortrijk. In het middelbaar koos ik al voor de wetenschappen, en om precies te zijn de Wetenschappen-Wiskunde richting. In combinatie met het feit dat ik al van kindsbeen gefascineerd was door de magische doos die de computer was en dat mijn vader in de IT-sector werkt, kon het bijna niet anders dan dat ik zelf ook de IT-richting uitging. Ik wil ook specifiek mijn dank betuigen aan twee personen, namelijk Francis De Brabandere en Steven Verborgh. Francis De Brabandere is mijn stagementor en co-founder van de start-up Carambla, waar ik stage loop. Hij heeft mij 13 weken bijgestaan op de stage, heel veel nieuwe dingen bijgeleerd van onschatbare waarde en mij bijgestaan waar hij kon voor mijn bachelorproef. Voor dit alles zeg ik: “danku”. Steven Verborgh, die vorig jaar een docent van mij was, is mijn stagebegeleider. Allereerst wens ik hem nog eens proficiat met het vaderschap tijdens mijn stage. Daarnaast wil ik hem bedanken voor de evaluaties, de tips en de bijsturingen die hij gaf voor zowel de bachelorproef als de eindpresentatie. Deze bachelorproef is geschreven als eindwerk voor de Professionele Bachelor in de New Media and Communication Technology. Met dit werk bewijs ik dat ik de competenties behaald heb die verwacht worden van een bachelor. Dit eindwerk is vooral geschreven voor mensen die zich willen verdiepen in de werking van databases, zowel beginners als meer gevorderden. Alsook voor mensen die applicaties bouwen en onzeker zijn over de keuze van het te gebruiken type database voor hun applicatie. Deze scriptie is bedoeld als leidraad voor diegene die twijfelen tussen het gebruik van een SQL of een NoSQL database, of als studiemateriaal voor de beginnende IT’er die zich wil verdiepen in de wereld van SQL en consoorten.

Tim Dhondt


Samenvatting Deze bachelorproef behandelt de discussie tussen de twee grote types databases: SQL en NoSQL. Dit onderwerp is sinds een paar jaar al oorzaak geweest van vele verhitte discussies over welk type nu de betere is: SQL databases aan de ene kant (relationele databases) en NoSQL databases aan de andere kant (niet-relationele databases). De scriptie zal daarom ook deze probleemstelling behandelen: welke van de twee is nu effectief beter? Is het SQL, omdat deze al sinds jaar en dag gebruikt wordt en meer built-in features heeft, of is het NoSQL? Want werken met “Big Data” en horizontaal schalen is hot stuff tegenwoordig. Om een vergelijking te kunnen maken, moeten we eerst grondig weten hoe beide in elkaar zitten en hoe ze data bewaren, kortom we moeten weten hoe ze er vanbinnen en vanbuiten uitzien. Hiervoor gaan we ze beide apart bestuderen en de geschiedenis, de eigenschappen, pro’s en contra’s, … bekijken. Pas wanneer we van beide typen databases weten hoe ze in elkaar zitten, kunnen we ze in een één-tegen-één strijd tegenover elkaar plaatsen. Hierin bekijken we welke aspecten belangrijk zijn, en welke de beperkingen zijn. Zijn er ook ongelooflijke afknappers of juist ideale gelegenheden om zeker één van de twee (niet) te gebruiken? Door de reeds vele discussies verkondig ik niet dat ik een antwoord zal bieden op de vraag “Welk type is er beter?”, maar wel op de vraag “Welk type is er beter in een specifieke situatie?”. Hiervoor zal ik als laatste onderdeel van dit naslagwerk verschillende situaties beschrijven en bij elke situatie het best passende type voorstellen en ook argumenten waarom. Het uiteindelijke resultaat is wel te verwachten: er is geen betere, er is alleen maar een betere in bepaalde situaties. En zelfs dan kan je met relationele databases, wanneer je er goed mee vertrouwd bent, heel veel van use cases afhandelen zonder echt in de problemen te geraken. Natuurlijk is het niet gewenst om veel performantieverlies te lijden en zeker niet als je een IT-gigant bent als bijvoorbeeld Google of Amazon. De stelling die je zeker en vast moet onthouden omtrent databases in het algemeen (of ze nu relationeel zijn of niet) is hoe dan ook “bezint eer ge begint”.

Tim Dhondt


Verklarende woordenlijst API API of application programming interface is een protocol dat gebruikt wordt door software componenten, zodat deze componenten gemakkelijk met elkaar in verbinding kunnen staan. Het is een protocol dat voor een bibliotheek van data zit, zodat deze bibliotheek op specifieke manieren kan worden aangesproken. Blob Een blob (of binary large object) is een verzameling van binaire data die als één en dezelfde entiteit worden bewaard in een DBMS. Over het algemeen gaat dit over multimediaobjecten zoals afbeeldingen en audio, maar soms ook over uitvoerbare code. Databasemanagementsysteem (DBMS) Een databasemanagementsysteem of DBMS is het programma dat alle data die aanwezig is in een database beheert. Dit is één van de drie onderdelen van een database, hiernaast zijn er nog de opgeslagen data zelf en de gebruikersinterface. Bekenden onder deze noemer zijn: MySQL, Microsoft SQL Server, Oracle, … Denormalisatie Denormalisatie is het proces dat probeert de lees-performantie te verbeteren van een database door redundante data toe te voegen of data te groeperen. Horizontaal schalen Dit is één van de twee methodes om meer middelen toe te voegen aan een applicatie. Horizontaal schalen gaat meer eenheden (in het geval van databases zijn dit servers) toevoegen aan het systeem om zo de applicatie (en database) te gaan verdelen over meerdere eenheden. Met deze methode kan je zware taken uitvoeren die vroeger alleen maar door een heel erg krachtige wetenschappelijke computer konden worden uitgevoerd. En door de lagere kost van de “standaard”-modellen, is dit stukken goedkoper. NoSQL NoSQL slaat – in tegenstelling tot SQL – niet op een taal, maar enkel en alleen op het type van de database. Deze databases worden dan bestempeld als niet-relationeel, gedistribueerd, open-source en horizontaal schaalbaar. De oorspronkelijke intentie was om het te gaan gebruiken voor moderne web-databases, en dat sinds het jaar 2009. De gemeenschap is sindsdien erg gegroeid, en heeft de verklaring van NoSQL – die oorspronkelijk stond voor ‘geen SQL’ – veranderd naar ‘Not Only SQL’ (niet alleen SQL). Open source Open source is de benaming voor een product dat de bronnen openstelt voor het publiek. Een project kan tijdens de ontwikkeling open source zijn, maar eenmaal in productie gaat

Tim Dhondt


het slot op de deur; het kan ook starten achter slot en grendel en bij productie zijn deuren openzetten; of over de hele lijn alle bronnen publiek te maken. Sharding Sharding is een design principe waarbij de rijen van een database afzonderlijk worden bewaard i.p.v. deze te gaan opsplitsen volgens kolommen. Elke rij is deel van een shard, en die shards kunnen op hun beurt op verschillende servers staan. SQL SQL staat voor Structured Query Language en is een standaardtaal die gebruikt wordt door relationele DBMS. Men kan met SQL verschillende taken uitvoeren waaronder data uit de database opvragen, deze gaan aanpassen of nieuwe data toevoegen. Thread Een thread is het kleinste op zichzelf staande proces dat kan beheerd worden door het operating systeem. Je kan een thread zien als de kleine vorm van een proces (een proces kan een applicatie zijn, een taak, …), zodoende bestaat 1 proces uit vele threads. Tuple Een tuple wordt gebruikt in de wiskunde of computer wetenschappen en is een gesorteerde lijst van elementen. Deze lijst kan verschillende types van elementen bevatten en elk element kan door middel van zijn index worden opgevraagd. UnQL UnQL staat voor Unstructured Query Language en de productie hiervan is gestart in 2011, dit met dezelfde reden als die waarom SQL tot leven is gekomen: een standaard. Verticaal schalen Dit is één van de twee methodes om meer middelen toe te voegen aan een applicatie. In tegenstelling tot horizontaal schalen, focust verticaal schalen zich maar op één eenheid. Er wordt dan in bijvoorbeeld een server meer geheugen gestoken of grotere harde schijven, in plaats van meer servers te plaatsen. Dit soort schalen is voordeliger voor virtualisatie omdat de draaiende operating systemen en applicaties dan meer middelen hebben om met elkaar te delen.

Tim Dhondt


Inhoudstafel Woord vooraf .......................................................................................................................... Samenvatting ........................................................................................................................... Verklarende woordenlijst ......................................................................................................... Inhoudstafel............................................................................................................................. Carambla, een start-up als geen ander ................................................................................... 8 1. SQL .................................................................................................................................. 9 1.1

Geschiedenis van de taal.......................................................................................... 9

1.2

Waarom kwam SQL in de wereld? ........................................................................... 9

1.3

Hoe zit SQL in elkaar? ............................................................................................ 10

1.3.1

Data Manipulation Language .......................................................................... 10

1.3.2

Data Control Language.................................................................................... 10

1.3.3

Data Definition Language ................................................................................ 11

1.4

Structuur van SQL databases ................................................................................. 11

1.4.1

Entiteiten ........................................................................................................ 11

1.4.2

Entiteit-types .................................................................................................. 12

1.4.3

Attributen ....................................................................................................... 12

1.4.4

Regels van de opbouw .................................................................................... 12

1.4.5

Relaties ........................................................................................................... 13

1.5

Transacties............................................................................................................. 14

1.6

Opbouw van queries .............................................................................................. 14

1.6.1

SELECT-statement ........................................................................................... 15

1.6.2

Onderdelen van de DML ................................................................................. 15

1.6.3

Onderdelen van de DDL .................................................................................. 16

1.6.4

Onderdelen van de DCL .................................................................................. 16

2. NoSQL ........................................................................................................................... 17 2.1

Geschiedenis van de term ...................................................................................... 17

2.2

UnQL ..................................................................................................................... 17

2.2.1

Opbouw van queries ....................................................................................... 17

Tim Dhondt


2.2.2 2.3

Hoe ver staat UnQL nu? .................................................................................. 19

Doel van niet-relationele databases ....................................................................... 19

2.3.1

Big Users ......................................................................................................... 19

2.3.2

Big Data .......................................................................................................... 19

2.3.3

Cloud Computing ............................................................................................ 20

2.4

Type NoSQL Databases .......................................................................................... 20

2.4.1

Key-Value Store .............................................................................................. 21

2.4.2

Document Store.............................................................................................. 21

2.4.3

Graph Database .............................................................................................. 22

3. SQL vs. NoSQL ............................................................................................................... 23 3.1

Transacties............................................................................................................. 23

3.2

Schaalbaarheid ...................................................................................................... 24

3.2.1

Locking ........................................................................................................... 24

3.2.2

Referentiële integriteit.................................................................................... 25

3.3

Beveiliging ............................................................................................................. 26

4. Use Cases ...................................................................................................................... 28 4.1

Groei in data? ........................................................................................................ 28

4.2

Gebruikersexplosie ................................................................................................ 28

4.3

Kan downtime geoorloofd worden? ....................................................................... 29

4.4

Gevoelige data overdracht? ................................................................................... 29

4.5

Specifieke data-modellen....................................................................................... 29

4.6

Geld is een struikelblok? ........................................................................................ 29

4.7

Vertrouwde omgeving ........................................................................................... 30

Conclusie ............................................................................................................................. 31 Literatuurlijst ....................................................................................................................... 34 Figurenlijst ........................................................................................................................... 37

Tim Dhondt


Carambla, een start-up als geen ander Voor mijn stage zat ik bij een kleine start-up genaamd Carambla. Carambla is, op het moment van dit schrijven, gesitueerd aan de Zuiderpoort in Ledeberg (naast de Financiële Overheidsdienst Belastingen). De “core business” van het bedrijf is het idee om parkeerplaatsen te delen. Dit betekent dat mensen met privé parkeerplaatsen deze kunnen registreren op de website, zodat later mensen via de mobiele Carambla appgebruik kunnen maken van door particulieren ter beschikking gestelde plaatsen. Op dit moment kan je enkel nog maar instant parkeren, maar er wordt gewerkt om in de toekomst abonnementen en reservaties aan te bieden. Start-ups maken vaak gebruik van nieuwe en open-source technologieën. Mee zijn met de technologieën van het moment is soms een hele opdracht, maar het is wel cruciaal om het verschil te kunnen maken in een sector die constant verandert. Een start-up als Carambla heeft ook zijn eigen sfeer: met een kleine groep van mensen wordt de band tussen de verschillende werknemers ook groter. Los van dit alles vond ik het idee van het delen van privé parkeerplaatsen ook wel heel goed gevonden en de visie die ze hadden om Carambla wat bij te sturen is wat me volledig heeft binnengezogen. Deze open-source technologieën gebruiken heel vaak NoSQL-databases (aangezien deze ook over het algemeen open-source zijn). Ik kwam dus in mijn eerste weken op mijn stage constant in aanraking met een NoSQL database. Aangezien wij op school geen NoSQL in het lessenpakket hadden, wist ik hier aanvankelijk zeer weinig over, maar het intrigeerde me wel en ik ging op onderzoek. Later maakte ik dan ook gebruik van een SQL-database (PostgreSQL voor geo-locaties), en vroeg me af welk type database (SQL of NoSQL) nu eigenlijk beter was, en in welke situatie. Zo kwam ik bij het idee om de vergelijking te maken tussen beide, situaties te bedenken waarin databases gebruikt worden en dan te kijken welk van beide types het beste past. Voor een bedrijf is deze informatie heel belangrijk aangezien men dan voor de juiste situatie het juiste type database kan kiezen, zodat het systeem performant en schaalbaar is. Dit is voor een start-up misschien nog crucialer dan voor een KMO of een groot bedrijf.

Tim Dhondt

8


1. SQL 1.1

Geschiedenis van de taal

SQL1 is ontstaan in de loop van de jaren zeventig, ze werd ontwikkeld door IBM, een bedrijf dat de dag van vandaag nog steeds actief is op het vlak van computer technologie. SQLdatabases zijn relationele databases, dit komt omdat de taal zelf gebaseerd is op de relationele algebra. Deze relationele algebra is enkel en alleen tot stand gekomen om een theoretische basis te bieden voor deze taal, en bij uitbreiding voor relationele databases. Deze wiskunde maakt gebruik van tuples2 – dit is een geordende lijst van variabelen – en identificeert de aparte elementen door een naam (of attribuut). Dit is anders dan voor andere soorten verzamelingen waar de identificatie vooral gebeurt door een index. Hierdoor krijg je relaties: een attribuut die een bepaalde waarde bevat. Over de loop van zo’n tien jaar zijn er verschillende vormen van SQL geweest, maar pas in de jaren tachtig werd SQL definitief gestandaardiseerd. Ondanks dat zijn er nog steeds nieuwe versies van SQL die het levenslicht zien, zo kwam er SQL 1999, SQL 2003, SQL 2008 en op dit moment SQL 2011. Dit is reeds de zevende revisie (sinds de standaardisering) van de taal in een loop van 25 jaar.

1.2

Waarom kwam SQL in de wereld?

IBM ontwikkelde SQL in de eerste plaats voor de modale eindgebruiker, in dit geval business managers. Zo konden zij het bedrijf waar ze toe behoorden gaan analyseren om zo alles beter te weten te komen wat er zich speelde in het bedrijf. Maar om SQL te gebruiken had je kennis nodig over de database die je wil ondervragen, wat helemaal niet zo evident was voor business managers, aangezien zij vaak niet heel technisch zijn aangelegd, laat staan weten hoe de structuur van de database in mekaar steekt. Hierdoor is het gebruik van SQL overgeschakeld van de business managers naar de programmeurs. De programmeurs schreven dan applicaties met een gebruikers interface voor de business managers, zodat zij hun analyses konden blijven doen. Ontwikkelaars kunnen dan via een API3 connectie maken met de desbetreffende database. Deze API’s verschillen van programmeertaal tot programmeertaal. Zo is er voor Java JDBC en voor .NET ODBC.

1

Zie verklarende woordenlijst

2


3


Tim Dhondt

9


Het huidige doel van SQL is dus niet meer om een taal te bieden voor een eindgebruiker, maar om een ontwikkelaar toe te laten een connectie te maken tussen applicaties en databases.

1.3

Hoe zit SQL in elkaar?

SQL bestaat uit drie grote onderdelen en deze zijn de Data Manipulation Language (DML), de Data Control Language (DCL) en de Data Definition Language (DDL). 1.3.1 Data Manipulation Language De Data Manipulation Language (vrij vertaald: de Data Manipulatie Taal) is een taal die men gebruikt om gegevens aan de database toe te voegen, te verwijderen of te wijzigen. Deze taal omvat verschillende commando’s die, zoals hierboven al vermeld, data kunnen manipuleren zonder de structuur van tabellen en database-objecten te wijzigen. In SQL zijn dit dan de INSERT-, DELETE- en UPDATE-commando’s. De zuivere lees-vorm van SELECT (SELECT … FROM …) manipuleert geen data en hoort dus volgens de standaard niet bij de DML. Er bestaat wel een vorm van de SELECT die wel data wijzigt (SELECT … IN …) en deze zit dan wel in deze groep. Maar in alledaags gebruik wordt er geen onderscheid gemaakt tussen beide SELECT’s en neemt men aan dat de SELECT een onderdeel is van de DML. De DM-talen kunnen in twee types worden onderverdeeld, namelijk imperatieve talen en declaratieve talen. De imperatieve talen beschrijven de procedures van hoe iets moet gebeuren of in elkaar zit, terwijl de declaratieve talen beschrijven wat een actie effectief doet. SQL zit geklasseerd onder de declaratieve talen aangezien elk commando vertelt wat de database moet doen. 1.3.2 Data Control Language De Data Control Language (vrij vertaald: de Data Controle Taal) is een taal die de toegang tot de database beheert. Hierin zitten dus de commando’s om verschillende rechten toe te kennen aan bepaalde gebruikers voor deze database. Om rechten toe te voegen gebruik je het GRANT-commando (met daarbij het toe te kennen recht, bv.: GRANT CONNECT). Om rechten te verwijderen doe je juist hetzelfde, alleen vervang je het GRANT-commando door REVOKE. Andere commando’s die ook aanwezig zijn in de DCL, maar geen betrekking hebben op de rechten van de database zijn onder andere CONNECT, COMMIT en ROLLBACK. CONNECT connecteert met de database, COMMIT gaat de acties van een vorig commando

Tim Dhondt

10


bewaren (permanent maken) en ROLLBACK gaat in plaats van de acties permanent te maken, deze ongedaan maken (terugkeren naar een vorige versie). 1.3.3 Data Definition Language De Data Definition Language of Data Description Language (vrij vertaald: Data Beschrijvingstaal) is een taal die de database tabellen definieert. De DDL is voor tabellen eigenlijk wat de DML is voor data: je kan een nieuwe tabel aanmaken (je kan een nieuwe record toevoegen), je kan een bestaande tabel verwijderen (je kan een bestaande record verwijderen) en je kan een bestaande tabel wijzigen (je kan een bestaande record wijzigen). De DDL heeft ook commando’s hiervoor, maar onder een andere naam: CREATE (maakt een nieuwe tabel aan, equivalent van de INSERT), DROP (verwijdert een bestaande tabel, equivalent van de DELETE) en ALTER (wijzigt een bestaande tabel, equivalent van UPDATE). Met CREATE kan je niet alleen tabellen aanmaken, ruim gezien kan men database-objecten aanmaken en hieronder horen onder andere databases, indices en stored procedures (dit zijn subroutines die dan gebruikt kunnen worden door de applicaties die de database gebruiken). DROP kan dit database-object dan ook weer verwijderen, dus met DROP kan je naast tabellen ook databases, indices of views verwijderen. En hetzelfde geldt dan voor ALTER: hiermee kan je bestaande database-objecten wijzigen. De types database-objecten die je kan wijzigen met het ALTER-commando hangen af van welke DBMS4 je gebruikt. Om nog even een vergelijking te maken met een andere taal, XML Schema is ook een voorbeeld van een DDL, maar dan voor XML.

1.4

Structuur van SQL databases

Een SQL database bestaat uit drie onderdelen: entiteiten, entiteit-types en attributen. 1.4.1 Entiteiten Een entiteit is een object dat informatie bevat die interessant is voor de applicatie of gebruiker. Zo kan je een entiteit Persoon hebben of een entiteit Auto en deze hebben op hun beurt verschillende attributen. Een Persoon heeft bijvoorbeeld een naam, geboortedatum, geslacht en ga zo maar door. Terwijl de Auto-entiteit eerder de attributen bouwjaar, kleur, type zal hebben. Elke entiteit is uniek, zoals iedere mens uniek is. Je zou kunnen stellen dat alle mensen ter wereld een entiteit zijn met elk hun eigen attributen en nergens zullen er twee identiek dezelfde zijn. 4


Tim Dhondt

11


De twee aangehaalde voorbeelden Persoon en Auto zijn fysieke objecten, maar een entiteit moet niet fysiek zijn: een entiteit Verkoop kan ook bestaan. Zolang het noodzakelijk is voor de applicatie en het attributen heeft met waarde, kan het opgenomen worden in de database als entiteit. 1.4.2 Entiteit-types Entiteit van hetzelfde type behoren tot eenzelfde entiteit-type. Dus een Persoon-entiteit A en Persoon-entiteit B behoren beide tot het entiteit-type Persoon. Men kan dus stellen dat een entiteit-type een verzameling is van alle entiteiten van dat type. Entiteit-types zijn zo mogelijk wel het belangrijkst van de drie onderdelen, want deze zullen de tabellen vormen in de database. 1.4.3 Attributen Attributen zijn de onderdelen van een entiteit die worden gedefinieerd in het entiteit-type. Dit zijn de karakteristieken voor die entiteit en bevatten interessante informatie voor de applicatie. Een persoon heeft bijvoorbeeld een huidstype, maar mogelijk is dit voor de applicatie niet van belang en dan zal dit ook niet opgenomen worden in de entiteit-definitie. De attributen worden in het database-model de kolommen van een tabel. 1.4.4 Regels van de opbouw Eens je entiteit-types hebt met attributen kan je hier niet zomaar een hele database mee construeren, je zal je moeten houden aan enkele regels. Elke tabel representeert exact één entiteit-type Er is één uitzondering op deze regel: indien twee entiteit-types dezelfde attributen hebben en een entiteit in beide entiteit-types kan worden ondergebracht, kunnen beide entiteittypes door dezelfde tabel worden gerepresenteerd. Het entiteit-type Folder (in een operating systeem) en het entiteit-type Subfolder hebben dezelfde attributen en een entiteit Subfolder kan zowel opgaan in het entiteit-type Folder als Subfolder. Dus kunnen beide voorgesteld worden in de tabel Folder. Alle kolommen moet atomisch zijn Om te kunnen weten of de definitie van de kolommen hieraan voldoet, moeten we eerst weten wat “atomisch zijn” betekent. Dit wil zeggen dat de kolommen zo ver mogelijk moeten opgesplitst worden onder de voorwaarde dat elk apart onderdeel nog waarde heeft. Een adres in de vorm van “Straat Nummer, Postcode Stad” wordt best niet opgenomen als één attribuut “adres”, want dit is niet atomisch. Het voorbeeld hier kan nog verder worden opgesplitst in “straat + nummer” (want een nummer alleen heeft geen waarde), “postcode” en “stad”. Een kolom kan maar één waarde bevatten Sommige entiteit-types kunnen attributen hebben die meerdere waardes bevatten, zoals bijvoorbeeld een parking operator. Een operator heeft een attribuut parkings wat dus

Tim Dhondt

12


meerdere waarden kan bevatten. Wanneer dit voorvalt, is het best om nog een entiteit-type (tabel) te maken, en in het geval van het voorbeeld is dit Parking. En dan wordt er een oneto-many relatie gelegd van Parking naar Operator. 1.4.5 Relaties Relaties zijn natuurlijk van groot belang in een relationele database. Maar niet elke relatie is vanzelfsprekend, zo zijn er verschillende types die zeker aandacht verdienen.

Figuur 1 Database-model met relaties van Public Parkings (stageproject)

1.4.5.1

One-to-one relatie

Een one-to-one relatie valt het best uit te leggen met een voorbeeld: in een monogame cultuur kan een man geen of één vrouw hebben en een vrouw kan geen of één man hebben. Indien Man een tabel is en Vrouw ook, zou er een one-to-one relatie zijn tussen beide tabellen. Ondanks het feit dat er een relatie is van de ene tabel naar de andere, zal er maar in één van de twee een foreign key aanwezig zijn. 1.4.5.2

One-to-many / many-to-one relatie

Hier haal ik het voorbeeld aan van de operator en de parkings aan. Tabel A kan via één (of meerdere) van zijn attributen één waarde (entiteit) uit tabel B bevatten, terwijl die entiteit dan meerdere waarden (entiteiten) uit tabel A kan bevatten. Hier zal de foreign key aanwezig zijn in de tabel met de many-to-one declaratie (in dit geval: Parking).

Tim Dhondt

13


1.4.5.3

Many-to-many relatie

Het aloude voorbeeld van het recept en de ingrediënten. Een recept heeft meerdere ingrediënten nodig en een ingrediënt kan voor meerdere recepten gebruikt worden. Hiervoor wordt er in een database een tussentabel gemaakt (gewoonlijk met naam van de twee tabellen, vb: ReceptIngrediënt). Met hier dan twee foreign keys in naar de originele tabellen.

1.5

Transacties

Een transactie is een gegeven van alles of niets. Om een simpel voorbeeld te geven: een geldtransactie. Deze bestaat uit twee delen, het verlagen van het saldo van de ene rekening en het verhogen van het saldo van de andere rekening. Indien het verlagen van het saldo gebeurt, maar door een stroompanne het verhogen niet gebeurd, dan is er een ongelijkheid (wat zeer onwenselijk is). We willen dat ofwel beide acties gebeuren ofwel geen van beide, en om dit op te lossen zijn transacties ontstaan. Een transactie is een reeks van commando’s die na elkaar worden uitgevoerd. Indien alles goed en zonder fouten verloopt, zal er aan het einde van de reeks operaties een COMMITstatement toegevoegd worden, zodat de transactie effectief wordt doorgevoerd en finaal gemaakt. Op dit punt wordt dan ook een nieuwe “Save Point” gemaakt van de database. Dit is nodig indien er tijdens de transactie iets misloopt of er een operatie wordt uitgevoerd die niet gewenst is. Want in die gevallen kan dan een rollback worden uitgevoerd (indien er een fout optreedt bij een transactie, treed de rollback automatisch in actie), zodat de database terug kan worden gezet naar de staat sinds de laatste commit of rollback. Hierdoor kan je geen rollback meer doen na een transactie aangezien hij stopt bij de laatste commit. Transacties zijn dus heel krachtige, maar ook heel gevaarlijke mechanismen. Heb je ze niet nodig, dan gebruik je ze beter ook niet. Heb je ze wel nodig, dan ben je best wat voorzichtig, maar kan je ook eens glimlachen over hoe gemakkelijk het allemaal niet is.

1.6

Opbouw van queries

SQL is opgebouwd op een manier zodat als je de query-structuur hardop leest, je ook precies weet wat je doet. Je zou bijna kunnen zeggen dat SQL een soort spreektaal is om een database te ondervragen. Als je enkel en alleen kijkt naar de pure definitie van de term query, slaat dit enkel en alleen op het SELECT-statement, aangezien dit een opvraging is van data. Terwijl de andere statements eerder opdrachten zijn om door de database te worden uitgevoerd, maar deze worden in de volksmond ook onder de noemer query geplaatst.

Tim Dhondt

14


1.6.1 SELECT-statement De select is opgebouwd uit minstens twee “clauses”: wat je wil selecteren en van waar. “SELECT * FROM tabel”, dit is de meest simpele SELECT-query die je kan doen, waarbij de asterisk een plaatsvervanger is voor de gehele entiteit. Maar deze query zal elke rij uit die tabel gaan ophalen wat in heel veel gevallen niet de bedoeling is. Er kunnen dus ook condities aan toegevoegd worden door de WHERE-clause: “SELECT * FROM Koffiekoek WHERE prijs < 2.00”. Hierbij vraag ik alle koffiekoeken op die goedkoper zijn dan twee. Je kan ook verschillende condities achter elkaar hangen. Een lijst is vaak het mooist als die geordend is, en dit kan je met SQL dan ook vragen met de ORDER BY-clause: “SELECT * FROM Koffiekoek WHERE prijs < 2.00 ORDER BY naam DESC”. Ondertussen kan je wel raden wat hier gevraagd wordt, alle koffiekoeken goedkoper dan twee, geordend op naam aflopend. De laatste clause die heel veel voorkomt, is de JOIN-clause. Hiermee kan je meerdere tabellen tegelijk ondervragen. In dit geval worden de attributen expliciet voorafgegaan door de tabelnaam zodat er geen verwarring kan ontstaan bij welke die hoort: “SELECT Boek.titel, Auteur.naam FROM Boek JOIN Auteur ON Boek.isbn = Auteur.isbn”. Deze methode wordt vaak gebruikt om data van verschillende tabellen in één keer op te vragen of om deze data gemakkelijk te aggregeren. 1.6.2 Onderdelen van de DML Zoals eerder aangegeven zijn dit de INSERT-, UPDATE- en DELETE-statements. Een minder voorkomend, maar niet onbelangrijk statement dat hier ook nog bij hoort is MERGE. INSERT Dit statement wordt gebruikt om nieuwe data toe te voegen: “INSERT INTO tabel (attr1, attr2, attr3) VALUES (5, ‘voorbeeld’, NULL)”. UPDATE De update wordt gebruikt om één of meerdere velden te wijzigen: “UPDATE tabel SET attr1 = ‘voorbeeld’”. DELETE Deze query verwijdert hele rijen uit een tabel: “DELETE FROM tabel”. MERGE Merge wordt gebruikt om data van verschillende tabellen samen te voegen, het is in feite een combinatie van INSERT en UPDATE: “MERGE INTO nieuwe_tabelNaam USING tabel_referentie ON voorwaarde WHEN matched THEN UPDATE SET attr1 = NULL, attr2 = 5 WHEN NOT matched THEN INSERT attr1, attr2 VALUES (NULL, 5)”.

Tim Dhondt

15


Opmerking: na UPDATE en DELETE kan je telkens ook de WHERE-clause plaatsen, zoals bij de SELECT, om je wijzigingen te verfijnen. 1.6.3 Onderdelen van de DDL Dit zijn dus de CREATE-, ALTER-, DROP- en TRUNCATE-statements. CREATE Met CREATE kan je database objecten creëren, in het bijzonder dus tabellen: “CREATE TABLE tabel ( attr1 INT, attr2 varchar(12) NOT NULL, PRIMARY KEY attr1 )” ALTER Bestaande database objecten worden met het ALTER-statement gewijzigd op verschillende manieren (in onderstaand voorbeeld door een attribuut toe te voegen): “ALTER TABLE tabel ADD attr3 TIMESTAMP NOT NULL”. DROP Met DROP verwijder je een object, en dit is over het algemeen finaal. Dit wil zeggen dat er dan geen rollback kan gedaan worden om de DROP ongedaan te maken (terwijl dit bij een DELETE wel kan): “DROP TABLE tabel”. TRUNCATE TRUNCATE verwijdert heel snel alle rijen in een tabel (zonder de tabel te verwijderen). Over het algemeen wil dit zeggen dat het COMMIT-statement uitgevoerd wordt, waardoor er dan ook geen rollback meer kan worden gedaan: “TRUNCATE TABLE tabel”. 1.6.4 Onderdelen van de DCL Hier zijn er twee heel belangrijke: GRANT en REVOKE. GRANT GRANT zorgt ervoor dat één of meerdere gebruikers rechten krijgen om een operatie of een set van operaties uit te voeren op een database object: “GRANT SELECT, UPDATE ON tabel TO gebruiker1, gebruiker2”. REVOKE REVOKE maakt wat GRANT deed ongedaan. “REVOKE SELECT, UPDATE ON tabel TO gebruiker1, gebruiker2”.

Tim Dhondt

16


2. NoSQL 2.1

Geschiedenis van de term

De term NoSQL5 kwam voor het eerst naar boven in 1998 toen Carlo Strozzi een relationele open-source6 database had gemaakt die geen gebruik maakte van de standaard SQL. Later zei hij dat de term NoSQL niet correct was en dat NoREL geschikter was, aangezien de huidige NoSQLbeweging zo goed als volledig is overgestapt naar het niet- relationeel model. NoSQL kwam pas tien jaar later weer boven water, in 2009, wanneer Last.fm een evenement wou organiseren over open-source distributed databases. De naam NoSQL verwees naar een groot aantal niet-relationele, distributed databases die vaak niet alles in huis hadden Figuur 2 Carlo Strozzi om de klassieke relationele database systemen te overtreffen. Dit was zo op verschillende vlakken: atomair, consistent, geïsoleerd en duurzaam (ACID: atomicity, consistency, isolation en durability). In 2011 begon men uiteindelijk aan de productie van UnQL (Unstructured Query Language), specificaties om een taal te gebruiken in combinatie met NoSQL-databases.

2.2

UnQL

Het UnQL-project is tot leven gekomen met de modale gebruiker in gedachte. Er zijn namelijk verschillende soorten NoSQL databases: van key-value stores tot document-stores en zelfs graph-databases met elk hun eigen manier om de database te ondervragen. De community rond NoSQL wou een standaard om deze verschillende types op eenzelfde manier te kunnen aanspreken, dus kan je stellen dat ze van UnQL de SQL van NoSQL databases wilden maken. 2.2.1 Opbouw van queries Voor je kan queries schrijven voor een NoSQL database, moet je eerst weten hoe deze in grote lijnen in elkaar zit. Een NoSQL database ziet er qua structuur een beetje hetzelfde uit als een SQL database. Een database bevat 0 of meerdere collecties (in de praktijk minstens 1), dit is de equivalent van tabellen. Een collectie kan 0 of meerder documenten bevatten, 5


6


Tim Dhondt

17


dit kan je dan vergelijken met de rijen uit een SQL database. En als laatste bevat een document los-gedefinieerde velden die in zekere zin te linken zijn aan de kolommen van een tabel. SELECT Dit statement doet exact hetzelfde als wat het zou doen in SQL, alleen voor documenten: data opvragen. De standaard query ziet er als volgt uit: “SELECT FROM collectie”, op deze manier wordt het hele document opgevraagd, terwijl dit kan verfijnd worden door tussen de SELECT en FROM iets te plaatsen in de trend van “{veld1: collectie.naam, veld2: collectie.leeftijd}”. Je hebt dan wel verfijnd om niet het hele document te verkrijgen, toch wordt heel de collectie teruggegeven. Dit kan opgelost worden met het WHERE-keyword: “WHERE collectie.leeftijd >= 20”. Het resultaat wordt weergegeven als JSON-tekst. INSERT De data die je bewaart, kan eender welke correcte JSON-tekst zijn. Dit kan dus een getal of tekst zijn, maar ook complexere objecten: “INSERT INTO collectie VALUE { naam: “test”, leeftijd: 21}”. Opmerking: hieraan kunnen ook nog de optionele keywords “GROUP BY”, “HAVING”, “ORDER BY” en “LIMIT … OFFSET” toegevoegd worden. UPDATE Indien je velden opsomt die nog niet bestonden in het document, dan zullen deze velden worden toegevoegd, anders worden ze gewijzigd: “UPDATE collectie SET collectie.veld1 = “testnaam”, collectie.veld3 = {studies: “NMCT”}”. UPSERT Een upsert is een update van een document, tenzij deze nog niet bestond, dan gebeurt er een insert. Onderstaand voorbeeld is om de teller op een website te verhogen: “UPDATE collectie SET collectie.aantal = collectie.aantal+1 WHERE collectie.pagina == /pagina/een ELSE INSERT {pagina: "/pagina/een", aantal: 1}”. DELETE Natuurlijk is het ook belangrijk om data te kunnen verwijderen: hiervoor gebruiken we, net als in SQL, het DELETE-statement. “DELETE FROM collectie WHERE collectie.naam = “NMCT” CREATE Normaal wordt, in een NoSQL database, een collectie automatisch aangemaakt wanneer je de eerste keer een document toevoegt aan een nog onbestaande collectie, maar dit wordt in UnQL nog niet ondersteund. Vandaar dat het CREATE-statement dus nog in de taal aanwezig is: “CREATE COLLECTION nieuwe_collectie”.

Tim Dhondt

18


2.2.2 Hoe ver staat UnQL nu? Eén van de grootste problemen met UnQL is dat het probeert om een standaard te zijn voor elke database (wat goed is), maar dan ook voor elke functionaliteit van deze database (wat minder is). In plaats van te starten met de standaard te leggen voor de basissen van elke database, wilden de oprichters van het project rechtstreeks naar de top: alles of niets. Dit bleek dus in het begin van 2012, na een ontwikkeling van geen jaar, niks te worden.

2.3

Doel van niet-relationele databases

NoSQL is eigenlijk tot stand gekomen omdat de computerwereld meer en meer veranderde (en nog steeds aan het veranderen is) naar een wereld van ‘Big Users’, ‘Big Data’ en ‘Cloud Computing’. 2.3.1 Big Users Met ‘Big Users’ bedoelt men dat het aantal gebruikers van een website of applicatie in de laatste jaren onnoemelijk is gestegen. Vroeger was een dagelijks quota van 1000 gebruikers normaal voor een applicatie of website, terwijl als je dit de dag van vandaag haalt als een groot internationaal bedrijf, dit eigenlijk niks waard is. Tegenwoordig zijn er meer dan twee miljard mensen geconnecteerd met het wereldwijde web. En de tijd die ze daar doorbrengen groeit een klein beetje elke dag, waardoor er meer en meer gelijktijdige gebruikers zijn. Je kan nooit perfect voorspellen hoeveel gebruikers een applicatie zal hebben, dus is het belangrijker om een flexibele carrosserie te hebben, die eventueel een explosie aan gebruikers wel aankan. Dit is dan ook onmiddellijk één van de redenen waarvoor men NoSQL gebruikt: veel gebruikers die gelijktijdig data opvragen of wijzigen. Het is van cruciaal belang dat er bij geen enkele van die gebruikers iets misloopt of, zeker vandaag, een operatie te traag verloopt, want dan bestaat de kans dat je die gebruiker niet meer terug ziet. 2.3.2 Big Data Tegenwoordig kunnen we op elk moment van de dag data aanmaken, data versturen en deze dan gaan opslaan, bv.: een foto trekken, een tweet versturen, een URL opslaan, … Veel van deze data is door de gebruiker gegenereerde inhoud (UGC: User Generated Content) en is dus heel vaak niet- of bijna niet-gestructureerd, waardoor niet ieder type data dezelfde eigenschappen bevat. Een SQL database werkt per tabel met vaste kolommen, dus om al deze verschillende types data te ondersteunen, zouden er heel veel tabellen nodig zijn. Daarom stappen er veel mensen over naar NoSQL databases, want in plaats van tabellen hebben zij dus die collecties met documenten en los-gedefinieerde velden. Deze velden zijn door hun definitie optioneel en daarom kan een document in collectie A er helemaal anders uitzien dan een ander

Tim Dhondt

19


document in diezelfde collectie. Maar over het algemeen worden documenten in dezelfde collectie geplaatst wanneer ze dezelfde globale betekenis hebben (maar niet altijd dezelfde velden). Om dus het voorbeeld te nemen van de UGC: om 5 verschillende types data te bewaren in een SQL-database is de kans groot dat je 5 verschillende tabellen nodig hebt (tenzij een paar types gelijkaardig zouden zijn), terwijl je deze in een NoSQL-database allemaal in één en dezelfde collectie kan plaatsen. 2.3.3 Cloud Computing Vroeger gebruikte men een twee-tier (lees: twee niveaus) client-server architectuur om een applicatie te bouwen. Dit wil zeggen dat er aan de ene kant een server stond die alle binnenkomende connecties opving en waarop ook de database draait. Deze connecties kwamen binnen van de client-applicaties en deze twee stonden dus rechtstreeks met elkaar in verbinding. Maar dit alles kon alleen met de server binnen dezelfde firewall als die van de clients en er stond ook een limiet op het aantal gelijktijdige gebruikers. Tegenwoordig is de drie-tier meer in trek: de server moet zich niet meer in dezelfde firewall netwerkomgeving bevinden als de gebruikers, sterker nog, deze draait in de cloud met daarbij verschillende servers om de gebruikers te “ontvangen” en nog eens verschillende servers voor de databases. Voor iedere zoveel gebruikers kan je in deze architectuur een bijkomende applicatie- en database-server opzetten. Hiervoor was het cruciaal dat de databases konden schalen in de breedte7, en niet noodzakelijk in de hoogte8. Dus om dan zomaar en database-server bij te plaatsen, was niet praktisch, men zocht dus een type database dat gemakkelijk schaalbaar was in de breedte. Dit is wat een NoSQL-database dan ook kan, ze zijn immers van in het begin gebouwd om distributed te zijn en gemakkelijk schaalbaar in de breedte.

2.4

Type NoSQL Databases

Aangezien er zoveel verschillende soorten data kan bewaard worden in NoSQL databases, zijn de type databases ook heel erg uiteen gaan lopen, waarvan de drie populairste (bekendste) de key-value store, de document-store en de graph-database zijn.

7


8


Tim Dhondt

20


2.4.1 Key-Value Store De key-value store is waarschijnlijk het simpelste type database onder de NoSQL databases. De meeste onder deze databases hebben een API die een variatie is op het volgende in Java: - void put(String key, byte[] data) - byte[] get(String key) - void remove(String key) Dit zijn dan ook de drie belangrijkste operaties die je nodig hebt in een database: insert (put), select (get) en delete (remove). Een key-value store bewaart een waarde d.m.v. een key. En zoals je reeds kon zien aan de methoden uit de API draait ook alles rond die key. Dit komt omdat de key uniek is en zo kan je dus ondubbelzinnig een object definiëren. De waarde op zich is een blob9, hierdoor hoeft de database zich niet te bekommeren om wat er bewaard zal worden, de enige die hier rekening zal moeten mee houden is de applicatie die in contact staat met de database, want daar zal het parsen moet gebeuren. Op deze manier is het gemakkelijk om een key-value store te bouwen en zelfs nog gemakkelijker om de database achteraf te schalen. 2.4.2 Document Store Het belangrijkste concept achter de document store of document-georiënteerde database is natuurlijk dat van het document. Dit is in elke database wel anders, maar het basis principe blijft hetzelfde: het omvatten en encoderen van data of informatie d.m.v. een standaard formaat. De meest gebruikte hieronder zijn XML, JSON en BSON, maar ook binaire formaten als PDF en Microsoft Office documenten. Zoals al eerder vermeld zijn documenten gelijkaardig aan rijen in een SQL database, maar deze zijn niet verplicht om een bepaald model te volgen om te kunnen worden opgenomen in de database. Documenten kunnen op twee manier opgevraagd worden: aan de hand van de key (zoals bij een key-value store) en aan de hand van wat er in de data zit (zoals bij SQL databases wordt gedaan). Zoals bij een key-value store is de key die aan een document gelinkt is uniek en op deze manier kan elk document ondubbelzinnig worden opgeslagen. Waar we bij SQL de WHERE-clause kunnen gebruiken om data te specifiëren, kunnen we gelijkaardige dingen doen in NoSQL databases om hetzelfde resultaat te bekomen. Dit verschilt van DBMS tot DBMS, maar bijvoorbeeld in MongoDB kan je een JSON-object meegeven waar de data moet aan voldoen om deel te nemen aan de operatie.

9


Tim Dhondt

21


2.4.3 Graph Database Graph databases gebruiken de grafen-structuur met knopen, lijnen en attributen om data op te slaan en weer te geven. In het algemeen kan je stellen dat iedere database die werkt met indexvrije verbindingen tussen entiteiten, een graph database is. De knopen in zo’n structuur lijken heel erg veel op objecten uit object-georiënteerde programmeertalen en valt dus voor programmeurs over het algemeen vlot aan te leren.

Figuur 3 Voorstelling van een simpele graaf

Het hoofdonderdeel zijn dus de knopen die vergelijkbaar zijn met entiteit in een SQL database. Je kan dus meerdere knopen hebben van hetzelfde type. Iedere entiteit heeft attributen en dit is met knopen niet anders. Stel dat je een knoop van type Persoon hebt, kan je attributen hebben als naam, geboortedatum, geslacht, … Als laatste heb je de lijnen en deze stellen de relatie voor tussen twee knopen of tussen een knoop en zijn attributen. De belangrijkste informatie van die relatie wordt dan ook in de lijn zelf bewaard. Als je graph databases vergelijkt met relationele databases zijn de eerste vaak sneller, omdat objecten direct aan elkaar gelinkt zijn. Dankzij deze eigenschap zijn er dus geen index opzoekingen meer nodig en kan alles vlotter opgehaald worden. Dit geldt echter enkel voor kleine tot middelgrote databases, wanneer de database groot is, zal een relationele database (door de index opzoekingen) sneller werk leveren. Nog een groot voordeel dat graph databases bieden, is het feit dat wanneer je een constantveranderend database-model hebt, dit voor graph databases geen enkel probleem is.

Tim Dhondt

22


3. SQL vs. NoSQL 3.1

Transacties

SQL databases bevatten standaard transacties zonder dat je zelf heel veel moet doen, terwijl NoSQL databases dit niet standaard ondersteunen. Je kan wel degelijk transacties verkrijgen, maar dan zal je heel veel handmatig werk moeten uitvoeren. Je zou dan kunnen zeggen dat SQL hier het voordeel heeft, want daar zijn er transacties aanwezig en bij NoSQL niet, maar zoals reeds eerder aangehaald, heeft niet iedere applicatie transacties nodig. Dit is bijvoorbeeld het geval bij de applicatie die ik heb helpen schrijven op mijn stage: om de tien minuten starten er een aantal jobs die een API uitlezen en de data opslaan in de database (om deze dan in de front-end te gaan weergeven).

Figuur 4 Uitlezen JSON van API Stad Gent

Na het inlezen van de JSON zal deze natuurlijk eerst nog moeten geparset worden zodat de correcte data wordt meegenomen naar de database.

Tim Dhondt

23


Figuur 5 Geparsete data wordt weggeschreven naar database

Indien je dit transactioneel opslaat en er loopt iets fout, gebeurt er helemaal niks en krijg je gaten in je data flow. Sla je de data op zonder transactie en er loopt iets mis, dan zal je enkel data missen van de onderdelen waar de fout zich voordeed en niet van alle data.

3.2

Schaalbaarheid

Schaalbaarheid is waarschijnlijk de grootste factor waardoor er zo’n verschil is tussen SQLen NoSQL-databases. Maar dit ligt niet alleen aan de schaalbaarheid zelf, aangezien beide types databases perfect te schalen zijn (op een andere manier weliswaar), maar aan vele onderliggende aspecten. 3.2.1 Locking Als we het Engelse woord “lock” vertalen, betekent dit “slot”. In het algemeen gesproken in de computer wereld is een lock een mechanisme die het aantal gelijktijdige gebruikers van bepaalde data beperkt. Als we spreken over gebruikers zijn dit de threads 10 van een programma of operating systeem. In deze context, als er over een lock gesproken wordt, zal dit een database-lock zijn. Een database-lock doet exact wat de definitie voorschrijft, maar in dit geval gaat het specifiek over een rij, meerdere rijen of soms zelfs hele tabellen. Locking is dus nodig aangezien de threads binnen eenzelfde proces dezelfde resources met elkaar delen, dus kunnen ze die gelijktijdig ook gaan opvragen of wijzigen. Om alles in goede banen te leiden zijn er twee soorten locks: de optimistic lock en de pessimistic lock.

10


Tim Dhondt

24


3.2.1.1

Optimistic locking

De optimistic lock zorgt ervoor dat er heel veel gelijktijdige threads de data (rijen, tabellen, …) kunnen opvragen en lezen. Met data te lezen verandert er niks en kunnen er dus ook geen foute weergaven gedaan worden. Maar het wijzigen van data gaat dus niet (of toch niet van die specifieke data die onder de lock staat), want dan zou thread A bijvoorbeeld het getal vijf uitlezen, thread B wil diezelfde data lezen, maar vlak daarvoor wijzigt thread C de data van vijf naar zeven en thread B leest het getal zeven uit, waardoor er inconsistente data is. 3.2.1.2

Pessimistic locking

Bij pessimistic locking kan je zeggen dat er één thread een exclusiviteitscontract heeft met de data die onder lock staat. Dit gebeurt wanneer deze data zal gewijzigd worden, zodat er geen verkeerde data kan ontstaan. Stel bijvoorbeeld dat de data die zal worden gewijzigd het getal vijf is. Thread A zal bijvoorbeeld een berekening uitvoeren door er twee bij op te tellen en dan te vermenigvuldigen met drie (wat 21 zal opleveren). Maar vlak voordat thread A de vermenigvuldiging kan uitvoeren, trekt thread B terug twee af van het getal, waardoor het totaal terug op vijf komt. De vermenigvuldiging vindt plaats en het eindtotaal is vijftien, wat dus de verkeerde uitkomst is, en bijgevolg corrupte data. 3.2.1.3

Invloed op schaalbaarheid

Bij SQL databases is locking standaard aanwezig (zoals transacties) en opnieuw is dit bij NoSQL databases niet het geval. Dit is meteen ook de reden waarom SQL databases eerder verticaal zullen schalen: het is zeer complex om er voor te zorgen dat een tabel die over verschillende servers verspreid staat volledig gelockt wordt. Hoewe het zeker niet onmogelijk is, blijft dit toch een zeer complex gegeven. Als je horizontaal wil schalen zit je beter bij een NoSQL database aangezien deze standaard geen locking bevat, maar dan zit je wel met het mogelijke “nadeel” dat je alles handmatig zal moeten locken. 3.2.2 Referentiële integriteit Referentiële integriteit is iets heel belangrijk in een relationele database en voor de schaalbaarheid misschien wel het belangrijkste aspect. Referentiële integriteit houdt in dat elke foreign key in tabel A ofwel null (geen waarde) is ofwel moet de waarde aanwezig zijn in een andere tabel als primary of candidate key. Indien entiteit A in tabel A een referentie heeft door entiteit B in tabel B, kan je entiteit A niet verwijderen. Anders zou de foreign key van entiteit B een waarde bevatten die niet voorkomt in tabel A waardoor de referentiële integriteit zou teniet gedaan zijn. Het afdwingen van deze integriteit is voor iedere RDBMS verschillend: sommige zullen een

Tim Dhondt

25


fout opwerpen en zeggen dat entiteit A nog steeds een referentie heeft bij entiteit B, andere zullen eerst de foreign key verwijderen en dan pas entiteit A. Beide mogelijkheden behouden zo de referentiële integriteit van de relationele database. Om ervoor te zorgen dat een SQL database horizontaal schaalbaar is, zal het gebruik maken van sharding11. Maar om klaar te zijn voor sharding zal het database-model zodanig moeten aangepast worden dat de referentiële integriteit geen last wordt (aangezien de rijen op verschillende servers bewaard zullen worden). Stel dat je een rij wil verwijderen en je hierbij aan elke server moet vragen of er daar een rij is opgeslagen die nog een referentie heeft naar de te verwijderen rij, kan dat heel lang duren. Maar het gaat niet alleen om de referentiële integriteit, maar ook over JOIN’s voor dezelfde redenen: als je tabel A joint met tabel B, maar deze staan beide over verschillende servers, kan dit gevolgen hebben voor de performantie van de database. De oplossing hiervoor is je database-model zodanig aanpassen dat het eigenlijk begint te lijken op een NoSQL database met zo weinig mogelijk onnodige relaties. Op deze manier zal de referentiële integriteit al veel minder een probleem zijn. Om ervoor te zorgen dat JOIN’s geen (of bijna geen) impact meer hebben op de performantie zal de database gedenormaliseerd12 moeten worden. Hierdoor zullen de servers minder belast worden als er veel data van relaties wordt opgevraagd. Vanzelfsprekend is dit bij NoSQL databases geen enkel probleem. Aangezien er geen relaties zijn, is er dus ook geen referentiële integriteit, en kan er dus veel eenvoudiger horizontaal geschaald worden. Hier heeft NoSQL dan wel degelijk het voordeel t.o.v. SQL, want het hele sharding proces is immers zeer complex en niet voor iedere developer weggelegd om dit tot een goed einde te kunnen brengen.

3.3

Beveiliging

SQL databases hebben altijd garant gestaan voor veilige databases. Er zijn nog steeds de gekende aanvallen zoals bijvoorbeeld het systeem van de SQL injection, maar over het algemeen kunnen we stellen dat SQL databases veilig zijn. De vraag is nu of dit bij NoSQL ook het geval is: “NoSQL, no security?” Zoals je dus SQL injection hebt, is er sinds de komst van NoSQL database ook de schema injection. Dit laat de hacker toe om key-value paren toe te voegen aan een document en zo data te overschrijven. Dit komt omdat de laatste key altijd zal opgeslagen worden, bv.: {password: “geheimWachtwoord”}, dan kan er d.m.v. schema injection het paar “password: 123” aan toe gevoegd worden. Hierdoor wordt het geheime wachtwoord dan overschreven

11


12


Tim Dhondt

26


door een gekend wachtwoord. Maar die problematiek is dus voor beide (SQL en NoSQL) gelijk. Het grote probleem zit hem bij de authenticatie van gebruikers: zwakke authenticatie methodes worden gebruikt, wachtwoorden worden niet op een veilige manier opgeslagen en bij sommige DBMS’en zijn er zelfs mogelijkheden om via brute force te proberen inloggen. Deze drie voorbeelden zijn allemaal van toepassing op de meeste NoSQL databases. Een voorbeeld hiervan is de DBMS CouchDB: “When you start out fresh, CouchDB allows any request to be made by anyone.” (guide.couchdb.org) Of even kijken naar MongoDB: “If there are no admin users, one may access the database from the localhost interface without authenticating.” (mongodb.org) Je kan zeggen dat je database in een veilige omgeving moet staan en dan zal je met CouchDB geen problemen ondervinden, maar geen enkele omgeving is 100% veilig. Veel mensen zullen je gek verklaren als je geen admin user(s) hebt voor je database, maar dit blijft toch nog steeds een rare beslissing van de mannen achter MongoDB. En om te eindigen nog een voorbeeld van de Redis DBMS: het aantal keren dat het AUTHcommando (om in te loggen) kan gebruikt worden achtereenvolgens is niet gelimiteerd. Hier kan dus brute force gebruikt worden om wachtwoorden te gokken. Veilig? Not so much…

Tim Dhondt

27


4. Use Cases Zoals al blijkt uit de vorige hoofdstukken, komt de kracht van de SQL of NoSQL database pas echt goed tot zijn recht wanneer ze gebruikt worden in de juiste situaties. In dit hoofdstuk worden een paar ezelsbruggetjes aangehaald en verklaard, zodat deze kunnen gebruikt worden om een goede beslissing te nemen in de zoektocht naar de correcte database. Opmerking: indien je reeds een relationele database gebruikt, dan heb je naar alle waarschijnlijkheid de correcte keuze gemaakt, aangezien die in de meeste gevallen genoeg performantie biedt. Heb je toch problemen, dan kunnen volgende punten misschien inzicht bieden over wat je kan doen.

4.1

Groei in data?

Zoals gezien in hoofdstuk 3 is het voor de gemiddelde programmeur niet zo vanzelfsprekend om een SQL database te schalen in de breedte, terwijl dit vrij gemakkelijk kan gerealiseerd worden voor een NoSQL database. Dan blijft enkel de vraag: is het wel nodig om te schalen? Indien je een database hebt waarbij de data constant blijft of de hoeveelheid data slechts heel traag toeneemt, dan is schalen in de breedte niet echt nodig (tenzij er nog andere aspecten in het spel zijn, waar ik later op terugkom). Aan de andere kant, stel dat je bijvoorbeeld een database nodig hebt voor social media (zoals bijvoorbeeld Twitter, Facebook, …) dan neemt die data dagelijks met enorme hoeveelheden toe en moet het mogelijk zijn om deze gemakkelijk te schalen. Dit is waar dan de NoSQL databases in uitblinken. Dit gaat natuurlijk ook wel gepaard met de grootte van je database. Stel dat je constant een snelle toename hebt aan data, maar “oude” data verwijder je wanneer deze niet meer nuttig is, dan kan de database relatief klein blijven. Dan behoudt een SQL database perfect zijn performantie en is de keuze voor NoSQL niet beter of slechter dan die voor SQL. Omgekeerd geldt ook: is er geen of bijna geen groei in data, maar heb je wel de grootte van een database waar zelfs Google toch even van zou versteld staan, en heb je performantie problemen, dan is een NoSQL database een alternatief.

4.2

Gebruikersexplosie

Is je applicatie Temple Run 2 of je website Facebook, dan zal je wel onnoemelijk veel gelijktijdige gebruikers hebben. Om dit alles in goede banen te leiden en vooral om het performant te houden, heb je veel servers nodig die al die client-connecties aankunnen. En zoals eerder gezegd staan veel servers (over het algemeen) gelijk aan horizontaal schalen waarmee we dus opnieuw in het verhaal van de NoSQL databases zitten. Wat natuurlijk ook kan, is verschillende servers naast elkaar plaatsen met kopieën van de originele SQL database. Op die manier heb je dan het probleem van de vele connecties

Tim Dhondt

28


opgelost, alleen zal je nog steeds performantieverlies lijden aangezien nog steeds de gehele database zal moeten doorlopen worden.

4.3

Kan downtime geoorloofd worden?

Heb je een populaire website of mobiele service, dan is het antwoord op deze vraag hoogstwaarschijnlijk “neen”. Dan biedt NoSQL de oplossing, terwijl ze daar eigenlijk niet specifiek voor ontworpen zijn. Maar door het feit dat ze distributed zijn, kan een NoSQL database bijna 24h/24 online zijn en zo geen of bijna geen downtime veroorzaken. Zo kan je met wat planning je soft- en/of hardware upgrades uitvoeren zonder de database offline te halen, wat zo veel frustraties bij klanten en gebruikers zal voorkomen. Het omgekeerde is dan ook weer te voorspellen, dat als je met de database wel eens offline kan gaan, de keuze voor beide evenwaardig is.

4.4

Gevoelige data-overdracht?

Het voorbeeld wordt eerder in deze scriptie al aangehaald: bankoverschrijvingen. Hier is het cruciaal dat het een alles of niets operatie is. Het zou wel nadelig zijn als de ene rekening verlaagd is, terwijl de andere nog hetzelfde saldo vertoont. Hiervoor gebruiken we dus zoals gezegd transacties en dit is iets wat niet vanzelfsprekend is voor NoSQL databases vanwege het feit dat ze distributed zijn. Ondersteuning voor transacties is één van de top redenen om een SQL database te kiezen (samen met het feit dat er veel relaties tussen de entiteiten zitten).

4.5

Specifieke data-modellen

Hiermee refereer ik in het bijzonder aan de graph databases (wat niet wil zeggen dat dit de enige databases zijn met andere soorten data-modellen). Neem nu bijvoorbeeld LinkedIn, zij doen berekening tussen de gebruiker en een ander profiel om zo te kijken in de hoeveelste graad ze met elkaar verbonden zijn. Dit is een perfect voorbeeld van een graaf en met een graph database kunnen deze berekeningen dan ook gemakkelijk gedaan worden. Maar dit wil ook zeggen dat wanneer de objecten in de database heel specifiek gemodelleerd zijn, men op voorhand weet hoe de tabellen en kolommen er gaan uitzien en is het gebruik van SQL databases dan weer evenwaardig aan die van NoSQL. Dit kan natuurlijk ook betekenen dat er tussen die entiteiten relaties liggen en dan is het hek al helemaal van de dam, dan is SQL gewoonweg DE keuze om te nemen.

4.6

Geld is een struikelblok?

We mogen stellen dat de meerderheid van de NoSQL databases open source zijn, wat wil zeggen dat de licentiekost daar nul komma nul is. Als je dan nog eens de hosting zelf doet, is

Tim Dhondt

29


het helemaal in the pocket. Maar zelfs als je de hosting doet via gespecialiseerde hosting providers, zijn de prijzen vaak lager dan wanneer je hetzelfde zou doen met SQL databases. Hetzelfde kan niet gezegd worden over de meeste SQL DBMS’en: dure softwarelicenties en waarschijnlijk ook omwille daarvan duurdere hosting-prijzen dan voor NoSQL databases.

4.7

Vertrouwde omgeving

Voor heel veel mensen die al lang in het vak zitten (en dus al lang met SQL databases werken) is één van de belangrijkste argumenten voor de keuze van SQL databases is het feit dat ze al heel lang ingeburgerd zijn. Het gebruik ervan is voor velen onder hen vanzelfsprekend geworden en waarom zouden ze een vertrouwd iets vervangen door het onzekere? Aan de andere kant is het ook duidelijk dat de IT-wereld een snel evoluerende wereld is en dat de mensen die erin zitten, mee moeten evolueren. Ik hoop dan ook dat deze scriptie daar kan toe bijdragen.

Tim Dhondt

30


Conclusie De ontwikkeling van SQL is ondertussen 35 jaar geleden gestart en sinds een goede 25 jaar gestandaardiseerd. Sindsdien zijn er verschillende updates geweest aan de taal en zijn we ondertussen aan de zevende versie. Nadat het al een tijd in gebruik was, stelde IBM zijn doelpubliek bij: van eindgebruikers van het type manager naar programmeurs om het te gebruiken in applicaties als communicatiemiddel met de databases. Dit bleek door het feit dat je met SQL nog steeds moet weten hoe de database gemodelleerd is en dit vereist een meer technische achtergrond. We kunnen in de query language drie grote onderdelen onderscheiden: Data Manipulation Language (DML), Data Control Language (DCL) en Data Definition Language (DDL). De DML houdt de syntax-elementen om data te manipuleren (invoegen, wijzigen, deleten). De DCL gaat over de rechten van gebruikers met dan vooral de GRANT- en REVOKE-statements. En als laatste de DDL die gelijkaardig is aan de DML maar dan voor de database-objecten, zoals onder andere tabellen. De bouwstenen voor een SQL database zijn de entiteit-types, de entiteiten en de attributen. Op deze manier kan je elke data voorstellen: het entiteit-type is de overkoepelende benaming voor het object (een set van dezelfde types objecten), de entiteit is het object zelf en de waarden die de entiteit definiëren, zijn de attributen. Geen relationele databases zonder relaties, maar de ene relatie is de andere niet, zo heb je opnieuw drie types. Dit zijn eigenlijk de combinaties van de mogelijkheden één entiteiten en vele entiteiten: one-to-one relatie, one-to-many/many-to-one relatie en many-to-many relatie. Eén van de grootste wapentuigen van de relationele databases zijn toch wel de transacties. Als ultieme garantie voor de correctheid van data, is dit dé reden om voor SQL databases te kiezen. Alhoewel de term NoSQL zo’n vijftien jaar geleden voor het eerst gebruikt werd, is de populariteit ervan pas heel erg beginnen toenemen in het jaar 2009. Twee jaar later werd de vraag zodanig groot naar een standaard binnen de NoSQL community dat de development begon aan UnQL. Een project dat na zo’n half jaar al stil viel en ondertussen zijn we meer dan anderhalf jaar verder en is er niks meer van het UnQL-project vernomen. Als je aan een NoSQL gebruiker de vraag stelt waarom NoSQL beter is, is de kans groot dan je één (of meerdere) van deze drie antwoorden zal krijgen: performant met “Big Data”, snel met “Big Users” en gewoon perfect “in the cloud”. Dit zijn dan ook de voornaamste redenen waarom NoSQL databases verder zijn uitgewerkt. Onder de SQL databases heb je wel wat verschillen, maar deze heb je al helemaal als je kijkt naar NoSQL databases: key-value stores, document stores, graph databases, en nog veel meer. Allemaal in het leven geroepen voor specifieke situaties.

Tim Dhondt

31


Als we twee types van iets apart en uitgebreid bespreken, is het onafwendbaar dat deze uiteindelijk head-to-head zullen staan om te kijken welk van de twee nu eigenlijk de beste is. Transacties, een krachtig iets dat zowel iets goed als iets “slecht” kan zijn (afhankelijk van de situatie waarin je ze gebruikt). Hier hebben de NoSQL databases toch wel het streepje voor, aangezien zij dit allemaal van uit de doos meekrijgen, terwijl je bij NoSQL veel handmatig werk zal mogen leveren. In een snel groeiende IT-wereld is het schalen van een database één van de hotste topics. Het is al langer geweten dan vandaag dat het voor een SQL database heel goed van pas komt om in de hoogte te schalen. Maar wanneer je, onder andere, heel veel gebruikers hebt, is het beter om een paar extra servers te plaatsen dan om die ene server te gaan versterken. En hier gaan SQL databases een beetje in de mist (lees: vrij moeilijk te implementeren), terwijl dit voor NoSQL databases geen probleem is vanwege het feit dat ze distributed zijn. Beveiliging is voor heel veel bedrijven heilig als het op hun database(s) aankomt en voor SQL databases zitten we daar heel goed. Er zijn nog steeds manieren om beveiliging te omzeilen, maar over het algemeen: good stuff! Maar dit is toch wel een pijnpunt voor vele NoSQL databases: weinig security features of eigenaardige beslissingen van de DBMS’en zodat de beveiliging eigenlijk een lachertje wordt. Heb je iets met veel (veel gelijktijdige gebruikers, veel data) dan is NoSQL zeker iets voor jou: de performantie die deze databases stellen om veel gelijktijdige gebruikers te behandelen die op hun beurt heel veel data opvragen, is fantastisch. Heb je ook iets met veel maar dan eerder in de zin van veel tijd, dan kan de beslissing eerder overhellen naar de SQL databases die in de meeste gevallen perfect zijn voor de job. Ben je gehecht aan gewoontes of dat vele dingen voor je gedaan worden, dan zal een SQL database je heel blij maken: SQL bestaat al 25 jaar en heeft intussen veel ingebouwde snufjes, waaronder dus de transacties en het verplichten van de referentiële integriteit. “The screwdriver did not replace the hammer, though the main purpose of both is to hold things together. NoSQL and relational DBs are two different tools for two different jobs.” (webbiedave op StackExchange) Dit citaat geeft eigenlijk perfect weer hoe SQL en NoSQL databases zich tot elkaar verhouden, namelijk: de ene is niet beter dan de andere, ze worden elk gebruikt voor andere doeleinden of situaties. Voor dit semester had ik nog nooit stage gelopen in een bedrijf, het was voor mij dus best spannend voor ik eraan begon. De stage heeft mij vooral geleerd dat het leven van een startup hard kan zijn, maar ook wel hartverwarmend. Ik denk dat ik op deze dertien weken enorm veel bijgeleerd heb (wat ergens wel wat logisch is), maar ik voel me een hele andere programmeur dan voor ik aan deze dertien weken begon. De stage zou ik voor geen geld in de wereld willen gemist hebben. Toen ik aankwam op Howest was ik helemaal weg van de richting. Heel breed qua spectrum en allemaal nieuwe technologieën, het was fantastisch. Maar in het tweede jaar veranderde

Tim Dhondt

32


dat beeld helemaal: ik had het gevoel dat we heel veel verschillende (en soms wat verouderde) dingen zagen, maar van elk onderdeel enkel en alleen de basis. Dat en binnen een jaar moest er op stage gegaan worden en ik vond eigenlijk dat ik nog niks speciaal kon. Het derde jaar werd dan voor mij opnieuw interessanter met dan weer met de vier keuzevakken met meer en zwaardere inhoud, en dan daarna de heel leerrijke stage zelf. Ondertussen heeft de opleiding een hele make-over gekregen en van wat ik ervan gezien en gehoord heb, is dat eigenlijk een soort van NMCT 2.0. Minder verschillende technologieën en zo kan er dieper ingegaan worden op de aangebrachte topics.

Tim Dhondt

33


Literatuurlijst ArangoDB. (2013, May 25). Is UnQL Dead? Opgehaald van ArangoDB Website: http://www.arangodb.org/2012/04/07/is_unql_dead Arvin, T. (2013, April 24). Comparison of different SQL implementations. Opgehaald van Troels Arvin Website: http://troels.arvin.dk/db/rdbms/ Couchbase. (2013, May 1). The database world is being disrupted. Are you ready for the change? Opgehaald van Couchbase | Document-Oriented NoSQL Database: http://info.couchbase.com/WhyNoSQLWhitepaper.html Fowler, A. (2013, June 10). Why use a NoSQL Database, and why not? Opgehaald van Adam's Big Data Discoveries: http://adamfowlerml.wordpress.com/2013/01/04/why-use-anosql-database-and-why-not/ Interface. (2013, May 20). Understanding Database Building Blocks in SQL Server. Opgehaald van Interface Blog: http://blogs.interfacett.com/understanding-database-buildingblocks-sql-server JSONiq. (2013, June 10). The JSON query language. Opgehaald van JSONiq Website: http://jsoniq.org/ Microsoft. (2013, April 23). INTO Clause (Transact-SQL). Opgehaald van MSDN Library: http://msdn.microsoft.com/en-us/library/ms188029.aspx NoSQL Database. (2013, April 20). NOSQL Databases. Opgehaald van NoSQL Database Website: http://nosql-database.org/ Proffitt, B. (2013, June 5). When NoSQL Databases Are - Yes - Good For You And Your Company. Opgehaald van ReadWrite: http://readwrite.com/2013/03/25/whennosql-databases-are-good-for-you Rahien, A. (2013, June 1). That No SQL Thing - Key/Value stores. Opgehaald van Ayende @ Rahien: http://ayende.com/blog/4449/that-no-sql-thing-key-value-stores Tiffany, R. (2013, May 17). Building Microsoft MEAP: Scaling Out SQL Server. Opgehaald van Rob Tiffany Website: http://robtiffany.com/building-microsoft-meap-scaling-out-sqlserver/ UnQL Specification. (2013, May 27). Example Queries and Usage. Opgehaald van UnQL Specification Website: http://www.unqlspec.org/display/UnQL/Example+Queries+and+Usage Urbanski, W. (2013, May 26). NoSQL, no security? Opgehaald van Slide Share, present yourself: http://www.slideshare.net/wurbanski/nosql-no-security

Tim Dhondt

34


Wikipedia. (2013, April 17). Application programming interface. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Application_programming_interface Wikipedia. (2013, June 3). Binary large object. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Binary_large_object Wikipedia. (2013, April 20). Data manipulation language. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Data_manipulation_language Wikipedia. (2013, April 27). Databasemanagementsysteem. Opgehaald van Wikipedia, the free Encyclopedia: http://nl.wikipedia.org/wiki/DBMS Wikipedia. (2013, May 17). Denormalization. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Denormalization Wikipedia. (2013, May 29). Document-oriented database. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Document-oriented_database Wikipedia. (2013, June 10). Grafentheorie. Opgehaald van Wikipedia, the free Encyclopedia: http://nl.wikipedia.org/wiki/Grafentheorie Wikipedia. (2013, June 10). Graph database. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Graph_database Wikipedia. (2013, April 25). IBM. Opgehaald van Wikipedia, the free Encyclopedia: http://nl.wikipedia.org/wiki/IBM Wikipedia. (2013, May 10). Lock (computer science). Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Lock_(computer_science) Wikipedia. (2013, April 20). NoSQL. Opgehaald van Wikipedia, the free Encyclopedia: https://en.wikipedia.org/wiki/NoSQL Wikipedia. (2013, April 21). Open source. Opgehaald van Wikipedia, the free Encyclopedia: http://nl.wikipedia.org/wiki/Open_source Wikipedia. (2013, May 10). Referential Integrity. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Referential_integrity Wikipedia. (2013, April 22). Relational Algebra. Opgehaald van Wikiepedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Relational_algebra Wikipedia. (2013, April 23). Scalability. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Scalability Wikipedia. (2013, May 15). Shard (database architecture). Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Shard_(database_architecture) Wikipedia. (2013, April 24). SQL. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/SQL

Tim Dhondt

35


Wikipedia. (2013, April 22). Stored procedure. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Stored_procedure Wikipedia. (2013, May 10). Thread (computing). Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Thread_(computing) Wikipedia. (2013, April 25). Tuple. Opgehaald van Wikipedia, the free Encyclopedia: http://en.wikipedia.org/wiki/Tuple

Tim Dhondt

36


Figurenlijst Figuur 1 Database-model met relaties van Public Parkings (stageproject) ............................ 13 Figuur 2 Carlo Strozzi ........................................................................................................... 17 Figuur 3 Voorstelling van een simpele graaf ......................................................................... 22 Figuur 4 Uitlezen JSON van API Stad Gent ............................................................................ 23 Figuur 5 Geparsete data wordt weggeschreven naar database ............................................ 24

Tim Dhondt

37

SQL vs. NoSQL: een uiteenzetting

Recommend Documents