Cos’è MongoDB? Caratteristiche, modello a documenti e quando usarlo

MongoDB è un database che memorizza i dati come documenti piuttosto che organizzarli principalmente in tabelle relazionali. Consideralo per dati comunemente letti insieme, come cataloghi di prodotti con attributi variabili o profili utente nidificati, pur progettando comunque lo schema e verificando le prestazioni.

Questa guida spiega il modello di archiviazione di MongoDB, le funzionalità, i casi d'uso e i criteri di adozione. Per avere una panoramica più ampia, vedi il confronto tra modelli NoSQL e database relazionali.

Come memorizza i dati MongoDB?

Un documento è costituito da coppie campo-valore. Una raccolta è un raggruppamento logico di documenti e un database può contenere raccolte per scopi diversi, come prodotti, ordini e clienti.

MongoDB memorizza i documenti come BSON (Binary JSON). BSON esprime strutture JSON (JavaScript Object Notation) in forma binaria e supporta tipi aggiuntivi, inclusi date e valori ObjectId. MongoDB non dovrebbe quindi essere inteso come un archivio che semplicemente salva file di testo JSON. Il riferimento sui documenti spiega i tipi e le regole degli identificatori.

Questo prodotto JSON fittizio illustra la forma di un documento. In una collezione standard, _id identifica un documento. L'esempio utilizza una stringa leggibile; un'applicazione ha ancora bisogno di un formato identificativo e di regole per la gestione dei duplicati.

{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}

attributes è un oggetto annidato e tags è un array. I libri possono avere campi autore e pagine mentre l'elettronica ha informazioni sulla batteria. Conserva le regole comuni per i tipi di prezzo, i campi obbligatori e i valori mancanti.

Caratteristiche principali e le loro condizioni

Schema flessibile e convalida

Uno schema definisce campi, tipi e condizioni obbligatorie. MongoDB non richiede che ogni documento in una raccolta abbia campi identici per impostazione predefinita. Questa flessibilità non elimina la progettazione dello schema.

La convalida dello schema può limitare i tipi consentiti e gli intervalli di valori. Coordinare i controlli dell'applicazione e la convalida del database per evitare prezzi misti numeri/stringa o rappresentazioni di date incoerenti. Prima di aggiungere regole ai dati esistenti, identificare i documenti non conformi e decidere come gestire gli aggiornamenti.

Query, aggregazione e dati correlati

Le query MongoDB utilizzano condizioni sui campi e operatori invece di accettare istruzioni SQL senza modifiche. Impara la sintassi utilizzata dal driver del tuo linguaggio o dalla shell. La notazione puntata accede ai campi annidati e le query possono anche esprimere condizioni sugli array.

Una pipeline di aggregazione elabora i documenti attraverso fasi come filtraggio, raggruppamento e calcolo. Ad esempio, filtra gli articoli dell'ordine non cancellati e calcola le quantità totali per prodotto. La guida sulle pipeline di aggregazione spiega come funzionano le fasi.

$lookup fornisce una join esterna sinistra con un'altra collection, quindi "MongoDB non ha join" è inaccurato. Consulta supporto e condizioni di performance di $lookup. Non assumere che i riferimenti ricevano automaticamente l'applicazione dell'integrità referenziale associata ai vincoli di chiave esterna relazionali.

Indici e prestazioni

Un indice è una struttura dati che può ridurre i dati esaminati per trovare documenti corrispondenti. Indici su singolo campo e composti servono a modelli di accesso diversi. La documentazione sugli indici spiega sia i benefici delle query sia i costi di scrittura.

Più indici richiedono spazio di archiviazione e lavoro per mantenerli durante le scritture. Le prestazioni dipendono anche dalle dimensioni dei documenti, dal mix letture/scritture, dalla memoria, dai dischi e dalla rete. Valuta query rappresentative usando piani di esecuzione e carico realistico invece di assumere che NoSQL sia intrinsecamente veloce.

Transazioni e garanzie di lettura/scrittura

Un aggiornamento su un singolo documento è atomico: non applica parzialmente quell'aggiornamento. Per modifiche che devono riuscire o fallire insieme su più documenti, considera le transazioni multi-documento su set di repliche o cluster sharded. Non presumere che la stessa capacità esista su un server standalone.

ACID significa Atomicità, Coerenza, Isolamento e Durabilità. Rivedi le condizioni di deployment e configurazione nella documentazione transazioni. Quando la creazione di ordini e la riduzione dell'inventario influenzano documenti separati, definisci i confini della transazione, la gestione delle richieste concorrenti e il comportamento di retry.

Il parametro read concern controlla lo stato dei dati che una lettura può osservare, mentre il parametro write concern controlla il livello di conferma per una scrittura. Stabilire le garanzie necessarie prima di dire a un utente che un pagamento è completato e distinguere le operazioni che possono accettare valori più vecchi dalle repliche.

I dati correlati devono essere incorporati o referenziati?

L’incorporazione mette i dati correlati all’interno di un documento. Il riferimento crea un collegamento all’identificatore di un altro documento. La guida alla modellazione raccomanda di memorizzare insieme ciò che viene accessato insieme; la guida incorporazione-contro-riferimenti spiega i compromessi per le relazioni e gli aggiornamenti.

Copiare un indirizzo di consegna in un ordine può preservarne il significato storico. Copiare i dettagli di contatto attuali di un cliente in ogni ordine crea copie da mantenere quando tali dettagli cambiano. Distingui prima i fatti storici dai valori che devono essere sempre aggiornati.

Un documento BSON regolare ha una dimensione massima di 16 mebibyte (MiB). Aggiungere ogni commento o voce di registro a un singolo array può incontrare tale limite e aumentare i costi di aggiornamento. Usa collezioni separate, riferimenti o gruppi limitati tenendo presente il limite dimensione del documento .

Quali casi d'uso meritano considerazione?

Questi sono motivi per valutare un modello di documenti, piuttosto che garanzie basate su etichette del settore. Le letture e gli aggiornamenti effettivi dovrebbero guidare la scelta.

Confrontare anche le basi di dati relazionali quando reportistica flessibile tra tabelle, relazioni condivise e vincoli, o aggiornamenti complessi molti-a-molti sono requisiti centrali. Memorizzare solo JSON non giustifica la sostituzione di un database esistente. Verificare se un modello a documenti migliora le query importanti e il carico operativo.

Un piccolo esempio di inserimento e query

I seguenti comandi utilizzano MongoDB Shell, mongosh. Collegati prima a un'installazione di pratica separata, utilizzando un account con permessi di lettura, scrittura e creazione di indici per il database di destinazione e una shell installata. Consultare la documentazione di MongoDB Shell per le istruzioni di connessione.

L'esempio inserisce un prodotto in product_catalog nel database mongodb_intro_demo. Inizia con una raccolta vuota con questo nome in un ambiente di pratica e verifica che la tua connessione punti a quell'ambiente prima di eseguire i comandi.

db = db.getSiblingDB("mongodb_intro_demo");

db.product_catalog.insertMany([
{
  "_id": "book-101",
  "name": "Database Basics",
  "category": "books",
  "price_krw": 24000,
  "attributes": {
    "author": "Mina Kim",
    "pages": 320
  },
  "tags": [
    "database",
    "beginner"
  ]
}
]);

insertMany() inserisce documenti. Ripetere lo stesso _id in una raccolta standard produce un errore di chiave duplicata. Per le esercitazioni ripetute, usa un nuovo database di pratica o identifica ed elabora esplicitamente solo il documento di esempio che hai aggiunto. Non eliminare una raccolta esistente per risolvere quell'errore.

Questa query trova i prodotti in books con prezzo inferiore a 30.000 won coreani, restituisce i loro identificatori, nomi e prezzi, e ordina per prezzo crescente. Con presenti solo i dati di esempio, book-101 soddisfa le condizioni.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } },
  { _id: 1, name: 1, price_krw: 1 }
).sort({ price_krw: 1 });

$lt significa “inferiore a.” Il secondo oggetto specifica i campi restituiti, una proiezione, e 1 in sort() significa ordine crescente. Il riferimento find() spiega filtri e proiezioni.

Per filtri di prezzo frequenti specifici per categoria e ordinamenti, considera questo indice composto. Esamina la distribuzione effettiva e altre query prima di applicare createIndex() in produzione.

db.product_catalog.createIndex(
  { category: 1, price_krw: 1 }
);

Il comando seguente esegue la query e riporta le statistiche di esecuzione senza modificare i documenti. Nei risultati explain("executionStats"), controlla il piano scelto, le chiavi e i documenti esaminati e i documenti restituiti. Una collezione piccola può utilizzare una scansione della collezione; la semplice creazione di un indice non dimostra un miglioramento della velocità.

db.product_catalog.find(
  { category: "books", price_krw: { $lt: 30000 } }
).sort({ price_krw: 1 }).explain("executionStats");

La replica e lo sharding hanno compiti diversi

Un set di replica è un gruppo di server che mantengono gli stessi dati. Tipicamente, un primario accetta scritture e i secondari replicano le modifiche; i membri idonei possono eleggere un nuovo primario dopo un guasto. La guida alla replica spiega le elezioni e la replica asincrona.

Il failover può provocare ritardi o errori temporanei nelle scritture, e le letture dai secondari possono riflettere il ritardo della replica. La replica non garantisce incondizionatamente un servizio ininterrotto né previene ogni perdita di dati. Progetta ritentativi, gestione delle richieste duplicate e garanzie di lettura/scrittura necessarie insieme all'applicazione.

Lo sharding distribuisce i dati tra i server per la scalabilità orizzontale. Una chiave di shard contiene i campi utilizzati per la distribuzione e il routing delle query. Chiavi concentrate o query che devono visitare ogni shard possono limitare il vantaggio. La guida sharding spiega la selezione delle chiavi e la complessità operativa.

Replica e sharding possono essere utilizzati insieme, ma servono a scopi diversi. Controlla il modello, gli indici e i colli di bottiglia attuali prima di introdurre lo sharding semplicemente perché i dati potrebbero crescere. Dovrebbe esserci una ragione per accettarne la complessità e il costo aggiuntivi.

Cosa dovresti controllare prima di adottare MongoDB?

1. Definisci le operazioni importanti. Specifica filtri, ordinamento e unità di aggiornamento per i dettagli del prodotto, le ricerche dei prezzi delle categorie e la creazione degli ordini; confronta le implementazioni relazionali e documentali effettive.
2. Rivedi il modello e la correttezza. Decidi tra embedding o riferimenti, dimensione del documento, validazione, indici, transazioni e requisiti di lettura immediata.
3. Confronta il carico rappresentativo. Misura latenza, throughput ed errori con dati realistici e distribuzione delle richieste. Registra versioni, hardware e impostazioni, ed esamina scenari di guasto e recupero.
4. Scegli un modello operativo. Decidi tra autogestione e servizio gestito, assegnando responsabilità per backup, ripristino, monitoraggio, aggiornamenti e supporto.
5. Prepara la migrazione e un percorso di ritorno. Definisci conversioni di identificatori/tipi, controlli dei dati mancanti, scritture durante il cutover e condizioni per tornare all’archivio esistente.

MongoDB Atlas è un servizio cloud gestito con una diversa divisione delle responsabilità operative rispetto a una distribuzione autogestita. Usa la documentazione di Atlas per verificare le funzionalità e le opzioni di distribuzione necessarie. Includi lo storage, i backup, le reti e il lavoro operativo insieme ai costi delle istanze.

In produzione, verifica account con privilegi minimi, connessioni cifrate, restrizioni di rete e gestione delle credenziali seguendo le indicazioni di sicurezza di MongoDB adatte alla tua distribuzione. Una cancellazione accidentale può propagarsi alle repliche, quindi la replica non sostituisce il backup. Segui le indicazioni sui metodi di backup e verifica che il ripristino funzioni davvero.