MongoDB — Cheat Sheet

Tag: mongodb, nosql, aggregation, indexing, database, backend

Livello: intermedio

TL;DR: Database NoSQL orientato ai documenti JSON/BSON, ottimizzato per scalabilita' orizzontale, query su documenti annidati e pipeline di aggregazione.

Concetti chiave

Database non relazionale basato su documenti BSON organizzati in collection.

Schema flessibile e dinamico che adatta i record senza alter table preventive.

Modello dati ibrido tra embedding (annidamento) e referencing (riferimento tramite ObjectId).

Identificatore primario univoco generato automaticamente tramite il campo _id.

Supporto a indici B-tree: singoli, composti, multikey per array e text.

Aggregation framework strutturato in pipeline a stadi sequenziali ($match, $group,$project).

Replica Set per alta disponibilita' con failover automatico (primario ed eletti secondari).

Sharding per partizionamento orizzontale dei dati su grandi volumi e carichi elevati.

Transazioni multi-documento con supporto ACID disponibili a partire dalla versione 4.0.

WiredTiger come storage engine predefinito per concorrenza a livello di documento e compressione.

Domande tipiche e risposte pronte

Q: Come decidi se annidare (embed) o referenziare (reference) un documento correlato?R: Valuto il pattern di accesso e il rapporto tra entita': per relazioni 1:1 o 1:few lette sempre insieme scelgo l'embedding; per relazioni 1:many unbounded o soggette al limite di 16 MB uso il referencing con ObjectId.

Q: Come analizzi e ottimizzi una query MongoDB lenta?R: Eseguo .explain("executionStats") sulla query per verificare l'indice utilizzato; mi assicuro di evitare COLLSCAN puntando a uno scan IXSCAN coperto, con un rapporto totalDocsExamined su nReturned il piu' vicino possibile a 1.

Q: Come funziona una transazione multi-documento e quando conviene evitarla?R: Uso la sessione (startSession) per eseguire operazioni ACID atomiche su piu' collection; cerco comunque di evitarla se posso modellare i dati sfruttando l'atomicita' intrinseca sul singolo documento.

Insidie e errori comuni

Superamento del limite rigido di 16 MB per singolo documento a causa di array che crescono indefinitamente.

Mancanza di indici composti con ordine corretto secondo la regola ESR: Equality, Sort, Range.

Esecuzione di stadi $lookup non indicizzati sulla collection di destinazione, causando table scan pesanti.

Posizionamento dello stadio $match dopo un $project o $group, perdendo l'uso degli indici.

Confusione tra update parziale con operatore $set e rimpiazzo totale del documento in assenza di operatori.

Snippet e comandiJavaScript

// Query con filtro, proiezione e ordinamento
db.collection.find(
  { status: "active", age: { $gte: 18 } },
  { name: 1, email: 1, _id: 0 }
).sort({ createdAt: -1 }).limit(10);

JavaScript

// Pipeline di aggregazione con match, raggruppamento e ordinamento
db.orders.aggregate([
  { $match: { status: "completed" } },
  { $group: { _id: "$customerId", totalSpent: { $sum: "$total" }, count: { $sum: 1 } } },
  { $match: { totalSpent: { $gt: 100 } } },
  { $sort: { totalSpent: -1 } }
]);

JavaScript

// Creazione indice composto con regola ESR
db.users.createIndex({ companyId: 1, createdAt: -1, age: 1 });

JavaScript

// Analisi piano di esecuzione
db.collection.find({ email: "test@example.com" }).explain("executionStats");

Da ripassare

[ ] Regola ESR per la definizione ottimale degli indici composti

[ ] Operatori della pipeline di aggregazione ($facet, $lookup con pipeline,$unwind)

[ ] Strategie di sharding e scelta della shard key appropriata

[ ] Gestione del read concern e write concern nei Replica Set

[x] CRUD di base e atomicita' del singolo documento

Jarvis Interviews
Jarvis