Schijfopslag is een kritieke bron voor elk schaalbaar databasesysteem. De prestaties van uw schijfgebaseerde databases zijn afhankelijk van hoe gegevens op de schijf worden beheerd. Uw MongoDB-server ondersteunt verschillende pluggable storage-engines die het opslagbeheer afhandelen en in eerste instantie alle documenten opeenvolgend opslaan. Naarmate de database groeit en meerdere schrijfbewerkingen worden uitgevoerd, wordt deze aaneengesloten ruimte gefragmenteerd in kleinere blokken met stukjes vrije ruimte ertussen. De standaardoplossing is om de schijfgrootte te vergroten, maar er zijn alternatieven die u kunnen helpen de vrije ruimte terug te winnen zonder dat u uw schijfgrootte hoeft te schalen. Een belangrijk ding om op te letten zijn de opslagstatistieken van MongoDB en hoe u de database kunt comprimeren of repareren om fragmentatie aan te pakken.

Hoe groot is uw database eigenlijk?

U moet altijd de hoeveelheid vrije schijfruimte op uw productieserver in de gaten houden en ook voorzichtig zijn om uw databasegrootte te kennen wanneer u ervoor betaalt op een cloudplatform. MongoDB heeft een opdracht db.stats()  die inzicht kan geven in de opslagstatistieken van een MongoDB-instantie.

>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

De totale grootte in bytes van de ongecomprimeerde gegevens bewaard in deze database.

storageSize

De totale hoeveelheid schijfruimte toegewezen aan alle collecties in de database.

Het antwoord van db.stats()  is afhankelijk van het type MongoDB-engine. U kunt uw versieafhankelijke beschrijving van de bovenstaande statistieken vinden in de MongoDB-documentatie.

Waarom het grote verschil tussen storageSize en dataSize ? Dit komt door fragmentatie van databestanden zoals eerder uitgelegd. MongoDB probeert waar mogelijk vrije ruimte tussen gefragmenteerde gegevens opnieuw te gebruiken en geeft deze niet vrij aan het besturingssysteem. In WiredTiger kan storageSize echter kleiner zijn dan dataSize als compressie is ingeschakeld.

Als een groot deel van de gegevens uit een verzameling wordt verwijderd en de verzameling nooit de verwijderde ruimte gebruikt voor nieuwe documenten, moet deze ruimte worden teruggegeven aan het besturingssysteem zodat deze door uw andere databases of verzamelingen kan worden gebruikt. U moet een compacte . uitvoeren of repareren bewerking om de schijfruimte te defragmenteren en de bruikbare vrije ruimte terug te winnen.

MongoDB comprimeren

De compacte bewerking MongoDB herschrijft alle documenten en indexen in een verzameling naar aangrenzende blokken schijfruimte. Deze bewerking blokkeert echter alle andere bewerkingen op de database waartoe de verzameling behoort. Voor een zelfstandige server is het dus aan te raden deze tijdens een onderhoudsperiode uit te voeren, en voor replicasets moet u deze voor elke shard op een rollende manier uitvoeren. Dit betekent dat eerst alle secundaire bestanden worden gecomprimeerd en vervolgens de primaire, zodat de beschikbaarheid van uw database niet wordt beïnvloed. De syntaxis van het commando is:

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

1. MMAPv1

• Verdichtingsbewerking defragmenteert gegevensbestanden en indexen. Houd er echter rekening mee dat er geen ruimte vrijkomt voor het besturingssysteem. De bewerking is nog steeds nuttig om te defragmenteren en meer aaneengesloten ruimte te creëren voor hergebruik door MongoDB, maar het heeft geen zin als de vrije schijfruimte erg laag is.
• Er is extra schijfruimte tot 2 GB nodig tijdens de verdichtingsbewerking.
• Er wordt een vergrendeling op databaseniveau vastgehouden tijdens de verdichtingsbewerking.

2. WiredTiger

De WiredTiger-engine biedt standaard compressie die minder schijfruimte in beslag neemt dan MMAPv1.

• Het compacte proces geeft de vrije ruimte vrij aan het besturingssysteem.
• Er is minimale schijfruimte nodig om de compacte bewerking uit te voeren.
• WiredTiger blokkeert ook alle bewerkingen op de database omdat deze op databaseniveau moet worden vergrendeld.

Als u WiredTiger gebruikt, raden we u aan de compacte bewerking uit te voeren wanneer de opslag 80% van de schijfgrootte heeft bereikt. U kunt dit doen door de 'Compact'-bewerking te activeren vanaf onze detailpagina.

MongoDB repareren

MongoDB reparatie bewerking herstelt alle fouten en inconsistenties in gegevensopslag, vergelijkbaar met de fcsk-opdracht voor een bestandssysteem. Deze opdracht zorgt voor de gegevensintegriteit na een onverwachte afsluiting of crash. Als het journaal echter is ingeschakeld op de server, is reparatie niet nodig, aangezien de server het journaal gebruikt om automatisch in de schone staat te komen na opnieuw opstarten. Als uw database beschadigd is, dan is een hersteldatabase zou de corrupte gegevens niet opslaan, dus het wordt niet aanbevolen om deze bewerking te gebruiken voor gegevensherstel als je andere opties hebt.

Voor MMAPv1,  reparatiedatabase is de enige manier om schijfruimte terug te winnen als u denkt dat uw database niet beschadigd is en voldoende ruimte heeft die nodig is voor de reparatie. De syntaxis van het commando is:

db.runCommand({repairDatabase: 1})

• Deze opdracht comprimeert alle collecties in de database en maakt alle indexen opnieuw.
• De taak vereist vrije schijfruimte die gelijk is aan de grootte van uw huidige dataset plus 2 gigabyte.

Bij ScaleGrid gebruiken we de repairDatabase bewerking om vrije ruimte terug te winnen voor MMAPv1 motorclusters.