Le stockage sur disque est une ressource essentielle pour tout système de base de données évolutif. Les performances de vos bases de données sur disque dépendent de la manière dont les données sont gérées sur le disque. Votre serveur MongoDB prend en charge divers moteurs de stockage enfichables qui gèrent la gestion du stockage et stockent initialement tous les documents de manière séquentielle. Au fur et à mesure que la base de données se développe et que plusieurs opérations d'écriture s'exécutent, cet espace contigu est fragmenté en blocs plus petits avec des morceaux d'espace libre entre les deux. La solution typique consiste à augmenter la taille du disque. Cependant, il existe des alternatives qui peuvent vous aider à récupérer l'espace libre sans avoir à redimensionner la taille de votre disque. Une chose importante à savoir est les statistiques de stockage MongoDB et comment vous pouvez compacter ou réparer la base de données pour gérer la fragmentation.

Quelle est la taille réelle de votre base de données ?

Vous devez toujours garder un œil sur la quantité d'espace disque disponible sur votre serveur de production, et également prudent de connaître la taille de votre base de données lorsque vous la payez sur une plate-forme cloud. MongoDB a une commande db.stats()  qui peuvent fournir des informations sur les statistiques de stockage d'une instance MongoDB.

>db.stats()
{
	"db" : "test",
	"collections" : 5,
	"views" : 0,
	"objects" : 53829,
	"avgObjSize" : 43.555,
	"dataSize" : 2344556121,
	"storageSize" :3124416336,
	"numExtents" : 0,
	"indexes" : 7,
	"indexSize" : 8096876,
	"ok" : 1
}

dataSize

La taille totale en octets des données non compressées détenues dans cette base de données.

taille de stockage

La quantité totale d'espace disque alloué à toutes les collections de la base de données.

La réponse de db.stats()  dépend du type de moteur MongoDB. Vous pouvez trouver votre description dépendante de la version des métriques ci-dessus dans la documentation MongoDB.

Pourquoi la grande différence entre storageSize et dataSize ? Cela est dû à la fragmentation des fichiers de données expliquée précédemment. MongoDB essaie de réutiliser l'espace libre entre les données fragmentées chaque fois que possible et ne le libère pas pour le système d'exploitation. Cependant, dans WiredTiger, storageSize peut être inférieur à dataSize si la compression est activée.

Dans le cas où une grande partie des données est supprimée d'une collection et que la collection n'utilise jamais l'espace supprimé pour les nouveaux documents, cet espace doit être restitué au système d'exploitation afin qu'il puisse être utilisé par vos autres bases de données ou collections. Vous devrez exécuter un compact ou réparer opération afin de défragmenter l'espace disque et de récupérer l'espace libre utilisable.

Compacter MongoDB

L'opération compacte MongoDB réécrit tous les documents et index d'une collection dans des blocs contigus d'espace disque. Cependant, cette opération bloque toutes les autres opérations sur la base de données à laquelle appartient la collection. Ainsi, pour un serveur autonome, il est recommandé de l'exécuter pendant une fenêtre de maintenance, et pour les jeux de répliques, vous devez l'exécuter de manière continue pour chaque fragment. Cela signifie compacter d'abord tous les secondaires, puis enfin le principal afin que la disponibilité de votre base de données ne soit pas affectée. La syntaxe de la commande est :

db.runCommand({compact: collection-name })

1. MMAPv1

• L'opération de compactage défragmente les fichiers de données et les index. Cependant, gardez à l'esprit qu'il ne libère pas d'espace pour le système d'exploitation. L'opération est toujours utile pour défragmenter et créer plus d'espace contigu pour réutilisation par MongoDB, mais elle n'est d'aucune utilité lorsque l'espace disque disponible est très faible.
• Un espace disque supplémentaire pouvant atteindre 2 Go est requis pendant l'opération de compactage.
• Un verrou au niveau de la base de données est maintenu pendant l'opération de compactage.

2. Tigre filaire

Le moteur WiredTiger fournit une compression par défaut qui consomme moins d'espace disque que MMAPv1.

• Le processus compact libère l'espace libre pour le système d'exploitation.
• Un espace disque minimal est requis pour exécuter l'opération de compactage.
• WiredTiger bloque également toutes les opérations sur la base de données car elle nécessite un verrouillage au niveau de la base de données.

Si vous utilisez WiredTiger, nous vous recommandons d'exécuter l'opération de compactage lorsque le stockage a atteint 80 % de la taille du disque. Vous pouvez le faire en déclenchant l'opération "Compact" à partir de notre page de détails.

Réparer MongoDB

MongoDB réparation L'opération répare toutes les erreurs et incohérences dans le stockage des données, comme la commande fcsk pour un système de fichiers. Cette commande garantit l'intégrité des données après un arrêt ou un crash inattendu. Cependant, si la journalisation est activée sur le serveur, aucune réparation n'est requise car le serveur utilise le journal pour passer automatiquement à l'état propre après le redémarrage. Si votre base de données a été corrompue, alors une base de données de réparation n'enregistrerait pas les données corrompues, il n'est donc pas recommandé d'utiliser cette opération pour la récupération de données lorsque vous avez d'autres options.

Pour MMAPv1,  réparer la base de données est le seul moyen de récupérer de l'espace disque si vous pensez que votre base de données n'a pas été corrompue et dispose de suffisamment d'espace requis par l'opération de réparation. La syntaxe de la commande est :

db.runCommand({repairDatabase: 1})

• Cette commande compacte toutes les collections de la base de données et recrée tous les index.
• La tâche nécessite un espace disque libre égal à la taille de votre ensemble de données actuel plus 2 Go.

Chez ScaleGrid, nous utilisons la repairDatabase opération pour récupérer de l'espace libre pour MMAPv1 groupes de moteurs.