Menu

Zeg maar vaarwel tegen het Relationele Model

René Krewinkel

Het fijne aan mijn persoonlijke (werk)situatie is dat ik, naast mijn werk als docent voor Educom, nog met een aantal andere zaken bezig ben die in meer of mindere mate verankerd zijn in de ICT.
Zo blijf ik een beetje "bij de tijd" en kan ik de opgedane kennis en ervaring mooi inzetten in het opleidingstraject.
Nou ben ik bijvoorbeeld met een tweetal projecten in een situatie terecht gekomen waarbij ik data-technisch tegen de beperkingen van het Relationele Model ben aangelopen.
Als kind van mijn tijd is zo'n ERD natuurlijk heilig, maar ik heb me ook altijd wel de vrijheid genomen om het model dusdanig uit te knijpen zodat ik met mijn code eigenlijk de volledige vrijheid had om de gegevens naar eigen inzicht in het model onder te brengen (ik ben dol op 'oortjes' en sub-entiteiten).
Het grote nadeel van een redelijk "vrij" model is dat je natuurlijk wel van die monster-queries gaat krijgen. Het blijkt in de praktijk ook nog eens redelijk lastig om het over te dragen aan een ontwikkelaar die conceptueel ergens tussen de 2de en de 3de normaalvorm is blijven hangen.

Als gezegd, liep ik tijdens het ontwerpen van een systeem tegen een bijzonder fenomeen aan: ergens in het operationele gebruik bestaat er een vrij grote kans dat er gegevens in het systeem opgeslagen moeten worden die dusdanig verschillend van aard zijn, dat ze nauwelijks in een standaard model te vatten zijn - ik kan er nu niet al te veel details over geven aangezien het project op dit moment nog een beetje "top secret" is, maar als de boel eenmaal is opgeleverd, is het wel weer een leuke technische case om hier te beschrijven.

Een ander punt is de gigantische hoeveelheid data die er straks in ondergebracht moet worden. Dat zijn niet alleen tekstuele gegevens, maar ook afbeeldingen, video's en audio-bestanden. Nou kun je de bestanden wel keurig op het filesystem zetten en een verwijzing in je database opnemen, maar in dit geval zou dat dus inhouden dat de klant op een zeker moment zeer zwaar in storage zou moeten gaan investeren.
"Groei" en de daarmee gepaard gaande "Kosten" zijn in dit project dus wel een dingetje: kijk je bijvoorbeeld naar een distributed oplossing van, zeg, Oracle, dan betaal je een godsvermogen aan licenties. Beperk je je tot een "verticaal" schaalbare oplossing (hardware uitbreidingen IN de server), dan loop je ter zijner tijd vanzelf tegen de beperkingen van het ijzer aan en zul je weer de beurs moeten trekken om de boel te upgraden of te vervangen.

Dat brengt ons bij het derde punt: downtime. Gezien het globale karakter van het systeem, kunnen we ons eigenlijk geen downtime permitteren. En dan het laatste punt: beheer. De klant heeft geen beheerders is dienst, en is ook niet van plan deze in dienst te nemen, dus zal er een (managed) VPS omgeving ergens in de cloud neergezet moeten worden.

Samengevat: een flexibel datamodel, een gigantische berg gegevens, horizontale en verticale schaalbaarheid, geen downtime en het mag niks kosten...

Na wat speurwerk en wat technische tests, kwam ik uiteindelijk uit bij MongoDB. Een zogenaamde No-SQL / Document-driven database systeem. Open Source, schaalbaar en gratis, althans de versie die we in het project gaan gebruiken.

Ik zal de komende weken mijn avonturen met Mongo hier gaan beschrijven en dan ook wat dieper ingaan op de techniek.


Stay tuned!






sittard Poststraat 2b - 6135 KR Sittard - +31 (0) 88 558 2525 - sittard@edu-deta.com
eindhoven Daalakkersweg 16 - 5641 JA Eindhoven - +31 (0) 88 558 2545 -eindhoven@edu-deta.com
utrecht Winthontlaan 200 - 3526 KV Utrecht- +31 (0) 88 558 2555 - utrecht@edu-deta.com
arnhem mr. d.u. stikkerstraat 10 - 6842 cw arnhem - +31 (0) 88 558 2565 - arnhem@edu-deta.com