Disklager er en kritisk ressource for ethvert skalerbart databasesystem. Ydeevnen af dine diskbaserede databaser vil afhænge af, hvordan data administreres på disken. Din MongoDB-server understøtter forskellige pluggbare lagermotorer, der håndterer lagerstyring og i første omgang gemmer alle dokumenter sekventielt. Efterhånden som databasen vokser og flere skriveoperationer kører, bliver dette sammenhængende rum fragmenteret i mindre blokke med bidder af ledig plads imellem. Den typiske løsning er at øge diskstørrelsen, men der er alternativer, der kan hjælpe dig med at genvinde den ledige plads uden at skulle skalere din diskstørrelse. En vigtig ting at være opmærksom på er MongoDB lagerstatistik og hvordan du kan komprimere eller reparere databasen for at håndtere fragmentering.

Hvor stor er din database egentlig?

Du bør altid holde øje med mængden af ledig diskplads på din produktionsserver, og du bør også være opmærksom på din databasestørrelse, når du betaler for den på en cloud-platform. MongoDB har en kommando db.stats() der kan give indsigt i lagerstatistikken for 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
}

datastørrelse

Den samlede størrelse i bytes af de ukomprimerede data opbevaret i denne database.

storageSize

Den samlede mængde diskplads allokeret til alle samlinger i databasen.

Svaret fra db.stats() er afhængig af typen af MongoDB-motor. Du kan finde din versionsafhængige beskrivelse af ovenstående metrics i MongoDB-dokumentationen.

Hvorfor den store forskel mellem storageSize og datastørrelse ? Dette skyldes fragmentering af datafiler forklaret tidligere. MongoDB forsøger at genbruge ledig plads mellem fragmenterede data, når det er muligt, og frigiver det ikke til operativsystemet. I WiredTiger kan storageSize dog være mindre end dataSize, hvis komprimering er aktiveret.

I tilfælde af at en stor del af data slettes fra en samling, og samlingen aldrig bruger den slettede plads til nye dokumenter, skal denne plads returneres til operativsystemet, så den kan bruges af dine andre databaser eller samlinger. Du skal køre en kompakt eller reparation operation for at defragmentere diskpladsen og genvinde den brugbare ledige plads.

Komprimering af MongoDB

MongoDB kompakte operation omskriver alle dokumenter og indekser i en samling til sammenhængende blokke af diskplads. Denne handling blokerer dog alle andre handlinger på databasen, som samlingen tilhører. Så for en selvstændig server anbefales det at køre den under et vedligeholdelsesvindue, og for replikasæt bør du køre den på en rullende måde for hvert shard. Det betyder, at du først skal komprimere alle sekundære og derefter til sidst de primære, så din databasetilgængelighed ikke påvirkes. Syntaksen for kommandoen er:

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

1. MMAPv1

Komprimeringsoperationen defragmenterer datafiler og indekser. Husk dog, at det ikke frigiver plads til operativsystemet. Handlingen er stadig nyttig til at defragmentere og skabe mere sammenhængende plads til genbrug af MongoDB, men den er til ingen nytte, når den ledige diskplads er meget lav.
En ekstra diskplads på op til 2 GB kræves under komprimeringen.
En databaseniveaulås holdes under komprimeringsoperationen.

2. WiredTiger

WiredTiger-motoren leverer som standard komprimering, som bruger mindre diskplads end MMAPv1.

Den kompakte proces frigiver den ledige plads til operativsystemet.
Der kræves minimalt med diskplads for at køre den kompakte operation.
WiredTiger blokerer også alle operationer på databasen, da den har brug for databaseniveaulås.

Hvis du kører WiredTiger, anbefaler vi, at du kører den kompakte operation, når lageret har nået 80 % af diskstørrelsen. Du kan gøre dette ved at udløse 'Kompakt'-handling fra vores side med detaljer.

Reparer MongoDB

MongoDB reparation operation reparerer alle fejl og uoverensstemmelser i datalagring, svarende til fcsk-kommandoen for et filsystem. Denne kommando sikrer dataintegriteten efter en uventet nedlukning eller nedbrud. Men hvis journalføring er aktiveret på serveren, er der ingen krav om reparation, da serveren bruger journalen til automatisk at komme i ren tilstand efter genstart. Hvis din database er blevet beskadiget, skal du reparere databasen ville ikke gemme de korrupte data, så det anbefales ikke at bruge denne handling til datagendannelse når du har andre muligheder.

For MMAPv1, reparer database er den eneste måde at genvinde diskplads, hvis du mener, at din database ikke er blevet beskadiget og har nok plads, der kræves af reparationsoperationen. Syntaksen for kommandoen er:

db.runCommand({repairDatabase: 1})

Denne kommando komprimerer alle samlinger i databasen og genskaber alle indekser.
Opgaven kræver ledig diskplads svarende til størrelsen af dit aktuelle datasæt plus 2 gigabyte.

Hos ScaleGrid bruger vi repairDatabasen handling for at genvinde ledig plads til MMAPv1 motorklynger.