Comprensión del límite de tamaño de documento BSON de MongoDB

De MongoDB La guía definitiva:

Los documentos de más de 4 MB (cuando se convierten a BSON) no se pueden guardar en la base de datos. Este es un límite algo arbitrario (y puede aumentarse en el futuro); es principalmente para evitar un mal diseño de esquema y garantizar un rendimiento constante.

No entiendo este límite, ¿significa esto que un documento que contiene una publicación de blog con muchos comentarios y que es mayor que 4 MB no se puede almacenar como un solo documento?

¿Esto también cuenta los documentos anidados?

¿Qué pasaría si quisiera un documento que audite los cambios a un valor? (Eventualmente puede crecer, excediendo el límite de 4MB).

Espero que alguien explique esto correctamente.

Acabo de empezar a leer sobre MongoDB (primera base de datos nosql sobre la que estoy aprendiendo).

Gracias.

En primer lugar, esto se plantea en la próxima versión para 8MBo 16MB... pero creo que para poner esto en perspectiva, Eliot de 10gen (que desarrolló MongoDB) lo expresa mejor:

EDITAR: El tamaño ha sido oficialmente 'elevado' a16MB

Entonces, en el ejemplo de su blog, 4 MB es en realidad mucho. Por ejemplo, el texto completo sin comprimir de "La guerra de los mundos" es solo 364k (html): http://www.gutenberg.org/etext/36

Si tu publicación de blog es tan larga con tantos comentarios, por mi parte no la voy a leer :)

Para los trackbacks, si les dedicó 1 MB, fácilmente podría tener más de 10k (probablemente más cerca de 20k)

Entonces, excepto en situaciones realmente extrañas, funcionará muy bien. Y en el caso de excepción o spam, realmente no creo que quieras un objeto de 20mb de todos modos. Creo que limitar los trackbacks como 15k más o menos tiene mucho sentido, sin importar el rendimiento. O al menos una carcasa especial si alguna vez sucede.

-Eliot

Creo que sería muy difícil llegar al límite ... y con el tiempo, si actualizas ... tendrás que preocuparte cada vez menos.

El punto principal del límite es que no use toda la RAM en su servidor (ya que necesita cargar todos MBlos documentos en la RAM cuando lo consulta).

Entonces, el límite es un% de la RAM utilizable normal en un sistema común ... que seguirá creciendo año tras año.

Nota sobre el almacenamiento de archivos en MongoDB

Si necesita almacenar documentos (o archivos) más grandes de lo 16MBque puede, use la API de GridFS que dividirá automáticamente los datos en segmentos y los transmitirá de nuevo a usted (evitando así el problema con los límites de tamaño / RAM).

En lugar de almacenar un archivo en un solo documento, GridFS divide el archivo en partes o fragmentos, y almacena cada fragmento como un documento separado.

GridFS usa dos colecciones para almacenar archivos. Una colección almacena los fragmentos de archivo y la otra almacena los metadatos del archivo.

Puede usar este método para almacenar imágenes, archivos, videos, etc. en la base de datos de la misma manera que lo haría en una base de datos SQL. Lo he usado incluso para almacenar archivos de video de varios gigabytes.

Muchos en la comunidad preferirían no tener límite con las advertencias sobre el rendimiento, vea este comentario para ver un argumento bien razonado: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin. system.issuetabpanels: comment-tabpanel # comment-22283

Mi opinión, los desarrolladores principales son tercos sobre este problema porque decidieron que era una "característica" importante desde el principio. No lo van a cambiar en el corto plazo porque sus sentimientos están heridos porque alguien lo cuestionó. Otro ejemplo de personalidad y política que perjudica a un producto en las comunidades de código abierto, pero este no es realmente un problema paralizante.

Para publicar una aclaración, responda aquí para aquellos a quienes Google dirige aquí.

El tamaño del documento incluye todo en el documento, incluidos los subdocumentos, los objetos anidados, etc.

Entonces un documento de:

{
    _id:{},
    na: [1,2,3],
    naa: [
        {w:1,v:2,b:[1,2,3]},
        {w:5,b:2,h:[{d:5,g:7},{}]}
    ]
}

Tiene un tamaño máximo de 16meg.

Sbudocuments y objetos anidados se cuentan para el tamaño del documento.

Todavía no he visto un problema con el límite que no involucre archivos grandes almacenados dentro del documento mismo. Ya hay una variedad de bases de datos que son muy eficientes para almacenar / recuperar archivos grandes; Se llaman sistemas operativos. La base de datos existe como una capa sobre el sistema operativo. Si está utilizando una solución NoSQL por razones de rendimiento, ¿por qué desearía agregar una sobrecarga de procesamiento adicional al acceso de sus datos colocando la capa de base de datos entre su aplicación y sus datos?

JSON es un formato de texto. Entonces, si está accediendo a sus datos a través de JSON, esto es especialmente cierto si tiene archivos binarios porque tienen que estar codificados en uuencode, hexadecimal o Base 64. La ruta de conversión podría verse así

archivo binario <> JSON (codificado) <> BSON (codificado)

Sería más eficiente poner la ruta (URL) al archivo de datos en su documento y mantener los datos en binario.

Si realmente desea mantener estos archivos de longitud desconocida en su base de datos, probablemente sea mejor ponerlos en GridFS y no arriesgarse a matar su concurrencia cuando se accede a los archivos grandes.

Profundidad anidada para documentos BSON: MongoDB admite no más de 100 niveles de anidamiento para documentos BSON.

Más más información vist

Quizás almacenar una publicación de blog -> relación de comentarios en una base de datos no relacional no es realmente el mejor diseño.

De todos modos, probablemente debería almacenar los comentarios en una colección separada para las publicaciones de blog.

[editar]

Vea los comentarios a continuación para mayor discusión.

De acuerdo con https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1

Si espera que una publicación de blog supere el límite de documentos de 16Mb, debe extraer los comentarios en una colección separada y hacer referencia a la publicación de blog desde el comentario y hacer una unión a nivel de aplicación.

// posts
[
  {
    _id: ObjectID('AAAA'),
    text: 'a post',
    ...
  }
]

// comments
[
  {
    text: 'a comment'
    post: ObjectID('AAAA')
  },
  {
    text: 'another comment'
    post: ObjectID('AAAA')
  }
]