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.
October 2, 2023