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.


SommaireConcurrence (15)
précédent sommaire suivant
 

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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


Plus précisément, le document locks dans la sortie de serverStatus, ou le champ locks dans les rapports sur l'opération courante donne un aperçu du type de verrou et la quantité de conflits de verrouillage dans votre instance mongod.

Pour mettre fin à une opération, utilisez db.killOp().

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Opération Type de verrou
Initier une requête Verrou de lecture
Obtenir plus de données d'un curseur Verrou de lecture
Insérer des données Verrou d'écriture
Supprimer des données Verrou d'écriture
Mettre à jour des données Verrou d'écriture
Map-reduce Verrou de lecture et d'écriture, sauf si les opérations sont spécifiées comme non atomiques. Des parties des jobs de map-reduce peuvent être utilisées simultanément.
Créer un index Construire un indice en premier plan, ce qui est la valeur par défaut, le verrouille la base de données pour des périodes de temps prolongées.
db.eval()
Déprécié depuis la version 3.0.
Verrou d'écriture. La méthode db.eval() prend un verrou global d'écriture pendant l'évaluation de la fonction JavaScript. Pour éviter la prise de ce verrou global, vous pouvez utiliser la commande eval avec nolock : true.
eval
Déprécié depuis la version 3.0.
Verrou d'écriture. Par défaut, la commande eval prend un verrou global d'écriture pendant l'évaluation de la fonction JavaScript. Si utilisé avec nolock: true, la commande eval ne prend pas un verrou global d'écriture pendant l'évaluation de la fonction JavaScript. Cependant, la logique à l'intérieur de la fonction JavaScript peut prendre des verrous d'écriture pour effectuer des opérations d'écriture.
aggregate() Verrou de lecture

Mis à jour le 11 décembre 2016

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 :


Les commandes d'administration suivantes verrouillent la base de données, mais gardent le verrou pour un temps très court :

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Mis à jour le 11 décembre 2016

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.

Bien que MongoDB fournisse ces fortes garanties pour les opérations sur un seul document, les opérations de lecture et écriture peuvent accéder à un nombre arbitraire de documents lors de l'exécution. Les opérations multidocuments n'ont pas lieu de façon transactionnelle et ne sont pas isolées des écritures simultanées. Cela signifie que les comportements suivants sont prévus dans le cadre du fonctionnement normal du système, pour les deux moteurs de stockage, MMAPv1 et WiredTiger :

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

Voir aussi : Atomicité et transactions.

Mis à jour le 11 décembre 2016

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.

D'autres systèmes se réfèrent à cette sémantique comme lecture non validée.

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.