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 los 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 presenta variaciones sustanciales con respecto a otros documentos de la colección.
En la práctica, sin embargo, los documentos de una colección comparten una estructura similar, y se pueden aplicar reglas de validación de documentos para una colección durante las operaciones de actualización e inserción.Consulte Validación de esquemas para obtener más información.
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 integrar datos relacionados en un solo documento.
Datos incrustados
Los documentos incrustados capturan relaciones entre datos al almacenar datos relacionados en una única estructura. Los documentos MongoDB permiten incrustar estructuras en un campo o matriz 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.
Consulte Modelos de datos integrados para conocer las fortalezas y debilidades de la integración de documentos.
Referencias
Las referencias almacenan las relaciones entre los datos mediante enlaces o referencias de un documento a otro. Las aplicaciones pueden resolver estas referencias para acceder a los datos relacionados. En general, se trata de modelos de datos normalizados.
Consulte Modelos de datos normalizados para conocer las fortalezas y debilidades del uso de 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 múltiples documentos incrustados dentro de un solo documento.
Un modelo de datos desnormalizado con datos integrados combina todos los datos relacionados en un solo documento, en lugar de normalizarlos en múltiples documentos y colecciones. Este modelo de datos facilita las operaciones atómicas.
Para obtener detalles sobre las transacciones en MongoDB, consulte la página Transacciones.
Transacciones multi-documento
Cuando se realiza una sola operación de escritura (por ejemplo,
db.collection.updateMany()) modifica múltiples documentos, la modificación de cada documento es atómica, pero la operación en su conjunto no es atómica.
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 su esquema, consulte el curso de Modelado de datos de MongoDB University.