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

En el mundo digital moderno, vastas cantidades de información se almacenan en formatos flexibles y no tradicionales conocidos como bases de datos orientadas a documentos. A diferencia de las estructuras más rígidas, similares a las hojas de cálculo de los sistemas antiguos, estas bases de datos permiten que los datos se organicen de formas que reflejan cómo las aplicaciones los utilizan realmente, agrupando a menudo información relacionada en unidades únicas y autónomas. A medida que las empresas trasladan estos sistemas a la nube, donde son gestionados por grandes proveedores tecnológicos, la forma en que se organizan los datos deja de ser solo una elección técnica para convertirse en una elección financiera. Cada vez que una computadora lee un fragmento de datos, escribe uno nuevo o almacena un archivo, el proveedor de la nube cobra una tarifa. Estos cargos se basan en el tamaño de los datos, el número de elementos accedidos y la complejidad de las solicitudes, creando un panorama económico complejo donde una pequeña decisión de diseño puede derivar en facturas significativamente más altas.

Durante años, los expertos que diseñan estos sistemas han dependido de modelos que predicen qué tan rápido funcionará una base de datos o cuánta memoria utilizará. Sin embargo, estas herramientas tradicionales suelen ignorar el dinero real gastado en la nube. Pueden decirle a un ingeniero que un diseño es rápido, pero no pueden decirle si esa velocidad tiene un precio inasequible. Esta brecha deja a las organizaciones adivinando sobre sus costos futuros, lo que puede conducir a arquitecturas que son eficientes en rendimiento pero desastrosas en presupuesto. El desafío es que el precio de la nube no es una tarifa única y plana; es un mosaico de tarifas por almacenamiento, por leer cantidades específicas de datos, por escribir actualizaciones y por mantener los índices que ayudan a encontrar la información rápidamente. Sin una forma de traducir las decisiones de diseño técnico en un monto de dinero único, comparar diferentes estructuras de bases de datos es como intentar comparar el costo de dos autos diferentes cuando uno tiene un precio en millas por galón y el otro en caballos de fuerza del motor.

Para resolver esto, los investigadores Matteo Francia, Enrico Gallinucci, Matteo Golfarelli y Alessandra Lumini, de la Universidad de Bolonia, desarrollaron una nueva herramienta llamada CM2. Este es un modelo de costo monetario en la nube diseñado específicamente para bases de datos NoSQL basadas en documentos que se ejecutan en entornos sin servidor (serverless). En lugar de centrarse en la velocidad o la complejidad técnica, CM2 actúa como una calculadora financiera para los diseñadores de bases de datos. Toma una forma propuesta de organizar los datos y una lista de las preguntas que se le harán a la base de datos, y luego calcula el costo mensual exacto en dólares. El modelo no adivina; desglosa el gasto total en tres partes distintas: el costo de almacenar los datos y sus índices, el costo de leer los datos y el costo de escribirlos o actualizarlos. Tiene en cuenta las políticas de precios específicas de los principales proveedores de la nube, como cuánto cobran por gigabyte de almacenamiento o por byte de datos transferidos.

Los investigadores probaron este modelo utilizando un escenario realista basado en una tienda en línea, con clientes, pedidos, productos y detalles de envío. Crearon diferentes versiones de cómo se podría organizar los datos de esta tienda. En una versión, mantuvieron los datos altamente organizados con una repetición mínima, similar a un catálogo de biblioteca estricto. En otra, duplicaron la información a través de diferentes grupos para que fuera más rápido encontrarla, similar a mantener una copia de un mapa en cada auto. Luego ejecutaron miles de consultas simuladas contra estas diferentes configuraciones en un servicio de base de datos en la nube real proporcionado por Microsoft Azure. El objetivo era ver si su modelo podía predecir la factura real que el proveedor de la nube enviaría.

Los resultados fueron sorprendentemente precisos. Cuando los investigadores compararon las predicciones del modelo con los costos reales incurridos por el servicio en la nube, la diferencia fue a menudo menor al dos por ciento para el número de documentos accedidos y menor al uno por ciento para el número de entradas de índice utilizadas. Para el tamaño total del almacenamiento, el modelo falló por menos del cinco por ciento. Lo más importante es que el modelo predijo con éxito el costo monetario final. En un caso de prueba, el modelo estimó un costo mensual de 0.70 dólares, mientras que el costo real fue de 0.73 dólares. En escenarios más complejos que involucraban millones de operaciones, el modelo identificó consistentemente qué diseño de base de datos sería el más barato, clasificando correctamente las opciones incluso cuando las diferencias eran sutiles.

El estudio también reveló que el diseño más eficiente depende enteramente de cómo se utilice el sistema. Un diseño que ahorra dinero en almacenamiento puede terminar costando una fortuna si la aplicación requiere búsquedas frecuentes y complejas que obligan al sistema a leer grandes cantidades de datos. Por el contrario, un diseño que repite datos para acelerar las búsquedas puede ser la opción más económica si el sistema tiene una carga alta de lectura pero se actualiza rara vez. El modelo mostró que, en algunos casos, un diseño redundante era más barato porque reducía el número de operaciones de lectura costosas, mientras que en otros casos, un diseño más ligero ganaba porque minimizaba el costo de las actualizaciones de escritura. Esto demuestra que no existe una única "mejor" forma de construir una base de datos; la elección correcta es la que se alinea con los patrones financieros y operativos específicos de la aplicación.

Al proporcionar una forma unificada de medir el costo, CM2 permite a los ingenieros tomar decisiones informadas incluso antes de construir el sistema. Cambia la conversación de "¿funcionará esto?" a "¿funcionará esto dentro de nuestro presupuesto?". Los investigadores demostraron que ignorar la dimensión monetaria durante la fase de diseño puede conducir a arquitecturas que son técnicamente sólidas pero financieramente insostenibles. Su trabajo ofrece un marco práctico para equilibrar el rendimiento y el precio, asegurando que las bases de datos que impulsan nuestro mundo digital sean no solo rápidas y flexibles, sino también asequibles.