web-dev-qa-db-fra.com

Comprendre MongoDB BSON Limite de taille de document

De MongoDB Le guide définitif:

Les documents de plus de 4 Mo (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 du schéma et d'assurer des performances cohérentes.

Je ne comprends pas cette limite. Cela signifie-t-il qu'un document contenant un article de blog avec beaucoup de commentaires dont la taille est supérieure à 4 Mo ne peut pas être stocké en tant que document unique?

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

Et si je voulais un document qui vérifie les modifications apportées à une valeur. (Il finira par croître, dépassant la limite de 4 Mo.)

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

Je viens tout juste de commencer à lire sur MongoDB (la première base de données nosql que je découvre).

Je vous remercie.

mongodbbson
136
saint

Tout d'abord, cela est en fait soulevé dans la prochaine version à 8MB ou 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 'élevé' à 16MB

Ainsi, sur votre blog par exemple, 4Mo est en réalité un lot. Par exemple, le texte complet de "War of the Worlds" n’est que de 364k (html): http://www.gutenberg.org/ etext/36

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

Pour les rétroliens, si vous leur consacriez 1 Mo, vous pourriez facilement avoir plus de 10k (probablement plus proche de 20k)

Donc, sauf dans des situations vraiment bizarres, ça fonctionnera très bien. Et dans le cas des exceptions ou du spam, je ne pense vraiment pas que vous souhaitiez un objet de 20 Mo de toute façon. Je pense qu'il est logique de limiter les rétroliens à environ 15k, peu importe la performance. Ou du moins un boîtier spécial si cela se produit.

-Eliot

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

Le point essentiel de la limite est de ne pas utiliser tous les RAM de votre serveur (car vous devez charger tous les MBs du document dans RAM lorsque vous l'interrogez.)

La limite est donc de quelques% de la normale utilisable RAM 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 devez stocker des documents (ou des fichiers) de taille supérieure à 16MB vous pouvez utiliser le API GridFS qui divisera automatiquement les données en segments et vous les transmettra (en évitant ainsi le problème des limites de taille/RAM).

Au lieu de stocker un fichier dans un seul document, GridFS le divise en parties ou morceaux et stocke chaque morceau en tant que document séparé.

GridFS utilise deux collections pour stocker des fichiers. Une collection stocke les fragments de fichier et l'autre stocke 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. J'ai utilisé cela pour même stocker des fichiers vidéo de plusieurs gigaoctets.

117
Justin Jenkins

De nombreux membres de la communauté préféreraient que les avertissements sur les performances soient sans limite, consultez ce commentaire pour un argument bien motivé: https://jira.mongodb.org/browse/SERVER-431?focusedCommentId=22283&page=com.atlassian. jira.plugin.system.issuetabpanels: comment-tabpanel # comment-2228

Mon avis, les développeurs principaux sont têtus à propos de ce problème car ils ont décidé qu’il s’agissait d’une "fonctionnalité" importante au tout début. Ils ne vont pas le changer de si tôt car leurs sentiments sont blessés que quiconque le conteste. Un autre exemple de personnalité et de politique qui nuit à un produit dans les communautés open source, mais ce n’est pas vraiment un problème invalidant.

31
marr75

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

La taille du document inclut tout le contenu du 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 documents et les objets imbriqués sont tous comptabilisés dans la taille du document.

25
Sammaye

Je n'ai pas encore vu un problème avec la limite qui n'impliquait pas de gros fichiers stockés dans le document lui-même. Il existe déjà diverses bases de données très efficaces pour stocker/récupérer des fichiers volumineux. ils s'appellent des 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 à l'accès de vos données en plaçant la couche de base de données entre votre application et vos données?

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

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

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 mieux de les placer dans GridFS et de ne pas risquer de mettre fin à votre concurrence lorsque vous accédez aux fichiers volumineux.

4
Chris Golledge

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

Plus d'infos vist

4
user2903536

Peut-être que stocker un article de blog -> commentaires relation dans une base de données non relationnelle n'est pas vraiment le meilleur design.

De toute façon, vous devriez probablement stocker les commentaires dans une collection séparée pour les articles de blog.

[modifier]

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

2
Mchl

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

Si vous vous attendez à ce qu'une publication de blog dépasse la limite de 16 Mo de document, vous devez extraire les commentaires dans une collection distincte, référencer la publication 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')
  }
]
0
mzarrugh