Come funzionano le transazioni in MongoDB?

Question

Accepted Answer

MongoDB supporta **transazioni ACID multi-documento** (dalla v4.0 per replica set, v4.2 per cluster sharded) — raggruppando operazioni su più documenti/collezioni in modo che abbiano successo tutte o falliscano tutte. Tuttavia, il modello di documento di MongoDB spesso rende le transazioni *non necessarie* attraverso operazioni atomiche su singoli documenti.

## Le operazioni su singoli documenti sono già atomiche

```text
KEY POINT: operations on a SINGLE document are ALWAYS atomic in MongoDB.
→ Because related data is often EMBEDDED in one document, many operations that would
  need a transaction in SQL are a single atomic document update in MongoDB.
→ Good schema design (embedding) often eliminates the NEED for multi-doc transactions.
```

```js
// updating a document and its embedded array atomically — NO transaction needed
db.accounts.updateOne(
  { _id: id },
  { $inc: { balance: -100 }, $push: { transactions: { amount: -100 } } }
);  // atomic — both changes succeed or fail together (single document)
```

## Transazioni multi-documento (quando veramente necessarie)

```js
// for operations across MULTIPLE documents/collections that must be atomic
const session = db.getMongo().startSession();
session.startTransaction();
try {
  db.accounts.updateOne({ _id: 1 }, { $inc: { balance: -100 } }, { session });
  db.accounts.updateOne({ _id: 2 }, { $inc: { balance: 100 } }, { session });
  session.commitTransaction();        // both succeed together
} catch (e) {
  session.abortTransaction();          // or both roll back
} finally {
  session.endSession();
}
```

Le transazioni multi-documento (utilizzando una sessione) forniscono garanzie ACID su più documenti — per casi come i trasferimenti tra documenti di account separati.

## Usa le transazioni con parsimonia

```text
✓ Transactions are available and provide ACID across documents WHEN NEEDED
✗ But they have PERFORMANCE COSTS (overhead, locking) — don't overuse them
→ PREFER good schema design (embedding related data) so single-document atomic
  operations suffice. Use multi-document transactions only when data genuinely
  spans documents and must be consistent (e.g. money transfers between accounts).
→ Requires a replica set (not standalone).
```

## Perché è importante

Comprendere le transazioni di MongoDB — e crucialmente quando sono necessarie — è importante per garantire la coerenza dei dati nelle applicazioni MongoDB, quindi è una conoscenza preziosa per costruire sistemi corretti.

L'intuizione più importante è che **le operazioni su singoli documenti sono sempre atomiche** in MongoDB, e poiché il modello di documento incoraggia l'**incorporamento di dati correlati in un documento**, molte operazioni che richiederebbero una transazione in un database relazionale (dove i dati correlati sono divisi su tabelle) sono un **singolo aggiornamento atomico di documento** in MongoDB — quindi **un buon design dello schema elimina spesso la necessità di transazioni multi-documento**.

Questo è un punto concettuale chiave: l'atomicità per-documento di MongoDB, combinata con l'embedding, gestisce molte esigenze di coerenza senza transazioni.

Comprendere che MongoDB **supporta effettivamente transazioni ACID multi-documento** (dalla v4.0+) per casi in cui le operazioni si estendono genuinamente su più documenti/collezioni (come trasferimenti tra documenti di account separati) è importante — sono disponibili quando veramente necessarie, fornendo garanzie tutto-o-niente.

Egualmente importante è la guida a **usare le transazioni con parsimonia**: hanno costi di prestazione (overhead, locking), quindi l'approccio preferito è un buon design dello schema (embedding) così che operazioni atomiche su singoli documenti siano sufficienti, riservando le transazioni multi-documento alle esigenze genuine di coerenza tra documenti.

Comprendere questo — atomicità di singoli documenti, che l'embedding spesso rimuove la necessità di transazioni, che le transazioni multi-documento esistono per quando sono genuinamente richieste, e la preferenza del design rispetto alle transazioni — riflette un buon giudizio su MongoDB.

Poiché la coerenza dei dati è critica e l'approccio di MongoDB (atomicità di documento + transazioni opzionali) differisce dal modello incentrato sulle transazioni di SQL, comprendere le transazioni di MongoDB — specialmente che le operazioni su singoli documenti sono atomiche, l'embedding riduce la necessità di transazioni, e le transazioni multi-documento sono disponibili ma dovrebbero essere usate con giudizio — è una conoscenza preziosa e importante per garantire la coerenza corretta ed efficiente nelle applicazioni MongoDB, un argomento che riflette la comprensione del modello di coerenza di MongoDB e delle buone pratiche di design.