javascript - tutorial - Subdocumentos mangosta vs esquema anidado

mongoose update

Question

Tengo curiosidad sobre los pros y los contras de usar subdocumentos frente a una capa más profunda en mi esquema principal:

var subDoc = new Schema({
name: String
});
var mainDoc = new Schema({
names: [subDoc]
});

o

var mainDoc = new Schema({
names: [{
name: String
}]
});

Actualmente estoy usando subdocs en todas partes, pero me pregunto principalmente sobre el rendimiento o los problemas de consulta que pueda encontrar.

Answer 1

Básicamente, crea una variable nestedDov y ponla aquí name: [nestedDov]

Versión simple:

var nestedDoc = new Schema({
name: String
});
var mainDoc = new Schema({
names: [nestedDoc]
});

Ejemplo de JSON

{
"_id" : ObjectId("57c88bf5818e70007dc72e85"),
"name" : "Corinthia Hotel Budapest",
"stars" : 5,
"description" : "The 5-star Corinthia Hotel Budapest on the Grand Boulevard offers free access to its Royal Spa",
"photos" : [
"/photos/hotel/corinthiahotelbudapest/1.jpg",
"/photos/hotel/corinthiahotelbudapest/2.jpg"
],
"currency" : "HUF",
"rooms" : [
{
"type" : "Superior Double or Twin Room",
"number" : 20,
"description" : "These are some great rooms",
"photos" : [
"/photos/room/corinthiahotelbudapest/2.jpg",
"/photos/room/corinthiahotelbudapest/5.jpg"
],
"price" : 73000
},
{
"type" : "Deluxe Double Room",
"number" : 50,
"description" : "These are amazing rooms",
"photos" : [
"/photos/room/corinthiahotelbudapest/4.jpg",
"/photos/room/corinthiahotelbudapest/6.jpg"
],
"price" : 92000
},
{
"type" : "Executive Double Room",
"number" : 25,
"description" : "These are amazing rooms",
"photos" : [
"/photos/room/corinthiahotelbudapest/4.jpg",
"/photos/room/corinthiahotelbudapest/6.jpg"
],
"price" : 112000
}
],
"reviews" : [
{
"name" : "Tamas",
"id" : "/user/tamas.json",
"review" : "Great hotel",
"rating" : 4
}
],
"services" : [
"Room service",
"Airport shuttle (surcharge)",
"24-hour front desk",
"Currency exchange",
"Tour desk"
]
}

Ejemplo:

Answer 2

Creo que esto se maneja en otra parte por varias publicaciones en SO.

Sólo algunos:

• Relaciones MongoDB: ¿incrustado o referencia?
• ¿Cómo debería implementar este esquema en MongoDB?
• Diseño de esquema MongoDB: ¿muchos documentos pequeños o menos documentos grandes?

La gran clave es que no hay una respuesta única aquí, solo un conjunto de compensaciones bastante complejas.

Answer 3

Debe usar documentos incrustados si son documentos estáticos o que no son más de unos cientos debido al impacto en el rendimiento. He hablado sobre ese tema hace un tiempo. Recientemente, Asya Kamsky, que trabaja como arquitecto de soluciones para MongoDB, había escrito un artículo sobre "el uso de subdocumentos".

Espero que ayude a quién está buscando soluciones o la mejor práctica.

Publicación original en http://askasya.com/post/largeembeddedarrays . Puede alcanzar su perfil en https://.com/users/431012/asya-kamsky

Antes que nada, tenemos que considerar por qué querríamos hacer tal cosa. Normalmente, aconsejaría a las personas que incorporen cosas que siempre desean recuperar cuando busquen este documento. La otra cara de esto es que no desea incrustar elementos en el documento que no desea recuperar.

Si inserta la actividad que desempeño en el documento, funcionará muy bien al principio porque toda mi actividad está ahí y con una sola lectura puede recuperar todo lo que quiera mostrarme: "hace poco hizo clic aquí y aquí son tus dos últimos comentarios "pero ¿qué pasa después de seis meses y no me importan las cosas que hice hace mucho tiempo y no quieres enseñármelas a menos que vaya específicamente a buscar alguna actividad anterior?

En primer lugar, terminará devolviendo documentos más grandes y más grandes y se preocupará por porciones cada vez más pequeñas. Pero puede usar la proyección para devolver solo una parte de la matriz, el verdadero problema es que el documento en el disco se hará más grande y aún se leerá aunque solo devuelva parte del mismo al usuario final, pero ya que mi actividad no se detendrá mientras esté activa, el documento seguirá creciendo y creciendo.

El problema más obvio con esto es que finalmente alcanzará el límite de documentos de 16MB, pero eso no es para nada de lo que debería preocuparse. Un documento que crece continuamente tendrá cada vez más costos cada vez que tenga que ser reubicado en el disco, e incluso si toma medidas para mitigar los efectos de la fragmentación, sus escrituras serán innecesariamente largas, lo que afectará el rendimiento general de toda su aplicación.

Hay una cosa más que puedes hacer que matará por completo el rendimiento de tu aplicación y es indexar esta matriz cada vez mayor. Lo que eso significa es que cada vez que se reubica el documento con esta matriz, el número de entradas de índice que se deben actualizar es directamente proporcional al número de valores indexados en ese documento, y cuanto más grande sea la matriz, mayor será el número ser.

No quiero que esto lo asuste de usar matrices cuando encajan bien en el modelo de datos: son una poderosa característica del modelo de datos de la base de datos de documentos, pero, como todas las herramientas poderosas, debe utilizarse en las circunstancias adecuadas. y debe usarse con cuidado.

Answer 4

Según los documentos , es exactamente lo mismo. Sin embargo, el uso de un Esquema también agregaría un campo _id (siempre que no lo tenga desactivado) y, presumiblemente, utiliza algunos recursos adicionales para el seguimiento de subdocs.

Sintaxis de declaración alternativa

Nuevo en v3 Si no necesita acceder a la instancia de esquema de subdocumento, también puede declarar subdocumentos simplemente pasando un objeto literal [...]

Answer 5

Si tiene esquemas que se reutilizan en varias partes de su modelo, puede ser útil definir esquemas individuales para los documentos secundarios para que no tenga que duplicarse.