FAQ MongoDBConsultez toutes les FAQ

Modifié dans la version 3.0.

MongoDB permet à plusieurs clients de lire et écrire les mêmes données. Dans un souci de cohérence, elle utilise le verrouillage et d'autres mesures de contrôle de concurrence pour prévenir plusieurs clients de modifier le même fragment de données simultanément. Ensemble, ces mécanismes garantissent que toutes les écritures dans un document unique se produisent soit en totalité, soit pas du tout et que les clients n'obtiennent jamais une vue incohérente des données.

MongoDB utilise des verrous de lecture-écriture qui permettent aux lecteurs simultanés l'accès partagé à une ressource, comme une base de données ou une collection, mais donnent un accès exclusif à une seule opération d'écriture.

MongoDB utilise le verrouillage multigranularité [1], qui permet aux opérations un verrouillage global de la base de données ou de la collection et permet aux moteurs de stockage individuels de mettre en œuvre leur propre contrôle de concurrence en dessous de la collection (par exemple, au niveau du document dans WiredTiger).

En plus d'un mode de verrouillage partagé, shared, (S) pour les lectures et un mode de verrouillage exclusif, exclusive, (X) pour les opérations d'écriture, les modes de verrouillage intention partagée, intent shared, (IS) et intention exclusive, intent exclusive, (IX) indiquent une intention de lire ou d'écrire une ressource en utilisant un verrou de granularité plus fine. Lors du verrouillage à une certaine granularité, tous les niveaux supérieurs sont verrouillés à l'aide d'un verrou d'intention.

Par exemple, lors du verrouillage d'une collection pour écriture (en utilisant le mode X), tant le verrou de la base de données correspondante que le verrou global doivent être verrouillés en mode intention exclusive (IX). Une base de données unique peut être verrouillée simultanément en mode IS et IX, mais un verrou exclusif (X) ne peut pas coexister avec d'autres modes, et un verrou partagé (S) ne peut pas coexister avec les verrous intention partagée (IS).

Les verrous sont justes, avec lectures et écritures mises en file d'attente dans l'ordre. Toutefois, pour optimiser le débit, lorsqu'une demande est accordée, toutes les autres demandes compatibles seront accordées en même temps, ce qui pourrait les libérer avant une demande contradictoire. Par exemple, examinez une situation dans laquelle un verrou X vient d'être libéré et dont la file d'attente des conflits contient les éléments suivants :

IS → IS → X → X → S → IS

Dans l'ordre strict du premier entré, premier sorti (FIFO), seuls les deux premiers modes IS seraient accordés. Au lieu de cela MongoDB accorde effectivement tous les modes IS et S, et une fois tous écoulés, elle accordera X, même si de nouvelles demandes IS ou S ont été mises en attente entretemps. Comme l'accord d'un accès déplacera toujours toutes les autres demandes en tête de la file d'attente, aucune requête ne sera empêchée.

[1] Voir la page Multiple granularity locking sur Wikipédia pour plus d'informations.

Modifié dans la version 3.0.

Depuis la version 3.0, MongoDB est fournie avec le moteur de stockage WiredTiger, qui utilise le contrôle de concurrence optimiste pour la plupart des opérations de lecture et écriture. WiredTiger utilise uniquement des verrous d'intention globaux de la base de données et de la collection. Lorsque le moteur de stockage détecte des conflits entre deux opérations, on va engager un conflit d'écriture provoquant le recommencement de cette opération par MongoDB de façon transparente.

Certaines opérations globales, typiquement des opérations à courte vie impliquant de multiples bases de données, nécessitent encore un verrou global « de dimension de l'instance ». Certaines autres opérations, telles que la suppression d'une collection, nécessitent encore un verrou exclusif de la base de données.

Le moteur de stockage MMAPv1 utilise le verrouillage de la collection à partir de la série de versions 3.0, une amélioration sur les versions précédentes dans lesquelles le verrouillage de la base avait la granulation la plus fine. Les moteurs de stockage tiers peuvent soit utiliser le verrouillage de la collection, soit mettre en œuvre leur propre contrôle de concurrence plus fin.

Par exemple, si vous avez six collections dans une base de données utilisant le moteur de stockage MMAPv1 et une opération prend un verrou en écriture au niveau de la collection, les cinq autres collections sont encore disponibles pour les opérations de lecture et d'écriture. Un verrou exclusif de base de données rend l'ensemble des six collections indisponibles pour la durée de l'opération qui maintient le verrou.

Pour les rapports sur l'information concernant l'utilisation des verrous, utilisez l'une des méthodes suivantes :

• db.serverStatus() ;
• db.currentOp() ;
• mongotop ;
• mongostat, et/ou
• MongoDB Cloud Manager ou Ops Manager, une solution sur place disponible dans les paramètres entreprise avancés de MongoDB.
  

Dans certaines situations, des opérations de lecture et d'écriture peuvent céder leurs verrous.

Les opérations longues de lecture et écriture, telles que les requêtes, les mises à jour et les suppressions, le rendent dans de nombreuses conditions. Les opérations MongoDB peuvent également céder les verrous entre modifications de documents individuels lors des opérations d'écriture qui affectent plusieurs documents comme update() avec le paramètre multi.

Le moteur de stockage mmapv1 de MongoDB utilise des heuristiques basées sur son modèle d'accès pour prédire si les données se trouvent dans la mémoire physique avant d'effectuer une lecture. Si MongoDB prédit que les données ne sont pas dans la mémoire physique, une opération cédera son verrou le temps que MongoDB charge les données dans la mémoire. Une fois que les données sont disponibles dans la mémoire, l'opération reprendra le verrou pour terminer l'opération.

Pour les moteurs de stockage supportant le contrôle de concurrence au niveau du document, il n'est pas nécessaire de céder le verrou lors de l'accès au stockage, car les verrous d'intention détenus au niveau global, de base de données et de collection ne bloquent pas les autres lectures et écritures.

Modifié dans la version 2.6 : MongoDB ne cède pas de verrous lors du parcours d'un index, même si elle prévoit que l'indice n'est pas en mémoire.

Modifié dans la version 2.2.

Le tableau suivant répertorie les opérations communes de base de données et les types de verrous qu'elles utilisent.

Certaines commandes peuvent verrouiller exclusivement la base de données pour des périodes de temps prolongées. Dans certains déploiements pour de grandes bases de données, vous pouvez envisager de rendre l'instance mongodmongod hors ligne afin que les clients ne soient pas affectés. Par exemple, si un fait partie d'un replica set, rendez mongod hors ligne et laissez charger les autres membres de l'ensemble de service tandis que la maintenance est en cours.

Les opérations d'administration suivantes nécessitent un verrou exclusif (par exemple en écriture) sur la base de données pour de longues périodes :

• db.collection.createIndex(), quand on l'appelle sans définir background à true ;
• reIndex ;
• compact ;
• db.repairDatabase() ;
• db.createCollection(), lors de la création d'une collection à taille fixe très volumineuse (plusieurs gigaoctets) ;
• db.collection.validate() et
• db.copyDatabase(). Cette opération peut verrouiller toutes les bases de données. Voir : Est-ce qu'une opération MongoDB peut verrouiller plusieurs bases de données ?
  

• db.collection.dropIndex() ;
• db.getLastError() ;
• db.isMaster() ;
• rs.status() (par exemple replSetGetStatus) ;
• db.serverStatus() ;
• db.auth() et
• db.addUser().
  

Les opérations MongoDB suivantes verrouillent de multiples bases de données.

• db.copyDatabase() doit verrouiller l'entièreté de l'instance mongod en une seule fois ;
• db.repairDatabase() obtient un verrou global d'écriture et bloquera les autres opérations jusqu'à sa fin ;
• la journalisation, qui est une opération interne, verrouille toutes les bases de données pour un court intervalle. Toutes les bases de données partagent un seul journal ;
• l'authentification de l'utilisateur nécessite un verrou en lecture sur la base de données admin pour les déploiements utilisant les informations d'identification utilisateur 2.6. Pour les déploiements utilisant le schéma 2.4 pour identification de l'utilisateur, l'authentification verrouille la base de données admin, ainsi que la base de données à laquelle l'utilisateur accède.
• Toutes les écritures dans le principal d'une replica set verrouillent à la fois la base de données qui reçoit les écritures et la base de données local pour un court laps de temps. Le verrouillage de la base de données local permet à mongod d'écrire dans le oplog du principal et représente une petite partie de la durée totale de l'opération.
  

La fragmentation (sharding) améliore la concurrence par la distribution de collections sur plusieurs instances mongod, permettant aux serveurs de fractionnement (par exemple, processus mongos) d'accomplir un certain nombre d'opérations concurrentes sur différentes instances de mongod en aval.

Chaque instance mongodmongod est indépendante des autres dans le cluster fragmenté et utilise ses propres verrous. Les opérations sur une instance ne bloquent pas les opérations sur les autres.

Lors de la réplication, quand MongoDB écrit dans une collection sur le principal, MongoDB écrit aussi dans le oplog du primary, qui est une collection spéciale dans la base de données local. Par conséquent, MongoDB doit verrouiller à la fois la base de données de la collection et la base de données local. Le mongod doit verrouiller les deux bases de données en même temps pour garder la cohérence et veiller à ce que les opérations d'écriture, même avec la réplication, soient des opérations « tout ou rien ».

Lors de la réplication, MongoDB n'applique pas les écritures en série dans les secondaires. Les secondaires recueillent des entrées oplog en lots et ensuite appliquent ces lots en parallèle. Les secondaires ne permettent aucune lecture pendant les opérations d'écriture, et effectuent les opérations d'écriture dans l'ordre où elles apparaissent dans l'oplog.

MongoDB peut appliquer plusieurs écritures en parallèle sur les secondaires d'un replica set, en deux phases :

• Pendant la première phase, prefer, grâce à un verrou de lecture, le mongod assure que tous les documents concernés par les opérations sont dans la mémoire. Pendant cette phase, les autres clients peuvent exécuter des requêtes dans cette base de données.
• Un pool de threads utilisant les verrous d'écriture applique toutes les opérations d'écriture dans le lot dans le cadre d'une phase d'écriture coordonnée.
  

Modifié dans la version 2.4 : Le moteur JavaScript V8 ajouté dans la version 2.4 permet l'exécution en même temps de multiples opérations JavaScript. Avant la 2.4, un seul mongod pouvait exécuter une seule opération JavaScript à la fois.

MongoDB ne supporte pas les transactions multidocuments.

Cependant, MongoDB fournit des opérations atomiques sur un seul document. Souvent, ces opérations atomiques au niveau du document sont suffisantes pour résoudre les problèmes qui nécessiteraient des transactions ACID dans une base de données relationnelle.

Par exemple, dans MongoDB vous pouvez intégrer des données connexes dans des tableaux imbriqués ou documents imbriqués dans un seul document et mettre à jour le document entier dans une seule opération atomique. Les bases de données relationnelles peuvent représenter le même genre de données par plusieurs tables et lignes, ce qui nécessiterait un support de transaction pour mettre à jour les données de façon atomique.

Voir aussi : Atomicité et transactions.

En présence d'opérations concurrentes de lecture et d'écriture, MongoDB fournit les garanties suivantes. Ces garanties tiennent sur des systèmes configurés avec un des deux moteurs de stockage, MMAPv1 ou WiredTiger.

• Les opérations de lecture et écriture sont atomiques par rapport à un seul document et laisseront toujours le document dans un état cohérent. Cela signifie que les lecteurs ne voient jamais un document partiellement mis à jour et les indices seront toujours cohérents avec le contenu de la collection. En outre, un ensemble d'opérations de lecture et d'écriture dans un seul document est sérialisable.
• Justesse des prédicats de requête, par exemple, db.collection.find() retournera uniquement les documents correspondants et db.collection.update() écrira seulement dans les documents correspondants.
• Justesse du tri. Pour les opérations de lecture qui demandent un ordre de tri (par exemple, db.collection.find() ou db.collection.aggregate()), l'ordre de tri ne sera pas violé en raison d'écritures simultanées.
  

• Des opérations de lecture non-point-in-time. Supposons une opération de lecture qui commence la lecture des documents au temps t1. Une opération d'écriture effectue alors la mise à jour d'un document à un temps ultérieur t2. Le lecteur peut voir la version mise à jour du document et ne voit donc aucun instantané point-in-time des données.
• Opérations non sérialisables. Supposons une opération de lecture qui lit un document d1 au temps t1 et une opération d'écriture qui met à jour d1 à un temps ultérieur t3. Cela introduit une dépendance lecture-écriture de sorte que, si les opérations devaient être sérialisées, l'opération de lecture doit précéder l'opération d'écriture. Mais supposons aussi que l'opération d'écriture mette à jour le document d2 au temps t2 et l'opération de lecture lit par la suite d2 à un moment ultérieur t4. Cela introduit une dépendance lecture-écriture qui exigerait plutôt que l'opération de lecture survienne après l'opération d'écriture dans une planification sérialisable. Il y a un cycle de dépendance qui rend la sérialisation impossible.
• Les résultats supprimés. Les lectures peuvent ne pas trouver certains documents correspondants qui sont actualisés ou supprimés au cours de l'opération de lecture. Toutefois, les données qui n'ont pas été modifiées au cours de l'opération seront toujours visibles.
  

Oui, les lecteurs peuvent voir les résultats des écritures avant qu'elles soient rendues durables, indépendamment du niveau de préoccupation de l'écriture ou de la configuration de la journalisation. En conséquence, les applications peuvent observer les comportements suivants :

• MongoDB permettra à un lecteur concurrent de voir le résultat de l'opération d'écriture avant que l'écriture soit reconnue par l'application cliente. Pour plus de détails sur le moment où les écritures sont reconnues pour différents niveaux de préoccupation de l'écriture, voir Write concern ;
• Les lectures peuvent voir des données qui peuvent ensuite être annulées dans de rares cas comme une panne ou une perte de puissance des replica-set. Cela ne signifie pas que les opérations de lecture peuvent voir les documents dans un état d'écriture partielle ou autre étant incohérent.