De MongoDB La Guía Definitiva:

Documentos de más de 4 MB (cuando se convierte en HIJO) no puede ser
guarda en la base de datos. Esto es un poco arbitrario límite (y puede ser
se crió en el futuro); es sobre todo para prevenir el mal diseño del esquema y garantizar
un rendimiento consistente.

No entiendo este límite, esto quiere decir que Un Documento que contiene un Blog con un montón de comentarios, que también pasa a ser mayor que la de 4MB no se puede guardar como un documento único?

También hace este recuento de la anidados documentos demasiado?

Lo que si quería un documento que revisa los cambios en un valor. (Eventualmente puede crecer, superior a 4MB límite.)

Espero que alguien lo explica correctamente.

He empezado a leer sobre MongoDB (primera base de datos nosql estoy aprendiendo acerca de).

Gracias.

  • Creo que la pregunta debería aclarar que esto es una limitación de la MongoDB documento almacenado tamaños y no de que el HIJO de formato.
  • estás en lo correcto.
  • Sin embargo, yo sólo traté de guardar un gran documento que ciertamente excede de 4 mb de hacer llegar el mensaje de «HIJO::InvalidDocument: Documento demasiado grande: AHIJO documentos se limitan a 4194304 bytes.» Si ese es el caso, ¿no es tipo de inducir a error en el aviso/mensaje de error?
  • Usted puede encontrar fácilmente su HIJO max tamaño de documento con db.isMaster().maxBsonObjectSize/(1024*1024)+' MB' comando en mongo shell.
  • ¿cuál es el propósito de schemaless nosql donde no se puede volcado de registros de más de 16 mb y construido operación crud en la parte superior de ella !
  • Creo que la cita inicial lo dice todo… El límite está en el lugar para prevenir el mal diseño del esquema. Si, por ejemplo, tienes un post con muchos comentarios, usted quiere una entrada en el blog de la colección y un comentario de la colección, o de los cambios de la colección. El diseño de mongo/nosql permite masivamente tamaño de las cosas como de las redes de los documentos, pero el desarrollador necesita para romper en partes que tengan sentido. Si no hay límite de tamaño se establece, otros problemas que va a suceder. Creo que el 4mb límite estaba bien. 16mb, genial! Pero si estoy escribiendo un 16mb documento, que es un indicio de que algo está mal con el diseño.

InformationsquelleAutor saint | 2011-01-12

7 Comentarios

  1. 115

    En primer lugar, esta realidad está siendo criado en la próxima versión de 8MB o 16MB … pero creo que para poner esto en perspectiva, Eliot de 10gen (que desarrolló MongoDB) pone mejor:

    EDICIÓN: El tamaño ha sido oficialmente ‘levantó’ a 16MB

    Así, en su blog ejemplo, 4 mb
    un montón.. Por ejemplo,
    el pleno descomprime el texto de «la Guerra de
    los Mundos» es sólo 364k (html):
    http://www.gutenberg.org/etext/36

    Si tu blog es que el tiempo con
    que muchos de los comentarios, yo soy uno que no
    vamos a leerlo 🙂

    Para los trackbacks, si usted dedica 1MB
    para ellos, usted puede fácilmente tener más
    de 10k (probablemente cerca de 20k)

    Así, excepto para verdaderamente extraño
    situaciones, se va un gran trabajo. Y en
    el caso de excepción o de spam, realmente me
    no creo que te gustaría un objeto de 20mb
    de todos modos. Creo tapado trackbacks como
    15k o así que hace un montón de sentido no
    importa lo que para el rendimiento. O en
    menos especial de la carcasa si es que alguna vez
    sucede.

    -Eliot

    Creo que iba a ser muy difícil alcanzar el límite … y con el tiempo, si se actualiza … tendrá que preocuparse menos y menos.

    El principal punto de que el límite es para que no use toda la RAM en el servidor (como usted necesita para cargar todos los MBs del documento en la memoria RAM cuando se consulta.)

    Por lo que el límite es de unos % de lo normal utilizable RAM en un sistema común … que seguirá creciendo de año en año.

    Nota sobre el Almacenamiento de Archivos en MongoDB

    Si usted necesita para almacenar documentos (o archivos) de más de 16MB puede utilizar el GridFS API que romperá automáticamente los datos en segmentos de secuencia y de vuelta a usted (evitando el problema con los límites de tamaño de RAM.)

    Lugar de almacenamiento de un archivo en un documento único, GridFS divide el archivo en partes o en trozos, y las tiendas de cada fragmento como un documento separado.

    GridFS utiliza dos colecciones para almacenar archivos. Una colección almacena el archivo en trozos, y la otra almacena en los metadatos del archivo.

    Puede utilizar este método para almacenar imágenes, archivos, videos, etc en la base de datos como en una base de datos SQL. He utilizado esta incluso almacenar múltiples gigabytes de archivos de vídeo.

    • Yo realmente no lo entiendo «El punto principal de que el límite es para que no use toda la RAM en el servidor». Guardamos toda nuestra base de datos MongoDB en la memoria RAM así es este sigue siendo un motivo de preocupación?
    • Eso es impresionante, tienes suficiente RAM para toda su base de datos … Normalmente el «trabajo» es en la RAM, no toda la base de datos (como en mi caso que tengo más de uno x Egb bases de datos donde si todos sumados exceda de mi RAM, pero eso está bien porque el trabajo es mucho, mucho más pequeño.) También, si no había ningún límite puede cargar un 800MB doc en la memoria RAM w/ una consulta y un 400k doc con el otro, haciendo balance de su RAM un poco difícil, y etc. Así que el «límite» es un % de servidor típico de RAM (por lo que crece con el tiempo.) mongodb.org/display/DOCS/Checking+Servidor+Memoria+de Uso
    • Es genial que usted puede almacenar todo en la RAM, pero tenga en cuenta la eficiencia y la entrada en el blog modismo. Obviamente usted quiere un puesto en la memoria si su lectura. Pero, ¿realmente quieren las 10 páginas de comentarios de un blog para estar en la memoria cuando la mayoría de la gente nunca va a leer más allá de la primera página? Seguro, usted puede hacerlo y si su base de datos es lo suficientemente pequeño que puede caber todo en la memoria, entonces no hay problema. Pero en términos de pura eficiencia, usted no desea inútil bits para tomar espacio en la memoria si se puede evitar (y eso va para RDBMS así).
    • dulce jesús, tan Mongo el argumento de «16 MB debería ser suficiente para cualquiera»? No es como que nunca ha demostrado ser incorrectas en el pasado.
    • Sería agradable si había un ejemplo de cómo lidiar con una situación como esta. Es concebible que uno podría fácilmente superar 16MB si los archivos (por ejemplo, imágenes, etc), se autorizó a una solicitud de comentarios.
    • Esto parece demasiado malo para mí. Mongo se supone que será útil para grandes volúmenes de datos, no tiene esas limitaciones. En mi proyecto, necesito el agregado y el grupo de los tweets que están relacionados con la misma tendencia, y esto podría terminar en más de 20000 tweets por un período de tiempo de 20 horas (y es muy posible que no serán las tendencias durating más de 20 horas en mi db). Haber que muchos tweets y almacenar su texto al mismo tiempo es devastador y después de agrupar un par de pequeñas tendencias, que termina con la excepción de una de las grandes tendencias.
    • es correcto ¿cuál es el propósito de 16 mb para nosql schemaless sistema.entendemos el por qué de 16 mb de límite está ahí, pero desde el escenario real alternativa es, que la distribución de datos a través de diversos documentos y aplicar vinculación para la operación crud como usted sabe que en el convencional sistema rdbms!
    • ¿por qué poner todos los tweets en un solo documento? El uso de un documento por tweet, poner el trending topic como otro campo en el documento. poner un índice sobre este tema en el campo y, a continuación, agregar en ese campo mediante el mongo de tuberías. toma algún ajuste de cómo hacer que las cosas funcionen con nosql, una vez que se adapte a sus métodos y pensando que va a encontrar grandes obras de un gran número de datos de casos de uso.
    • Yo no lo recuerdo ahora mismo, pero creo que eso es lo que hice. Pero cuando me agregan en el tema de campo, se creó un documento único para cada clave, y terminó con enorme documentos de los temas más grandes. De todos modos, que fue el año pasado y apenas puedo recordar mi aplicación 😛

  2. 27

    Muchos en la comunidad prefiere no hay límite con advertencias acerca del rendimiento, vea este comentario para una argumentación razonada:
    https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-22283

    Mi opinión, los principales desarrolladores son tercos acerca de este problema debido a que se decidió que era importante «función» desde el principio. Ellos no van a cambiar en cualquier momento pronto debido a sus sentimientos están heridos que nadie lo cuestionó. Otro ejemplo de la personalidad y de la política de restar el valor de un producto en las comunidades de código abierto, pero esto no es realmente una agobiante problema.

    • Estoy totalmente de acuerdo con usted, además, se frustra el propósito de tener los documentos incrustados ahora, como la mayoría de los documentos incrustados ahora cruzar el límite fácilmente. Esp con matriz de documentos dentro de ellos
    • dice fija ahora, ha sido solucionado?
    • Quiero decir, el límite se elevó a 16 MB, que no soluciona el «problema» de largo plazo; IMO el límite que debería ser eliminado.
    • 6 años de edad hilo necro. Estoy firmemente convencida de su específica de la mala utilización de caso/ejemplo de diseño. También, que el ejemplo es mucho mejor para ilustrar por qué usted necesita para validar las entradas de una base de datos documento único límite de tamaño. Hacer la aplicación de dividir su anidada documentos como documentos individuales en otra colección o iniciar un nuevo «continuación» del documento (soluciones que he utilizado varias veces para trabajar dentro de este límite) tuvo poco impacto en el rendimiento, pero grandes impactos sobre la complejidad del código. Todo el punto de documento DBs es la localidad de los datos.
    • Añadir un adicional de 2¢, una limitación como esto no es así, de hecho, «la derrota el propósito» de los documentos incrustados. Mi juego de los foros, por ejemplo, almacenar todas las respuestas a un hilo en el hilo. Para superar la actual 16MB límite requeriría la comunidad colectivamente escribir una novela que contiene más de 500 capítulos en un solo hilo de esta no va a suceder. (6.5 promedio de bytes por palabra, 5K palabra capítulo de longitud.)
    • Gracias por hacer sobre las mismas matemáticas mongoDB documentos de hacer para defender a esta decisión, pero su único caso de uso y un experimento de pensamiento, está lejos de ser concluyente. He tenido que llegar a los complejos, redundante diseños para solucionar el hecho de que hay un límite arbitrario que no ser golpeado por mongo (sin profundamente anidadas o entradas duplicadas, por cierto). Por su lógica, no de la base de datos debe contener más de 16 MB total debido a que algunas de texto arbitrario que puede ser representado utilizando menos espacio de almacenamiento. Esto es obviamente una tontería.

  3. 24

    A publicar una aclaración respuesta para aquellos que se dirigen aquí por Google.

    El tamaño de los documentos que incluye todo lo que en el documento, incluyendo los subdocumentos, objetos anidados etc.

    Así 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 son todos cuentan para el tamaño del documento.

    • El único más grande posible de la estructura de poder ser representada en BSON es, irónicamente, también la mayoría de los compactos. A pesar del hecho de que MongoDB utiliza size_t (64-bit) de la matriz de índices internamente, el 16MB documento límite de tamaño, en el mejor de los casos, capaces de representar un documento que contiene una única matriz que contiene en sí dos millones de valores Nulos.
    • Disculpas, la adición de una segunda observación a la dirección/aclarar otro detalle importante: cuando usted dice que tamaño del documento incluye todo lo que en el documento, que también incluye el teclas. E. g. {"f": 1} es de dos bytes más pequeño que {"foo": 1}. Este rápidamente se puede agregar para arriba si usted no es cuidadoso, aunque moderno en el disco de compresión de ayuda.
  4. 4

    Todavía no he visto un problema con el límite de que no implican grandes archivos almacenados en el propio documento. Ya hay una variedad de bases de datos que son muy eficientes en el almacenamiento/recuperación de archivos de gran tamaño; son los llamados sistemas operativos. La base de datos existe como una capa sobre el sistema operativo. Si usted está utilizando una solución NoSQL por motivos de rendimiento, ¿por qué quieres agregar más la sobrecarga de procesamiento para el acceso de los datos haciendo que la base de datos de la capa entre la aplicación y sus datos?

    JSON es un formato de texto. Así que, si desea acceder a sus datos a través de JSON, esto es especialmente cierto si usted tiene archivos binarios, ya que han de ser codificados en uuencode, hexadecimal o Base 64. La ruta de conversión podría parecer

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

    Que sería más eficaz para poner la ruta de acceso (URL) para el archivo de datos en el documento y guardar los datos en binario.

    Si usted realmente quiere mantener estos archivos de longitud desconocida en su DB, entonces probablemente sería mejor poner estos en GridFS y no arriesgar matar a su concurrencia cuando se accede a archivos grandes.

    • «Ya hay una variedad de bases de datos que son muy eficientes en el almacenamiento/recuperación de archivos de gran tamaño; son los llamados sistemas operativos.»; Consulte blog.mongodb.org/post/183689081/…
  5. 2

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

    Probablemente debería guardar comentarios en un sistema de recogida selectiva a las entradas del blog de todos modos.

    [editar]

    Ver los comentarios de abajo para más discusión.

    • No saber sobre el mejor diseño en esta etapa temprana de la experiencia. El libro da un poco de ejemplo de un blog. De ahí el pensamiento. Gracias.
    • No estoy de acuerdo en todo. Los comentarios en su blog que los documentos deben estar perfectamente bien en MongoDB … es un uso muy común (yo lo uso más de un lugar en la producción y funciona bastante bien.)
    • Jenkins: estoy de acuerdo con usted, pero en realidad, depende del sitio. Así que creo que para sitios como stackoverflow necesidad de crear documento aparte para comentar.
    • seguro que es ASÍ, pero el 98% de los sitios no están en cualquier lugar cerca 🙂 eso es todo lo que estoy diciendo. Para la mayoría de los sitios que será un gran trabajo (y, posiblemente, AYUDAR realmente más de lo que podría lastimar.) Dicho esto, dependiendo de su escala de almacenar comentarios en un sistema de recogida selectiva puede ser la única opción.
    • Estaba quizá demasiado estricto en mi respuesta. No hay nada de malo en el almacenamiento de entradas de blog y los comentarios asociados en MongoDB o similar de la base de datos. Es más que la gente tiende a abusar de las habilidades documento de bases de datos basadas en dar (más radical ejemplo sería para almacenar todos sus datos en un solo documento denominado «blog»)
    • Estoy de acuerdo de nuevo… Pero una cosa más. Diseño del documento db también dependen de un diseño de sitio, porque si usted necesita para mostrar el listado de hilos sin comentarios(como la lista de preguntas en stackoverflow) para asegurarse de la necesidad de crear documentos separados por el blog y los comentarios.
    • totalmente de acuerdo en que el abuso! Un «blog» documento sería una locura. 🙂
    • Yo no lo podría entender totalmente lo que usted está diciendo, pero me gustaría pensar que es en realidad bastante simple MongoDB consulta: «mostrar el listado de hilos sin comentarios». Dicho esto, creo que entiendo tu punto de vista.
    • no es buena, pero el almacenamiento de comentarios en un sistema de recogida selectiva es igual de malo, por las mismas razones. Posts con comentarios de la matriz es igual, la cannonical ejemplo de un documento db.
    • almacenar comentarios dentro de un post es como el ejemplo canónico de Documento orientado a la DBs. (como el almacenamiento de la totalidad de un texto de la wiki dentro de un mismo documento) Si yo fuera a escribir por LO que se corre completamente en MongoDB. Ninguna de estas entradas es ir a la razonablemente exceda los 4 mb. Craigslist está haciendo un gigante DB migración de su historia a MongoDB. Sólo había un par de docs ir por encima de este límite y el desarrollador principal sugirió que los médicos mismos eran en realidad roto (el resultado de algunos errores). De nuevo, de 4 megas es de varias novelas de texto.
    • VP, estoy de acuerdo!
    • VP, ¿qué acerca de la etiqueta de la búsqueda? La recuperación de los resultados de la búsqueda sería razonablemente rápido para ASÍ, pero para un sitio que tiene un montón de documentos de gran tamaño, usted puede ser que necesite para carga y transferencia de megabytes de datos.
    • que 4 MB (ahora 16MB) límite es para un único documento. Recuerde que en MongoDB un «documento» es aproximadamente equivalente a una «fila». Si usted tiene grandes objetos binarios, entonces usted debe echar un vistazo a GridFS para almacenar estos objetos. Si usted necesita para buscar a través de grandes cuerpos de texto directamente Y este texto supera los 4 MB, entonces MongoDB no es la herramienta correcta (ni la mayoría de los DBs). Para buscar a través de una gran cantidad de texto por favor, mira a SOLR o la Esfinge.
    • VP, estoy de acuerdo acerca del uso de un motor de búsqueda de texto completo separado. Yo estaba pensando en una búsqueda de metadatos. Lo que si se tiene un conjunto de documentos de Libro, y usted quiere encontrar todos los libros publicados en 1982? Si cada libro tiene +100 kb de texto, usted no desea transferir varios megabytes sólo para mostrar los 20 primeros títulos del libro.

  6. 0

    Según https://www.mongodb.com/blog/post/6-rules-of-thumb-for-mongodb-schema-design-part-1

    Si espera que un blog puede exceder el 16Mb documento límite, usted debe extraer los comentarios en una colección de referencia y la entrada en el blog de el comentario y hacer una aplicación de nivel de unirse.

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

Dejar respuesta

Please enter your comment!
Please enter your name here