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

Dans le monde numérique moderne, de vastes quantités d'informations sont stockées dans des formats flexibles et non traditionnels connus sous le nom de bases de données orientées documents. Contraques aux structures rigides, semblables à des feuilles de calcul, des systèmes plus anciens, ces bases de données permettent d'organiser les données de manières qui reflètent la façon dont les applications les utilisent réellement, en regroupant souvent des informations liées au sein d'unités uniques et autonomes. À mesure que les entreprises migrent ces systèmes vers le cloud, où ils sont gérés par de grands fournisseurs technologiques, la manière dont les données sont organisées cesse d'être un simple choix technique pour devenir un choix financier. Chaque fois qu'un ordinateur lit une donnée, en écrit une nouvelle ou stocke un fichier, le fournisseur de cloud facture des frais. Ces charges sont basées sur la taille des données, le nombre d'éléments accédés et la complexité des requêtes, créant un paysage économique complexe où une petite décision de conception peut entraîner des factures considérablement plus élevées.

Pendant des années, les experts concevant ces systèmes se sont appuyés sur des modèles qui prédisent la vitesse à laquelle une base de données fonctionnera ou la quantité de mémoire qu'elle utilisera. Cependant, ces outils traditionnels ignorent souvent l'argent réellement dépensé dans le cloud. Ils peuvent dire à un ingénieur qu'une conception est rapide, mais ils ne peuvent pas dire si cette rapidité se fait à un prix inabordable. Ce fossé laisse les organisations dans l'incertitude quant à leurs coûts futurs, menant potentiellement à des architectures qui sont efficaces en termes de performance mais désastreuses pour le budget. Le défi réside dans le fait que la tarification du cloud n'est pas un tarif unique et forfaitaire ; c'est un assemblage de frais pour le stockage, pour la lecture de quantités spécifiques de données, pour l'écriture de mises à jour et pour la maintenance des index qui aident à trouver l'information rapidement. Sans un moyen de traduire les choix de conception technique en un montant monétaire unique, comparer différentes structures de bases de données revient à essayer de comparer le coût de deux voitures différentes quand l'un des prix est exprimé en kilomètres par litre et l'autre en chevaux vapeur.

Pour résoudre ce problème, les chercheurs Matteo Francia, Enrico Gallinucci, Matteo Golfarelli et Alessandra Lumini de l'Université de Bologne ont développé un nouvel outil appelé CM2. Il s'agit d'un modèle de coût monétaire pour le cloud spécifiquement conçu pour les bases de données NoSQL orientées documents fonctionnant dans des environnements sans serveur (serverless). Au lieu de se concentrer sur la vitesse ou la complexité technique, CM2 agit comme une calculatrice financière pour les concepteurs de bases de données. Il prend une manière proposée d'organiser les données et une liste de questions qui seront posées à la base de données, puis calcule le coût mensuel exact en dollars. Le modèle ne devine pas ; il décompose la dépense totale en trois parties distinctes : le coût du stockage des données et de ses index, le coût de la lecture des données, et le coût de l'écriture ou de la mise à jour. Il tient compte des politiques de tarification spécifiques des principaux fournisseurs de cloud, comme le prix facturé par gigaoctet de stockage ou par octet de données transférées.

Les chercheurs ont testé ce modèle en utilisant un scénario réaliste basé sur une boutique en ligne, comprenant des clients, des commandes, des produits et des détails d'expédition. Ils ont créé différentes versions de la manière dont les données de cette boutique pourraient être organisées. Dans une version, ils ont gardé les données hautement organisées avec une répétition minimale, semblable à un catalogue de bibliothèque strict. Dans une autre, ils ont dupliqué des informations à travers différents groupes pour rendre la recherche plus rapide, semblable au fait de garder une copie d'une carte dans chaque voiture. Ils ont ensuite exécuté des milliers de requêtes simulées contre ces différentes configurations sur un véritable service de base de données cloud fourni par Microsoft Azure. L'objectif était de voir si leur modèle pouvait prédire la facture réelle que le fournisseur de cloud enverrait.

Les résultats étaient d'une précision frappante. Lorsque les chercheurs ont comparé les prédictions du modèle aux coûts réels encourus par le service cloud, la différence était souvent inférieure à deux pour cent pour le nombre de documents accédés et moins de un pour cent pour le nombre d'entrées d'index utilisées. Pour la taille totale du stockage, le modèle présentait une erreur de moins de cinq pour cent. Plus important encore, le modèle a prédit avec succès le coût monétaire final. Dans un cas de test, le modèle estimait un coût mensuel de 0,70 dollar, alors que le coût réel était de 0,73 dollar. Dans des scénarios plus complexes impliquant des millions d'opérations, le modèle identifiait systématiquement quel design de base de données serait le moins cher, classant correctement les options même lorsque les différences étaient subtiles.

L'étude a également révélé que le design le plus efficace dépend entièrement de la manière dont le système est utilisé. Un design qui économise de l'argent sur le stockage peut finir par coûter une fortune si l'application nécessite des recherches fréquentes et complexes qui forcent le système à lire de grandes quantités de données. Inversement, un design qui répète les données pour accélérer les recherches peut être le choix le plus économique si le système est riche en lectures mais rarement mis à jour. Le modèle a montré que, dans certains cas, un design redondant était moins cher car il réduisait le nombre d'opérations de lecture coûteuses, tandis que dans d'autres cas, un design plus léger l'emportait car il minimisait le coût des mises à jour. Cela prouve qu'il n'existe pas de "meilleure" façon unique de construire une base de données ; le bon choix est celui qui s'aligne sur les schémas financiers et opérationnels spécifiques de l'application.

En fournissant un moyen unifié de mesurer le coût, CM2 permet aux ingénieurs de prendre des décisions éclairées avant même de construire le système. Cela déplace la conversation de « cela fonctionnera-t-il ? » vers « cela fonctionnera-t-il dans notre budget ? ». Les chercheurs ont démontré qu'ignorer la dimension monétaire lors de la phase de conception peut mener à des architectures qui sont techniquement solides mais financièrement insoutenables. Leur travail offre un cadre pratique pour équilibrer performance et prix, garantissant que les bases de données qui alimentent notre monde numérique restent non seulement rapides et flexibles, mais aussi abordables.