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.


SommaireStockage MongoDBLe moteur de stockage MMAPv1Pourquoi les fichiers dans mon répertoire de données sont-ils plus grands que les données dans ma base de données ? (11)
précédent sommaire suivant
 

Les fichiers de données dans votre répertoire de données, qui est le répertoire /data/db dans les configurations par défaut, pourraient être plus grands que l'ensemble de données inséré dans la base de données. Considérez les causes possibles suivantes :

Mis à jour le 11 décembre 2016

MongoDB préalloue ses fichiers de données afin d'éviter la fragmentation, et de ce fait la taille de ces fichiers ne reflète pas nécessairement la taille de vos données.

L'option storage.mmapv1.smallFiles permettra de réduire la taille de ces fichiers, ce qui peut être utile si vous avez beaucoup de petites bases de données sur le disque.

Mis à jour le 11 décembre 2016

Si cette mongod est un membre d'un replica set, le répertoire de données inclut le fichier oplog.rs, qui est une collection de taille limitée préallouée dans la base de données local.

L'allocation par défaut est d'environ 5 % de l'espace disque sur les installations 64 bits. Dans la plupart des cas, vous ne devriez pas avoir besoin de redimensionner l'oplog. Voir Dimensionnement de l'oplog pour plus d'informations.

Mis à jour le 11 décembre 2016

Le répertoire de données contient les fichiers journal, qui stockent les opérations d'écriture sur le disque avant que MongoDB les applique aux bases de données. Voir Mécanique de journalisation.

Mis à jour le 11 décembre 2016

MongoDB maintient des listes d'enregistrements vides dans les fichiers de données lorsqu'elle supprime des documents et des collections. MongoDB peut réutiliser cet espace, mais ne cédera pas, par défaut, cet espace au système d'exploitation.

Pour permettre à MongoDB de réutiliser plus efficacement l'espace, vous pouvez défragmenter vos données. Pour ce faire, utilisez la commande compact, qui nécessite jusqu'à 2 gigaoctets d'espace supplémentaire sur le disque pour fonctionner. N'utilisez pas compact si vous disposez de très peu d'espace disque. Pour plus d'informations sur son comportement et d'autres considérations, voir compact.

compact ne fait que supprimer la fragmentation de fichiers de données MongoDB au sein d'une collection et ne retourne pas d'espace disque au système d'exploitation. Pour récupérer de l'espace disque pour le système d'exploitation, voir Comment puis-je récupérer l'espace disque ?.

Mis à jour le 11 décembre 2016

Ce qui suit fournit quelques options à considérer lors de la récupération de l'espace disque.

Vous ne devez pas récupérer de l'espace disque pour que MongoDB réutilise l'espace libéré. Voir Enregistrements vides pour plus d'informations sur la réutilisation de l'espace libéré.

Mis à jour le 11 décembre 2016

Vous pouvez utiliser repairDatabase sur une base de données pour reconstruire la base de données, défragmentant le stockage associé dans le processus.

repairDatabase nécessite de l'espace disque libre égal à la taille de votre ensemble de données actuel plus 2 gigaoctets. Si le volume qui stocke dbpath manque d'espace suffisant, vous pouvez monter un volume séparé et l'utiliser pour la réparation. Pour plus d'informations et considérations supplémentaires, voir repairDatabase.

Ne pas utiliser repairDatabase si vous disposez de très peu d'espace disque.

repairDatabase bloquera toutes les autres opérations et peut prendre beaucoup de temps.
Vous pouvez exécuter repairDatabase uniquement sur une instance autonome mongod. Si l'instance mongod est un membre d'un replica set, vous devrez sortir le noud en dehors du replica set et le redémarrer comme instance autonome pour exécuter repairDatabase.

Vous pouvez également exécuter l'opération repairDatabase pour toutes les bases de données sur le serveur en redémarrant votre instance autonome mongod avec les options --repair et --repairpath. Toutes les bases de données sur le serveur seront indisponibles pendant cette opération.

Mis à jour le 11 décembre 2016

Pour un membre secondaire d'un replica set, vous pouvez effectuer une resynchronisation de membre par : l'arrêt de la resynchronisation de l'élément secondaire, la suppression de tous les données et sous-répertoires du répertoire des données du membre et redémarrage.

Pour plus de détails, voir Resynchroniser un membre de replica set.

Mis à jour le 11 décembre 2016

Le working set représente le volume total de données que l'application utilise dans le cadre d'un fonctionnement normal. Souvent, cela est un sous-ensemble de la taille totale de données, mais la taille spécifique du working set dépend de l'utilisation réelle de la base de données d'un moment à l'autre.

Si vous exécutez une requête qui nécessite que MongoDB parcoure tous les documents d'une collection, l'ensemble de travail sera élargi pour inclure tous les documents. Selon la taille de la mémoire physique, cela peut causer l'exclusion de la pagination des documents du working set, ou leur suppression de la mémoire physique par le système d'exploitation. La prochaine fois que MongoDB aura besoin d'accéder à ces documents, MongoDB peut encourir un défaut grave de pagination.

Pour de meilleures performances, la majorité de votre ensemble actif doit pouvoir être stocké dans la RAM.

Mis à jour le 11 décembre 2016

Avec le moteur de stockage MMAPv1, les défauts de page peuvent se produire lorsque MongoDB lit ou écrit des données dans des parties de ses fichiers de données ne se trouvant pas actuellement dans la mémoire physique. En revanche, les défauts de page des systèmes d'exploitation se produisent lorsque la mémoire physique est épuisée et des pages se trouvant dans la mémoire physique sont permutées sur le disque.

S'il existe de la mémoire libre, alors le système d'exploitation peut trouver la page sur le disque et la charger directement dans la mémoire. Cependant, s'il n'y a pas de mémoire libre, le système d'exploitation doit :

  • trouver dans la mémoire une page qui est périmée ou n'est plus nécessaire et écrire la page sur le disque ;
  • lire la page demandée à partir du disque et la charger dans la mémoire.

Ce processus peut prendre un certain temps sur un système actif, en particulier en comparaison avec la lecture d'une page qui se trouve déjà en mémoire.

Voir Défauts de page pour plus d'informations.

Mis à jour le 11 décembre 2016

Les défauts de page se produisent lorsque MongoDB, avec le moteur de stockage MMAP, a besoin d'accéder à des données qui ne sont pas actuellement dans la mémoire active. Un défaut de page « grave » survient dans des situations où MongoDB doit accéder à un disque pour accéder aux données. Un défaut de page « léger », en revanche, ne fait que déplacer les pages d'une liste à l'autre en mémoire, par exemple, à partir de la cache de fichiers du système d'exploitation.

Voir Défauts de page pour plus d'informations.

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.