Esta página describe un modelo de datos que utiliza documentos incrustados para describir una relación uno a uno entre los datos conectados. Incrustar datos conectados en un solo documento puede reducir el número de operaciones de lectura necesarias para obtener datos. En general, debe estructurar su esquema para que su aplicación reciba toda la información requerida en una sola operación de lectura.
Considere el siguiente ejemplo que mapea las relaciones entre usuarios y direcciones. El ejemplo ilustra la ventaja de incrustar sobre las referencias si necesita ver una entidad de datos en el contexto de la otra. En esta relación uno a uno entre patrony addressdatos, el addresspertenece a patron.
En el modelo de datos normalizados, el addressdocumento contiene una referencia al patrondocumento.
// patron document
{
_id: "joe",
name: "Joe Bookreader"
}
// address document
{
patron_id: "joe", // reference to patron document
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
}
Si los addressdatos se recuperan con frecuencia con la name información, entonces con la referencia, su aplicación necesita emitir múltiples consultas para resolver la referencia. El mejor modelo de datos sería incrustar los addressdatos en los patrondatos, como en el siguiente documento:
{
_id: "joe",
name: "Joe Bookreader",
address: {
street: "123 Fake Street",
city: "Faketon",
state: "MA",
zip: "12345"
}
}
Con el modelo de datos integrado, su aplicación puede recuperar la información completa del usuario con una sola consulta.
Un problema potencial con el patrón de documento incrustado es que puede generar documentos grandes que contienen campos que la aplicación no necesita. Estos datos innecesarios pueden causar una carga adicional en su servidor y ralentizar las operaciones de lectura. En su lugar, puede utilizar el patrón de subconjunto para recuperar el subconjunto de datos al que se accede con más frecuencia en una única llamada a la base de datos.
Considere una aplicación que muestra información sobre películas. La base de datos contiene una moviecolección con el siguiente esquema:
{
"_id": 1,
"title": "The Arrival of a Train",
"year": 1896,
"runtime": 1,
"released": ISODate("01-25-1896"),
"poster": "http://ia.media-imdb.com/images/M/MV5BMjEyNDk5MDYzOV5BMl5BanBnXkFtZTgwNjIxMTEwMzE@._V1_SX300.jpg",
"plot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, ...",
"fullplot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, the line dissolves. The doors of the railway-cars open, and people on the platform help passengers to get off.",
"lastupdated": ISODate("2015-08-15T10:06:53"),
"type": "movie",
"directors": [ "Auguste Lumière", "Louis Lumière" ],
"imdb": {
"rating": 7.3,
"votes": 5043,
"id": 12
},
"countries": [ "France" ],
"genres": [ "Documentary", "Short" ],
"tomatoes": {
"viewer": {
"rating": 3.7,
"numReviews": 59
},
"lastUpdated": ISODate("2020-01-09T00:02:53")
}
}
Actualmente, la moviecolección contiene varios campos que la aplicación no necesita para mostrar una descripción general simple de una película, como fullplotinformación de clasificación. En lugar de almacenar todos los datos de la película en una sola colección, puede dividir la colección en dos colecciones:
- La
moviecolección contiene información básica sobre una película. Estos son los datos que carga la aplicación por defecto:
// movie collection
{
"_id": 1,
"title": "The Arrival of a Train",
"year": 1896,
"runtime": 1,
"released": ISODate("1896-01-25"),
"type": "movie",
"directors": [ "Auguste Lumière", "Louis Lumière" ],
"countries": [ "France" ],
"genres": [ "Documentary", "Short" ],
}
La movie_detailscolección contiene datos adicionales a los que se accede con menos frecuencia para cada película:
// movie_details collection
{
"_id": 156,
"movie_id": 1, // reference to the movie collection
"poster": "http://ia.media-imdb.com/images/M/MV5BMjEyNDk5MDYzOV5BMl5BanBnXkFtZTgwNjIxMTEwMzE@._V1_SX300.jpg",
"plot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, ...",
"fullplot": "A group of people are standing in a straight line along the platform of a railway station, waiting for a train, which is seen coming at some distance. When the train stops at the platform, the line dissolves. The doors of the railway-cars open, and people on the platform help passengers to get off.",
"lastupdated": ISODate("2015-08-15T10:06:53"),
"imdb": {
"rating": 7.3,
"votes": 5043,
"id": 12
},
"tomatoes": {
"viewer": {
"rating": 3.7,
"numReviews": 59
},
"lastUpdated": ISODate("2020-01-29T00:02:53")
}
}
Este método mejora el rendimiento de lectura porque requiere que la aplicación lea menos datos para cumplir con su solicitud más común. La aplicación puede realizar una llamada adicional a la base de datos para recuperar los datos a los que se accede con menos frecuencia si es necesario.
CONSEJO
Al considerar dónde dividir sus datos, la parte de los datos a la que se accede con mayor frecuencia debe ir a la colección que la aplicación carga primero.
CONSEJO
Para aprender a usar el patrón de subconjunto para modelar relaciones de uno a varios entre colecciones, consulte Modelar relaciones de uno a varios con documentos incrustados .
El uso de documentos más pequeños que contienen datos a los que se accede con más frecuencia reduce el tamaño general del conjunto de trabajo. Estos documentos más pequeños dan como resultado un rendimiento de lectura mejorado y hacen que haya más memoria disponible para la aplicación.
Sin embargo, es importante comprender su aplicación y la forma en que carga los datos. Si divide sus datos en varias colecciones de manera incorrecta, su aplicación a menudo necesitará realizar varios viajes a la base de datos y depender de las JOINoperaciones para recuperar todos los datos que necesita.
Además, dividir sus datos en muchas colecciones pequeñas puede aumentar el mantenimiento requerido de la base de datos, ya que puede resultar difícil rastrear qué datos se almacenan en qué colección.