El principal desafío en el modelado de datos es equilibrar las necesidades de la aplicación, las características de rendimiento del motor de base de datos y los patrones de recuperación de datos. Al diseñar modelos de datos, siempre considera el uso que la aplicación hará de los datos (es decir, consultas, actualizaciones y procesamiento de los datos), así como la estructura inherente de los propios datos.
Esquema flexible
A diferencia de las bases de datos SQL, donde debe determinar y declarar el esquema de una tabla antes de insertar datos, MongoDB Las colecciones, por defecto, no requieren que sus documentos tengan el mismo esquema. Es decir:
Los documentos de una sola colección no necesitan tener el mismo conjunto de campos y el tipo de datos de un campo puede diferir entre documentos dentro de una colección.
Para modificar la estructura de los documentos en una colección, como agregar nuevos campos, remover campos existentes o cambiar los valores de los campos a un nuevo tipo, actualiza los documentos a la nueva estructura.
Esta flexibilidad facilita la asignación de documentos a una entidad u objeto. Cada documento puede coincidir con los campos de datos de la entidad representada, incluso si hay una variación sustancial entre ese documento y otros en la colección.
En la práctica, sin embargo, los documentos de una colección comparten una estructura similar, y puedes aplicar reglas de validación de documentos a una colección durante las operaciones de actualización e inserción. Consulta Validación de Esquemas para más detalles.
Estructura del documento
La decisión clave al diseñar modelos de datos para aplicaciones MongoDB gira en torno a la estructura de los documentos y a cómo la aplicación representa las relaciones entre los datos. MongoDB permite insertar datos relacionados dentro de un solo documento.
Datos incrustados
Los documentos incrustados capturan las relaciones entre datos al almacenar datos relacionados en una sola estructura de documento. Los documentos de MongoDB hacen posible incluir estructuras de documentos incrustados en un campo o arreglo dentro de un documento. Estos modelos de datos desnormalizados permiten a las aplicaciones recuperar y manipular datos relacionados en una sola operación de base de datos.
Para muchos casos de uso en MongoDB, el modelo de datos desnormalizado es óptimo.
Consulta Modelos de datos incrustados para conocer los puntos fuertes y débiles de incrustar documentos.
Referencias
Las referencias almacenan las relaciones entre datos al incluir enlaces o referencias de un documento a otro. Las aplicaciones pueden resolver estas referencias para acceder a los datos relacionados. En general, estos son modelos de datos normalizados.
Vea Modelos de datos normalizados para conocer las ventajas y desventajas de usar referencias.
Atomicidad de las operaciones de escritura
Atomicidad de documento único
En MongoDB, una operación de escritura es atómica a nivel de un solo documento, incluso si la operación modifica varios documentos incrustados dentro de un solo documento.
Un modelo de datos desnormalizado con datos incrustados combina todos los datos relacionados en un solo documento, en lugar de normalizar entre varios documentos y colecciones. Este modelo de datos facilita las operaciones atómicas.
Para detalles sobre las operaciones en MongoDB, consulta la página de Operaciones.
Transacciones multi-documento
Cuando se realiza una sola operación de escritura (por ejemplo,
db.collection.updateMany()) modifica varios documentos, la modificación de cada documento es atómica, pero la operación en su conjunto no lo es.
Al realizar Operaciones de guardado multidocumento, ya sea a través de una sola Operación de guardado o de múltiples Operaciones de guardado, otras Operaciones pueden intercalarse.
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.
Uso y rendimiento de los datos
Al diseñar un modelo de datos, considere cómo las aplicaciones usarán su base de datos. Por ejemplo, si su aplicación solo usa documentos insertados recientemente, considere usar colecciones limitadas. Si su aplicación requiere principalmente operaciones de lectura en una colección, agregar índices para admitir consultas comunes puede mejorar el rendimiento.
Consulta Factores operativos y modelos de datos para obtener más información sobre estos y otros aspectos operativos que afectan los diseños de modelos de datos.
Obtén más información
MongoDB University
Para aprender a estructurar documentos y definir tu esquema, consulta el curso de Modelado de Datos de MongoDB University.