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

Nel mondo digitale moderno, enormi quantità di informazioni sono archiviate in formati flessibili e non tradizionali, noti come database orientati ai documenti. A differenza delle strutture rigide, simili a fogli di calcolo, dei sistemi più datati, questi database consentono di organizzare i dati in modi che rispecchiano il modo in cui le applicazioni li utilizzano effettivamente, raggruppando spesso informazioni correlate in singole unità autosufficienti. Man mano che le aziende spostano questi sistemi nel cloud, dove sono gestiti da grandi fornitori tecnologici, il modo in cui i dati sono organizzati smette di essere solo una scelta tecnica e diventa una scelta finanziaria. Ogni volta che un computer legge un pezzo di dati, ne scrive uno nuovo o archivia un file, il fornitore del cloud addebita una commissione. Questi costi si basano sulla dimensione dei dati, sul numero di elementi accessi e sulla complessità delle richieste, creando un panorama economico complesso in cui una piccola decisione progettuale può portare a fatture significativamente più alte.

Per anni, gli esperti che progettano questi sistemi si sono affidati a modelli che prevedono quanto sarà veloce un database o quanta memoria utilizzerà. Tuttavia, questi strumenti tradizionali spesso ignorano il denaro effettivamente speso nel cloud. Possono dire a un ingegnere che un design è veloce, ma non possono dire se questa velocità avvenga a un prezzo insostenibile. Questa lacuna lascia le organizzazioni a indovinare i propri costi futuri, portando potenzialmente ad architetture che sono efficienti in termini di prestazioni ma disastrose per il budget. La sfida è che il pricing del cloud non è una singola tariffa fissa; è un mosaico di commissioni per l'archiviazione, per la lettura di quantità specifiche di dati, per l'aggiornamento dei dati e per la manutenzione degli indici che aiutano a trovare rapidamente le informazioni. Senza un modo per tradurre le scelte di progettazione tecnica in un singolo importo monetario, confrontare diverse strutture di database è come cercare di confrontare il costo di due auto diverse quando un prezzo è espresso in chilometri al litro e l'altro in cavalli vapore.

Per risolvere questo problema, i ricercatori Matteo Francia, Enrico Gallinucci, Matteo Golfarelli e Alessandra Lumini dell'Università di Bologna hanno sviluppato un nuovo strumento chiamato CM2. Si tratta di un modello di costo monetario per il cloud progettato specificamente per database NoSQL orientati ai documenti in ambienti serverless. Inve modo di concentrarsi sulla velocità o sulla complessità tecnica, CM2 agisce come una calcolatrice finanziaria per i progettisti di database. Prende un modo proposto di organizzare i dati e un elenco di domande che verranno poste al database, quindi calcola il costo mensile esatto in dollari. Il modello non va a tentativi; scompone la spesa totale in tre parti distinte: il costo di archiviazione dei dati e dei loro indici, il costo di lettura dei dati e il costo di scrittura o aggiornamento. Tiene conto delle specifiche politiche di prezzo dei principali fornitori di cloud, come quanto venga addebitato per gigabyte di archiviazione o per byte di dati trasferiti.

I ricercatori hanno testato questo modello utilizzando uno scenario realistico basato su un negozio online, completo di clienti, ordini, prodotti e dettagli di spedizione. Hanno creato diverse versioni di come i dati di questo negozio potessero essere organizzati. In una versione, hanno mantenuto i dati altamente organizzati con una ripetizione minima, simile a un rigoroso catalogo di biblioteca. In un'altra, hanno duplicato le informazioni attraverso diversi gruppi per rendere più veloce la ricerca, simile a tenere una copia di una mappa in ogni auto. Hanno poi eseguito migliaoli di query simulate contro queste diverse configurazioni su un vero servizio di database cloud fornito da Microsoft Azure. L'obiettivo era vedere se il loro modello potesse prevedere la fattura reale che il fornitore del cloud avrebbe inviato.

I risultati sono stati sorprendentemente accurati. Quando i ricercatori hanno confrontato le previsioni del modello con i costi reali sostenuti dal servizio cloud, la differenza era spesso inferiore al due percento per il numero di documenti accessi e inferiore all'uno percento per il numero di voci di indice utilizzate. Per la dimensione totale dell'archiviazione, il modello presentava uno scostamento inferiore al cinque percento. Ancora più importante, il modello ha previsto con successo il costo monetario finale. In un caso di test, il modello stimava un costo mensile di 0,70 dollari, mentre il costo reale era di 0,73 dollari. In scenari più complessi che coinvolgevano milioni di operazioni, il modello ha identificato costantemente quale design di database sarebbe stato il più economico, classificando correttamente le opzioni anche quando le differenze erano sottili.

Lo studio ha anche rivelato che il design più efficiente dipende interamente da come viene utilizzato il sistema. Un design che risparmia denaro sull'archiviazione potrebbe finire per costare una fortuna se l'applicazione richiede ricerche frequenti e complesse che costringono il sistema a leggere grandi quantità di dati. Viceversa, un design che ripete i dati per velocizzare le ricerche potrebbe essere la scelta più economica se il sistema è orientato alla lettura ma viene aggiornato raramente. Il modello ha dimostrato che in alcuni casi un design ridondante era più economico perché riduceva il numero di costose operazioni di lettura, mentre in altri casi un design più snello vinceva perché minimizzava i costi di aggiornamento. Ciò prova che non esiste un unico modo "migliore" per costruire un database; la scelta giusta è quella che si allinea con i pattern finanziari e operativi specifici dell'applicazione.

Fornendo un modo unificato per misurare il costo, CM2 consente agli ingegneri di prendere decisioni informate prima ancora di costruire il sistema. Sposta la conversazione da "funzionerà?" a "funzionerà entro il nostro budget?". I ricercatori hanno dimostrato che ignorare la dimensione monetaria durante la fase di progettazione può portare ad architetture tecnicamente solide ma finanziariamente insostenibili. Il loro lavoro offre un quadro pratico per bilanciare prestazioni e prezzo, garantendo che i database che alimentano il nostro mondo digitale rimangano non solo veloci e flessibili, ma anche accessibili.