Diagnosi e Risoluzione delle Query Lente in MongoDB: Una Guida Pratica

Le query lente in MongoDB compaiono solitamente dopo la crescita dei dati, il cambiamento dei pattern di accesso o quando un indice non corrisponde più al modo in cui l'applicazione legge i dati. Potresti notare timeout degli endpoint API, caricamento lento delle dashboard o un aumento di CPU e I/O del disco anche se il traffico sembra normale.

Usa il profiler per trovare l'operazione lenta, explain() per vedere come MongoDB la esegue e indici mirati per ridurre il lavoro che MongoDB deve svolgere.

Capire Perché le Query Diventano Lente

Prima di modificare gli indici, verifica le cause comuni:

1. Indici mancanti o inefficaci: Senza un indice utile, MongoDB potrebbe eseguire una scansione della collezione ed esaminare ogni documento.
2. Complessità della Query: Operazioni che richiedono fasi di aggregazione, ordinamenti grandi o ricerche tra collezioni possono essere intrinsecamente lente se non ottimizzate.
3. Volume di Dati: Anche le query indicizzate possono rallentare se il dataset è enorme e la query deve comunque elaborare milioni di documenti prima del filtraggio.
4. Vincoli Hardware: RAM insufficiente (che porta a un esteso swapping su disco) o I/O del disco lento possono degradare le prestazioni di tutte le operazioni.

Passo 1: Identificare le Query Lente Usando la Profilazione

Il primo passo per la risoluzione è l'identificazione. Il Profiler del Database di MongoDB registra i tempi di esecuzione delle operazioni del database, permettendoti di individuare esattamente quali query stanno causando problemi.

Abilitare e Configurare il Profiler

Il profiler opera a diversi livelli. Il livello 0 disabilita la profilazione. Il livello 1 registra le operazioni più lente della soglia configurata. Il livello 2 registra tutte le operazioni.

Per analizzare le query lente, di solito imposta il livello 1 con una soglia come 50 millisecondi:

// Passa al database che vuoi profilare
use myDatabase

// Cattura le operazioni che richiedono più di 50 millisecondi
db.setProfilingLevel(1, { slowms: 50 })

Revisione dei Risultati del Profiler

Le operazioni lente registrate sono memorizzate nella collezione system.profile. Puoi interrogare questa collezione per vedere le query lente recenti:

// Trova le operazioni che richiedono più di 50ms
db.system.profile.find({ ns: "myDatabase.myCollection", millis: { $gt: 50 } }).sort({ ts: -1 }).limit(10).pretty()

Mantieni il livello 2 solo per indagini brevi. Registra ogni operazione e può aggiungere overhead su un database di produzione occupato.

Passo 2: Analizzare l'Esecuzione della Query con explain()

Una volta identificata una query lenta, usa explain() per vedere come MongoDB la elabora.

Usare explain('executionStats')

Il livello di dettaglio executionStats fornisce l'output più completo, inclusi i tempi di esecuzione effettivi e l'utilizzo delle risorse.

Considera questa query lenta sulla collezione users:

db.users.find({ status: "active", city: "New York" }).sort({ registrationDate: -1 }).explain('executionStats')

Interpretare l'Output

I campi chiave da ispezionare nell'output di explain() sono:

Campo	Descrizione	Indicatore di Lentezza
winningPlan stages	Il piano di esecuzione scelto dall'ottimizzatore.	Cerca COLLSCAN, SORT bloccante o un indice inaspettato.
executionStats.nReturned	Il numero di documenti restituiti dall'operazione.	Un numero alto quando ci si aspettano pochi risultati indica spesso un filtraggio iniziale scarso.
executionStats.totalKeysExamined	Quante chiavi dell'indice sono state controllate.	Dovrebbe essere generalmente vicino a nReturned se un indice viene usato efficacemente.
executionStats.totalDocsExamined	Quanti documenti sono stati effettivamente recuperati dal disco/memoria.	Un numero alto suggerisce che l'indice non era abbastanza selettivo.
executionStats.executionTimeMillis	Il tempo totale impiegato per l'esecuzione.	Confrontalo con la latenza del mondo reale.

Il Segnale d'Allarme: COLLSCAN

Se il piano vincente contiene COLLSCAN, MongoDB ha scansionato la collezione. Questo di solito significa che la query ha bisogno di un indice migliore, il predicato non è selettivo o la forma della query impedisce l'uso dell'indice.

Passo 3: Implementare Strategie di Indicizzazione

Risolvere COLLSCAN di solito comporta la creazione o la modifica degli indici per corrispondere al pattern della query.

Creare Indici Composti

Per query che coinvolgono più campi, come corrispondenze di uguaglianza, filtri di intervallo o ordinamenti, è spesso necessario un indice composto. La comune linea guida ESR ordina i campi dell'indice composto mettendo prima i predicati di uguaglianza, poi i campi di ordinamento, poi i predicati di intervallo. È una linea guida, non un sostituto per i test con la tua query e i tuoi dati reali.

Scenario di Esempio: Query: db.orders.find({ status: "PENDING", customerId: 123 }).sort({ orderDate: -1 })

Basandosi su ESR, l'indice dovrebbe seguire questa struttura:

1. Predicati di uguaglianza (status, customerId)
2. Predicati di ordinamento (orderDate)

Creazione dell'Indice:

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

Questo indice permette a MongoDB di filtrare rapidamente per stato e ID cliente, e poi recuperare efficientemente i risultati già ordinati per orderDate.

Gestire le Operazioni di Ordinamento

Se explain() mostra una fase SORT bloccante dopo che molti documenti sono stati esaminati, MongoDB non ha potuto usare un indice per restituire il risultato in ordine ordinato.

Gli ordinamenti grandi possono consumare memoria e possono riversarsi su disco a seconda della versione del server e delle opzioni del comando. La soluzione migliore è di solito un indice che supporti sia il filtro che l'ordinamento.

Assicurati che i campi usati nella clausola .sort() siano presenti come elementi finali nell'indice composto appropriato.

Passo 4: Tecniche di Ottimizzazione Avanzate

Se l'indicizzazione da sola non risolve la lentezza, considera questi passaggi avanzati:

Ottimizzazione della Proiezione

Usa la proiezione, il secondo argomento in .find(), per restituire solo i campi di cui la tua applicazione ha bisogno. Questo riduce il trasferimento di rete e può abilitare una query coperta quando i campi proiettati sono nell'indice.

// Restituisce solo i campi _id, name ed email
db.users.find({ city: "Boston" }, { name: 1, email: 1, _id: 1 })

Indici Coprenti

Un indice coprente è l'obiettivo di prestazioni ultimo. Si verifica quando tutti i campi richiesti dalla query (nel filtro, nella proiezione e nell'ordinamento) sono presenti all'interno dell'indice stesso. Quando ciò accade, MongoDB non deve mai recuperare il documento effettivo (COLLSCAN è evitato e totalDocsExamined sarà 0 o molto basso).

Nell'output di explain(), un indice coprente risulta nella fase che mostra IXSCAN e totalDocsExamined pari a 0.

Revisione dell'Hardware e della Configurazione

Se totalKeysExamined e totalDocsExamined sembrano ragionevoli ma la latenza rimane alta, guarda oltre la forma della query. Controlla se il working set entra in memoria, se la latenza del disco è alta e se il server è sotto pressione di scrittura, contesa di lock o saturazione della CPU.

Conclusione

Diagnosticare le query lente di MongoDB è un ciclo: profila il carico di lavoro, spiega la query lenta, aggiungi o modifica l'indice, poi misura di nuovo. Una buona correzione riduce i documenti esaminati, rimuove scansioni di collezione evitabili o ordinamenti bloccanti e migliora il percorso di richiesta reale che i tuoi utenti percepiscono.

Checklist Azionabile:

1. Abilita temporaneamente il profiler per catturare le query lente (slowms).
2. Esegui la query problematica usando explain('executionStats').
3. Controlla la presenza di COLLSCAN o totalDocsExamined alto.
4. Crea o modifica gli indici composti basandoti sulla regola ESR per coprire filtri e ordinamenti.
5. Verifica il miglioramento rieseguendo il comando explain().