FAQ MongoDBConsultez toutes les FAQ

Nombre d'auteurs : 1, nombre de questions : 331, dernière mise à jour : 18 décembre 2016  Ajouter une question

 

Cette FAQ a été réalisée à partir de la documentation officielle de Mongodb, des questions fréquemment posées sur les forums NoSQL Developpez.com et de l'expérience personnelle des auteurs.

Nous tenons à souligner que cette FAQ ne garantit en aucun cas que les informations qu'elle propose sont correctes. Les auteurs font leur maximum, mais l'erreur est humaine. Cette FAQ ne prétend pas non plus être complète. Si vous trouvez une erreur, ou que vous souhaitez nous aider en devenant rédacteur, lisez ceci.


SommaireMongoDB pour développeurs d'applications (27)
précédent sommaire suivant
 

Cette partie répond aux questions courantes sur le développement d'applications utilisant MongoDB.

Si vous ne trouvez pas la réponse que vous recherchez, consultez la liste complète des FAQ ou postez votre question dans la liste de diffusion des utilisateurs MongoDB.

Mis à jour le 11 décembre 2016

Un namespace est la concaténation du nom de la base de données et des noms de collection [1] séparés par un point.

Les collections sont des conteneurs pour les documents qui partagent un ou plusieurs index. Les bases de données sont des groupes de collections stockées sur le disque à l'aide d'un seul ensemble de fichiers de données. [2]

Par exemple, dans l'espace de noms acme.users, acme est le nom de la base de données et users est le nom de la collection. Le caractère point peut apparaître dans les noms de collection, de sorte que acme.user.history est un espace de noms valide, où acme est le nom de la base de données et user.history est le nom de la collection.

Alors que les modèles de données de ce genre semblent supporter les collections imbriquées, l'espace de noms des collections est plat, et du point de vue de MongoDB il n'y a pas de différence entre acme, acme.users et acme.records.

[1] Chaque index a également son propre espace de noms.

[2] Les bases de données MongoDB ont une limite configurable du nombre d'espaces de noms d'une base de données.

Mis à jour le 11 décembre 2016

Oui.

Lorsque vous utilisez remove(), l'objet n'existera plus dans le stockage de données MongoDB sur disque.

Mis à jour le 11 décembre 2016

MongoDB force l'écriture sur le disque après un intervalle régulier. Dans la configuration par défaut, MongoDB écrit des données dans les principaux fichiers de données sur le disque toutes les 60 secondes et effectue des commit dans le journal environ toutes les 100 millisecondes. Ces valeurs sont configurables avec commitIntervalMs et syncPeriodSecs.

Ces valeurs représentent le maximum de temps entre la fin d'une opération d'écriture et le moment où l'écriture est durable dans le journal, si elle est activée, et le moment où MongoDB force l'écriture de données sur le disque. Dans de nombreux cas, MongoDB et le système d'exploitation forcent l'écriture des données sur le disque plus fréquemment, de sorte que les valeurs ci-dessus représentent un maximum théorique.

Toutefois, par défaut, MongoDB utilise une stratégie « paresseuse » d'écriture sur le disque. Ceci est avantageux dans des situations où la base de données reçoit un millier d'incrémentations d'un objet dans une seconde, car MongoDB ne doit écrire ces données sur le disque qu'une fois. En plus des options de configuration ci-dessus, vous pouvez également utiliser fsync et write concern pour modifier cette stratégie.

Mis à jour le 11 décembre 2016

MongoDB ne dispose d'aucun support pour le verrouillage traditionnel ou les transactions complexes avec rollback. MongoDB vise à être légère, rapide et prévisible de ses performances. Ceci est similaire au modèle de validation automatique MySQL MyISAM. En gardant le support des transactions extrêmement simple, MongoDB peut fournir une plus grande performance, surtout pour les systèmes partitionnés ou répliqués avec un certain nombre de processus serveur de base de données.

MongoDB n'a pas le support pour opérations atomiques dans un seul document. Compte tenu des possibilités offertes par les documents imbriqués, cette fonctionnalité fournit un support pour un grand nombre de cas d'utilisation.

Voir aussi la page atomicité et transactions.

Mis à jour le 11 décembre 2016

Dans la version 2.1 et ultérieures, vous pouvez utiliser le nouveau framework d'agrégation, avec la commande aggregate.

MongoDB supporte également les opérations map-reduce avec la commande mapReduce, ainsi que l'agrégation basique avec les commandes group, count, et distinct.

Voir aussi la page sur l'agrégation.

Mis à jour le 11 décembre 2016

Si vous voyez un très grand nombre de messages de connexion et de reconnexion dans votre journal de MongoDB, alors les clients se connectent et se déconnectent fréquemment au serveur MongoDB. Ce comportement est normal pour les applications qui n'utilisent pas une centralisation des requêtes, comme CGI. Envisagez d'utiliser FastCGI, un module Apache, ou un autre type de serveur d'applications persistant afin de diminuer la surcharge de connexion.

Si ces connexions n'affectent pas votre rendement, vous pouvez utiliser l'option quiet au moment de l'exécution ou l'option en ligne de commande --quiet pour supprimer ces messages du journal.

Mis à jour le 11 décembre 2016

Oui.

Des utilisateurs MongoDB de toutes tailles ont eu beaucoup de succès en utilisant MongoDB sur la plateforme EC2 utilisant des disques EBS.

Voir aussi Amazon EC2.

Mis à jour le 11 décembre 2016

MongoDB préalloue agressivement des fichiers de données pour réserver de l'espace et pour éviter la fragmentation du système de fichiers. Vous pouvez utiliser le paramètre storage.smallFiles afin de modifier la stratégie de préallocation de fichiers.

Voir aussi : Pourquoi les fichiers dans mon répertoire de données sont-ils plus gros que les données dans ma base de données ?.

Mis à jour le 11 décembre 2016

Chaque document MongoDB contient une certaine quantité de surcharge. Celle-ci est normalement insignifiante, mais devient significative si tous les documents ne font que quelques octets, comme cela pourrait être le cas si les documents de votre collection ont seulement un ou deux champs.

Considérez les suggestions et les stratégies suivantes pour optimiser l'utilisation du stockage pour ces collections.

  • Utilisez explicitement le champ _id.
    Les clients MongoDB ajoutent automatiquement un champ _id à chaque document et génèrent un ObjectId unique de 12 octets pour celui-ci. En outre, MongoDB indexe toujours le champ _id. Pour les documents plus petits, cela peut occuper beaucoup d'espace.
    Pour optimiser l'utilisation du stockage, les utilisateurs peuvent spécifier explicitement une valeur pour le champ _id lors de l'insertion des documents dans la collection. Cette stratégie permet aux applications de stocker dans le champ _id une valeur qui aurait occupé de l'espace dans une autre partie du document.
    Vous pouvez stocker n'importe quelle valeur dans le champ _id, mais parce que cette valeur sert de clé primaire pour les documents de la collection, elle doit les identifier de façon unique. Si la valeur du champ n'est pas unique, alors elle ne peut pas servir de clé primaire, car il y aurait des collisions dans la collection.
  • Utilisez des noms de champs plus courts.
    MongoDB stocke tous les noms de champs dans chaque document. Pour la plupart des documents, cela représente une petite fraction de l'espace utilisé par un document. Toutefois, pour les petits documents les noms de champs peuvent représenter beaucoup d'espace. Envisagez une collection de documents qui ressemblerait à ce qui suit :

    Code javascript : Sélectionner tout
    { last_name : "Smith", best_score: 3.9 }
  • Si vous raccourcissez le nom du champ last_name à lname et le nom du champ best_score à score, comme suit, vous pourriez économiser 9 octets par document.

    Code javascript : Sélectionner tout
    { lname : "Smith", score : 3.9 }
  • Raccourcir les noms des champs réduit l'expressivité et ne fournit pas un avantage considérable pour les documents plus grands, où la surcharge du document n'est pas une préoccupation importante. Les noms de champs plus courts ne réduisent pas la taille des index, car les index ont une structure prédéfinie.
    En général, il n'est pas nécessaire d'utiliser des noms de champs courts.
  • Imbriquez les documents.
    Dans certains cas, vous voudrez peut-être imbriquer des documents dans d'autres documents et économiser sur la surcharge par document.

Mis à jour le 11 décembre 2016

Dans une collection de documents MongoDB, vous devriez toujours utiliser GridFS pour stocker des fichiers de plus de 16 Mo.

Dans certaines situations, le stockage des gros fichiers peut être plus efficace dans une base de données MongoDB que dans un système de fichiers du système.

  • Si votre système de fichiers limite le nombre de fichiers dans un répertoire, vous pouvez utiliser GridFS pour stocker autant de fichiers que nécessaire.
  • Lorsque vous souhaitez conserver vos fichiers et les métadonnées automatiquement synchronisés et déployés à travers un certain nombre de systèmes et installations. Lors de l'utilisation des données distribuées géographiquement, MongoDB peut distribuer automatiquement les fichiers et leurs métadonnées à un certain nombre d'instances et installations mongod.
  • Lorsque vous souhaitez accéder aux informations à partir de portions de fichiers volumineux sans avoir à charger l'ensemble des fichiers en mémoire, vous pouvez utiliser GridFS pour appeler des sections de fichiers sans avoir à lire la totalité du fichier en mémoire.

N'utilisez pas GridFS si vous avez besoin de mettre à jour atomiquement l'ensemble du contenu du fichier. Comme autre choix, vous pouvez stocker plusieurs versions de chaque fichier et spécifier la version actuelle du fichier dans les métadonnées. Vous pouvez mettre à jour le champ de métadonnées qui indique « le dernier » statut dans une mise à jour atomique après le téléchargement de la nouvelle version du fichier, et supprimer plus tard les versions précédentes, si nécessaire.

En outre, si vos fichiers sont tous plus petits que la limite BSON Document Size de 16 Mo, envisagez de stocker le fichier manuellement dans un seul document. Vous pouvez utiliser le type de données BinData pour stocker les données binaires. Consultez la documentation de vos pilotes pour plus de détails sur l'utilisation de BinData.

Pour plus d'informations sur GridFS, voir GridFS.

Mis à jour le 11 décembre 2016

MongoDB implémente un verrou en lecture-écriture. Cela signifie qu'à un moment donné, un seul client peut écrire ou n'importe quel nombre de clients peuvent lire, mais que la lecture et l'écriture ne peuvent pas se produire simultanément.

Dans les instances autonomes et les replica sets, la portée du verrou s'applique à une seule instance de mongod, ou instance principale. Dans un cluster partagé, appliquent à chaque fragment individuel, et non à l'ensemble du cluster.

Pour plus d'informations, voir Concurrence.

Mis à jour le 11 décembre 2016

MongoDB permet aux documents au sein d'une collection unique d'avoir des champs avec des types BSON différents. Par exemple, les documents suivants peuvent exister au sein d'une seule collection.

Code javascript : Sélectionner tout
1
2
{ x: "string" } 
{ x: 42 }
Lors de la comparaison des différents types BSON, MongoDB utilise l'ordre de comparaison suivant, du plus bas au plus élevé :

  • MinKey (type interne) ;
  • Null ;
  • Nombres (entiers, longs, doubles) ;
  • Symbole, String ;
  • Objet ;
  • Tableau ;
  • BinData ;
  • ObjectId ;
  • Boolean ;
  • Date ;
  • Timestamp ;
  • Expression régulière ;
  • MaxKey (type interne).

MongoDB traite certains types comme équivalents à des fins de comparaison. Par exemple, les types numériques subissent une conversion avant la comparaison.

Modifié dans la version 3.0.0 : les objets Date sont évalués avant les objets Timestamp. Auparavant, les objets Date et Timestamp étaient évalués ensemble.

La comparaison traite un champ non renseigné comme un objet BSON vide. Ainsi, un tri sur champ dans les documents { } et { a: null } traiterait les documents comme équivalents dans l'ordre de tri.

Avec des tableaux, une comparaison inférieur à ou un tri croissant compare les plus petits éléments des tableaux, et une comparaison supérieur à ou un tri décroissant compare les plus grands éléments des tableaux. Ainsi, lorsque l'on compare un champ dont la valeur est un tableau à un seul élément (par exemple [ 1 ]) avec des champs non-tableau (par exemple 2), la comparaison est faite entre 1 et 2. Une comparaison d'un tableau vide (par exemple [ ]) traite le tableau vide comme étant plus petit que null ou un champ non renseigné.

MongoDB trie BinData dans l'ordre suivant :

  • Premièrement, la longueur ou la taille des données ;
  • Puis, par le sous-type BSON one-byte ;
  • Enfin, par les données, en effectuant une comparaison octet par octet.

Prenons l'exemple mongo suivant :

Code javascript : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
db.test.insert( {x : 3 } ); 
db.test.insert( {x : 2.9 } ); 
db.test.insert( {x : new Date() } ); 
db.test.insert( {x : true } ); 
  
db.test.find().sort({x:1}); 
{ "_id" : ObjectId("4b03155dce8de6586fb002c7"), "x" : 2.9 } 
{ "_id" : ObjectId("4b03154cce8de6586fb002c6"), "x" : 3 } 
{ "_id" : ObjectId("4b031566ce8de6586fb002c9"), "x" : true } 
{ "_id" : ObjectId("4b031563ce8de6586fb002c8"), "x" : "Tue Nov 17 2009 16:28:03 GMT-0500 (EST)" }
L'opérateur $type permet d'accéder à la comparaison du type BSON dans la syntaxe de requête MongoDB. Voir la documentation des types BSON et de l'opérateur $type pour plus d'informations.

Les modèles de données qui associent un nom de champ avec différents types de données au sein d'une collection sont fortement déconseillés.

Le manque de cohérence interne complique le code de l'application et peut conduire à une complexité inutile pour les développeurs d'applications.
Voir aussi : la page Curseurs Tailable pour un exemple d'utilisation de MinKey en C++.

Mis à jour le 11 décembre 2016

L'opérateur $mul multiplie la valeur numérique d'un champ par un certain nombre. Pour la multiplication des valeurs de types numériques mixtes (entiers sur 32 bits, entiers sur 64 bits, float), les règles suivantes de conversion de type sont applicables :

  Integer 32 bits Integer 64 bits Float
Integer 32 bits Integer 32 bits ou 64 bits Integer 64 bits Float
Integer 64 bits Integer 64 bits Integer 64 bits Float
Float Float Float Float
  • Si le produit de deux entiers sur 32 bits dépasse la valeur maximale pour un entier sur 32 bits, le résultat est un entier sur 64 bits.
  • Les opérations sur des entiers de tout type dont le résultat dépasse la valeur maximale pour un entier sur 64 bits produiront une erreur.

Mis à jour le 11 décembre 2016

Les noms de collections peuvent être toute chaîne UTF-8 avec les exceptions suivantes :

  • un nom de collection doit commencer par une lettre ou un trait de soulignement ;
  • la chaîne vide ("") n'est pas un nom de collection valide ;
  • les noms de collections ne peuvent pas contenir le caractère $ (version 2.2 uniquement) ;
  • les noms de collections ne peuvent pas contenir le caractère nul: \0 ;
  • ne nommez pas une collection en utilisant le préfixe system.. MongoDB réserve ce préfixe pour les collections du système ;
  • la longueur maximale de l'espace de noms de la collection, qui comprend le nom de la base de données, le séparateur point (.) et le nom de la collection (par exemple <base de données>.<collection>), est de 120 octets. Cependant, pour une flexibilité maximale, les collections doivent avoir des noms de moins de 80 caractères.

Si votre nom de collection inclut des caractères spéciaux, tels que le caractère de soulignement, pour accéder à la collection, utilisez la méthode db.getCollection() ou une méthode similaire pour votre pilote.

Exemple

Pour créer une collection _foo et y insérer le document { a : 1 }, utilisez l'opération suivante :

Code javascript : Sélectionner tout
db.getCollection("_foo").insert( { a : 1 } )
Pour exécuter une requête, utilisez la méthode find() comme suit :

Code javascript : Sélectionner tout
db.getCollection("_foo").find()

Mis à jour le 11 décembre 2016

Les curseurs MongoDB peuvent retourner le même document plus d'une fois dans certaines situations. [3] Vous pouvez utiliser la méthode snapshot() sur un curseur pour isoler l'opération pour un cas très particulier.

snapshot() traverse l'index sur le champ _id et garantit que la requête retournera chaque document (par rapport à la valeur du champ _id) une seule fois. [4]

snapshot() ne garantit pas que les données renvoyées par la requête refléteront un seul moment dans le temps et ne fournit pas un isolement pour les opérations d'insertion ou de suppression.

Comme une autre solution, si votre collection a un ou plusieurs champs qui ne sont jamais modifiés, vous pouvez utiliser un index unique sur ce ou ces champs pour atteindre un résultat similaire à celui de snapshot(). Utilisez hint() pour forcer explicitement la requête à utiliser cet indice.

[3] Lorsqu'un curseur retourne des documents, d'autres opérations peuvent interférer avec la requête : si certaines de ces opérations sont des update qui causent le déplacement du document (dans le cas d'un balayage de table, causé par la croissance de document) ou modifient le champ indexé sur l'indice utilisé par la requête, alors le curseur retournera le même document plus d'une fois.

[4] MongoDB ne permet pas la modification de la valeur du champ _id ; il est impossible pour un curseur qui traverse cet indice de retourner le même document plus d'une fois.

Mis à jour le 11 décembre 2016

Lors de la modélisation des données dans MongoDB, l'imbrication est souvent le choix parce que :

  • « contient » des relations entre les entités ;
  • dans les relations one-to-many, les objets « many » apparaissent toujours avec, ou sont considérés dans le contexte de leurs parents.

Vous devriez également envisager l'imbrication pour des raisons de performances si vous avez une collection avec un grand nombre de petits documents. Néanmoins, si petits, des documents distincts représentent le modèle naturel pour les données, alors vous devez maintenir ce modèle.

Si, cependant, vous pouvez regrouper ces petits documents par une certaine relation logique et que vous récupérez fréquemment les documents grâce à ce groupement, vous pourriez envisager de « enrouler » les petits documents en documents plus volumineux qui contiennent un tableau de documents imbriqués. Gardez à l'esprit que si vous avez souvent besoin de récupérer une partie des documents au sein du groupe, « l'enroulement » des documents pourrait ne pas fournir de meilleures performances.

« Enrouler » ces petits documents en groupes logiques signifie que les requêtes pour récupérer un groupe de documents impliquent des lectures séquentielles et moins d'accès disque aléatoires.

En outre, « l'enroulement » des documents et le déplacement des champs communs vers des documents plus volumineux tirent profit de l'index sur ces champs. Il y aurait moins de copies des champs communs et il y aurait moins d'entrées clés associées à l'indice correspondant. Voir Conception des index pour plus d'informations sur les indices.

Mis à jour le 11 décembre 2016

Commencez par lire les documents dans la section sur la modélisation des données. Ces documents contiennent une introduction de haut niveau à des considérations de modélisation de données en plus des exemples pratiques de modèles de données ciblés sur des problèmes particuliers.

En outre, tenez compte des ressources externes suivantes, qui fournissent d'autres exemples :

Mis à jour le 11 décembre 2016

Modifié dans la version 3.0.0.

Une mise à jour peut provoquer le déplacement d'un document sur le disque si le document croît en taille. Pour minimiser les mouvements de documents, MongoDB utilise le padding.

Vous ne devriez pas devoir augmenter la taille manuellement, car par défaut, MongoDB utilise les allocations dimensionnées par des puissances de 2 pour ajouter de l'augmentation automatique. Les allocations dimensionnées par des puissances de 2 assurent que MongoDB alloue au document de l'espace dont la taille est une puissance de 2, ce qui permet de garantir que MongoDB peut réutiliser efficacement l'espace libre créé par la suppression ou le déplacement du document, ainsi que de réduire les occurrences de réaffectation dans de nombreux cas.

Toutefois, si vous devez augmenter manuellement la taille d'un document, vous pouvez lui ajouter un champ temporaire, puis $unset le champ, comme dans l'exemple suivant.

Ne pas augmenter manuellement la taille des documents dans une collection à taille fixe. L'application du remplissage manuel à un document dans une collection à taille fixe peut interrompre la réplication. En outre, le remplissage n'est pas conservé si vous resynchronisez l'instance MongoDB.
Code javascript : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
var myTempPadding = [ "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 
                      "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 
                      "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 
                      "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"]; 
  
db.myCollection.insert( { _id: 5, paddingField: myTempPadding } ); 
  
db.myCollection.update( { _id: 5 }, 
                        { $unset: { paddingField: "" } } 
                      ) 
  
db.myCollection.update( { _id: 5 }, 
                        { $set: { realField: "Some text that I might have needed padding for" } }
Voir aussi Stratégies d'allocation d'enregistrements.

Mis à jour le 11 décembre 2016

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire suivant
 

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2020 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.