Computed pattern en MongoDB para totales

Contenido del curso

Introducción

Proyecto

Validación de datos

Relaciones

Bonus: patrones

Próximos pasos

22
Modelado de Datos con MongoDB: Relaciones y Consultas Avanzadas
02:03 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0011:48

Computed pattern en MongoDB para totales

Curso de Modelado de Datos en MongoDB

Clase 20 de 22

Clase 20 / 22

Recursos

El computed pattern en MongoDB te permite precalcular valores como totales o promedios al momento de escribir, en lugar de calcularlos cada vez que lees el documento. Es ideal para desarrolladores que diseñan bases de datos con operaciones frecuentes de lectura, como ecommerce, sistemas de calificaciones o métricas de negocio.

Cuándo aplicar el computed pattern en tu modelado

Dentro de la metodología de modelado en MongoDB, los patrones aparecen en el último paso. Antes ya analizaste el caso de negocio, identificaste entidades, definiste qué queries se ejecutan más y mapeaste relaciones decidiendo si embeber o referenciar. Ahora toca optimizar.

El caso más natural para aplicar este patrón son las órdenes de compra de un ecommerce [04:30]. Imagina un carrito al que el usuario va agregando productos uno a uno. Cada producto tiene precio y cantidad, y tú necesitas mostrar el total de la orden.

Si cada vez que renderizas la factura recorres todos los ítems y multiplicas precio por cantidad, estás gastando CPU innecesariamente. Aquí entra el patrón: calculas el total al escribir, no al leer.

¿Qué es el computed pattern en MongoDB? Es un patrón de diseño que precalcula valores derivados (totales, promedios, sumas) en el momento de la escritura y los almacena en el documento, evitando recalcularlos en cada lectura.

Cómo implementar el computed pattern paso a paso

El ejercicio parte de una estructura de orden de compra con cuatro campos: el usuario que origina la compra, la fecha, un array vacío de ítems y un campo total inicializado en cero [03:20].

En lugar de insertar todos los productos de golpe, simulas el comportamiento real de un carrito: el usuario va agregando productos dinámicamente. Cada vez que agrega uno, ejecutas un updateOne con dos operadores en paralelo.

Qué operadores de MongoDB necesitas

Para que el patrón funcione necesitas combinar dos operadores en la misma operación de actualización:

$push: agrega el nuevo producto al array de ítems con su precio, cantidad y referencia.
$inc: incrementa el campo total con el resultado de precio multiplicado por cantidad.
objid: referencia el ID específico de la orden que estás actualizando.

La lógica es directa. Si el primer producto vale 12 dólares y el usuario pide una unidad, el $inc suma 12 al total [06:40]. Si después agrega otro producto de 45 dólares con cantidad de tres, el $inc suma 135. El total queda en 147 sin que tengas que recorrer el array.

Por qué precalcular ahorra recursos

Cuando consultas la orden con un findOne, el total ya está listo. No hay multiplicaciones en tiempo de lectura, no hay agregaciones costosas, no hay latencia adicional al renderizar la factura.

Esto importa porque la base de datos hace menos trabajo en cada query, y el frontend recibe la respuesta casi inmediata. La regla de fondo: mueves el costo computacional desde la lectura hacia la escritura, que suele ser menos frecuente.

Por qué el computed pattern optimiza CPU y rendimiento

Un caso real ilustra el impacto. En un sistema de evaluaciones tipo ICFES en Colombia [09:10], cada estudiante presentaba un examen con un score final. Originalmente, cada vez que un profesor consultaba la lista de un salón, la base de datos recalculaba el score de cada estudiante: revisaba pregunta por pregunta, validaba respuestas correctas y sumaba puntos.

El resultado era una interfaz lentísima. La solución fue aplicar computed pattern: a medida que el estudiante respondía, el sistema iba actualizando el score en el documento. Cuando terminaba el examen, el valor quedaba congelado y la consulta se volvía instantánea.

Otro ejemplo es el revenue de una película proyectada en varias salas. Sumar todos los documentos de cada sala en cada consulta sería costoso. Si precalculas el ingreso acumulado cada vez que cierra una función, la lectura es ligera.

¿Cuándo conviene usar computed pattern? Cuando lees datos con mucha más frecuencia que los escribes, y cuando necesitas valores agregados como totales, promedios o sumas que no cambian todo el tiempo.

Qué criterios usar para decidir

Antes de aplicar el patrón, valida tres condiciones:

La operación de lectura es más frecuente que la de escritura.
El valor a calcular es derivable de otros campos del documento.
Es más eficiente actualizar dinámicamente que computar en cada query.

También recuerda que la lógica de actualización puedes manejarla desde tu backend en Python, JavaScript, .NET o Java. La regla de negocio se ejecuta cada vez que insertas o modificas un producto, manteniendo el documento siempre con el total actualizado.

¿Te gustaría que profundicemos en más patrones de diseño con MongoDB? Déjalo en los comentarios.

Brayan Burgos

Hace 3 años

Patrones de Diseño en MongoDB - Resumen

1. Patrón de Aproximación:

Útil para cálculos costosos con baja prioridad de precisión.
Pros: Menos escrituras en la base de datos, mantenimiento de números estadísticamente válidos.
Contras: No representa números exactos, implementación en la aplicación.

2. Patrón de Atributo:

Útil para documentos grandes con campos similares, pero con un subconjunto que se usa para consultas o clasificación.
Pros: Menos índices necesarios, consultas más simples y rápidas.
Contras: Duplicación de datos.

3. Patrón de Cubo (Bucket):

Ideal para gestionar datos de transmisión, como series temporales o IoT.
Pros: Reduce la cantidad de documentos, mejora el rendimiento del índice, simplifica el acceso a datos.

4. Patrón Calculado (Computed):

Útil cuando se necesitan cálculos repetitivos y intensivos en lectura.
Pros: Reduce la carga de CPU, consultas más simples y rápidas.
Contras: Difícil de identificar la necesidad.

5. Patrón de Versionado de Documentos:

Para mantener versiones anteriores de documentos.
Pros: Fácil de implementar, sin impacto en el rendimiento de las consultas.
Contras: Duplica las escrituras, requiere apuntar a la colección correcta.

6. Patrón de Referencia Extendida:

Útil para reducir JOINs costosos en aplicaciones con muchas operaciones JOIN.
Pros: Mejora el rendimiento, menos JOINs.
Contras: Duplicación de datos.

7. Patrón de Valor Atípico (Outlier):

Maneja documentos o consultas excepcionales.
Pros: Evita que unos pocos documentos o consultas afecten la solución, se adaptan a casos típicos.
Contras: Puede no funcionar bien con consultas ad hoc.

8. Patrón de Preasignación (Pre-allocation):

Útil cuando se conoce la estructura del documento de antemano.
Pros: Simplifica el diseño, pero a costa del rendimiento.

9. Patrón Polimórfico:

Mantiene diferentes documentos en una sola colección.
Pros: Fácil de implementar, consultas en una colección.

10. Patrón de Versionado de Esquema:

Permite versiones previas y actuales de documentos en una colección.
Pros: Sin tiempo de inactividad, control de migración de esquema, menos deuda técnica.
Contras: Puede requerir dos índices para un campo durante la migración.

11. Patrón de Subconjunto:

Evita que el conjunto de trabajo exceda la RAM debido a documentos grandes.
Pros: Reducción del tamaño del conjunto de trabajo, acceso más rápido a datos frecuentemente usados.
Contras: Requiere gestión del subconjunto, más viajes a la base de datos.

12. Patrón de Árbol:

Para estructuras jerárquicas de datos consultadas con frecuencia.
Pros: Mejora el rendimiento al evitar JOINs, pero requiere gestión de actualizaciones en la aplicación.

Máximo Calderon

Hace 3 años

Excelentísimo aporte amigo Brayan.... Muchas gracias por compartir.... Y Nico es un verdadero Crack !!! Quiero ser como él cuando sea grande 💪💪💪

Comentarios (24)24 comentarios

JORGE ALEXANDER MÚNERA CANABAL

Hace 4 años

Danilo Andres Vallejo Ramos

Lissett Paez

BALFRE VAZQUEZ CASTREJON

Sebastián Groselj Pausic

Markin Piero Pulache Guarniz

Hace 2 años

Eduard Arias

Leonel Veliz

Daniel Antonio

Kenny Estiven Raúl Contreras Aguilar

Martín de la Rosa

Álvaro Ambiorix Marcelino Taveras

José Reinaldo Duque Serna

Ulises Serrano Pérez

Daniel Camacho

Christian Valenzuela

Daniel Villanueva

Jose Ospina

Company_admin

María Requenes Ramos

Hace un año

Emanuel Salazar

Norberto Iván Tolaba

Ronald Martin Saavedra Garay

Introducción

Modelado de datos en MongoDB desde cero

Modelado de Datos en MongoDB: Uso de JSON y Diagrama Entidad-Relación

Metodología de modelado de datos en MongoDB

Proyecto

Creación de Clúster y Bases de Datos en Mongo Atlas

Modelado de Workloads en Bases de Datos con MongoDB

Configuración de Entorno y Conexión a MongoDB con VSCode

Validación de datos

Validación de strings con JSON Schema en MongoDB

Validación de números, booleanos y enums en MongoDB

Validar arrays y subdocumentos en MongoDB

Validar contraseñas en MongoDB con regex

Validación de Datos en MongoDB: JSON Schema y Actualizaciones

Relaciones

Relaciones en Bases de Datos NoSQL: Embebidas y Referenciales

Relaciones uno a uno embebidas en MongoDB

Relaciones uno a uno con $lookup en MongoDB

Relaciones Uno a Muchos: Embebidas y Referenciadas en Bases de Datos

Relaciones Uno a Muchos con Referencias en Bases de Datos

Relaciones Muchos a Muchos en Bases de Datos: Tiendas y Productos

Relaciones Muchos a Muchos en Bases de Datos Documentales

Bonus: patrones

Desnormalización en Bases de Datos Documentales: Optimización Avanzada

Computed pattern en MongoDB para totales

Balance entre Simplicidad y Rendimiento en MongoDB

Próximos pasos

Modelado de Datos con MongoDB: Relaciones y Consultas Avanzadas

Computed pattern en MongoDB para totales

Progreso del curso

Introducción

Proyecto

Validación de datos

Relaciones

Bonus: patrones

Próximos pasos

Recursos

Recursos