update - Comprender el MongoDB BSON Límite de tamaño del documento
mongodb max db size (6)
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 plantearse en el futuro); es sobre todo para evitar el mal diseño del esquema y garantizar un rendimiento constante.
No entiendo este límite, ¿significa esto que un documento que contenga una publicación de blog con muchos comentarios que suceden por encima de 4 MB no puede almacenarse como un documento único?
¿También cuenta esto los documentos anidados?
¿Qué sucede si quiero un documento que audita los cambios en un valor? (Eventualmente puede crecer, excediendo el límite de 4MB).
Espero que alguien lo explique correctamente.
Acabo de empezar a leer sobre MongoDB (la primera base de datos nosql de la que estoy aprendiendo).
Gracias.
En primer lugar, esto se está planteando en la próxima versión a 8 8MB o 16MB ... pero creo que para poner esto en perspectiva, Eliot de 10gen (que desarrolló MongoDB) lo describe mejor:
EDITAR: El tamaño ha sido officially ''elevado'' a 16MB
Entonces, en su ejemplo de blog, 4MB es en realidad un montón. Por ejemplo, el texto completo de "War of the Worlds" es de 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 dedicas 1MB a ellos, fácilmente podrías tener más de 10k (probablemente más cerca de 20k)
Entonces, a excepción de situaciones realmente extrañas, funcionará muy bien. Y en el caso de excepción o spam, realmente no creo que quieras un objeto de 20 MB de todos modos. Creo que limitar los trackbacks como 15k o más 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 no gastar toda la memoria RAM en su servidor (ya que necesita cargar todos los MB del documento en la RAM cuando la consulta).
Entonces el límite es un% de 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) de más de 16MB , puede usar la API de GridFS, que dividirá automáticamente los datos en segmentos y los transmitirá nuevamente (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 archivos y la otra almacena los metadatos de los archivos.
Puede usar este método para almacenar imágenes, archivos, videos, etc. en la base de datos de manera similar a como 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ímites con las advertencias sobre el rendimiento, consulte este comentario para obtener 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 es que los desarrolladores principales son tercos sobre este tema porque decidieron que era una "característica" importante desde el principio. No van a cambiarlo pronto porque sus sentimientos están heridos y alguien lo cuestionó. Otro ejemplo de personalidad y política que resta valor a un producto en comunidades de código abierto, pero esto no es realmente un problema paralizante.
Para publicar una respuesta de aclaración aquí para aquellos que son dirigidos aquí por Google.
El tamaño del documento incluye todo en el documento, incluidos los subdocumentos, 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 16 megas
Los documentos ocultos y los objetos anidados se cuentan para el tamaño del documento.
Quizás almacenar una publicación de blog -> comentarios en una base de datos no relacional no sea realmente el mejor diseño.
Probablemente debería almacenar los comentarios en una colección separada para las publicaciones de blog de todos modos.
[editar]
Ver comentarios a continuación para mayor discusión.
Todavía no he visto un problema con el límite que no implicaba archivos grandes almacenados en el documento en sí. Ya hay una variedad de bases de datos que son muy eficientes para almacenar / recuperar archivos de gran tamaño; se llaman sistemas operativos. La base de datos existe como una capa sobre el sistema operativo. Si está utilizando una solución NoSQL por motivos de rendimiento, ¿por qué desea agregar una sobrecarga de procesamiento adicional al acceso de sus datos al poner la capa de DB entre su aplicación y sus datos?
JSON es un formato de texto. Por lo tanto, 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 como
archivo binario <> JSON (codificado) <> BSON (codificado)
Sería más eficiente poner la ruta (URL) en el 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, entonces probablemente sea mejor que los ponga en GridFS y no se arriesgue a matar su concurrencia cuando se acceda a los archivos de gran tamaño.
Profundidad anidada para documentos BSON: MongoDB no admite más de 100 niveles de anidación para documentos BSON.