CM2: a Cloud Monetary Cost Model for Document-Based NoSQL Databases

In de moderne digitale wereld wordt enorme hoeveelheden informatie opgeslagen in flexibele, niet-traditionele formaten die bekend staan als documentgeoriënteerde databases. In tegen tegenover de rigide, spreadsheet-achtige structuren van oudere systemen, laten deze databases toe dat gegevens worden georganiseerd op manieren die de werkelijke manier waarop applicaties ze gebruiken weerspiegelen, waarbij gerelateerde informatie vaak samen in enkele, zelfstandige eenheden wordt gegroepeerd. Wanneer bedrijven deze systemen naar de cloud verplaatsen, waar ze worden beheerd door grote technologieleveranciers, stopt de manier waarop gegevens worden georganiseerd met slechts een technische keuze te zijn en wordt het een financiële keuze. Elke keer dat een computer een stukje data leest, een nieuwe schrijft of een bestand opslaat, brengt de cloudprovider een vergoeding in rekening. Deze kosten zijn gebaseerd op de grootte van de data, het aantal geraadpleegde items en de complexiteit van de verzoeken, wat een complex economisch landschap creëert waarin een kleine ontwerpbeslissing kan leiden tot aanzienlijk hogere rekeningen.

Jarenlang hebben experts die deze systemen ontwerpen vertrouwd op modellen die voorspellen hoe snel een database zal draaien of hoeveel geheugen het zal gebruiken. Deze traditionele tools negeren echter vaak het werkelijke geld dat in de cloud wordt uitgegeven. Ze kunnen een ingenieur vertellen dat een ontwerp snel is, maar ze kunnen niet zeggen of die snelheid tegen een onbetaalbare prijs komt. Deze kloof laat organisaties tasten in het duister over hun toekomstige kosten, wat potentieel kan leiden tot architecturen die efficiënt zijn qua prestaties, maar rampzalig zijn voor het budget. De uitdaging is dat cloudpricing geen enkel vast tarief is; het is een lappendeken van kosten voor opslag, voor het lezen van specifieke hoeveelheden data, voor het bijwerken van gegevens en voor het onderhouden van de indexen die helpen om informatie snel te vinden. Zonder een manier om technische ontwerpkeuzes te vertalen naar één enkel dollarbedrag, is het vergelijken van verschillende database-structuren alsoر met het proberen te vergelijken van de kosten van twee verschillende auto's wanneer de ene prijs in mijlen per gallon is en de andere in motorvermogen.

Om dit op te lossen, ontwikkelden onderzoekers Matteo Francia, Enrico Gallinucci, Matteo Golfarelli en Alessandra Lumini van de Universiteit van Bologna een nieuwe tool genaamd CM2. Dit is een cloud monetair kostenmodel dat specifiek is ontworpen voor documentgebaseerde NoSQL-databases die draaien in serverless omgevingen. In plaats van zich te richten op snelheid of technische complexiteit, fungeert CM2 als een financiële rekenmachine voor database-ontwerpers. Het neemt een voorgestelde manier van gegevensorganisatie en een lijst met de vragen die aan de database gesteld zullen worden, en berekent vervolgens de exacte maandelijkse kosten in dollars. Het model raadt niet; het breekt de totale uitgave af in drie afzonderlijke delen: de kosten voor het opslaan van de data en de indexen, de kosten voor het lezen van de data, en de kosten voor het schrijven of bijwerken ervan. Het houdt rekening met de specifieke prijsbeleid van grote cloudproviders, zoals hoeveel ze rekenen per gigabyte opslag of per byte aan overgedragen data.

De onderzoekers testten dit model met een realistisch scenario gebaseerd op een webshop, compleet met klanten, bestellingen, producten en verzendgegevens. Ze creëerden verschillende versies van hoe de gegevens van deze winkel georganiseerd konden worden. In één versie hielden ze de gegevens zeer georganiseerd met minimale duplicatie, vergelijkbaar met een strikte bibliotheekcatalogus. In een andere versie dupliceerden ze informatie over verschillende groepen om het sneller vindbaar te maken, vergelijkbaar met het bewaren van een kopie van een kaart in elke auto. Vervolgens draaiden ze duizenden gesimuleerde queries tegen deze verschillende opstellingen op een echte cloud-databaseservice geleverd door Microsoft Azure. Het doel was om te zien of hun model de werkelijke rekening kon voorspellen die de cloudprovider zou sturen.

De resultaten waren opvallend accuraat. Wanneer de onderzoekers de voorspellingen van het model vergeleken met de werkelijke kosten die door de clouddienst werden gemaakt, was het verschil vaak minder dan twee procent voor het aantal geraadpleegde documenten en minder dan één procent voor het aantal gebruikte index-items. Voor de totale opslaggrootte week het model af met minder dan vijf procent. Nog belangrijker was dat het model de uiteindelijke monetaire kosten succesvol voorspelde. In één testgeval schatte het model een maandelijkse kost van 0,70 dollar, terwijl de werkelijke kosten 0,73 dollar waren. In complexere scenario's met miljoenen operaties identificeerde het model consequent welke database-ontwerp de goedkoopste zou zijn, en rangschikte de opties zelfs bij subtiele verschillen correct.

De studie onthulde ook dat het meest efficiënte ontwerp volledig afhangt van hoe het systeem wordt gebruikt. Een ontwerp dat geld bespaart op opslag, kan een fortuin kosten als de applicatie frequente, complexe zoekopdrachten vereist die het systeem dwingen om grote hoeveelheden data te lezen. Omgekeerd kan een ontwerp dat gegevens herhaalt om zoekopdrachten te versnellen, de meest economische keuze zijn als het systeem 'read-heavy' is maar zelden wordt bijgewerkt. Het model toonde aan dat in sommige gevallen een redundant ontwerp goedkoper was omdat het het aantal dure leesoperaties verminderde, terwijl in andere gevallen een slanker ontwerp won omdat het de kosten van het bijwerken van gegevens minimaliseerde. Dit bewijst dat er niet één enkele "beste" manier is om een database te bouwen; de juiste keuze is de keuze die aansluit bij de specifieke financiële en operationele patronen van de applicatie.

Door een verenigde manier te bieden om kosten te meten, stelt CM2 ingenieurs in staat om geïnformeerde beslissingen te nemen nog voordat ze het systeem bouwen. Het verschuift het gesprek van "werkt dit?" naar "werkt dit binnen ons budget?". De onderzoekers toonden aan dat het negeren van de monetaire dimensie tijdens de ontwerpfase kan leiden tot architecturen die technisch solide zijn, maar financieel onhoudbaar. Hun werk biedt een praktisch kader voor het balanceren van prestaties en prijs, waardoor de databases die onze digitale wereld aandrijven niet alleen snel en flexibel blijven, maar ook betaalbaar.