Mejores prácticas para el modelado de datos en MongoDB

El modelo de datos flexible de MongoDB permite equilibrar estratégicamente el rendimiento y la capacidad de adaptación al tiempo que garantiza la coherencia e integridad de los datos. Además de la orientación general sobre planificar tu esquema, considera las siguientes mejores prácticas para optimizar tu modelo de datos y determinar cuál patrón de diseño de esquema puede ser más adecuado para tu caso de uso de la aplicación.

Planifica tu esquema con antelación e itera

Planifica y diseña tu esquema al principio del proceso de desarrollo. Esto ayuda a prevenir problemas de rendimiento a medida que su aplicación crece.

El esquema flexible de MongoDB te permite diseñar tu esquema de manera iterativa. Sin embargo, puede seguir siendo difícil modificar esquemas a gran escala que se utilizan en producción. Dependiendo de tu aplicación, puede que desees establecer un esquema simple para cubrir la funcionalidad básica antes de optimizar.

Modificar Tu Modelo de Datos

Considera el siguiente ejemplo:

Se te ha encomendado la tarea de construir el backend de una plataforma de aprendizaje en linea que almacena información sobre cursos y sus lecciones. Inicialmente, la plataforma solo necesita almacenar la siguiente información básica de cada curso:

Título del curso
Instructor
Descripción
Lecciones, embebidas como un arreglo de subdocumentos dentro de cada documento de curso. Por el momento, cada subdocumento de lección solo contiene un título, descripción y diapositivas de presentación.

A medida que la plataforma evoluciona, cada curso necesita formatos adicionales de aprendizaje y evaluación, tales como videos, cuestionarios, tareas y enlaces a recursos externos. Incorporar todos estos nuevos datos en cada documento del curso haría que el modelo de datos sea demasiado complejo.

En su lugar, considere crear un/a independiente lessons colección. De este modo, puedes enlazar las colecciones course y lessons usando referencias de IDs. Al utilizar referencias, cada lección puede incluir diferentes tipos de contenido y ser más flexible para futuros cambios de formato.

Datos relacionados con enlaces

Cuando se diseñe el modelo de datos en MongoDB, se debe considerar la estructura de los documentos y las formas en que la aplicación utiliza datos de entidades relacionadas.

Para vincular datos relacionados, puedes:

Incrusta los datos relacionados dentro de un solo documento.
Consulte los datos relacionados almacenados en una colección aparte.

Para ejemplos de cuándo utilizar incrustación o referencia, consulta la siguiente tabla:

Scenario	Método de vinculación
Mantener los datos relacionados juntos llevará a un modelo de datos y un código más sencillo.	Incrustación
Tienes una relación "tiene-a" o "contiene" entre las entidades.	Incrustación
Su aplicación query piezas de información en conjunto.	Incrustación
Tienes datos que a menudo se actualizan juntos.	Incrustación
Tienes datos que deberían ser archivados al mismo tiempo.	Incrustación
El lado secundario de la relación tiene alta cardinalidad.	Referenciando
La duplicación de datos es demasiado complicada de gestionar y no se prefiere.	Referenciando
El tamaño combinado de tus datos ocupa demasiada memoria o ancho de banda de transferencia para tu aplicación.	Referenciando
Tus datos integrados crecen sin límites.	Referenciando
Tus datos se escriben en diferentes momentos en una carga de trabajo intensiva en escritura.	Referenciando
Para el lado hijo de la relación, tus datos pueden existir por sí solos sin un padre.	Referenciando

Para obtener más información sobre los casos de uso, consideraciones de rendimiento y beneficios de cada método de vinculación de datos, consulta:

Duplicate Data

Al incrustar datos relacionados en un solo documento, se puede duplicar datos entre dos colecciones. La duplicación de datos permite a la aplicación hacer una query de información relacionada sobre varias entidades en una sola query, mientras separa lógicamente las entidades en el modelo.

Antes de duplicar datos, considere los siguientes factores:

El beneficio del rendimiento de las lecturas cuando los datos están duplicados. La duplicación de datos puede eliminar la necesidad de realizar uniones entre varias colecciones, lo que puede mejorar el rendimiento de la aplicación.
Con qué frecuencia se deben actualizar los datos duplicados. La lógica extra necesaria para gestionar las actualizaciones poco frecuentes es menos costosa que realizar uniones (búsquedas) en las operaciones de lectura. Sin embargo, la actualización frecuente de datos duplicados puede causar cargas de trabajo pesadas y problemas de rendimiento.

La siguiente tabla enumera los diferentes tipos de datos duplicados que podrían existir en tu esquema:

Tipo de datos duplicados	Descripción	Ejemplo
Inmutable	Datos que nunca cambian. Los datos inmutables son un buen candidato para la duplicación de datos	La fecha en que se creó la cuenta de usuario.
Temporal	Datos que pueden cambiar con el tiempo, pero es importante conservar el valor histórico de los datos.	La dirección de un cliente en el momento en que realizó un pedido. Si el cliente se traslada a una nueva dirección, no afecta las direcciones registradas donde se enviaron los pedidos anteriores.
Sensible a la caducidad	Datos que requieren actualizaciones frecuentes para garantizar que todas las ocurrencias de los datos sean coherentes. Las aplicaciones pueden usar transacciones o activadores para actualizar todas las ocurrencias.	La cantidad de artículos en acciones para un producto determinado, que debe actualizarse cada vez que un cliente realiza un pedido de ese producto.
No es sensible al estado obsoleto	Datos que pueden tolerar la obsolescencia durante un período de tiempo más prolongado. Las aplicaciones pueden utilizar una tarea en segundo plano para actualizar periódicamente todas las apariciones de los datos en función de la obsolescencia aceptable y el costo de las actualizaciones.	Una lista de productos recomendados para un cliente, que no necesita ser recompilada cada vez que se agrega un nuevo producto al sistema.

Si no necesitas actualizar los datos duplicados con frecuencia, sería necesario un trabajo adicional mínimo para mantener la consistencia entre las dos colecciones. Sin embargo, si los datos duplicados se actualizan con frecuencia, utilizar una referencia para vincular datos relacionados puede ser un mejor enfoque.

Para ver ejemplos de cómo la duplicación de datos relacionados puede ayudar a optimizar el modelo de datos, consulta Gestionar datos duplicados.

Aplicar coherencia de los datos

Si duplicas datos en tu esquema, necesitas decidir cómo mantener tus datos coherentes a través de varias colecciones. Por ejemplo, una plataforma de comercio electrónico probablemente requiere datos continuamente actualizados para proporcionar el estado en tiempo real de sus acciones de productos. Por otro lado, las aplicaciones que gestionan datos para decisiones estratégicas a largo plazo, como el análisis en redes sociales, pueden tolerar la lectura de datos ligeramente obsoletos.

Puedes aplicar la coherencia de los datos en tu aplicación utilizando cualquiera de los siguientes métodos:

Para aprender más sobre cada método de aplicación de la integridad de datos, sus casos de uso y los pros y contras de su rendimiento, consulte Coherencia de datos.

Aplicar esquema con reglas de validación

Las necesidades de validación de esquemas dependen de cómo su aplicación organice los datos. La validación de esquemas resulta más útil para una aplicación consolidada con una estructura de datos definida.

Nota

Las reglas de validación de esquema también son flexibles, por lo que no es necesario que cubran todos los campos de un documento, a menos que la aplicación lo requiera.

Puedes utilizar la validación de esquemas en los siguientes casos:

Para una colección events, asegúrese de que el campo start_date almacene solo una fecha, no una cadena de texto. Los tipos consistentes evitan valores inesperados al conectar aplicaciones.
Para una colección store, asegúrese de que el campo accepted_credit_cards contenga solo tipos de tarjeta aceptados, como ["Visa", "MasterCard", "American Express"]. Esta regla evita que los usuarios ingresen valores no admitidos.
Para una colección students, asegúrese de que el campo gpa sea siempre un número de coma flotante positivo. Esta regla evita errores de entrada de datos.

Para obtener más información, consulta Validación de esquemas.

Índice de campos comúnmente consultados

Al diseñar tu modelo de datos, piensa en cómo accedes y almacenas tus datos. Si consultas, filtras, ordenas o unes campos específicos con frecuencia, considera crear índices en esos campos. Con los índices, MongoDB puede:

Devuelve resultados de consultas más rápido
Ordenar los resultados de manera más eficiente
Optimiza las operaciones de $lookup y $group
Reducir el uso de CPU y E/S

A medida que tu aplicación crece, supervisa el uso del índice en tu implementación para asegurarte de que tus índices sigan respaldando queries relevantes.

Cuando crees índices, ten en cuenta los siguientes comportamientos de los índices:

Cada índice requiere al menos 8 kB de espacio de datos.
Agregar un índice tiene un impacto negativo en el rendimiento de las operaciones de guardar. Para las colecciones con una alta relación de escritura-lectura, los índices son costosos ya que cada inserción también debe actualizar cualquier índice.
Las colecciones con una alta proporción de lecturas respecto a escrituras suelen beneficiarse de índices adicionales. Los índices no afectan a las operaciones de lectura no indexadas.
Cuando está activo, cada índice consume espacio en disco y memoria. Este uso puede ser significativo y debe ser rastreado para la planificación de capacidad, especialmente en lo que respecta al tamaño del conjunto de trabajo.

Para obtener más información sobre los índices, consulta las Estrategias de indexación.

Consideraciones adicionales

Al desarrollar un modelo de datos, analice todas las operaciones de lectura y guardar de su aplicación junto con las siguientes consideraciones.

Atomicidad

En MongoDB, una operación de guardar es atómica al nivel de un solo documento. Esto significa que incluso si una actualización afecta a varios subdocumentos, todos esos subdocumentos se actualizan o la operación falla completamente y no se producen actualizaciones.

Un modelo de datos desnormalizado que utiliza documentos incrustados y arreglos combina todos los datos relacionados en un solo documento en lugar de normalizarlos en múltiples documentos y colecciones. Este modelo de datos permite operaciones atómicas, en contraste con un modelo normalizado en el que las operaciones afectan a varios documentos y colecciones. Para obtener un ejemplo de un modelo de datos que proporcione actualizaciones atómicas para un solo documento, consulta Modelo de datos para operaciones atómicas.

Para los modelos de datos que almacenan referencias entre piezas de datos relacionadas, la aplicación debe emitir operaciones de lectura y guardado separadas para recuperar y modificar estas piezas de datos relacionadas.

Para situaciones que requieren atomicidad de las lecturas y escrituras en varios documentos (en una sola colección o en varias), MongoDB admite transacciones distribuidas, incluidas las transacciones en sets de réplica y clústeres fragmentados.

Para obtener más información, consulta transacciones.

Importante

En la mayoría de los casos, una transacción distribuida incurre en un costo de rendimiento mayor que las escrituras de documentos individuales, y la disponibilidad de transacciones distribuidas no debería ser un sustituto para un diseño de esquema efectivo. Para muchos casos, el modelo de datos desnormalizado (documento incrustado y matrices) seguirá siendo óptimo para tus datos y casos de uso. Es decir, en muchos casos, modelar tus datos de forma adecuada minimizará la necesidad de transacciones distribuidas.

Para consideraciones adicionales sobre el uso de transacciones (como el límite de tiempo de ejecución y el límite de tamaño del oplog), consulta también las consideraciones de producción.

Gestión del ciclo de vida de los datos

La gestión del ciclo de vida de los datos se refiere al proceso de gestión de los datos desde su creación y almacenamiento hasta su archivado y eliminación. Para garantizar la eficiencia, el rendimiento y la seguridad del esquema, considera la gestión del ciclo de vida de los datos al tomar decisiones de modelado de datos.

Si tu aplicación requiere que algunos datos permanezcan en la base de datos durante un período de tiempo limitado, considera utilizar la funcionalidad de Time to Live o TTL. Por ejemplo, las colecciones TTL podrían ser útiles para gestionar las sesiones de login de usuarios en una aplicación web, donde las sesiones están configuradas para expirar automáticamente después de 30 minutos de inactividad. Esto significa que MongoDB borra automáticamente los documentos de sesión después del periodo de tiempo especificado.

Además, si tu aplicación sólo utiliza documentos insertados recientemente, considera colección con tamaño fijo. Las colecciones acotadas proporcionan una gestión primero en entrar, primero en salir (FIFO) de los documentos insertados y admiten eficazmente las operaciones que insertan y leen documentos según el orden de inserción.

Restricciones de hardware

Cuando diseñes tu esquema, considera el hardware de tu implementación, especialmente la cantidad de RAM disponible. Los documentos más grandes utilizan más RAM, lo que puede provocar que tu aplicación lea del disco y degrade el rendimiento. Cuando sea posible, diseña tu esquema para que solo se devuelvan los campos relevantes en las consultas, asegurando que el conjunto de trabajo de tu aplicación no crezca innecesariamente.

Documentos pequeños

Cada documento de MongoDB contiene una cierta cantidad de gastos en general. Estos gastos en general suelen ser insignificantes, pero se vuelven significativos si todos los documentos tienen solo unos pocos bytes, como podría ser el caso si los documentos de tu colección solo tienen uno o dos campos.

Considera las siguientes sugerencias y estrategias para optimizar el uso del almacenamiento para estas colecciones:

Use explícitamente el campo _id.
Los clientes de MongoDB agregan automáticamente un campo _id a cada documento y generan un ObjectId único de 12bytes para el campo _id. Además, MongoDB siempre indexa el campo _id. Para documentos más pequeños, esto puede utilizar una cantidad significativa de espacio.
Para optimizar el uso del almacenamiento, se puede especificar explícitamente un valor para el campo _id al insertar documentos en la colección. Esto permite a las aplicaciones almacenar un valor en el campo _id que habría ocupado espacio en otra parte del documento. Este valor debe ser único, ya que el campo _id identifica de manera exclusiva los documentos en una colección.
Utiliza nombres de campos más cortos.
Nota
Si bien acortar los nombres de los campos puede reducir el tamaño de BSON en MongoDB, a menudo es más efectivo modificar el modelo orientado a documentos general para reducir el tamaño de BSON. Acortar los nombres de campo podría reducir la expresividad y no afecta el tamaño de los índices, ya que los índices tienen una estructura predefinida que no incorpora los nombres de campo.
MongoDB almacena todos los nombres de campos en cada documento. Para la mayoría de los documentos, esto representa una pequeña fracción del espacio utilizado por un documento; sin embargo, para documentos pequeños los nombres de campo pueden representar una proporción considerablemente grande de espacio. Considere una colección de documentos pequeños que se asemejan a lo siguiente:
```
{ last_name : "Smith", best_score: 3.9 }
```
Si acortas el campo llamado last_name a lname y el campo llamado best_score a score, como se indica a continuación, podrías ahorrar 9 bytes por documento.
```
{ lname : "Smith", score : 3.9 }
```
documento incrustado.
En algunos casos, es posible que desees usar documentos incrustados para ahorrar en los gastos en general por documento. Consulta Colecciones con una gran cantidad de documentos pequeños.

Obtén más información

Para aprender más sobre cómo estructurar tus documentos y definir tu esquema, consulta el curso Data Modeling de MongoDB University.

Volver

Modelado de datos

Datos incrustados