Door: Tino Dudink 11-1-2024
“The cloud or out”. Een gevatte slogan die ooit werd bedacht door een bekend adviesbureau. Toegegeven, er zit iets in. De cloud biedt onbegrensde schaalbaarheid en beschikbaarheid, zonder dat je enorme investeringen moet doen. Toch is een waarschuwing op z’n plaats. Inzicht in de kostendrijvers van cloudoplossingen is heel belangrijk. Want schaalbaarheid is geweldig, maar van een spontaan opschalende factuur wordt niemand blij. In deze blog onderzoekt Tino Dudink, DBA Consultant en Senior Database Reliability Engineer, het belang van zorgvuldige planning en datamodellering bij de migratie naar een clouddatabase. Doe je dat niet, dan kun je weleens te maken krijgen met ongecontroleerde datagroei.
De cloud biedt flexibiliteit en schaalbaarheid, daar is geen twijfel over mogelijk. Maar is het ook altijd de meest kostenefficiënte oplossing? Dat is nog maar de vraag. De rekening komt altijd achteraf en uitgaven kunnen onopgemerkt blijven stijgen. Of het nu gaat om Infrastructure as a Service (IaaS), Platform as a Service (PaaS) of DBaaS (Database as a Service), alle cloudproviders bieden verschillende serviceniveaus en flexibiliteit aan, waarbij de componenten rekenkracht (CPU), opslag (diskspace), werkgeheugen (RAM), en netwerk (I/O) van invloed zijn op de uiteindelijke kosten. Laten we eens dieper ingaan op de impact van het gebruik van (cloud)opslag op de kosten (cloudspend of Opex).
In een database wordt veel gebruikersgegevens opgeslagen die meestal te maken hebben met dimensies zoals klant, tijd, product, producteenheid, prijs en contract. Hoeveel ruimte die gegevens in beslag nemen, hangt af van je datamodel. Voor we ingaan op de kosten, wil ik illustreren hoeveel invloed het datamodel heeft. Dat doe ik aan de hand van twee voorbeelden.
Stel dat je in een tijdveld niet alleen de datum en tijd (uren, minuten, seconden) registreert, maar ook de fracties van seconden tot op microseconden nauwkeurig. Supernauwkeurig natuurlijk, maar is het ook altijd nodig? Misschien als je Jac Orie heet, maar als je contractdata bijhoudt, lijkt me dat wat overdadig. Door dit veld te vereenvoudigen naar alleen een datum, uren en minuten, kan je aanzienlijk op opslagruimte besparen. In een database met miljoenen records kan dit verschil in datagrootte leiden tot een vermindering van de totale opslagbehoefte met wel veertig procent!
‘Varchar’ is een datatype dat staat voor ‘variabel aantal karakters’. Het wordt gebruikt om tekst van variabele lengte op te slaan. Bijvoorbeeld, ‘varchar(50)’ betekent dat het veld tot 50 karakters kan bevatten. Het lijkt misschien efficiënt om dit datatype te gebruiken voor kortere tekstvelden om zo flexibiliteit te garanderen. Maar pas op, het kan er ook voor zorgen dat je onnodig veel opslagruimte in beslag neemt. Neem bijvoorbeeld een veld voor postcodes. In Nederland bestaat dit altijd uit zes karakters. Door dit veld te definiëren als ‘varchar(50)’, reserveer je veel meer ruimte dan nodig is. Dit kan leiden tot een aanzienlijk grotere opslagbehoefte, zowel voor de data zelf als voor de indexen waarin deze velden zijn opgenomen.
Laten we een rekenvoorbeeld nemen. Stel je voor. Je hebt een bedrijf met duizend klanten, een bescheiden aantal in vergelijking met de grote spelers in de branche. Ik gok dat de lokale boekhandel al duizend klanten heeft. Maar kijk dan eens naar de hoeveelheid gegevens die deze duizend klanten genereren. In slechts één jaar tijd kunnen deze klanten een opslagbehoefte van meer dan twintig gigabytes genereren. Klinkt best beheersbaar, toch? Maar wat als het bedrijf succesvol is en zijn klantenbestand uitbreidt naar 100.000 of zelfs 1.000.000 klanten? Neem een Nederlands e-commercebedrijf dat zich richt op wonen, koken en lifestyleproducten. Niet eens zo’n heel extreem grote speler, maar met een flinke groeiambitie. Als je dan niet goed naar je datamodel hebt gekeken, dan groeien de opslagvereisten de pan uit.
| Benieuwd naar het precieze rekenvoorbeeld? Stuur een mail en je ontvangt het in je mailbox!
Nu denk je misschien: mooi rekenvoorbeeld Tino, maar dat is allemaal theorie. Het zal zo’n vaart niet lopen, toch? Vergis je niet, ik heb het onlangs zelf meegemaakt bij een klant. Als die klant zonder veel aandacht zo maar al zijn data naar de cloud had gemigreerd, zou zijn database in drie jaar tijd van een bescheiden 2 terabytes zijn gegroeid naar een gigantische 180 terabytes. Ja, je leest het goed, een groei van 8.900 procent!
Zoals je ziet, kan zelfs een kleine wijziging in het datamodel – op het eerste gezicht misschien verwaarloosbaar – een enorme impact hebben op de opslagvereisten en dus op de kosten. Dit geldt zowel voor on-premise systemen als voor cloudopslag, maar met één belangrijk verschil: in de cloud is er geen natuurlijke 'rem' op de datagroei. Waar bij een on-premise systeem de fysieke beperking van diskruimte een grens stelt en zorgt dat je bewust nadenkt over al dan niet extra investeren, biedt de cloud een schijnbaar onbegrensde capaciteit. Tel daarbij op de kosten voor rekenkracht, geheugen en het aantal transacties. Het is als winkelen met een creditcard zonder limiet: voor je het weet word je onverwacht met een dikke vette factuur geconfronteerd. Als je daar niet heel alert op bent, kan dat een bedrijfsrisico vormen.
Het zal duidelijk zijn dat zorgvuldige planning en datamodellering onmisbaar zijn om dergelijke ongecontroleerde datagroei te voorkomen. Dat geldt on-premise, maar nog veel meer bij de migratie naar de cloud. Een hybride oplossing, waarbij je de voordelen van zowel cloud als on-premise opslag combineert, kan een effectieve strategie zijn. Dit biedt de flexibiliteit van de cloud voor schaalbaarheid waar het moet en als uitwijkmogelijkheid voor nood, terwijl je tegelijkertijd het voordeel van onpremise behoudt: controle over data en governance.
In 1987 was je een held als je via een PC-privé-project een computer kreeg met een 10 megabytes harde schijf. Als je in die tijd een database moest bouwen had je niet meer ruimte dan die 10 megabytes. Dat maakte dat je vanzelf wel scherp was op datavelden en datatypes. Door deze natuurlijke rem bouwde je de meest efficiënte databases. Voor de ‘jeugd van tegenwoordig’ lijkt die opslag (diskruimte) ongelimiteerd. Daardoor stap je al snel in een valkuil: te grote datavelden, inefficiënte datatypes en te wijde indexen. Niet omdat het moet, maar omdat het kan. Dan gaat de wet van de grote getallen spelen. Als je groeit – in aantal transacties of in aantal klanten – is het risico dat je database uiteindelijk in relatief korte tijd naar – pak ‘m beet – 500 terabytes of meer groeit.
Overweeg je te gaan migreren naar de cloud en vraag je je af wat het effect is op je bedrijfsprocessen? OptimaData kan ondersteuning bieden in het maken van de juiste keuzes, het doorlopen van een migratie-readiness-programma of het in kaart brengen van cloud- en beheerkosten via een benchmark. Direct een Trusted Advisor achter de hand hebben voor ‘stel dat het nodig is’ en ‘who do you gonna call’? Vraag gerust eens naar de mogelijkheden.
Optimaliseren van databasegebruik
Optimaliseren van datamodellering