Construyendo con patrones: un resumen

Al concluir la serie Construyendo con patrones, es una buena oportunidad para recapitular los problemas que resuelven los patrones que se han cubierto y resaltar algunos de los beneficios y compensaciones que tiene cada patrón. La pregunta más frecuente que se hace sobre los patrones de diseño de esquemas es "Estoy diseñando una aplicación para hacer X, ¿cómo modelo los datos?" Como esperamos que haya descubierto a lo largo de esta serie de blogs, hay muchas cosas a tener en cuenta para responder a esa pregunta. Sin embargo, hemos incluido un gráfico de casos de uso de muestra que nos ha parecido útil para al menos proporcionar una guía inicial sobre patrones de modelado de datos para casos de uso genéricos.

Casos de uso de muestra

El siguiente cuadro es una guía de lo que hemos encontrado después de años de experiencia trabajando con nuestros clientes sobre qué patrones de diseño de esquemas se utilizan en una variedad de aplicaciones. Este no es un conjunto de reglas “escritas en piedra” sobre qué patrón de diseño se puede utilizar para un tipo particular de aplicación. Asegúrese de mirar los que se usan con frecuencia en su caso de uso. Sin embargo, no descartes los demás, es posible que aún se apliquen. La forma en que diseña el esquema de datos de su aplicación depende en gran medida de sus patrones de acceso a los datos.

Resúmenes de patrones de diseño

Aproximación

El patrón de aproximación es útil cuando con frecuencia se realizan cálculos costosos y cuando la precisión de esos cálculos no es la máxima prioridad.

Ventajas

• Menos escrituras en la base de datos.
• Mantener números estadísticamente válidos.

Contras

• No se representan números exactos.
• La implementación debe realizarse en la aplicación.

Atributo

El patrón de atributos es útil para problemas que se basan en tener documentos grandes con muchos campos similares, pero hay un subconjunto de campos que comparten características comunes y queremos ordenar o consultar ese subconjunto de campos. Cuando los campos que necesitamos ordenar solo se encuentran en un pequeño subconjunto de documentos. O cuando ambas condiciones se cumplen en los documentos.

Ventajas

• Se necesitan menos índices.
• Las consultas se vuelven más sencillas de escribir y, en general, más rápidas.

Balde

Patron de cubo es una excelente solución cuando se necesita gestionar la transmisión de datos, como series temporales, análisis en tiempo real o aplicaciones de Internet de las cosas (IoT).

Ventajas

• Reduce el número total de documentos de una colección.
• Mejora el rendimiento del índice.
• Puede simplificar el acceso a los datos aprovechando la agregación previa.

Calculado

Cuando hay patrones de acceso a datos intensivos en lectura y la aplicación debe calcular los datos repetidamente, el patrón calculado es una excelente opción para explorar.

Ventajas

• Reducción de la carga de trabajo de la CPU para cálculos frecuentes.
• Las consultas se vuelven más sencillas de escribir y, en general, más rápidas.

Contras

• Puede resultar difícil identificar la necesidad de este patrón.
• Se debe evitar aplicar o abusar del patrón a menos que sea necesario.

Versiones de documentos

Cuando se enfrenta a la necesidad de mantener versiones anteriores de documentos en MongoDB, el patrón de control de versiones de documentos es una posible solución.

Ventajas

• Fácil de implementar, incluso en sistemas existentes.
• No hay impacto en el rendimiento de las consultas sobre la última revisión.

Contras

• Duplica el número de escrituras.
• Las consultas deben dirigirse a la colección correcta.

Referencia extendida

Encontrará que el patrón de referencia extendida es más útil cuando su aplicación experimente muchas operaciones JOIN para reunir datos a los que se accede con frecuencia.

Ventajas

• Mejora el rendimiento cuando hay muchas operaciones JOIN.
• Lecturas más rápidas y reducción del número total de JOIN.

Contras

• Duplicación de datos.

Parte aislada

¿Le parece que hay algunas consultas o documentos que no encajan en el resto de sus patrones de datos típicos? ¿Estas excepciones impulsan la solución de su aplicación? Si es así, el patrón de valores atípicos es una solución maravillosa para esta situación.

Ventajas

• Evita que algunos documentos o consultas determinen la solución de una aplicación.
• Las consultas se adaptan a casos de uso "típicos", pero aún se abordan los valores atípicos.

Contras

• A menudo se adaptan a consultas específicas, por lo que es posible que las consultas ad hoc no funcionen bien.
• Gran parte de este patrón se realiza con código de aplicación.

Preasignación

Cuando conoce la estructura de su documento y su aplicación simplemente necesita llenarla con datos, el patrón de asignación previa es la opción correcta.

Ventajas

• Simplificación del diseño cuando se conoce de antemano la estructura del documento.

Contras

• Simplicidad versus rendimiento.

Polimórfico

El Patrón Polimórfico es la solución cuando hay una variedad de documentos que tienen más similitudes que diferencias y los documentos necesitan mantenerse en una sola colección.

Ventajas

• Fácil de implementar.
• Las consultas pueden ejecutarse en una única colección.

Control de versiones de esquemas

Prácticamente todas las aplicaciones pueden beneficiarse del patrón de control de versiones del esquema, ya que con frecuencia se producen cambios en el esquema de datos durante la vida útil de una aplicación. Este patrón permite que las versiones anterior y actual de documentos existan una al lado de la otra en una colección.

Ventajas

• No se necesita tiempo de inactividad.
• Control de migración de esquemas.
• Reducción de la deuda técnica futura.

Contras

• Es posible que necesite dos índices para el mismo campo durante la migración.

Subconjunto

El patrón de subconjunto resuelve el problema de que el conjunto de trabajo exceda la capacidad de la RAM debido a documentos grandes en los que gran parte de los datos del documento no están siendo utilizados por la aplicación.

Ventajas

• Reducción del tamaño total del conjunto de trabajo.
• Tiempo de acceso al disco más corto para los datos utilizados con más frecuencia.

Contras

• Debemos gestionar el subconjunto.
• Obtener datos adicionales requiere viajes adicionales a la base de datos.

Árbol

Cuando los datos tienen una estructura jerárquica y se consultan con frecuencia, el patrón de árbol es el patrón de diseño a implementar.

Ventajas

• Mayor rendimiento al evitar múltiples operaciones JOIN.

Contras

• Las actualizaciones del gráfico deben gestionarse en la aplicación.

Conclusión

Como esperamos que haya visto en esta serie, el modelo de documento de MongoDB proporciona mucha flexibilidad en la forma de modelar datos. Esa flexibilidad es increíblemente poderosa, pero ese poder debe aprovecharse en términos de los patrones de acceso a datos de su aplicación. Recuerde que el diseño de esquemas en MongoDB tiene un impacto tremendo en el rendimiento de su aplicación. Hemos descubierto que los problemas de rendimiento con frecuencia se deben a un diseño deficiente del esquema.

Tenga en cuenta que para mejorar aún más el poder del modelo de documento, estos patrones de diseño de esquema se pueden usar juntos, cuando y si tiene sentido. Por ejemplo, el control de versiones de esquemas se puede utilizar junto con cualquiera de los otros patrones a medida que evoluciona la aplicación. Con los doce patrones de diseño de esquemas que se han cubierto, usted tiene las herramientas y el conocimiento necesarios para aprovechar el poder de la flexibilidad del modelo de documento.