Best practice per la gestione e la riduzione dello spazio su disco di MongoDB

MongoDB, un popolare database documentale NoSQL, è rinomato per la sua flessibilità e scalabilità. Tuttavia, senza una gestione proattiva, l'utilizzo dello spazio su disco può crescere rapidamente, portando a un degrado delle prestazioni, interruzioni del sistema e aumento dei costi infrastrutturali. Comprendere come MongoDB consuma spazio su disco e implementare strategie di gestione efficaci sono fondamentali per mantenere un ambiente di database sano ed efficiente.

Questo articolo approfondisce strategie complete per la gestione e la riduzione dello spazio su disco di MongoDB. Esploreremo tecniche pratiche come la compattazione delle collezioni, l'ottimizzazione e la gestione degli indici di grandi dimensioni, la configurazione delle impostazioni del motore di archiviazione per l'efficienza e l'implementazione di criteri per il ciclo di vita dei dati. Seguendo queste best practice, è possibile prevenire una crescita inutile del disco, garantire operazioni stabili e prolungare la durata delle implementazioni di MongoDB.

Comprendere il consumo di spazio su disco di MongoDB

MongoDB utilizza lo spazio su disco per diversi componenti:

File di dati: Memorizzano i documenti BSON effettivi all'interno delle collezioni.
File di indice: Memorizzano gli indici B-tree creati per supportare un'esecuzione efficiente delle query.
File di Journal (WiredTiger): Registrano le operazioni di scrittura prima che vengano applicate ai file di dati, garantendo la durabilità dei dati. Questi sono preallocati.
Oplog (Registro Operativo): Una speciale collezione capped nei set di repliche che registra tutte le operazioni di scrittura. Essenziale per la replica.
Dati diagnostici: Log, file di processo mongod e altre informazioni relative al sistema.

Nel tempo, a causa di aggiornamenti, eliminazioni e crescita dei documenti (padding), le collezioni e gli indici possono frammentarsi o contenere spazio allocato inutilizzato, portando a un utilizzo inefficiente del disco. Questo "spazio bianco" non viene immediatamente recuperato dal sistema operativo, anche se il database non ne ha più bisogno per i dati attivi.

Strategie per la riduzione dello spazio su disco di MongoDB

1. Compattazione di collezioni e indici

Le operazioni di compattazione aiutano a recuperare lo spazio su disco inutilizzato riscrivendo i file di dati e di indice in modo più efficiente. Questo può essere particolarmente utile dopo eliminazioni o aggiornamenti significativi dei dati.

Compattazione delle collezioni

Con il motore di archiviazione WiredTiger (predefinito da MongoDB 3.2), compact recupera principalmente lo spazio libero dai documenti eliminati e deframmenta le collezioni. Non ricostruisce il file di dati della collezione da zero come faceva l'operazione compact di MMAPv1.

db.runCommand({ compact: "myCollection" })

Considerazioni per compact:

Le operazioni compact possono richiedere molte risorse (CPU, I/O) e richiedere molto tempo, specialmente per collezioni di grandi dimensioni. È spesso meglio eseguirle durante le finestre di manutenzione o sui membri secondari di un set di repliche.
Richiede spazio su disco libero pari alla dimensione della collezione in fase di compattazione, poiché ricostruisce i dati in una nuova posizione prima di scambiarli.
Per i cluster sharded, eseguire compact su ogni shard in modo indipendente.

Ricostruzione degli indici

Anche gli indici possono frammentarsi. La ricostruzione di un indice può recuperare spazio e potenzialmente migliorare le prestazioni delle query.

db.myCollection.reIndex()

Considerazioni su reIndex():

reIndex() è un'operazione online da MongoDB 4.2 (richiede spazio su disco sufficiente per il nuovo indice). Per le versioni precedenti alla 4.2, applica un blocco di scrittura al database (non solo alla collezione), bloccando tutte le altre operazioni. Si consiglia di eseguire prima reIndex() sui membri secondari e poi effettuare il step down del primario per eseguirlo sul nuovo primario.
Simile a compact, reIndex() richiede spazio su disco aggiuntivo durante l'operazione.

`repairDatabase` (Operazione offline)

In caso di grave frammentazione o corruzione dei dati, repairDatabase può ricostruire tutti i file di dati. Si tratta di un'operazione offline e richiede l'arresto dell'istanza mongod.

mongod --repair

Attenzione: repairDatabase dovrebbe essere utilizzato come ultima risorsa per il recupero dello spazio poiché è un'operazione distruttiva se non gestita con attenzione e può richiedere molto tempo. Avere sempre un backup.

2. Ottimizzazione degli indici

Gli indici sono fondamentali per le prestazioni ma possono consumare una notevole quantità di spazio su disco. Gli indici inutilizzati o ridondanti sono un puro sovraccarico.

Identificazione ed eliminazione degli indici non necessari

Rivedere regolarmente gli indici per assicurarsi che siano ancora necessari.

Elencare tutti gli indici per una collezione:
javascript db.myCollection.getIndexes()
Monitorare l'utilizzo degli indici: Abilitare la profilazione del database (db.setProfilingLevel(1)) o utilizzare db.collection.stats() per visualizzare l'utilizzo degli indici. Gli strumenti di monitoraggio cloud spesso forniscono informazioni sull'utilizzo degli indici.
Identificare indici duplicati o ridondanti: Ad esempio, un indice su { a: 1, b: 1 } rende superfluo un indice su { a: 1 } per le query che possono utilizzare l'indice composto. Un indice su { a: 1, b: 1 } è anche coperto da un indice su { a: 1, b: 1, c: 1 } per le query che coinvolgono solo a e b.

Una volta identificato, eliminare l'indice non utilizzato:

db.myCollection.dropIndex("indexName")

Suggerimento: Testare sempre l'impatto dell'eliminazione di un indice in un ambiente di staging prima di applicarlo alla produzione.

Utilizzo di indici parziali

Gli indici parziali indicizzano solo i documenti in una collezione che soddisfano un'espressione di filtro specificata. Ciò riduce il numero di documenti indicizzati, risparmiando spazio su disco e migliorando le prestazioni di scrittura.

db.orders.createIndex(
   { customerId: 1, orderDate: -1 },
   { partialFilterExpression: { status: "active" } }
)

Questo indice includerebbe solo i documenti in cui status è "active", riducendone drasticamente le dimensioni se la maggior parte degli ordini è "