Disklagring är en kritisk resurs för alla skalbara databassystem. Prestandan för dina diskbaserade databaser beror på hur data hanteras på disken. Din MongoDB-server stöder olika pluggbara lagringsmotorer som hanterar lagringshantering och initialt lagrar alla dokument sekventiellt. När databasen växer och flera skrivoperationer körs, blir detta sammanhängande utrymme fragmenterat i mindre block med bitar av ledigt utrymme däremellan. Den typiska lösningen är att öka diskstorleken, men det finns alternativ som kan hjälpa dig att återta det lediga utrymmet utan att behöva skala diskstorleken. En viktig sak att vara medveten om är MongoDB-lagringsstatistik och hur du kan komprimera eller reparera databasen för att hantera fragmentering.

Hur stor är din databas egentligen?

Du bör alltid hålla ett öga på mängden ledigt diskutrymme på din produktionsserver, och även vara klokt att känna till din databasstorlek när du betalar för den på en molnplattform. MongoDB har ett kommando db.stats()  som kan ge insikter i lagringsstatistiken för en MongoDB-instans.

>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

Den totala storleken i byte av okomprimerad data hålls i denna databas.

storageSize

Den totala mängden diskutrymme allokeras till alla samlingar i databasen.

Svaret från db.stats()  är beroende av typen av MongoDB-motor. Du kan hitta din versionsberoende beskrivning av ovanstående mätvärden i MongoDB-dokumentationen.

Varför den stora skillnaden mellan storageSize och datastorlek ? Detta beror på fragmentering av datafiler som förklarats tidigare. MongoDB försöker återanvända ledigt utrymme mellan fragmenterad data när det är möjligt och släpper det inte till operativsystemet. I WiredTiger kan dock storageSize vara mindre än dataSize om komprimering är aktiverad.

Om en stor del av data raderas från en samling och samlingen aldrig använder det borttagna utrymmet för nya dokument, måste detta utrymme returneras till operativsystemet så att det kan användas av dina andra databaser eller samlingar. Du måste köra en kompakt eller reparation operation för att defragmentera diskutrymmet och återfå det användbara lediga utrymmet.

Komprimerar MongoDB

MongoDB compact operation skriver om alla dokument och index i en samling till sammanhängande block med diskutrymme. Denna operation blockerar dock alla andra operationer på databasen som samlingen tillhör. Så för en fristående server rekommenderas det att köra den under ett underhållsfönster, och för replikuppsättningar bör du köra den på ett rullande sätt för varje skärva. Detta innebär att först komprimera alla sekundärer och sedan den primära så att din databastillgänglighet inte påverkas. Syntaxen för kommandot är:

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

1. MMAPv1

• Komprimeringsoperationen defragmenterar datafiler och index. Kom dock ihåg att det inte frigör utrymme till operativsystemet. Operationen är fortfarande användbar för att defragmentera och skapa mer sammanhängande utrymme för återanvändning av MongoDB, men den är till ingen nytta när det lediga diskutrymmet är väldigt litet.
• Ett extra diskutrymme på upp till 2 GB krävs under komprimeringen.
• Ett databasnivålås hålls under komprimeringsoperationen.

2. WiredTiger

WiredTiger-motorn tillhandahåller komprimering som standard som förbrukar mindre diskutrymme än MMAPv1.

• Den kompakta processen frigör det lediga utrymmet till operativsystemet.
• Minimalt diskutrymme krävs för att köra den kompakta operationen.
• WiredTiger blockerar också alla operationer på databasen eftersom den behöver databasnivålås.

Om du kör WiredTiger rekommenderar vi att du kör den kompakta operationen när lagringen har nått 80 % av diskstorleken. Du kan göra detta genom att aktivera "Kompakt" från vår informationssida.

Reparera MongoDB

MongoDB reparation operation reparerar alla fel och inkonsekvenser i datalagring, liknande kommandot fcsk för ett filsystem. Detta kommando säkerställer dataintegriteten efter en oväntad avstängning eller krasch. Men om journalföring är aktiverat på servern finns det inget krav på reparation eftersom servern använder journalen för att automatiskt komma in i rent tillstånd efter omstart. Om din databas har skadats, sedan en reparationsdatabas skulle inte spara korrupta data, så det rekommenderas inte att använda den här åtgärden för dataåterställning när du har andra alternativ.

För MMAPv1,  reparera databas är det enda sättet att återta diskutrymme om du tror att din databas inte har skadats och har tillräckligt med utrymme som krävs för reparationen. Syntaxen för kommandot är:

db.runCommand({repairDatabase: 1})

• Detta kommando komprimerar alla samlingar i databasen och återskapar alla index.
• Jobbet kräver ledigt diskutrymme som motsvarar storleken på din nuvarande datamängd plus 2 gigabyte.

På ScaleGrid använder vi repairDatabase operation för att återta ledigt utrymme för MMAPv1 motorkluster.