Comprendre la limite de taille des documents BSON de MongoDB

Question

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. Il s'agit d'une limite quelque peu arbitraire (qui pourrait être augmentée à l'avenir). être augmentée à l'avenir) ; il s'agit surtout d'éviter une mauvaise conception des schémas et d'assurer des des performances cohérentes.

Je ne comprends pas cette limite, est-ce que cela signifie qu'un document contenant un article de blog avec beaucoup de commentaires qui se trouve être plus grand que 4MB ne peut pas être stocké comme un seul document ?

Les documents imbriqués sont-ils également pris en compte ?

Et si je voulais un document qui vérifie les changements apportés à une valeur. (Il finira par grossir, dépassant la limite de 4MB).

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

Je viens de commencer à lire sur MongoDB (première base de données nosql sur laquelle je me renseigne).

Merci.

Answer 1

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

EDITAR: La taille a été officiellement élevé" à 16MB

Donc, sur votre exemple de blog, 4MB est en fait beaucoup Par exemple, le texte complet non compressé de "La guerre des des mondes" est seulement 364k (html) : http://www.gutenberg.org/etext/36

Si ton article de blog est si long avec de commentaires, je ne vais pas le lire ne le lirai pas :)

Pour les trackbacks, si vous leur consacrez 1MB à eux, vous pourriez facilement avoir plus de plus de 10k (probablement plus proche de 20k)

Donc, sauf pour les situations vraiment bizarres des situations vraiment bizarres, ça marchera très bien. Et dans l'exception du cas ou du spam, je n'ai vraiment que vous ne voudriez pas d'un objet de 20mb de toute façon. Je pense que plafonner les trackbacks à 15k ou plus, ça a beaucoup de sens, peu importe quoi que ce soit pour les performances. Ou au moins au moins une enveloppe spéciale si jamais cela arrive.

-Eliot

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

L'objectif principal de cette limite est de ne pas utiliser toute la mémoire vive de votre serveur (car vous devez charger toutes les données de l MB du document dans la RAM lorsque vous l'interrogez).

La limite est donc d'un certain pourcentage de la RAM normalement utilisable sur un système commun... qui ne cessera d'augmenter d'année en année.

Note sur le stockage des fichiers dans MongoDB

Si vous avez besoin de stocker des documents (ou des fichiers) plus volumineux que 16MB vous pouvez utiliser le API GridFS qui décomposera automatiquement les données en segments et vous les transmettra en continu (é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 chunks, et stocke chaque chunk comme un document séparé.

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

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 même utilisé cette méthode pour stocker des fichiers vidéo de plusieurs gigaoctets.

Answer 2

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 principaux développeurs s'entêtent sur cette question parce qu'ils ont décidé très tôt qu'il s'agissait d'une "fonctionnalité" importante. Ils ne vont pas la changer de sitôt parce qu'ils sont blessés que quelqu'un la remette en question. 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 rédhibitoire.

Answer 3

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

La taille du document inclut 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 16 MB.

Les sous-documents et les objets imbriqués sont tous comptabilisés dans la taille du document.

Answer 4

Je n'ai pas encore vu de problème avec la limite qui ne concernait 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 ; on les appelle des systèmes d'exploitation. La base de données existe comme une couche au-dessus du système d'exploitation. Si vous utilisez une solution NoSQL pour des raisons de performance, pourquoi voudriez-vous ajouter des frais de traitement supplémentaires à l'accès à vos données en plaçant la couche de base de données entre votre application et vos données ?

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

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

Il serait plus efficace d'indiquer le chemin d'accès (URL) au 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 tuer votre concurrence lors de l'accès aux gros fichiers.

Answer 5

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

De toute façon, vous devriez probablement stocker les commentaires dans une collection distincte de celle des articles de blog.

[modifier]

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