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 adaptabilidad, garantizando al mismo tiempo la consistencia e integridad de los datos. Además de las directrices generales sobre Al planificar su esquema, tenga en cuenta las siguientes prácticas recomendadas para optimizar su modelo de datos y determinar qué patrón de diseño de esquema puede ser el más adecuado para el caso de uso de su aplicación.

Planifique su esquema con anticipación e itérelo

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 permite diseñar el esquema de forma iterativa. Sin embargo, modificar esquemas a gran escala utilizados en producción puede resultar difícil. Dependiendo de la aplicación, es posible que desee establecer un esquema simple que cubra la funcionalidad básica antes de optimizarlo.

Modificar su 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 lugar de ello, considere crear una cuenta separada 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 ver ejemplos de cuándo utilizar incrustación o referencia, consulte la siguiente tabla:

Scenario	Método de vinculación
Mantener juntos los datos relacionados conducirá a un modelo de datos y un código más simples.	Incrustar
Tiene una relación "tiene un" o "contiene" entre entidades.	Incrustar
Su aplicación consulta fragmentos de información juntos.	Incrustar
Tiene datos que a menudo se actualizan juntos.	Incrustar
Tienes datos que deberían archivarse al mismo tiempo.	Incrustar
El lado secundario de la relación tiene alta cardinalidad.	Referencias
La duplicación de datos es demasiado complicada de gestionar y no es la opción preferida.	Referencias
El tamaño combinado de sus datos ocupa demasiada memoria o ancho de banda de transferencia para su aplicación.	Referencias
Sus datos incrustados crecen sin límites.	Referencias
Sus datos se escriben en diferentes momentos en una carga de trabajo de escritura intensiva.	Referencias
Para el lado secundario de la relación, sus datos pueden existir por sí solos sin un padre.	Referencias

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

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.
Frecuencia con la que se deben actualizar los datos duplicados. La lógica adicional necesaria para gestionar actualizaciones poco frecuentes es menos costosa que realizar uniones (búsquedas) en operaciones de lectura. Sin embargo, actualizar frecuentemente los datos duplicados puede generar cargas de trabajo elevadas 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 buenos candidatos 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 stock de un producto determinado, que debe actualizarse cada vez que un cliente realiza un pedido del producto.
No es sensible a la ranciedad	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 volver a calcularse cada vez que se agrega un nuevo producto al sistema.

Si no necesita actualizar los datos duplicados con frecuencia, se requerirá un trabajo adicional mínimo para mantener la coherencia entre ambas colecciones. Sin embargo, si los datos duplicados se actualizan con frecuencia, usar una referencia para vincular datos relacionados puede ser una mejor opción.

Para obtener ejemplos de cómo la duplicación de datos relacionados puede ayudar a optimizar su modelo de datos, consulte Manejar datos duplicados.

Hacer cumplir la coherencia de los datos

Si duplica datos en su esquema, debe decidir cómo mantener la coherencia de los datos en varias colecciones. Por ejemplo, una plataforma de comercio electrónico probablemente requiera datos continuamente actualizados para proporcionar el estado en tiempo real de su inventario de productos. Por otro lado, las aplicaciones que gestionan datos para decisiones estratégicas a largo plazo, como el análisis de redes sociales, pueden tolerar la lectura de datos ligeramente obsoletos.

Puede aplicar la coherencia de datos en su aplicación con cualquiera de los siguientes métodos:

Para obtener más información sobre cada método de cumplimiento de la consistencia de datos, sus casos de uso y sus compensaciones en el rendimiento, consulte Consistencia de datos.

Aplicar el 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 events, asegúrese de que el campo start_date solo se almacene como una fecha y no como una cadena, de modo que las aplicaciones de conexión no utilicen tipos inesperados.
Para una colección store, asegúrese de que el campo accepted_credit_cards pertenezca a una lista de tarjetas de crédito que su tienda acepte, como ["Visa", "MasterCard", "American Express"]. Esta validación evita que el usuario introduzca un valor de tarjeta de crédito no admitido.
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, consulte Validación de esquema.

Índice de campos comúnmente consultados

Al diseñar su modelo de datos, piense en cómo accede y almacena sus datos. Si consulta, filtra, ordena o une campos específicos con frecuencia, considere crear índices en esos campos. Con los índices, MongoDB puede:

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

A medida que su aplicación crece, supervise el uso del índice de su implementación para asegurarse de que sus índices aún admitan consultas relevantes.

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

Cada índice requiere al menos 8 kB de espacio de datos.
Añadir un índice tiene un impacto negativo en el rendimiento de las operaciones de escritura. En colecciones con una alta tasa de escritura a lectura, los índices son costosos, ya que cada inserción también debe actualizar los índices.
Las colecciones con una alta tasa de lectura-escritura suelen beneficiarse de índices adicionales. Los índices no afectan las operaciones de lectura no indexadas.
Cuando está activo, cada índice consume espacio en disco y memoria. Este uso puede ser significativo y debe monitorizarse para la planificación de la capacidad, especialmente por cuestiones relacionadas con el tamaño del conjunto de trabajo.

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

Consideraciones adicionales

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

Atomicidad

En MongoDB, una operación de escritura es atómica a nivel de un solo documento. Esto significa que, incluso si una operación de actualización afecta a varios subdocumentos, estos se actualizan todos o la operación falla por completo y no se produce ninguna actualización.

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 escritura 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 datos desde su creación y almacenamiento hasta su archivado y eliminación. Para garantizar la rentabilidad, el rendimiento y la seguridad del esquema, considere 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 su aplicación solo utiliza documentos insertados recientemente, considere las Colecciones Limitadas. Estas colecciones permiten la gestión FIFO (primero en entrar, primero en salir) de los documentos insertados y facilitan la inserción y lectura de documentos según el orden de inserción.

Restricciones de hardware

Al diseñar su esquema, tenga en cuenta el hardware de su implementación, especialmente la cantidad de RAM disponible. Los documentos más grandes consumen más RAM, lo que puede provocar que su aplicación lea desde el disco y reduzca el rendimiento. Siempre que sea posible, diseñe su esquema de modo que las consultas solo devuelvan los campos relevantes, garantizando así que el conjunto de trabajo de su aplicación no crezca innecesariamente.

Documentos pequeños

Cada documento de MongoDB conlleva una cierta cantidad de sobrecarga. Esta sobrecarga suele ser insignificante, pero se vuelve significativa si todos los documentos ocupan solo unos pocos bytes, como podría ocurrir si los documentos de su colección solo tienen uno o dos campos.

Tenga en cuenta las siguientes sugerencias y estrategias para optimizar la utilización del almacenamiento para estas colecciones:

Utilice el campo _id explícitamente.
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 campo en cada documento. Para la mayoría de los documentos, esto representa una pequeña fracción del espacio utilizado; sin embargo, para documentos pequeños, los nombres de campo pueden representar una cantidad de espacio proporcionalmente grande. Considere una colección de documentos pequeños similar a la siguiente:
```
{ last_name : "Smith", best_score: 3.9 }
```
Si acorta el campo llamado last_name a lname y el campo llamado best_score a score, de la siguiente manera, podría ahorrar 9 bytes por documento.
```
{ lname : "Smith", score : 3.9 }
```
Incrustar documentos.
En algunos casos, puede que desee incrustar documentos en otros documentos y ahorrarse el trabajo por documento.Consulte 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