FAQ MongoDBConsultez toutes les FAQ

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.

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.

Oui.

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

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.

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.

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.

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.

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.

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 ?.

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.
  

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.
  

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.

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.

1
2
{ x: "string" } 
{ x: 42 }

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

• 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.
  

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)" }

	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.

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 :

	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.

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.
  

db.getCollection("_foo").insert( { a : 1 } )

db.getCollection("_foo").find()

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.

	Vous ne pouvez pas utiliser snapshot() avec des collections fragmentées. Vous ne pouvez pas utiliser snapshot() avec les méthodes curseur sort() ou hint().

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.
  

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 :

• Design du schéma par des exemples ;
• Billet de blog sur le schéma dynamique ;
• Modélisation des données MongoDB et Rails ;
• Exemple de chemins matérialisés en Ruby ;
• Le billet de blog de Sean Cribs, qui a été la source d'une grande partie du contenu des Structures de modèles d'arbres dans MongoDB.
  

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.

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" } }