L'archiviazione su disco è una risorsa fondamentale per qualsiasi sistema di database scalabile. Le prestazioni dei database basati su disco dipenderanno dalla modalità di gestione dei dati sul disco. Il tuo server MongoDB supporta vari motori di archiviazione collegabili che gestiscono la gestione dello spazio di archiviazione e inizialmente archiviano tutti i documenti in sequenza. Man mano che il database cresce e vengono eseguite più operazioni di scrittura, questo spazio contiguo viene frammentato in blocchi più piccoli con blocchi di spazio libero nel mezzo. La soluzione tipica è aumentare le dimensioni del disco, tuttavia esistono alternative che possono aiutarti a recuperare lo spazio libero senza dover ridimensionare le dimensioni del disco. Una cosa importante da tenere presente sono le statistiche di archiviazione di MongoDB e come puoi compattare o riparare il database per gestire la frammentazione.
Quanto è grande il tuo database, davvero?
Dovresti sempre tenere d'occhio la quantità di spazio libero su disco sul tuo server di produzione e anche essere prudente per conoscere le dimensioni del tuo database quando lo paghi su una piattaforma cloud. MongoDB ha un comando db.stats() in grado di fornire informazioni dettagliate sulle statistiche di archiviazione di un'istanza 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 dimensione totale in byte dei dati non compressi contenuto in questo database.
storageSize
La quantità totale di spazio su disco assegnato a tutte le raccolte nel database.
La risposta di db.stats() dipende dal tipo di motore MongoDB. Puoi trovare la tua descrizione dipendente dalla versione delle metriche di cui sopra nella documentazione di MongoDB.
Perché la grande differenza tra storageSize e dimensione dati ? Ciò è dovuto alla frammentazione dei file di dati spiegata in precedenza. MongoDB cerca di riutilizzare lo spazio libero tra i dati frammentati quando possibile e non lo rilascia al sistema operativo. Tuttavia, in WiredTiger, storageSize potrebbe essere inferiore a dataSize se la compressione è abilitata.
Nel caso in cui una grossa porzione di dati venga eliminata da una raccolta e la raccolta non utilizzi mai lo spazio eliminato per nuovi documenti, questo spazio deve essere restituito al sistema operativo in modo che possa essere utilizzato dagli altri database o raccolte. Dovrai eseguire un compatto o riparare operazione per deframmentare lo spazio su disco e recuperare lo spazio libero utilizzabile.
Compattazione di MongoDB
L'operazione compatta di MongoDB riscrive tutti i documenti e gli indici di una raccolta in blocchi contigui di spazio su disco. Tuttavia, questa operazione blocca tutte le altre operazioni sul database a cui appartiene la raccolta. Pertanto, per un server autonomo, si consiglia di eseguirlo durante una finestra di manutenzione e per i set di repliche, è necessario eseguirlo in sequenza per ogni shard. Ciò significa prima compattare tutti i secondari e poi infine il primario in modo che la disponibilità del database non ne risenta. La sintassi del comando è:
db.runCommand({compact: collection-name }) 1. MMAPv1
- L'operazione di compattazione deframmenta i file di dati e gli indici. Tuttavia, continua a ricordare che non rilascia spazio al sistema operativo. L'operazione è comunque utile per deframmentare e creare più spazio contiguo per il riutilizzo da parte di MongoDB, ma è inutile quando lo spazio libero su disco è molto basso.
- Durante l'operazione di compattazione è necessario uno spazio su disco aggiuntivo fino a 2 GB.
- Durante l'operazione di compattazione viene mantenuto un blocco a livello di database.
2. WiredTiger
Il motore WiredTiger fornisce compressione per impostazione predefinita che consuma meno spazio su disco rispetto a MMAPv1.
- Il processo compatto rilascia lo spazio libero al sistema operativo.
- È richiesto uno spazio su disco minimo per eseguire l'operazione compatta.
- WiredTiger blocca anche tutte le operazioni sul database poiché necessita di un blocco a livello di database.
Se stai utilizzando WiredTiger, ti consigliamo di eseguire l'operazione compatta quando lo spazio di archiviazione ha raggiunto l'80% delle dimensioni del disco. Puoi farlo attivando l'operazione "Compatta" dalla nostra pagina dei dettagli.
Ripara MongoDB
MongoDB riparare l'operazione ripara tutti gli errori e le incoerenze nell'archiviazione dei dati, in modo simile al comando fcsk per un file system. Questo comando garantisce l'integrità dei dati dopo un arresto imprevisto o un arresto anomalo. Tuttavia, se l'inserimento nel journal è abilitato sul server, non è necessaria alcuna riparazione poiché il server utilizza il journal per entrare automaticamente nello stato pulito dopo il riavvio. Se il tuo database è stato danneggiato, ripara il database non salverebbe i dati corrotti, quindi non è consigliabile utilizzare questa operazione per il recupero dei dati quando hai altre opzioni.
Per MMAPv1, ripara il database è l'unico modo per recuperare spazio su disco se si ritiene che il database non sia stato danneggiato e disponga di spazio sufficiente per l'operazione di riparazione. La sintassi del comando è:
db.runCommand({repairDatabase: 1}) - Questo comando compatta tutte le raccolte nel database e ricrea tutti gli indici.
- Il lavoro richiede spazio libero su disco pari alla dimensione del tuo set di dati corrente più 2 gigabyte.
In ScaleGrid, utilizziamo il repairDatabase operazione per recuperare spazio libero per MMAPv1 gruppi motore.
