SQL vs. NoSQL: een uiteenzetting

Transcriptie

1 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 Stageplaats : Carambla Stagementor : Francis De Brabandere Stagebegeleider : Steven Verborgh

2 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

3 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

4 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 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

5 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

6 Inhoudstafel Woord vooraf... Samenvatting... Verklarende woordenlijst... Inhoudstafel... Carambla, een start-up als geen ander SQL Geschiedenis van de taal Waarom kwam SQL in de wereld? Hoe zit SQL in elkaar? Data Manipulation Language Data Control Language Data Definition Language Structuur van SQL databases Entiteiten Entiteit-types Attributen Regels van de opbouw Relaties Transacties Opbouw van queries SELECT-statement Onderdelen van de DML Onderdelen van de DDL Onderdelen van de DCL NoSQL Geschiedenis van de term UnQL Opbouw van queries Tim Dhondt

7 2.2.2 Hoe ver staat UnQL nu? Doel van niet-relationele databases Big Users Big Data Cloud Computing Type NoSQL Databases Key-Value Store Document Store Graph Database SQL vs. NoSQL Transacties Schaalbaarheid Locking Referentiële integriteit Beveiliging Use Cases Groei in data? Gebruikersexplosie Kan downtime geoorloofd worden? Gevoelige data overdracht? Specifieke data-modellen Geld is een struikelblok? Vertrouwde omgeving Conclusie Literatuurlijst Figurenlijst Tim Dhondt

8 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

9 1.1 Geschiedenis van de taal 1. SQL SQL 1 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 tuples 2 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 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 API 3 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 Zie verklarende woordenlijst 3 Zie verklarende woordenlijst Tim Dhondt 9

10 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) 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 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

11 bewaren (permanent maken) en ROLLBACK gaat in plaats van de acties permanent te maken, deze ongedaan maken (terugkeren naar een vorige versie) 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 DBMS 4 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 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 Zie verklarende woordenlijst Tim Dhondt 11

12 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 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 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 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

13 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 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) 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 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

14 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

15 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 < 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 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

16 Opmerking: na UPDATE en DELETE kan je telkens ook de WHERE-clause plaatsen, zoals bij de SELECT, om je wijzigingen te verfijnen 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 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

17 2.1 Geschiedenis van de term 2. NoSQL De term NoSQL 5 kwam voor het eerst naar boven in 1998 toen Carlo Strozzi een relationele open-source 6 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 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 Zie verklarende woordenlijst 6 Zie verklarende woordenlijst Tim Dhondt 17

18 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

19 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 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 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

20 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 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 breedte 7, en niet noodzakelijk in de hoogte 8. 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 Zie verklarende woordenlijst 8 Zie verklarende woordenlijst Tim Dhondt 20

21 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 blob 9, 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 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 Zie verklarende woordenlijst Tim Dhondt 21

22 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

23 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

24 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 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 Zie verklarende woordenlijst Tim Dhondt 24