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

Planifique y diseñe su esquema al inicio 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:

Tienes la tarea de crear el backend de una plataforma de aprendizaje en línea para usuarios que almacena información sobre los cursos y sus lecciones. Inicialmente, la plataforma solo necesita almacenar la siguiente información básica para 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, como videos, cuestionarios, tareas y enlaces a recursos externos. Integrar todos estos nuevos datos en cada documento del curso haría el modelo de datos demasiado complejo.

En su lugar, considere crear un/a independiente lessons Colección. De esta manera, puede vincular las course lessons colecciones y mediante identificadores de referencia. Al usar 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.
Datos de referencia relacionados almacenados en una colección separada.

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.	integración
Tienes una relación "tiene-a" o "contiene" entre las entidades.	integración
Su aplicación query piezas de información en conjunto.	integración
Tiene datos que a menudo se actualizan juntos.	integración
Tienes datos que deberían ser archivados al mismo tiempo.	integració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 sus datos ocupa demasiada memoria o ancho de banda de transferencia para su aplicación.	Referenciando
Tus datos integrados crecen sin límites.	Referenciando
Sus datos se escriben en diferentes momentos en una carga de trabajo de escritura intensiva.	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 su 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ó una cuenta de usuario.
Temporal	Datos que pueden cambiar con el tiempo, pero donde es importante preservar el valor histórico de los datos.	La dirección del cliente al realizar un pedido. Si el cliente se muda a una nueva dirección, esto no afecta las direcciones registradas donde se enviaron pedidos anteriores.
Sensible a la ranciedad	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 toleran la obsolescencia durante un período más largo. Las aplicaciones pueden usar un trabajo en segundo plano para actualizar periódicamente todas las ocurrencias de los datos según 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

Sus necesidades de validación de esquemas dependen de cómo los usuarios usan su aplicación. La validación de esquemas es más útil para una aplicación consolidada donde tienes una buena idea de cómo organizar tus datos.

Nota

Las reglas de validación de esquema también son flexibles, por lo que no necesitan cubrir todos los campos de un documento, a menos que su aplicación lo requiera.

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

Para una colección de events, asegúrese de que el campo start_date se almacene sólo como una fecha y no como una string, para que las aplicaciones conectadas no utilicen tipos inesperados.
Para una colección store, asegúrate de que el campo accepted_credit_cards pertenezca a una lista de tarjetas de crédito que tu tienda acepte, como ["Visa", "MasterCard", "American Express"]. Esta validación impide que un usuario ingrese un valor de tarjeta de crédito no aceptado.
Para una colección de estudiantes, asegúrese de que el campo gpa sea siempre un número de punto flotante positivo. Esta validación evita errores durante la 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.

Al crear índices, tenga en cuenta los siguientes comportamientos de índice:

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 y matrices incrustados combina todos los datos relacionados en un solo documento en lugar de normalizarlos en varios documentos y colecciones. Este modelo de datos permite operaciones atómicas, a diferencia de un modelo normalizado, donde las operaciones afectan a varios documentos y colecciones. Para ver un ejemplo de modelo de datos que proporciona actualizaciones atómicas para un solo documento, consulte Datos de modelo 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, consulte 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.
Utilice nombres de campo más cortos.
Nota
Si bien acortar los nombres de campo puede reducir el tamaño de BSON en MongoDB, suele ser más efectivo modificar el modelo general del documento para reducirlo. Acortar los nombres de campo puede reducir la expresividad y no afecta el tamaño de los índices, ya que estos tienen una estructura predefinida que no incorpora 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 obtener más información sobre cómo estructurar sus documentos y definir su esquema, consulte el curso de Modelado de datos de MongoDB University.

Volver

Modelado de datos

Datos incrustados