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.