Comprendre la limite de taille de document MongoDB BSON

De MongoDB The Definitive Guide:

Les documents de plus de 4 Mo (lorsqu'ils sont convertis en BSON) ne peuvent pas être enregistrés dans la base de données. C'est une limite quelque peu arbitraire (et peut être augmentée à l'avenir); il s'agit principalement d'éviter une mauvaise conception de schéma et d'assurer des performances constantes.

Je ne comprends pas cette limite, cela signifie-t-il qu'un document contenant un article de blog avec beaucoup de commentaires qui se trouve être plus grand que 4 Mo ne peut pas être stocké en tant que document unique?

Cela compte-t-il également les documents imbriqués?

Et si je voulais un document qui vérifie les changements d'une valeur. (Il finira par grandir, dépassant la limite de 4 Mo.)

J'espère que quelqu'un explique cela correctement.

Je viens de commencer à lire sur MongoDB (première base de données nosql que j'apprends).

Je vous remercie.

Tout d'abord, cela est en fait soulevé dans la prochaine version de 8MBou 16MB... mais je pense que pour mettre cela en perspective, Eliot de 10gen (qui a développé MongoDB) le dit le mieux:

EDIT: La taille a été officiellement `` augmentée '' à16MB

Donc, sur votre exemple de blog, 4 Mo, c'est en fait beaucoup. Par exemple, le texte intégral non compressé de "War of the Worlds" ne fait que 364k (html): http://www.gutenberg.org/etext/36

Si votre article de blog est aussi long avec autant de commentaires, je ne vais pas le lire :)

Pour les trackbacks, si vous leur consacrez 1 Mo, vous pourriez facilement avoir plus de 10k (probablement plus près de 20k)

Donc, à l'exception des situations vraiment bizarres, cela fonctionnera très bien. Et dans le cas d'exception ou de spam, je ne pense vraiment pas que vous voudriez un objet de 20 Mo de toute façon. Je pense que plafonner les trackbacks à environ 15k a beaucoup de sens, peu importe les performances. Ou du moins un boîtier spécial si cela arrive.

-Éliot

Je pense que vous auriez du mal à atteindre la limite ... et avec le temps, si vous mettez à niveau ... vous devrez vous inquiéter de moins en moins.

Le point principal de la limite est de ne pas utiliser toute la RAM de votre serveur (car vous devez charger tous MBles documents dans la RAM lorsque vous l'interrogez.)

La limite est donc de quelques% de RAM utilisable normale sur un système commun ... qui continuera de croître d'année en année.

Remarque sur le stockage de fichiers dans MongoDB

Si vous avez besoin de stocker des documents (ou des fichiers) plus volumineux que 16MBvous pouvez utiliser l' API GridFS qui divisera automatiquement les données en segments et vous les restituera (évitant ainsi le problème des limites de taille / RAM.)

Au lieu de stocker un fichier dans un seul document, GridFS divise le fichier en parties, ou blocs, et stocke chaque bloc dans un document distinct.

GridFS utilise deux collections pour stocker les fichiers. Une collection stocke les morceaux de fichier et l'autre les métadonnées de fichier.

Vous pouvez utiliser cette méthode pour stocker des images, des fichiers, des vidéos, etc. dans la base de données comme vous le feriez dans une base de données SQL. Je l'ai utilisé pour même stocker des fichiers vidéo de plusieurs gigaoctets.

De nombreux membres de la communauté préféreraient qu'il n'y ait pas de limite avec des avertissements sur les performances, voir ce commentaire pour un argument bien raisonné: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian.jira.plugin. system.issuetabpanels: comment-tabpanel # comment-22283

À mon avis, les développeurs principaux sont têtus sur ce problème car ils ont décidé très tôt que c'était une «fonctionnalité» importante. Ils ne vont pas le changer de sitôt parce que leurs sentiments sont blessés que quiconque la remette en question. Un autre exemple de personnalité et de politique nuisant à un produit dans les communautés open source, mais ce n'est pas vraiment un problème paralysant.

Pour publier une réponse de clarification ici pour ceux qui sont dirigés ici par Google.

La taille du document comprend tout ce qui se trouve dans le document, y compris les sous-documents, les objets imbriqués, etc.

Donc un document de:

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

A une taille maximale de 16meg.

Les sbudocuments et les objets imbriqués sont tous comptés dans la taille du document.

Je n'ai pas encore vu de problème avec la limite qui n'impliquait pas de gros fichiers stockés dans le document lui-même. Il existe déjà une variété de bases de données qui sont très efficaces pour stocker / récupérer des fichiers volumineux; ils sont appelés systèmes d'exploitation. La base de données existe en tant que couche sur le système d'exploitation. Si vous utilisez une solution NoSQL pour des raisons de performances, pourquoi voudriez-vous ajouter une surcharge de traitement supplémentaire à l'accès de vos données en plaçant la couche DB entre votre application et vos données?

JSON est un format de texte. Donc, si vous accédez à vos données via JSON, cela est particulièrement vrai si vous avez des fichiers binaires car ils doivent être encodés en uuencode, hexadécimal ou Base 64. Le chemin de conversion peut ressembler à

fichier binaire <> JSON (encodé) <> BSON (encodé)

Il serait plus efficace de mettre le chemin (URL) du fichier de données dans votre document et de conserver les données elles-mêmes en binaire.

Si vous voulez vraiment conserver ces fichiers de longueur inconnue dans votre base de données, vous feriez probablement mieux de les mettre dans GridFS et de ne pas risquer de tuer votre concurrence lors de l'accès aux fichiers volumineux.

Profondeur imbriquée pour les documents BSON: MongoDB ne prend pas en charge plus de 100 niveaux d'imbrication pour les documents BSON.

Plus plus d'infos voir

Peut-être que stocker une relation article de blog -> commentaires dans une base de données non relationnelle n'est pas vraiment la meilleure conception.

Vous devriez probablement stocker les commentaires dans une collection séparée des articles de blog de toute façon.

[Éditer]

Voir les commentaires ci-dessous pour une discussion plus approfondie.

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

Si vous pensez qu'un article de blog peut dépasser la limite de 16 Mo de document, vous devez extraire les commentaires dans une collection distincte et référencer l'article de blog à partir du commentaire et effectuer une jointure au niveau de l'application.

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

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