No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Computed pattern

20/22
Recursos

Aportes 22

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Sí estaría bueno ese curso de patrones y casos de uso 👍
De igual manera un curso para bakend con Node.js y mongoDB

Estaria excelente poder ver cada uno de los patrones

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.

Computed Pattern

Es realizar solo los computos necesarios cuando hay cambios, para no calcularlos durante las consultas.

Casos de uso

  • No recalcular en cada consulta, ya que se actualiza cuando es necesario. Pre-calculo para consultas.
  • Reduce las consultas necesarias y simplifica las consultas, a costa de las actualizaciones.
  • Cuando necesitas calcular un valor a partir de otros campos en un documento y mostrar el resultado en una consulta o informe.
  • Cuando es más frecuente la lectura que la escritura.
  • Calcular el valor por cada lectura es costoso, es mejor pre calcular en cada escritura.
  • No requiere hacer busquedas innecesarias de valores ya agregados, ya que puede ser incremental.
  • Se puede manipular con un lenguaje de programacion.

Ejemplo

Se hara una orden de compra dinamica, en donde, al agregar productos a la orden esta actualizara el valor total que es la suma de todos los productos multiplicado su cantidad.

  1. Creamos una nueva orden de compra
    db.orders.insertOne({
        user_id: ObjectId('6497b8b4affb4e4355c4f297'),
        date: '2020-12-12',
        total: 0, // nuevo campo que sera la suma de los items
        items: [] //normalmente empieza sin nada una orden de compra
    })
    
    Guardamos el ObjectID generado
  2. Creamos un script para agregar items add-item.mongodb, en el que se agrega un item a la lista y se suma al precio el valor extra.
    db.orders.updateOne( // actualizamos la orden
        { // hacemos match con la orden que queremos actualizar
            _id: ObjectId('649cb8c89f973670e36e123f')   
        },
        {   // mostramos el cambio, agregando un nuevo elemento
            $push: { // agregar elemento
                items: { // quien se lo agrego
                    name: 'Producto 1',
                    qty: 2,
                    price: 12,
                    product_id: ObjectId('649923f457514437ac501dd4')  
                }
            },
            $inc: { // incrementador
                total: 12 * 2 // total = total + price * qty
            }
        }
    )
    

Otros patrones

Me quedó gustando el tema de los patrones de diseño para bases de datos. Estaría buena una ruta completa de patrones para backend.

En este Computed Pattern es darle la responsabilidad al Motor de Base de Datos del procesamiento de los mismos.

Cuando lo aplicaría?

  1. Cuando no hay restricciones de procesamiento en BD
  2. Cuando tengo restricciones en el tamaño de mi servicio que hace la llamada a Mongo
  3. Cuando el documento que debo procesar se que no tiene una concurrencia exagerada donde un procesamiento pueda pisar al anterior
  4. Cuando la empresa en donde estoy haciendo el producto, tiene una cultura de procesamiento en la DB (ejemplo, empresas con trayectoria que tienen sus sistemas principales en oracle, y el procesamiento ocurre en la DB, la transformación digital debería pasar por preguntarnos si mantener ese estilo seria lo mas indicado)

Curso de patrones estaria genial.

Un curso de patrones y arquitecturas sería genial.

queremos curso de patrones.

Exquisites de clase. Muy buenos ejemplos y una excelente forma de sacarle jugo a las bases de datos NoSQL.

Muy bueno calcular el valor de un campo, con la opercion de otrs campos del mismo documento, auqnue del todo no es dinamico ya que tuvo que poner los valores manualmente, tambien los aggregate, ademas de traer la info referenciada de otro doc, me sirve para agregar un campo al docuemnto actual calculando el total ejemplo:

db.ventas.aggregate([
  {
    $addFields: {
      precioTotal: {
        $multiply: ["$cantidad", "$precioUnitario"]
      }
    }
  }
]);
Estaria excelente un curso complementario de tal vez no todos los patrones, pero si digamos los mas utilizados en la industria

para cuando un curso de patrones en mongoDB ?

Sería demasiado interesante un curso de patrones, ya que con esta breve introducción queda uno con el deseo de conocer mejores prácticas al aplicar estos patrones en nuestros proyectos.

Dentro de la metodología para modelado de datos existe una fase que es aplicar patrones. Los patrones de diseño de esquemas sirven para optimizar el modelo de datos en función de cómo la aplicación consulta y utiliza los datos. Existen diferentes categorías de patrones de diseño: * **Manejo de valores calculados:** Realizar cálculos en la base de datos para que los resultados estén listos cuando el cliente solicite los datos * **Agrupamiento de datos:** Agrupar los datos en series para mejorar el rendimiento y tener en cuenta los valores atípicos. * **Datos polimórficos:** Manejar campos de documentos variables y tipos de datos en una sola colección. * **Control de versiones de documentos y esquemas:** Prepararse para los cambios de esquema a fin de tener en cuenta los requisitos técnicos cambiantes. **Almacenar datos calculados** Es posible que una aplicación necesite derivar un valor de los datos de origen almacenados en una base de datos. Calcular un nuevo valor puede requerir grandes recursos de CPU, especialmente en el caso de grandes conjuntos de datos o en casos en los que se deben examinar varios documentos. Si se solicita un valor calculado con frecuencia, puede resultar más eficiente guardar ese valor en la base de datos con anticipación. De esta manera cuando la aplicación solicita datos, solo se requiere una operación de lectura. Documentación: <https://www.mongodb.com/docs/manual/data-modeling/design-patterns/> ↙️
El computed patt (patrón calculado) se utiliza cuando tenemos datos que deben calcularse repetidamente en nuestra aplicación.
Queremos curso exclusivo de patrones!

SI estaria bien mas cursos de Mongo (incluidos patrones)

Me gustaria que sigan agregando cursos de MongoDB. Patrones, Arquitecturas, Permisos, Seguridad.

Seria muy interesante un curso enfocado en los patrones de mongoDB

Concido con varios compañeros, seria importante conocer estos patrones para poder crecer como developer más integrales

Comparto información adicional acerca de computed pattern: https://www.mongodb.com/blog/post/building-with-patterns-the-computed-pattern