Quando il COMMIT non basta più

1 · Le basi: tabelle, operazioni, confine

Un capitolo di vocabolario. Se questi termini ti sono già familiari, scorri fino al capitolo 2: ma è qui che vengono definiti, e tutto il documento li usa senza rispiegarli.

A chi si rivolge il documento

A chi scrive applicazioni che parlano con un database relazionale e vuole capire che cosa succede sotto le istruzioni che manda. Gli esempi SQL sono scritti per PostgreSQL (con confronti espliciti con MySQL/InnoDB dove il comportamento diverge); gli esempi di codice usano Java/Kotlin con JPA (Jakarta Persistence API) e Hibernate, tipicamente attraverso Spring Data. Non serve conoscere nulla di questo in anticipo: ogni concetto viene definito la prima volta che compare, e il glossario finale li raccoglie tutti.

Tabella, riga, pagina

Una tabella è un insieme di righe (o record) che hanno tutte le stesse colonne: la tabella conti ha le colonne id e saldo, e ogni riga è un conto. Fin qui è il modello logico, quello che vedi nelle query.

Il database però non memorizza le righe una per una. Le raggruppa in pagine: blocchi di dimensione fissa (8 KB in PostgreSQL, 16 KB in InnoDB) che sono l'unità minima spostata tra disco e memoria. Quando leggi una riga, il database carica l'intera pagina che la contiene; quando ne modifichi una, è la pagina intera a diventare «sporca». Questa distinzione, riga logica contro pagina fisica, tornerà nel capitolo 3.

Le quattro operazioni sui dati

Tutto ciò che un'applicazione fa su una tabella si riduce a quattro istruzioni SQL (Structured Query Language), che insieme formano il DML (Data Manipulation Language). In gergo applicativo si chiamano CRUD (Create, Read, Update, Delete).

Accanto al DML c'è il DDL (Data Definition Language): le istruzioni che non toccano i dati ma la forma delle tabelle, come CREATE TABLE, ALTER TABLE, CREATE INDEX. Li incontrerai nel capitolo 2, perché non ovunque godono delle stesse garanzie del DML.

Il confine: BEGIN, COMMIT, ROLLBACK

Una singola istruzione fa una cosa sola. Quando un'operazione ne richiede più d'una, servono tre parole che disegnano un confine intorno al gruppo.

BEGIN;
UPDATE conti SET saldo = saldo - 100 WHERE id = 'anna';
UPDATE conti SET saldo = saldo + 100 WHERE id = 'bruno';
COMMIT;        -- oppure ROLLBACK, e nessuno dei due saldi cambia

Il ROLLBACK può essere richiesto dall'applicazione, ma può anche essere deciso dal database da solo: se una UPDATE viola un vincolo (in PostgreSQL; InnoDB annulla solo l'istruzione fallita e lascia aperta la transazione) o se il processo si interrompe a metà, la transazione viene abortita e tutto ciò che aveva fatto scompare. È questo il senso in cui il confine è una garanzia, non una convenzione.

Autocommit: non esiste SQL fuori da una transazione

Domanda che vale la pena porsi esplicitamente: se non scrivo mai BEGIN, che cosa succede? Il database ne apre una implicita attorno alla singola istruzione e la committa appena finisce. È l'autocommit, il comportamento di default di JDBC e di molti driver (non di tutti: psycopg in Python, per esempio, apre una transazione implicita e aspetta il commit). Quindi non esiste SQL fuori da una transazione: quello che varia è solo se l'hai dichiarata tu.

UPDATE conto SET saldo = saldo - 10 WHERE id = 1;

-- il database esegue in realtà:
BEGIN;
UPDATE conto SET saldo = saldo - 10 WHERE id = 1;
COMMIT;

Ogni istruzione DML ha il suo confine? Quasi sempre sì

In autocommit il confine è la singola istruzione, qualunque sia la sua ampiezza: una SELECT, un INSERT, una UPDATE che tocca una riga o diecimila. Ogni istruzione apre la propria transazione e la committa appena finisce; l'istruzione successiva ne apre un'altra, nuova e indipendente.

Il database non raggruppa mai da solo due istruzioni consecutive: non ha modo di sapere che «leggi il saldo» e «aggiorna il saldo» appartengono alla stessa operazione di business, e non lo indovina.

Se le vuoi insieme, il confine lo devi dichiarare tu (o farlo dichiarare al framework: in Spring è ciò che fa @Transactional, che apre la transazione all'ingresso del metodo e la committa all'uscita).

Ci sono però tre situazioni in cui più istruzioni finiscono davvero nella stessa transazione senza che tu abbia scritto BEGIN, e conviene conoscerle perché sembrano eccezioni alla regola ma non lo sono:

• Il lavoro derivato dall'istruzione. Trigger, cascate ON DELETE CASCADE, aggiornamento degli indici, verifica dei constraint: tutto ciò che il database esegue per causa della tua istruzione sta nel suo confine (capitolo 5). Un trigger che fa dieci INSERT in un'altra tabella non apre dieci transazioni: è dentro quella dell'istruzione che l'ha scatenato. Non sono più istruzioni raggruppate: è una sola istruzione più larga di come appare.
• Funzioni e procedure. In PostgreSQL una funzione chiamata da un'istruzione (SELECT preleva(1, 10)) esegue tutte le sue istruzioni interne dentro la transazione della chiamata, perché per il database è sempre una istruzione. Le PROCEDURE (dalla versione 11) possono invece fare COMMIT al proprio interno, e spezzano il confine.
• Il driver che disattiva l'autocommit. Alcuni client (psycopg in Python, o JDBC con setAutoCommit(false)) aprono una transazione implicita alla prima istruzione e la tengono aperta finché non chiami commit(): lì le istruzioni si accumulano nella stessa transazione, ma è il driver a decidere, non il database. È la causa più comune di «transazione dimenticata aperta» (capitolo 7).

Ogni transazione ha un numero

Quando una transazione inizia a scrivere, il database le assegna un identificativo progressivo (in PostgreSQL lo leggi con SELECT pg_current_xact_id(), txid_current() prima della versione 13). Nei diagrammi di questo documento le transazioni si chiamano T1, T2, T88, T90: il numero non è decorativo. È ciò che il database scrive dentro le righe per sapere chi ha creato o cancellato ogni versione, e ciò che confronta per decidere che cosa una transazione può vedere. Il meccanismo è nel capitolo 7.

Il lock

Finché una transazione lavora da sola, non ha bisogno di nulla. Il problema nasce quando due transazioni vogliono la stessa riga nello stesso momento, e può prendere due forme:

• Due scrivono. T1 e T2 modificano entrambe il saldo del conto 1. Se le scritture si intrecciano, una copre l'altra e il valore finale non è quello che nessuna delle due voleva.
• Uno scrive, l'altro legge. T1 sta modificando il saldo e non ha ancora committato; T2 lo legge. T2 ha in mano un numero provvisorio, che T1 potrebbe ancora annullare con un ROLLBACK: un numero che forse non esisterà mai.

Notare che cosa non è un problema: due che leggono. Dieci transazioni che leggono lo stesso saldo non si disturbano in nessun modo, perché nessuna lo cambia.

Il lock è la soluzione più antica ai due problemi. L'idea: prima di toccare una riga, la transazione deve ottenere dal database un permesso su quella riga; il database tiene un registro (il lock manager) con scritto, per ogni riga in uso, chi ha il permesso e di che tipo; e se il permesso che chiedi è incompatibile con uno già concesso a qualcun altro, la tua istruzione si ferma e aspetta, senza errori, finché quell'altro non finisce e lo restituisce. Non sei tu a chiederlo: lo fa il database per conto tuo quando esegui l'istruzione.

Perché servono due tipi di permesso

Se esistesse un solo tipo di permesso, «la riga è mia», anche due lettori si farebbero aspettare a vicenda, e abbiamo appena visto che non ce n'è motivo. Per questo il permesso ha due forme, che corrispondono alle due cose che puoi voler fare:

Da queste due definizioni discendono da sole le quattro situazioni possibili quando una seconda transazione arriva su una riga che la prima sta già usando. Vediamole una per una, sempre con T1 arrivata prima e T2 dopo.

Tre cose vanno fissate subito, perché tornano nella Parte III.

• Granularità. Il permesso può riguardare una singola riga, un'intera tabella, oppure un range di valori (tutte le righe con stato = 'ATTIVO', incluse quelle che non esistono ancora). Più è fine, più transazioni possono lavorare in parallelo su righe diverse; più è grossa, meno costa gestirlo. Nei database moderni il lock di scrittura è di riga.
• Implicito o esplicito. UPDATE e DELETE prendono da soli il lock esclusivo sulle righe che toccano. Puoi anche chiederlo tu, su righe che stai solo leggendo, con SELECT … FOR UPDATE: «bloccami queste righe come se stessi per scriverle», utile quando sai che le scriverai tra poco e non vuoi che nessuno le cambi nel frattempo. Il capitolo 9 è dedicato a quando conviene.
• Durata. Un lock esclusivo si tiene fino al commit o al rollback, mai prima: rilasciarlo appena finita l'istruzione permetterebbe a un altro di leggere un valore che tu potresti ancora annullare (il caso 3 tornerebbe a essere un problema). È il motivo per cui una transazione lunga fa male a tutti gli altri: non per il lavoro che fa, ma per i lock che tiene mentre lo fa.

Il deadlock

Se T1 tiene il lock su A e aspetta B, mentre T2 tiene B e aspetta A, nessuna delle due potrà mai proseguire: è un deadlock, un'attesa circolare.

Il database non lo previene: lo rileva. Chi resta in attesa controlla se si è formato un ciclo nel grafo delle attese (PostgreSQL dopo deadlock_timeout, 1 secondo di default; InnoDB subito) e, se lo trova, il database abortisce una delle transazioni coinvolte (in PostgreSQL con l'errore 40P01 deadlock_detected), liberando l'altra. L'applicazione riceve un'eccezione e deve riprovare. La contromisura di progetto è una sola, e la vedremo nel capitolo 9: far acquisire a tutti i lock nello stesso ordine.

Lo snapshot: la risposta al difetto del lock

Torna al caso 3: T1 sta modificando il saldo, T2 vuole solo leggerlo, e deve aspettare. Ora immagina un sistema reale, dove per ogni transazione che scrive ce ne sono cento che leggono: una sola scrittura lenta mette in coda cento lettori, che a loro volta (caso 2) bloccano le scritture successive. I lettori sono la maggioranza e sono innocui, eppure sono loro a pagare di più. È il difetto strutturale dello schema a soli lock.

La soluzione dei database moderni cambia domanda. Invece di «come faccio aspettare il lettore finché il valore non è definitivo?», chiede: «e se al lettore dessi il valore precedente, quello già committato, senza farlo aspettare?». Per farlo, il database non sovrascrive la riga quando la modifica: conserva la versione vecchia accanto a quella nuova, finché serve a qualcuno.

Lo snapshot è il nome di ciò che T2 vede: una fotografia dello stato del database fatta di sole versioni committate, scattata a un certo istante. Chi lavora su uno snapshot non vede le modifiche non ancora committate degli altri (quindi il caso 3 non ha più bisogno di attesa) e non viene disturbato da ciò che gli altri committano dopo lo scatto. Questa tecnica si chiama MVCC (multiversion concurrency control, «controllo della concorrenza a più versioni») ed è quella di PostgreSQL, Oracle e MySQL/InnoDB.

Attenzione a che cosa cambia e che cosa no: lo snapshot serve ai lettori. Chi scrive continua a prendere il lock esclusivo, perché due scritture sulla stessa riga devono comunque mettersi in fila (caso 4). Ciò che sparisce è il conflitto tra chi legge e chi scrive.

E se la lettura sta nella stessa transazione della scrittura?

Domanda che sorge spontanea a questo punto: con MVCC i lettori non prendono lock, ma se la mia transazione fa SELECT e poi UPDATE sulla stessa riga, quella SELECT «eredita» il lock esclusivo? No. Il lock non è una proprietà della transazione che si spalma su tutto ciò che fa: viene preso dall'istruzione che scrive, nel momento in cui scrive, e da lì in poi tenuto fino al commit. Tutto ciò che la transazione ha letto prima resta una lettura da snapshot, senza lock, esattamente come se fosse stata fatta da una transazione di sola lettura.

Il diagramma mostra la conseguenza: la finestra tra la SELECT e l'UPDATE è scoperta anche dentro una transazione esplicita. Dichiarare BEGIN … COMMIT ti dà atomicità (o tutto o niente) e regola che cosa le tue letture vedono, ma non ti dà l'esclusività sulla riga letta.

L'UPDATE lavora sullo snapshot della SELECT? No: chi scrive non guarda lo snapshot

Vale la pena scioglierlo subito, perché è la fonte più comune di confusione su MVCC. Lo snapshot governa solo ciò che vedi quando leggi. Uno snapshot «coerente» è una fotografia in cui tutte le righe appartengono allo stesso istante: nessuna metà vecchia e metà nuova, nessun valore provvisorio di transazioni non committate.

Ma nel momento in cui un'istruzione scrive, il database mette da parte la fotografia e va a prendere la versione fisicamente corrente della riga, quella che sta in cima alla catena delle versioni: scrivere sopra una foto non avrebbe senso, perché la foto potrebbe essere già vecchia. L'UPDATE di T1, quindi, non lavora sul 100 che la SELECT aveva visto: prende il lock sulla riga, e se la trova bloccata da T2 aspetta; quando T2 committa, T1 vede che la versione corrente è 50, cioè diversa da quella del suo snapshot. Che cosa faccia a quel punto dipende dal livello di isolamento:

Se vuoi che la lettura prenda il lock esclusivo, devi chiederlo: è esattamente ciò che fa SELECT … FOR UPDATE (capitolo 9). Con quello, T2 nel diagramma si sarebbe fermata in attesa fin dalla SELECT di T1. L'alternativa è comprimere lettura e scrittura in un'unica istruzione (UPDATE saldo = saldo - 30), che prende il lock nell'istante stesso in cui legge.

Allora che relazione c'è tra transazione e lock? E a che cosa serve una transazione se leggo soltanto?

Le due domande hanno la stessa risposta, e conviene fissarla perché è facile confondersi. Il lock nasce da un'istruzione, la transazione decide quanto vive. Nessuna transazione «ha» un lock per il fatto di esistere: lo ottiene nel momento in cui una sua istruzione scrive (UPDATE, DELETE, INSERT) o lo chiede (SELECT … FOR UPDATE). Da quel momento, però, il lock non appartiene più all'istruzione, che è finita, ma alla transazione, che lo tiene fino a COMMIT o ROLLBACK. La transazione è quindi il contenitore della durata: allunga la vita del lock dall'istante della scrittura fino al confine.

Da qui la risposta alla seconda domanda. Una SELECT normale non prende lock, quindi la transazione non le dà nessuna protezione dagli scrittori: se leggi soltanto, una transazione serve a una cosa sola, la coerenza tra più letture.

• Una sola lettura. La transazione non aggiunge nulla: la singola istruzione ha già il suo snapshot coerente (mai un numero «sporco a metà») e in autocommit è già dentro una transazione implicita. Un BEGIN/COMMIT attorno a una SELECT isolata è inerte.
• Più letture che devono raccontare lo stesso istante (un report con tre SUM, una testata d'ordine più le sue righe, un export). Qui la transazione è l'unico modo per ottenerlo, ma solo a livello REPEATABLE_READ: lo snapshot viene scattato una volta all'inizio e tutte le query vedono la stessa fotografia. In READ_COMMITTED, il default, ogni istruzione scatta la propria foto anche dentro la stessa transazione, quindi il BEGIN da solo non basta: serve anche il livello (capitolo 7).
• Leggere per poi scrivere. La transazione dà atomicità alla scrittura e la lega alle letture nello stesso confine, ma non dà esclusività sulla riga letta: la finestra tra SELECT e UPDATE resta aperta, come nel diagramma sopra. Per chiuderla devi far nascere il lock dalla lettura con FOR UPDATE (capitolo 9), affidarti al 40001 di REPEATABLE_READ, oppure comprimere in un'unica UPDATE che legge e scrive nello stesso istante.

2 · Che cos'è una transazione

Il concetto arriva dalla contabilità, non dall'informatica — e il malinteso più costoso riguarda dove ne finisca il confine.

Il termine viene dalla contabilità, non dall'informatica: una transazione è uno scambio che o avviene per intero o non avviene affatto. Non esiste mezzo pagamento. I database prendono il concetto alla lettera e lo rendono una primitiva: un'unità di lavoro che porta il sistema da uno stato consistente a un altro, senza stati intermedi osservabili.

Jim Gray formalizza l'idea nel 1981 (The Transaction Concept: Virtues and Limitations). Due anni dopo Theo Härder e Andreas Reuter coniano l'acronimo che tutti conoscono, ACID. Prima di scioglierlo, però, conviene capire da quali problemi nasce: le quattro lettere non sono un elenco imparato a memoria, sono quattro risposte a quattro modi in cui un'operazione può andare male.

Da quali esigenze nasce ACID

Torniamo al bonifico del capitolo 1: togli 100 € ad Anna, aggiungi 100 € a Bruno. Sono due istruzioni, e tra la prima e la seconda passa del tempo, poco, ma non zero. Un'applicazione che facesse questo lavoro senza un database transazionale dovrebbe preoccuparsi da sola di quattro cose che possono succedere.

Sono proprietà della transazione, non del database in generale: il database è il meccanismo che le realizza, ma la cosa che viene qualificata come atomica, consistente, isolata e durevole è il gruppo di istruzioni racchiuso tra BEGIN e COMMIT. È anche ciò che distingue una transazione da una semplice sequenza di istruzioni: due UPDATE lanciate una dopo l'altra sono una sequenza; due UPDATE dentro un confine transazionale sono un'unità che gode delle quattro garanzie insieme.

Il resto di questa Parte e tutta la Parte II sono lo studio di come il database mantenga queste quattro promesse, una per una. Qui basta averle nominate per rispondere alla prima domanda.

Una singola istruzione è già una transazione

Abbiamo visto nel capitolo 1 che, grazie all'autocommit, anche un'istruzione senza BEGIN vive dentro una transazione implicita. La domanda successiva è: quanto di ACID vale su quella singola istruzione? Quasi tutto.

Istruzione SQL ≠ operazione di business

Prendiamo il prelievo di 10 € dalla colonna di destra e guardiamo dove finiscono le garanzie:

• L'atomicità c'è, ma sul pezzo sbagliato — e la transazione la sistema. La SELECT è atomica. La UPDATE è atomica. L'operazione «preleva 10 se il saldo lo consente» in autocommit non lo è: non esiste da nessuna parte nel database un confine che la racchiuda, quindi se il processo muore tra il controllo e la scrittura il DB non ha nulla da disfare, perché per lui erano due lavori distinti, entrambi conclusi correttamente. Questo problema si risolve racchiudendo i tre pezzi in BEGIN … COMMIT: da quel momento o l'intera operazione è avvenuta o nulla lo è. Ma è l'unico dei due problemi che la transazione risolve.
• L'isolamento c'è, ma non copre la finestra — e la transazione NON la chiude. La SELECT ha visto uno snapshot coerente. La UPDATE ha visto un altro snapshot coerente. In mezzo, nel tempo in cui la tua applicazione valutava l'if, chiunque poteva scrivere: l'isolamento protegge ciascuna istruzione mentre gira, non il tempo che passa tra l'una e l'altra. Nessuna delle due ha «letto un dato sporco»: hanno letto due dati puliti in due istanti diversi. E attenzione al punto che inganna: mettere SELECT, if e UPDATE nella stessa transazione non cambia nulla qui. La SELECT legge dallo snapshot senza prendere alcun lock (capitolo 1); il lock esclusivo lo prende solo l'UPDATE, nell'istante in cui scrive. Fino a quell'istante la riga è libera, dentro o fuori da BEGIN, e un'altra transazione può modificarla. La transazione ti dice che i tre pezzi falliranno o riusciranno insieme; non ti dice che nessuno si sia infilato in mezzo. Questo è il problema come causa; il punto seguente è il danno che ne deriva.

Che cosa succede, concretamente, se qualcuno scrive in quella finestra? Saldo 100, due prelievi in parallelo. Leggi il diagramma immaginando che T1 sia dentro un BEGIN … COMMIT: non cambia una riga, perché fino all'UPDATE T1 non tiene nessun lock.

La decisione di T1 («posso prelevare, e il nuovo saldo è 90») è stata presa su un valore che, al momento della scrittura, aveva smesso di essere attuale; e la scrittura, non sapendolo, ha coperto quella di T2. Questa anomalia ha un nome, lost update (aggiornamento perso), e il capitolo 10 la mette in laboratorio con le tre protezioni possibili.

Nota la relazione con il punto precedente: la finestra scoperta è la condizione che rende possibile l'anomalia; il lost update è ciò che accade quando qualcuno la attraversa davvero. Senza concorrenza, la finestra resta scoperta ma non fa danni.

E nota che l'autocommit qui non c'entra: l'unica istruzione che prende un lock è l'UPDATE, e lo prende nell'istante in cui scrive, quindi la finestra tra SELECT e UPDATE è identica con o senza BEGIN. L'autocommit fa differenza solo per l'altro problema, il crash a metà: senza confine dichiarato non c'è nulla da disfare.

Dove nemmeno la singola operazione è ACID

È utile saperlo perché in un'architettura a servizi questi datastore convivono, e la saga (Parte IV) deve tenere conto di cosa ciascun passo può davvero garantire da solo.

3 · Come funziona un database

Un database è una macchina costruita attorno a un solo problema: la memoria veloce si perde, quella durevole è lenta. Ogni componente di questo capitolo nasce da un tentativo di tenere insieme le due cose.

Il problema di partenza: due memorie, due difetti

Un computer ha due posti dove mettere i dati, e nessuno dei due va bene da solo. La tabella li confronta su tre aspetti; il terzo, la differenza tra scrivere in posizioni sparse e scrivere in fila, sembra il meno importante ed è invece quello attorno a cui è costruito tutto il capitolo, per un motivo spiegato subito dopo.

Perché al database importa la differenza tra sparso e in fila

La terza riga della tabella non è una curiosità sull'hardware: è il cuore del problema. Guarda che cosa fa un database in un secondo qualunque di lavoro. Arrivano tre transazioni: una aggiorna il conto 1, una il conto 8.204, una il conto 51.377. Le tre righe vivono in tre pagine diverse, che sul disco stanno in tre punti lontani tra loro, perché i file dati sono ordinati per come le righe sono state inserite nel tempo, non per come verranno modificate.

Ecco il punto: le modifiche di un database sono sparse per natura. Non c'è modo di ordinare le richieste degli utenti perché tocchino pagine vicine. Se il database scrivesse ogni modifica nel punto del disco in cui la riga vive, farebbe per forza una scrittura sparsa a ogni UPDATE, cioè l'operazione più costosa che il disco conosca: su un disco rotante, un centinaio di transazioni al secondo e non una di più.

La distinzione sparso/in fila conta perché è la via d'uscita. Se invece di scrivere le tre pagine al loro posto il database annota le tre modifiche una dopo l'altra in fondo a un unico file, le tre scritture sparse diventano tre righe consecutive: in fila. Le pagine, al loro posto, le scriverà più tardi, quando potrà accorparne molte. Questo file è il log di cui parla tutto il resto del capitolo, e il motivo per cui esiste è esattamente la terza riga della tabella. Per capire quanto sia grande il guadagno, però, bisogna vedere da vicino perché il disco fa pagare tanto le scritture sparse.

Le memorie da vicino

La tabella usa tre parole che vanno chiarite prima di proseguire: che cosa rende la RAM volatile, che cosa rende il disco lento, e che cosa significhi scrivere «in fila» oppure «in ordine sparso». Sono dettagli fisici, ma tutto il progetto di un database è una risposta a questi dettagli.

RAM: nessuna penalità per l'accesso sparso, ma volatile

La RAM (Random Access Memory) è fatta di miliardi di celle che tengono un bit come carica elettrica in un minuscolo condensatore. Si legge e si scrive per indirizzo, direttamente: chiedere il byte 4.000.000 costa quanto chiedere il byte 7, decine di nanosecondi in entrambi i casi (è il senso di random access: qualunque posizione, stesso costo; in fila o sparso, per la RAM non fa differenza). Il rovescio è nel meccanismo: la carica si disperde in decine di millisecondi e va rinfrescata continuamente (ogni 64 ms); senza corrente, sparisce. Quindi tutto ciò che sta solo in RAM non esiste più dopo un blackout.

Disco rotante (HDD): la penalità massima, per via della testina

Un disco rigido (HDD, Hard Disk Drive) memorizza i bit come magnetizzazione di piccole aree su piatti metallici che ruotano a 5.400–15.000 giri al minuto. Una testina montata su un braccio si sposta radialmente per raggiungere la traccia giusta e aspetta che il settore giusto le passi sotto. La magnetizzazione resta senza corrente: è durevole. Ma ogni accesso paga due attese meccaniche:

Ecco l'origine della distinzione che il capitolo usa di continuo. Scrivere in fila (in sequenza, sequenziale) significa scrivere nel settore immediatamente successivo a quello appena scritto: la testina è già lì, il piatto sta già passando, si paga solo il trasferimento. Scrivere in ordine sparso (casuale, random) significa che ogni scrittura è in un punto diverso del disco: ogni volta si paga seek e rotazione. La differenza è di due o tre ordini di grandezza: un disco rotante fa circa 100–200 scritture sparse al secondo, ma trasferisce 100–200 MB al secondo se scrive in fila, cioè decine di migliaia di pagine da 8 KB.

SSD: penalità piccola in lettura, non trascurabile in scrittura

Un SSD (Solid State Drive) memorizza i bit come carica intrappolata in celle di memoria flash NAND, che la conservano senza corrente: è durevole come il disco rotante, e senza testine da spostare un accesso sparso costa decine di microsecondi invece di millisecondi, cento volte meglio. Sembrerebbe che la distinzione fila/sparso non conti più. Conta meno, ma non sparisce, per una peculiarità fisica della flash:

• Si legge e si scrive per pagine (4–16 KB), ma una pagina già scritta non si può sovrascrivere: prima va cancellata.
• Si cancella solo per blocchi, gruppi di centinaia di pagine (da qualche megabyte a qualche decina): è la cancellazione di blocco. Non esiste il modo di azzerare una pagina sola.

Quindi il controller non riscrive la pagina al suo posto: scrive la nuova versione in una pagina libera altrove e marca la vecchia come non valida; più tardi, per liberare un blocco (garbage collection), dovrà copiare altrove le pagine ancora valide. Nei casi peggiori, per modificare 8 KB in mezzo a un blocco già pieno, deve copiare altrove le pagine ancora valide del blocco, cancellare l'intero blocco e riscrivere. Una piccola scrittura sparsa può costare fisicamente la riscrittura di megabyte (write amplification), e ogni blocco sopporta un numero limitato di cancellazioni prima di usurarsi. I controller mascherano tutto questo scrivendo sempre in blocchi «freschi» e riordinando in background (garbage collection, wear leveling), ma il risultato è che anche su SSD molte piccole scritture sparse costano più di una scrittura lunga in fila, e degradano il dispositivo più in fretta.

I numeri, fianco a fianco

La promessa di durabilità del capitolo 2 dice: quando rispondo «fatto», il dato deve sopravvivere a un blackout. Quindi il dato deve finire su disco prima che io risponda. Ma se ogni UPDATE aspettasse che la sua pagina venga scritta sul disco, nel punto sparso in cui quella pagina vive, il database farebbe poche centinaia di operazioni al secondo. Vediamo i due progetti ingenui, e perché falliscono entrambi.

La soluzione: prendere nota prima di fare

Il database fa esattamente questo. Tiene un file speciale, il log o WAL (write-ahead log, «log scritto in anticipo»), in cui annota ogni modifica prima di applicarla: «riga 1: saldo era 100, diventa 70». Il log ha due proprietà che risolvono i due difetti dei progetti ingenui:

• Si scrive solo in fondo (append-only). Non importa quale pagina stai modificando: la nota va sempre in coda al file. È una scrittura sequenziale, l'operazione più economica che un disco sappia fare. Ecco risolto il problema della lentezza.
• Ogni nota è piccola e autosufficiente. Se la corrente salta a metà di una nota, la nota incompleta si riconosce, grazie a un checksum (spiegato nel riquadro qui sotto), e si scarta; tutte quelle prima sono intere. Resta un secondo problema: la pagina dati scritta a metà durante la scrittura in background, che il redo non può riparare confrontando gli LSN. PostgreSQL lo risolve salvando nel WAL l'immagine completa della pagina alla prima modifica dopo ogni checkpoint (full_page_writes), InnoDB con il doublewrite buffer.

Ogni nota ha un indirizzo: l'LSN. Prima di andare avanti serve un nome che tornerà in continuazione. Ogni nota scritta nel log riceve un LSN (Log Sequence Number, «numero di sequenza nel log»). Non è un contatore assegnato a mano: è la posizione della nota dentro il log, cioè a quanti byte dall'inizio del log la nota comincia. In PostgreSQL si legge nella forma 0/16B3D50 (due numeri esadecimali, un unico indirizzo a 64 bit che cresce dal primo giorno di vita del database); InnoDB usa un contatore di byte analogo. Da questa definizione discendono le due proprietà che lo rendono utile:

• Ordina. Il log si scrive solo in fondo, quindi una nota con LSN più alto è stata scritta dopo: confrontare due LSN significa sapere chi è venuto prima, senza orologi.
• Localizza. Dato un LSN, il database sa esattamente dove leggere nel log, come un numero di pagina in un libro. È per questo che in tanti posti si annota «un LSN» invece di «una nota»: sono la stessa cosa.

Lo ritroverai scritto in tre posti: nell'intestazione di ogni nota del log, nell'intestazione di ogni pagina dati (il campo «LSN» dell'header visto nel capitolo 1, il cui ruolo è spiegato più sotto) e in un piccolo file di controllo che indica da dove ripartire dopo un crash. Nel resto del documento gli LSN sono numeri piccoli e comodi (4180, 4195, 4200…) al posto degli indirizzi veri, ma la logica è identica: più alto vuol dire più recente.

Tre dettagli che rendono il meccanismo affidabile. Primo, il CRC copre anche l'intestazione (lunghezza e LSN inclusi), così una nota troncata non può fingersi più corta di quanto fosse. Secondo, il log è append-only: le note sono scritte in ordine, quindi la prima nota non valida segna con certezza la fine di ciò che è arrivato su disco, e non c'è bisogno di cercare oltre. Terzo, il commit è l'fsync del log (passo 5 della traccia): se il database ha risposto «fatto», la nota di commit era intera e su disco prima della risposta, quindi una nota troncata appartiene sempre a una transazione a cui nessuno aveva ancora promesso nulla. Il checksum risolve così il problema della «pagina mezza scritta» dal lato del log; per le pagine dati vale il rimedio già citato nel punto precedente (full_page_writes, doublewrite buffer).

Con il log in mano, il progetto diventa: le pagine si modificano in RAM (come nel progetto 2, veloce), ma una pagina sporca non può mai arrivare sul file dati prima che le note che la riguardano siano già sul disco nel log (write-ahead, «prima il log, poi i dati»). Al COMMIT non si scrivono le pagine: si forza sul disco il log. Da quel momento, qualunque cosa succeda, le note ci sono, e da esse le pagine si possono ricostruire.

Da questo schema discendono direttamente i componenti che si trovano in ogni database relazionale. Ora hanno un nome perché hanno già un motivo.

I componenti, ognuno con il suo perché

La traccia completa di una UPDATE, passo per passo

Seguiamo l'esempio del capitolo 1: UPDATE conti SET saldo = 70 WHERE id = 1, e la riga 1 vive nella pagina 17. A ogni passo guardiamo lo stato dei tre posti in cui un dato può trovarsi: la RAM del buffer pool, il file di log su disco e il file dati su disco. Prima dell'UPDATE la situazione è questa:

Passi 1 e 2 · caricamento e lock. Prima la pagina, poi la riga: il database cerca la pagina 17 nel buffer pool; non c'è, quindi la legge dal file dati e ne mette una copia in RAM. Ora esistono due copie identiche della pagina. Solo a questo punto, dentro la copia in RAM, trova la riga 1, verifica che nessun'altra transazione la stia modificando e la blocca per noi (in PostgreSQL il lock di riga è scritto nell'intestazione della riga stessa, quindi deve stare in una pagina già in memoria; InnoDB lo tiene in una struttura separata in RAM).

Passo 3 · la nota nel log. Prima di toccare la pagina, il database scrive la nota «riga 1: saldo era 100, diventa 70». La nota riceve il numero progressivo successivo, 4180. Per ora sta in un piccolo buffer di RAM riservato al log: sul disco non è ancora arrivata.

Passo 4 · la modifica, solo in RAM. La copia della pagina 17 in RAM viene cambiata: saldo 70. La copia sul file dati resta 100. Da questo momento le due copie sono diverse, ed è esattamente questo che si intende con pagina sporca: una pagina in RAM che non coincide più con la sua versione su disco. Il database la segna come tale per ricordarsi che prima o poi andrà riscritta.

Passo 5 · COMMIT = la nota va su disco. L'applicazione chiede il commit. Il database non scrive la pagina 17: chiama fsync sul file di log, e aspetta che il disco confermi di aver ricevuto fisicamente la nota 4180. Solo allora risponde «fatto». È il momento in cui la modifica diventa durevole: non perché il saldo 70 sia nel file dati (non lo è), ma perché sul disco esiste una nota che dice come ottenerlo.

Questo è lo stato che sorprende: l'utente ha ricevuto conferma, eppure nel file dati c'è ancora 100. Non è un errore, è il progetto: il file dati è indietro di proposito, perché aggiornarlo ora costerebbe una scrittura sparsa, e il log basta a garantire che il 70 non si perda.

Passo 6 · più tardi, la pagina raggiunge il disco. Secondi o minuti dopo, un processo separato del database (in PostgreSQL soprattutto il checkpointer, aiutato dal background writer, che lavorano mentre le transazioni continuano) prende le pagine sporche accumulate nel buffer pool e le scrive al loro posto nel file dati. Ora le due copie coincidono di nuovo: la pagina è pulita. Quel «più tardi» è la ragione di tutto ciò che segue.

Passo 7 · il checkpoint, di cui parliamo tra poco, è ciò che ogni tanto forza il passo 6 per tutte le pagine sporche e lo annota nel log. Ecco la traccia completa in forma compatta, la stessa che si trova in ogni manuale:

Due dettagli ricorrono in tutto il documento. Al punto 3 il database scrive cosa sta per fare prima di farlo. Al punto 5 rende durevole il log, non i dati. Sono le due scelte che rendono possibili le transazioni — e il punto 7 è ciò che impedisce loro di far esplodere il disco.

E se la transazione viene abortita prima del commit?

Tra il passo 4 e il passo 5 la transazione può finire male in molti modi: un ROLLBACK esplicito, un vincolo violato, un deadlock rilevato, un errore 40001, la connessione che cade, il processo che muore. Due cose vanno capite: che fine fanno le note già scritte nel WAL, e che fine fa la pagina sporca in RAM.

Le note nel WAL restano. Il log è append-only: nulla viene cancellato, nemmeno le note di una transazione abortita, che potrebbero essere già su disco se nel frattempo il commit di un'altra transazione ha forzato l'fsync. L'abort si registra scrivendo un'altra nota, «T88: ABORT», oppure semplicemente non scrivendo mai il COMMIT. Al riavvio il redo rilegge tutto ma applica solo le note delle transazioni di cui trova la nota di commit; le altre le tratta come non avvenute.

La pagina sporca: dipende dal motore, ed è una differenza reale che il resto del capitolo semplifica.

Un corollario che spiega una cosa vista nel capitolo 7: in PostgreSQL «disfare» non costa quasi nulla, perché non c'è niente da riscrivere, ma lascia spazzatura nelle pagine (le versioni morte, il bloat). In InnoDB l'abort costa lavoro proporzionale a quanto la transazione aveva scritto, ma le pagine restano pulite.

Che cosa succede se salta la corrente

Un crash cancella tutta la colonna RAM e lascia intatte le due colonne DISCO. Il problema del riavvio è quindi sempre lo stesso: guardando solo log e file dati, rimettere il file dati nello stato che le transazioni committate avevano promesso. Vediamo i tre momenti in cui il crash può arrivare nella traccia sopra.

Nel modello classico (ARIES) la stessa nota di log serve a due cose opposte: contiene il valore nuovo (per il redo) e il valore vecchio (per l'undo). È per questo che al passo 3 il database ha scritto entrambi. Il riavvio analizza il log, poi rifà tutte le modifiche registrate, anche quelle non committate («ripete la storia»), e infine annulla quelle delle transazioni rimaste incomplete: questo procedimento si chiama ARIES (Algorithms for Recovery and Isolation Exploiting Semantics, IBM 1992), ed è ancora lo standard di fatto di molti database, InnoDB compreso (che tiene i valori vecchi in un undo log separato, protetto a sua volta dal redo log).

PostgreSQL fa eccezione: il suo WAL è di solo redo. Al riavvio non annulla nulla, perché le versioni scritte da una transazione mai committata restano nella tabella ma risultano invisibili (la transazione è registrata come abortita) e il VACUUM le rimuove più tardi. Il capitolo 5 mostra perché questa doppia mossa è esattamente ciò che realizza l'atomicità.

Un problema del redo: «l'ho già applicata?»

Il redo sembra semplice: rileggi le note delle transazioni committate e riapplica il valore nuovo alla pagina. Ma c'è un dettaglio che lo complica, e nasce ancora dal «più tardi» del passo 6: al momento del crash, ogni pagina sul disco può essere aggiornata fino a una nota diversa, a seconda di quando il processo di scrittura in background è passato a scriverla. Il redo deve quindi decidere, nota per nota, se quella modifica è già dentro la pagina su disco oppure no. Se la applica due volte, o non la applica affatto, il file dati finisce sbagliato.

Costruiamo il caso. Sul conto 1 avvengono tre transazioni committate in sequenza, ognuna con la sua nota nel log:

La pagina 17 è stata scritta sul disco «più tardi, in background», ma quando? Non lo sappiamo: dipende da quando il processo di scrittura è passato. Sul disco possiamo trovare uno qualunque di questi quattro stati:

Guarda la prima riga: il valore 100 è compatibile con due storie opposte. Nel caso (a) la pagina è indietro di tre note e il redo deve applicarle tutte; nel caso (b) la pagina è già aggiornata e il redo non deve toccare nulla. Se il redo ragionasse sui valori («la nota 4180 dice 100 → 70, la pagina contiene 100, quindi la 4180 non è ancora applicata: applico»), nel caso (b) porterebbe il saldo a 70, poi a 40, poi di nuovo a 100: per fortuna qui torna giusto, ma solo per coincidenza. Basta che la sequenza sia diversa (per esempio una nota «saldo = saldo + 30», che PostgreSQL non scrive ma altri sistemi sì, o una nota su un'altra colonna della stessa riga) e riapplicare a una pagina già aggiornata produce un valore che non è mai esistito.

Il punto generale è questo: il contenuto di una pagina non dice fino a quale nota è aggiornata. Valori uguali possono nascondere storie diverse, e il redo non può permettersi di indovinare. Serve che la pagina porti con sé, esplicitamente, la risposta alla domanda «a che nota sei arrivata?».

La soluzione: l'LSN scritto nella pagina

Ogni nota del log ha il suo numero progressivo, l'LSN (Log Sequence Number), che cresce sempre e non si riusa mai. La regola in più è una sola: ogni volta che il database applica una nota a una pagina, scrive l'LSN di quella nota nell'intestazione della pagina (l'header visto nel capitolo 1), sovrascrivendo il precedente. La pagina porta così con sé, ovunque vada, in RAM come sul disco, il numero dell'ultima nota che contiene.

Riprendiamo i quattro stati possibili della pagina 17. Sono quattro scenari alternativi, non quattro passi: al momento del crash il disco contiene uno solo di questi stati, a seconda di quando il background writer è passato l'ultima volta. In ogni scenario il redo parte dal valore e dall'LSN che trova nell'header, scorre le tre note del log in ordine e per ciascuna applica la stessa regola: applica se il numero della nota è maggiore di quello nell'header, altrimenti salta. Ogni nota applicata aggiorna anche l'header.

Confronta lo scenario A con lo scenario D: entrambi partono da saldo=100, ma l'header dice 4150 in un caso e 4200 nell'altro, e il redo si comporta in modo opposto, applicando tutto oppure niente. Senza l'LSN i due scenari sarebbero stati indistinguibili. Con l'LSN, in tutti e quattro il file dati finisce nello stato corretto, quello che le transazioni committate avevano promesso.

Il redo non interpreta più i valori: confronta due numeri. Se l'LSN della nota è maggiore di quello nell'header, la pagina non contiene ancora quella modifica e va applicata; altrimenti la contiene già e si salta. Ed è per questo che, nella traccia del capitolo 1, l'intestazione della pagina conteneva un campo «LSN»: adesso sai a cosa serve.

Resta una domanda che a questo punto è legittima: al riavvio, come fa il database a sapere qual è l'ultima nota arrivata su disco, e da quale nota cominciare a confrontare? Non certo rileggendo tutte le pagine. La risposta ha bisogno del checkpoint, quindi arriva subito dopo di esso.

Due problemi del «più tardi»: il checkpoint

Torniamo al passo 6. Le pagine sporche raggiungono il file dati «più tardi», e il log intanto continua a crescere a ogni modifica. Lasciato così, lo schema ha due difetti che si aggravano col tempo:

• Il log non si può mai cancellare. Finché una nota descrive una modifica che potrebbe non essere ancora nel file dati, quella nota serve al redo. Se non sappiamo quali pagine sono state scritte, dobbiamo tenere tutto: il log occuperebbe alla fine l'intero disco.
• Il riavvio dovrebbe rileggere tutto il log dal primo giorno, perché non sa da dove le pagine potrebbero essere indietro. Un database attivo da un anno impiegherebbe ore a ripartire.

La soluzione a entrambi è un'operazione periodica, il checkpoint. Vediamola su un caso concreto, nello stesso modo degli scenari precedenti.

Lo scenario: tre pagine, sei note, nessun checkpoint ancora

In un minuto di lavoro sono arrivate sei transazioni committate su tre conti diversi, che vivono nelle pagine 17, 4.913 e 30.201. Il log le ha registrate in ordine; il background writer non è ancora passato su nessuna pagina. Ecco lo stato dei tre posti:

Il checkpoint, passo per passo

Poniamo che il checkpoint scatti subito dopo la nota 4210 (prima che la 4215 sia scritta). Esegue tre operazioni in sequenza:

Passo 1 · annota la posizione corrente del log. L'ultima nota è la 4210: il checkpoint si segna «sto per garantire tutto fino alla 4210». Le note che arrivano dopo questo istante (la 4215) non sono coperte da questo checkpoint, e va bene così: le prenderà il prossimo.

Passo 2 · forza sul file dati tutte le pagine sporche. È il passo 6 della traccia, eseguito per tutte le pagine insieme: le tre pagine in RAM vengono scritte al loro posto nel file dati, ognuna con l'header aggiornato. Costa tre scritture sparse, ma sono tre, non cinque: la pagina 17 aveva assorbito due modifiche e la 30.201 altre due, e ciascuna viene scritta una volta sola (è il guadagno spiegato nel callout più sotto).

Passo 3 · scrive nel log il record di checkpoint. Una nota speciale che dice: «tutto ciò che precede l'LSN 4210 è nei file dati». Da questo momento il database sa due cose che prima non sapeva.

Prima cosa: il log fino alla 4210 può essere riciclato (salvo che serva a repliche o all'archiviazione per i backup), perché non serve più a nessun recovery. Nella realtà le transazioni continuano mentre il checkpoint lavora, quindi il recovery riparte dalla posizione annotata all'inizio del checkpoint (il redo point), non dal record di fine. Il WAL smette di crescere all'infinito: contiene solo ciò che è successo dall'ultimo checkpoint in qua. Seconda cosa: il prossimo recovery partirà dalla 4211, non dall'inizio dei tempi.

Ora il crash: che cosa fa il recovery

Dopo il checkpoint arriva la nota 4215 (pagina 17: 40 → 100), committata e quindi su disco nel log. La pagina 17 in RAM diventa di nuovo sporca (saldo=100, header=4215), ma il background writer non ha ancora avuto tempo di scriverla. Salta la corrente.

Senza il checkpoint il recovery avrebbe dovuto rileggere dalla 4180 e confrontare sei note con gli header (saltandone cinque grazie all'LSN, ma leggendole tutte); e il log avrebbe dovuto conservarle tutte per sempre. Con il checkpoint entrambi i problemi si chiudono nello stesso istante. Nella metafora del cameriere: ogni tanto controlla che la cucina abbia eseguito tutto fino a una certa riga del blocchetto, e strappa le pagine precedenti.

Dopo il crash: come si trova l'ultima nota scritta?

Mettiamo insieme LSN e checkpoint per rispondere alla domanda lasciata aperta. Il riavvio ha bisogno di due estremi: da dove cominciare a rileggere il log e fino a dove il log è arrivato prima del crash. Il sospetto naturale è che debba scorrere tutte le pagine del file dati e cercare l'header con l'LSN più alto. Non lo fa, e per due motivi. Il primo è il costo: un database da un terabyte ha oltre cento milioni di pagine, e leggerle tutte in ordine sparso richiederebbe ore. Il secondo è che non servirebbe: l'LSN più alto che si trova nelle pagine dice fin dove è arrivato il background writer, non fin dove è arrivato il log, e le note che il redo cerca sono proprio quelle che nelle pagine non ci sono ancora. Le pagine dati, al riavvio, non si scansionano mai. L'unica cosa che si legge in sequenza è il log, ed è fatto apposta.

Da dove: il file di controllo. Accanto al log il database tiene un file minuscolo (in PostgreSQL pg_control, poche centinaia di byte, aggiornato a ogni checkpoint; InnoDB scrive la stessa informazione nell'intestazione del redo log). Contiene l'LSN dell'ultimo record di checkpoint completato e, dentro quel record, il redo point: la posizione da cui il recovery deve ripartire perché tutto ciò che precede è garantito nei file dati. Nel nostro esempio il file di controllo dice «ultimo checkpoint: 4211, redo point 4210». Il riavvio legge quel file, salta all'LSN indicato (è un indirizzo: la proprietà «localizza») e comincia da lì.

Fino a dove: la prima nota che non regge. Da quel punto il database legge il log in avanti, nota per nota, con il controllo già visto: lunghezza dall'intestazione, CRC ricalcolato sul contenuto. Finché i controlli passano, la nota è valida e viene messa in coda per il redo. Alla prima nota che non regge (CRC diverso, byte insufficienti, oppure spazio vuoto) il log finisce lì: l'ultima nota valida è l'ultimo LSN scritto. Non c'è bisogno di cercare oltre, perché il log è append-only: dopo un buco non può esserci nulla di buono.

Solo adesso entrano in gioco le pagine. Ma come sa il redo quale pagina aprire? Non lo cerca: lo legge nella nota. Il WAL è un log fisico (PostgreSQL lo chiama «fisiologico»: fisico nell'indirizzo, logico nel contenuto della modifica), e ogni nota porta scritto dentro di sé dove avviene la modifica. In PostgreSQL è una terna: il file della tabella (relfilenode), il numero del blocco, cioè della pagina, e l'offset della riga dentro la pagina; InnoDB usa tablespace, numero di pagina e offset. La nota 4215 completa suona quindi così: «file 16384 · blocco 17 · riga 3 · saldo 40 → 100». Chi l'ha scritta poteva farlo senza sforzo: la transazione stava già lavorando su quella pagina in RAM, quindi l'indirizzo lo conosceva. Al riavvio il redo legge l'indirizzo e carica esattamente quella pagina dal file dati, senza indici né ricerche.

A questo punto il ciclo del redo è completo: legge la nota → l'indirizzo nella nota dice quale pagina → carica quella pagina → confronta il suo header.LSN con l'LSN della nota → applica o salta, come negli scenari A–D. Nell'esempio tocca due pagine, la 17 e la 4.913, su milioni. Il costo del riavvio è quindi proporzionale a quanto log si è accumulato dall'ultimo checkpoint, non alla dimensione del database: è la ragione per cui la frequenza dei checkpoint (il callout qui sopra) governa il tempo di ripartenza.

Due dettagli che rendono la ricerca della fine affidabile in pratica.

Primo, PostgreSQL non allunga il log all'infinito: lo tiene in file da 16 MB che, una volta riciclabili, vengono riutilizzati rinominandoli, quindi dopo l'ultima nota vera può esserci il contenuto vecchio di un file precedente, con CRC perfettamente validi. Per non scambiarlo per log buono, ogni blocco di 8 KB del WAL porta nella propria intestazione l'LSN che dovrebbe avere in quella posizione, e ogni nota porta l'LSN della nota precedente: se uno dei due non coincide, quello che segue è rimasuglio, e il log finisce lì.

Secondo, la posizione «corrente» del log, quella a cui il database appende mentre lavora, vive in RAM e il crash la cancella: viene ricostruita proprio da questa scansione, e le nuove note dopo il riavvio riprendono dall'LSN successivo all'ultima nota valida (qui dopo la 4222). Il pezzo di 4230 mai completato viene sovrascritto: apparteneva a una transazione a cui nessuno aveva ancora risposto «fatto».

Il componente che non abbiamo ancora aperto

Torniamo alla traccia. Il punto 2 diceva «il lock manager verifica che nessun altro tenga la riga 1», e l'abbiamo lasciato cadere lì. È l'unico blocco della mappa che non riguarda la durabilità ma la convivenza: cosa succede quando due transazioni vogliono la stessa riga nello stesso istante.

Non è una nota a margine dell'architettura. La strategia che un database sceglie qui determina la forma fisica dei dati sul disco: nei database moderni una riga non è una riga, è una catena di versioni. Le famiglie sono due, lock (2PL) e versioni (MVCC), e le apriremo nel capitolo 7, dedicato all'isolamento, perché è lì che la scelta produce le sue conseguenze visibili. Prima però conviene mettere in fila le quattro promesse a cui tutta questa architettura serve.

4 · Le quattro promesse

Il capitolo 2 ha mostrato da quali guasti nascono le quattro promesse. Qui, prima di prenderle una per una, il meccanismo che realizza ciascuna.

La lettera aggiunta da Härder e Reuter è la I: Gray aveva nominato atomicità, consistenza e durabilità, ma non l'isolamento come proprietà separata. La C c'era fin dall'inizio — resta però la lettera diversa dalle altre tre, e vale la pena capire perché.

I quattro capitoli che seguono affrontano una lettera ciascuno.

5 · A · Atomicity

Tutto o niente. La lettera più semplice da enunciare e la più fraintesa nel meccanismo.

Un bonifico di 100 € da Anna a Bruno, scritto come lo scriveresti davvero:

BEGIN;
UPDATE conti SET saldo = saldo - 100 WHERE id = 'anna';
UPDATE conti SET saldo = saldo + 100 WHERE id = 'bruno';
INSERT INTO movimenti (da, a, importo) VALUES ('anna','bruno',100);
COMMIT;

Se il processo muore dopo la prima UPDATE, i 100 € sono usciti da un conto e non sono entrati in nessun altro: sono scomparsi. L'atomicità è la promessa che questo stato non possa sopravvivere.

Fin qui l'enunciato. Le due parti che seguono sono quelle che in genere sorprendono: quanto è largo il confine, e il fatto che lo stato invalido arrivi su disco e venga cancellato dopo.

Che cosa c'è dentro il confine atomico

Una UPDATE non fa solo quello che c'è scritto: il database esegue una serie di lavori derivati, e la garanzia utile è che anche quelli stanno nel tutto-o-niente. I tre casi che vale la pena conoscere.

Aggiornamento degli indici

Un indice è una struttura dati separata dalla tabella — tipicamente un B-tree — che tiene i valori di una colonna ordinati, così una ricerca non deve scorrere l'intera tabella. Se modifichi una colonna indicizzata, il DB deve aggiornare due strutture.

UPDATE clienti SET email = 'nuova@x.it' WHERE id = 7;

Se un crash cadesse tra le due, l'indice punterebbe a un valore che nella tabella non esiste più: una ricerca per email darebbe risultati sbagliati o nessun risultato. Non succede, perché l'aggiornamento dell'indice è nella stessa transazione.

ON DELETE CASCADE

È un'opzione della foreign key (chiave esterna, il vincolo che dice «questa colonna deve corrispondere alla chiave primaria di un'altra tabella»): quando cancelli la riga padre, il database cancella automaticamente le righe figlie che la referenziano.

CREATE TABLE ordini (
  id         INT PRIMARY KEY,
  cliente_id INT REFERENCES clienti(id) ON DELETE CASCADE
);

DELETE FROM clienti WHERE id = 7;
-- una istruzione, ma cancella anche i 40 ordini del cliente 7

Quaranta righe cancellate da un'istruzione che ne nominava una — e la cascata può propagarsi su più livelli (cliente → ordini → righe d'ordine). Tutto dentro lo stesso confine: se qualcosa fallisce a metà, non resta un ordine orfano che punta a un cliente inesistente.

Trigger

Un trigger è codice che il database esegue automaticamente al verificarsi di un evento su una tabella. Lo registri una volta, e da quel momento scatta da solo.

CREATE TRIGGER log_variazioni
AFTER UPDATE ON conti
FOR EACH ROW
EXECUTE FUNCTION scrivi_audit();

Da lì in poi, ogni UPDATE su conti fa girare anche scrivi_audit(), che tipicamente scrive su un'altra tabella. Chi lancia l'UPDATE non sa che sta succedendo. Su 10.000 righe il trigger scatta 10.000 volte. E anche queste scritture sono nel confine: un rollback annulla sia le modifiche ai conti sia le righe di audit — non ti ritrovi un log che documenta un evento mai avvenuto.

Redo e undo · cosa succede davvero al riavvio

C'è un punto controintuitivo che vale la pena rendere esplicito: le pagine sporche possono finire su disco prima del commit. Il buffer pool ha spazio limitato, e se serve fare posto il DB scrive su disco anche pagine appartenenti a transazioni ancora aperte. Quindi uno stato invalido può materializzarsi sul disco. Non è un bug: è previsto.

6 · C · Consistency

L'unica lettera che non dipende soltanto dal database.

Riprendiamo il bonifico del capitolo precedente. L'atomicità garantisce che le due UPDATE avvengano entrambe o nessuna. Ma non ha alcuna opinione su questo:

BEGIN;
UPDATE conti SET saldo = saldo - 100 WHERE id = 'anna';
UPDATE conti SET saldo = saldo +  50 WHERE id = 'bruno';   -- ← 50, non 100
COMMIT;

Atomica. Isolata. Durevole. E sbagliata: cinquanta euro sono stati distrutti. Nessun meccanismo del database si è accorto di nulla, perché «in un bonifico la somma dei saldi non cambia» è una regola che vive nel tuo dominio, non nel motore.

Questo capitolo riguarda quindi una domanda diversa dalle altre tre: non «come fa il database a garantirla», ma dove conviene scrivere l'invariante perché sia il database a difenderla.

La C è di natura diversa dalle altre

A, I e D sono proprietà del meccanismo. Il database le garantisce senza sapere nulla di cosa contiene: può darti atomicità su una tabella di gattini o su un libro mastro, gli è indifferente.

La C è una proprietà del contenuto. Nessun database può sapere che «la somma dei dare deve uguagliare la somma degli avere» se non gliel'hai detto tu. Non è qualcosa che il DB ti dà: è qualcosa che tu definisci e che il DB ti aiuta a difendere.

È un'implicazione condizionata: se il DB parte da uno stato valido e la transazione è scritta correttamente, allora finisce in uno stato valido. Nessuna delle due premesse è garantita dal database.

Durante la transazione l'invariante è violata. Un bonifico ha un istante in cui i 100 € sono usciti dal conto A e non sono ancora entrati in B: la somma totale è sbagliata, e quello stato esiste. Da qui la cosa più utile da capire:

Le tre «consistency» che si confondono

La stessa parola indica tre cose che non hanno nulla in comune, ed è la fonte di equivoci più frequente di tutto l'argomento.

La C di CAP riguarda dove sta il dato — più copie che devono accordarsi. La C di ACID riguarda cosa dice il dato. Puoi avere un sistema perfettamente linearizzabile e pieno di saldi negativi. CAP e la consistenza eventuale tornano nel capitolo 12, quando il dato smette di vivere in un solo posto.

Dove si mette concretamente l'invariante

Tre livelli, in ordine di robustezza decrescente.

1. Constraint del database — CHECK saldo >= 0, UNIQUE, FOREIGN KEY. È l'unico posto dove l'invariante è vera sempre, anche se domani qualcuno scrive uno script che bypassa la tua applicazione. Limite: esprime solo vincoli su una riga o su una relazione semplice.
2. L'aggregato — nel design tattico DDD (Domain-Driven Design) un aggregato è esattamente l'insieme di dati che deve restare consistente dentro una singola transazione. Non è una definizione estetica, è operativa: il confine dell'aggregato è il confine della C.
3. Nessuno dei due — se l'invariante attraversa più aggregati o più servizi non è difendibile transazionalmente. Diventa consistenza eventuale, e la compensazione (Parte IV) è ciò che la ripristina.

Nelle saghe (Parte IV) la C non vale durante l'esecuzione: credito riservato, ordine non confermato, e stavolta gli altri lo vedono. Quello che una saga garantisce è che la C torni valida alla fine, per completamento o per compensazione. Non «da stato valido a stato valido», ma «da stato valido a stato valido, passando per un territorio esposto» — e progettarla significa in buona parte decidere quanto grande sia quel territorio e chi possa guardarci dentro.

Caso pratico · l'indice parziale

Un indice normale (capitolo 5) copre tutte le righe della tabella. Un indice parziale ha una WHERE, e il database ci mette dentro solo le righe che la soddisfano.

CREATE INDEX idx_entry_athlete_occurred
    ON medical_record_entry (athlete_id, occurred_on DESC, created_at DESC)
    WHERE deleted_at IS NULL;        -- ← questa riga lo rende parziale

Il guadagno è doppio e vale la pena distinguerlo: l'indice è più piccolo (meno pagine da leggere, più cache utile) e le scritture sulle righe escluse non lo toccano affatto. Se l'unica lettura che esiste chiede le voci vive di un atleta, le voci cancellate nell'indice sarebbero peso che nessuno legge mai. (C'è una trappola nell'uso degli indici parziali che non riguarda la consistenza ma il planner: la trovi nel capitolo 11, insieme all'altro caso in cui un predicato «messo dove serve» rompe qualcosa.)

L'indice parziale unico: un invariante dichiarato

Qui la cosa diventa interessante. Quando l'indice parziale è UNIQUE, il vincolo di unicità vale solo dentro quel sottoinsieme. È il modo di scrivere nel database un invariante che una UNIQUE normale non sa esprimere: al più uno attivo. Attenzione: MySQL non supporta indici parziali; lì si ottiene lo stesso effetto con una colonna generata che vale NULL per le righe revocate e un indice UNIQUE su di essa.

CREATE UNIQUE INDEX uq_user_consent_active
    ON user_consents (user_id, consent_type)
    WHERE revoked_at IS NULL;

Una UNIQUE (user_id, consent_type) normale vieterebbe le prime due righe — cioè renderebbe lo storico impossibile. Quella parziale dice esattamente la regola di dominio, «al più un consenso attivo», e lascia libera la storia. Torna il tema di apertura di questo capitolo: la C di ACID è un'invariante che tu dichiari, e il posto più robusto per dichiararla è il database, dove vale anche per lo script che domani bypassa la tua applicazione.

7 · I · Isolation

La lettera aggiunta per ultima, e quella che costa di più. È anche la più lunga da trattare, perché non è una promessa sola: è una scala.

Due casse dello stesso negozio, un solo pezzo in magazzino:

Entrambe le transazioni sono atomiche, entrambe rispettano i propri constraint, entrambe sono durevoli. Il problema non sta dentro nessuna delle due: sta nel fatto che sono girate insieme. È il territorio dell'isolamento — e il resto del capitolo è, in buona parte, un catalogo di quanto isolamento sei disposto a pagare.

Il capitolo procede in quattro tempi: prima che cosa promette l'isolamento e che nome hanno le sue violazioni; poi come un database lo realizza fisicamente (è qui che riapriamo il lock manager lasciato chiuso nel capitolo 3); poi i quattro livelli con cui lo compri a rate; infine come scegliere.

Perché si dice «come se fossero eseguite in serie»

Vale la pena fermarsi su questa formula, perché nasconde il punto centrale: l'isolamento non è una proprietà di una transazione, è una proprietà di un insieme di transazioni concorrenti.

Se nel database c'è una transazione sola, l'isolamento è gratis e non c'è nulla da discutere: nessuno può disturbarti perché non c'è nessuno. Tutte le anomalie — dirty read, non-repeatable read, phantom, write skew — richiedono almeno due transazioni. Non a caso ogni diagramma di questo capitolo ha due righe.

La domanda a cui l'isolamento risponde è: quando N transazioni girano insieme e le loro operazioni si mescolano, il risultato è accettabile? E «accettabile» ha bisogno di un metro di paragone. Il metro scelto è l'esecuzione seriale.

• Non «in serie» davvero. Nessuno esegue le transazioni una alla volta: sarebbe corretto e inutilizzabile. Il DB le fa girare in parallelo e garantisce solo l'equivalenza a un risultato seriale. È un criterio di correttezza, non un piano di esecuzione.
• Qualsiasi ordine va bene. La definizione non promette che T1 venga prima di T2, ma che il risultato corrisponda a uno dei due ordini possibili. Se ti serve un ordine specifico, quello è un requisito di business e devi imporlo tu.
• È il livello massimo, non il default. «Come se in serie» descrive SERIALIZABLE. Gli altri tre livelli sono deviazioni deliberate da questa promessa, comprate in cambio di prestazioni: ogni ✗ nella matrice che vedremo è una situazione in cui il risultato non corrisponde a nessun ordine seriale, e tu hai accettato che sia così.

Le due casse di apertura sono già un esempio: se fossero andate davvero una dopo l'altra, la seconda avrebbe letto giacenza 0 e non avrebbe venduto. Lo stato «due clienti, un pezzo» non è raggiungibile in nessun ordine seriale. Il caso dei medici reperibili anticipato nel capitolo 6 ha la stessa struttura, e lo vedremo passo per passo più avanti.

Le anomalie, e perché si chiamano così

Anche i nomi delle anomalie sono descrittivi, e ognuno risponde a una domanda diversa.

La progressione dirty → non-repeatable → phantom è una scala di granularità crescente: prima il singolo valore, poi la singola riga nel tempo, poi l'insieme delle righe. Ed è nello stesso ordine in cui i livelli le eliminano. Le prime tre sono anomalie di lettura e sono quelle che lo standard usa per definire i livelli; le ultime due sono anomalie di scrittura (o meglio: di decisione), non compaiono nella matrice ufficiale, ed è proprio per questo che sono le più insidiose. Il lost update ha un capitolo tutto suo (il 10); il write skew lo incontreremo alla fine di questo.

I nomi dei livelli dicono la promessa

Tre nomi su quattro sono costruiti allo stesso modo: [cosa faccio io] + [che tipo di dato]. Traducendoli, la matrice si ricostruisce da sola.

Come il database realizza l'isolamento: i due modi

Riprendiamo il lock manager della mappa del capitolo 3. La strategia che un database sceglie per far convivere le transazioni determina la forma fisica dei dati sul disco, e con essa tutto ciò che leggerai nel resto del capitolo. Le famiglie sono due.

Questa distinzione spiega la matrice che vedremo tra poco: con MVCC, «rileggere lo stesso valore» è gratis, mentre impedire che l'insieme dei risultati cambi è caro. Ma prima va resa esplicita la conseguenza fisica di MVCC, quella che chiude il cerchio con il buffer pool e il log: se ogni scrittura crea una nuova versione, allora sul disco una riga non è una riga.

Una riga non è una riga: le versioni

Questa è la parte che raramente viene spiegata, ed è quella che rende tutto il resto ovvio. In MVCC ogni riga non è una riga: è una catena di versioni (in PostgreSQL si chiamano tuple), ognuna con due marcatori nascosti che contengono gli identificativi di transazione del capitolo 1.

Lo snapshot non è una copia dei dati: è la lista delle transazioni committate al momento dello scatto. Leggere significa scorrere la catena e prendere la versione il cui xmin è nello snapshot e il cui xmax non lo è.

Quando si scatta lo snapshot: per istruzione o per transazione

Resta una domanda che decide la differenza fra i due livelli più usati: lo snapshot si prende quando? In READ_COMMITTED ogni istruzione prende il proprio snapshot nell'istante in cui parte — e la garanzia è più stretta di quanto sembri: non è «T1 ignora T2 per sempre», ma mentre l'istruzione scorre la tabella, il mondo non cambia sotto i suoi piedi.

Ecco cosa succederebbe senza quella garanzia:

Un numero così non corrisponderebbe a nessuno stato reale del database: né a quello prima dell'INSERT, né a quello dopo. Sarebbe un miscuglio di due momenti diversi. Questo intendiamo con «mai un numero sporco a metà», ed è ciò che il capitolo 2 chiamava «isolamento a livello di istruzione».

Rifare però la stessa query un istante dopo è un'altra storia, perché lo snapshot è nuovo:

È la phantom read: stessa query, stessa transazione, insieme di risultati diverso. Ed è la differenza fra i due livelli più usati.

Ecco perché READ_COMMITTED previene le dirty read ma non le non-repeatable read né i phantom: la coerenza è garantita dentro l'istruzione, non tra due istruzioni della stessa transazione.

I livelli ANSI e la loro critica

Lo standard SQL-92 (Structured Query Language), pubblicato da ANSI (American National Standards Institute), definisce i quattro livelli di isolamento non per come funzionano, ma per quali anomalie vietano. Nel 1995 Berenson, Bernstein, Gray e altri pubblicano A Critique of ANSI SQL Isolation Levels: la definizione è ambigua e incompleta: manca il dirty write, mancano lost update e write skew, e non c'è posto per lo snapshot isolation, che il paper definisce formalmente e che negli anni successivi sarebbe diventato il comportamento reale della maggior parte dei DB.

La matrice (secondo ANSI)

Clicca una cella per vedere l'anomalia che quel livello lascia passare, con lo scenario concreto. La matrice riporta le tre anomalie di lettura dello standard: lost update e write skew non vi compaiono perché ANSI non le contempla, ed è uno dei motivi della critica del 1995.

I quattro livelli, uno per uno

Per ciascuno: che cosa promette in concreto, dove ha senso usarlo e dove no.

-- caso tipico: una richiesta HTTP che legge e mostra
BEGIN;
SELECT * FROM ordini WHERE id = 42;      -- dati reali, confermati
SELECT * FROM righe_ordine WHERE ordine_id = 42;
COMMIT;

-- report finanziario: tutte le query devono vedere lo stesso istante
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT SUM(importo) FROM movimenti WHERE tipo='ENTRATA';
SELECT SUM(importo) FROM movimenti WHERE tipo='USCITA';
SELECT COUNT(*)     FROM movimenti;
COMMIT;
-- entrate, uscite e conteggio sono coerenti tra loro

Fotografia contro fila indiana

REPEATABLE_READ ti consegna una fotografia del database scattata all'inizio della transazione. Da lì in avanti guardi la foto, qualunque cosa accada fuori.

Il vantaggio è la coerenza interna: tutte le tue query raccontano lo stesso istante. Il limite è già nella metafora — la foto invecchia mentre la guardi, e tu non te ne accorgi. Finché leggi soltanto non è un problema: stai producendo un report di com'era il mondo alle 14:32, ed è quello che volevi. Il problema nasce quando scrivi basandoti sulla foto, perché la scrittura avviene nel presente mentre la decisione l'hai presa guardando il passato.

Il meccanismo: come il DB si accorge che stai scrivendo su un dato vecchio

Le versioni di riga e lo snapshot li abbiamo visti poco sopra. Quando provi a scrivere una riga, il database esegue questa sequenza precisa:

1. Prende un lock esclusivo sulla riga. Scrivere non è mai snapshot-based: per modificare devi passare dalla versione fisicamente corrente, non dalla tua foto.
2. Guarda l'xmax della versione che vede. Se è vuoto, o appartiene a una transazione abortita o a un semplice lock di riga, procede; se appartiene a una transazione già committata dopo il suo snapshot, il conflitto è immediato.
3. Se l'xmax è valorizzato da una transazione ancora aperta, si mette in attesa che quella finisca.
4. Quando quella committa, confronta. La versione corrente è stata creata da una transazione che ha committato dopo il mio snapshot: quindi io non l'ho mai vista.

Ed è qui che i due livelli divergono radicalmente:

Dove REPEATABLE_READ non arriva: il write skew

Il buco si apre quando due transazioni leggono le stesse righe ma ne scrivono di diverse. Nessuna tocca la riga dell'altra, quindi il meccanismo appena descritto non ha nulla da rilevare: non c'è nessun xmax contestato. È l'esempio dei medici reperibili anticipato nel capitolo 6, e questa è la sua sede.

Ognuna delle due, presa da sola, è ineccepibile. Insieme violano l'invariante. E non è servito a nulla che la foto fosse coerente: era vera al momento dello scatto e falsa al momento della scrittura, e nessuno l'ha riverificata. Da notare: non si è verificata nessuna anomalia di lettura — niente dirty read, niente non-repeatable read, niente phantom. È un'anomalia di decisione, non di lettura. È il write skew.

Torna anche la formula «come se in serie»: se i due medici fossero andati davvero uno dopo l'altro, il secondo avrebbe visto di essere rimasto solo e si sarebbe fermato. Lo stato «zero reperibili» non corrisponde a nessun ordine seriale, ed è per questo che serve il livello che promette l'equivalenza seriale, oppure bloccare esplicitamente le righe lette con SELECT … FOR UPDATE, quando esistono. Nemmeno @Version aiuta: nessuna delle due ha toccato la riga dell'altra.

-- invariante d'insieme: almeno un medico deve restare reperibile
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT COUNT(*) FROM turni WHERE reperibile = true;   -- 2
-- l'applicazione verifica: 2 > 1, posso togliermi
UPDATE turni SET reperibile = false WHERE medico_id = 7;
COMMIT;   -- se le due transazioni hanno letto ciò che l'altra ha scritto: 40001

La discrepanza tra lo standard e i database veri

Lo standard descriveva database basati su lock (il 2PL visto sopra), dove REPEATABLE_READ bloccava le righe lette ma non i range — da lì i phantom. I database MVCC ti danno uno snapshot completo, che elimina i phantom nelle letture semplici; in cambio lasciano passare il write skew che il 2PL bloccava. E InnoDB, mescolando letture da snapshot e letture correnti, può ancora mostrarli (lì li bloccano i next-key lock).

Come deciderlo in tre passi

Il terzo caso si riconosce da una forma ricorrente: «conto o verifico qualcosa su un insieme, poi modifico un elemento di quell'insieme». Massimo N iscritti, almeno uno reperibile, capienza della sala, saldo aggregato su più conti.

Riepilogo: scenario per scenario

DEFAULT (il valore dell'attributo isolation di @Transactional in Spring) significa «usa quello del datasource». PostgreSQL e Oracle stanno su READ_COMMITTED, MySQL/InnoDB su REPEATABLE_READ: lo stesso identico codice cambia comportamento cambiando database.

8 · D · Durability

Dopo il commit, resiste. Sembra la lettera più ovvia: è quella che dipende dal maggior numero di strati fuori dal database.

L'applicazione mostra «ordine confermato». Un secondo dopo il server perde corrente. Alla riaccensione, l'ordine c'è?

Deve esserci. Il commit è una promessa fatta a qualcuno che ora agisce di conseguenza — l'utente che chiude il browser, il servizio a valle che ha ricevuto 200 OK. La parte non ovvia è che il database, da solo, non può mantenerla: deve convincere il sistema operativo, che a sua volta deve convincere il disco. Ognuno dei due, se lasciato fare, mentirebbe per andare più veloce.

Che cos'è fsync, e perché serve

fsync, già incontrato al punto 5 della traccia del capitolo 3, è una system call POSIX — non un comando di shell. POSIX (Portable Operating System Interface) è la famiglia di standard IEEE che definisce l'interfaccia comune dei sistemi Unix-like: quali chiamate esistono, come si chiamano, cosa devono garantire. È il motivo per cui lo stesso codice C che apre un file e lo sincronizza compila su Linux, macOS, BSD e Solaris, anche se la garanzia effettiva varia (su macOS fsync non svuota la cache del disco: serve F_FULLFSYNC). La firma è int fsync(int fd), dove fd è il file descriptor del file da rendere durevole.

Serve perché tra la tua scrittura e il supporto fisico ci sono almeno tre livelli di cache.

La page cache del kernel

Il kernel non fa passare le scritture direttamente al disco: tiene in RAM una copia delle pagine di file su cui si sta lavorando. Quella copia è la page cache, e ha due compiti.

• In lettura funziona da cache vera: rileggere un file appena letto non tocca il disco. È il motivo per cui su Linux la RAM «libera» tende a zero — la memoria non usata viene impiegata come cache, e liberata appena serve altrove.
• In scrittura funziona da buffer: write() copia i byte nella page cache, marca la pagina come dirty e ritorna subito. La scrittura vera avviene dopo, in modo asincrono, quando lo decide il kernel (writeback).

Da qui l'espressione «veloce e bugiarda»: quando write() ti risponde con successo, i dati esistono solo in memoria volatile. Se stacchi la corrente in quell'istante, non sono mai esistiti. Per un editor di testo è un compromesso ragionevole; per un database che ha appena promesso committed a un'applicazione, è inaccettabile.

fsync(fd) risolve proprio questo: blocca il chiamante finché tutte le pagine sporche di quel file — e i relativi metadati — non sono arrivate su supporto non volatile.

9 · Lock: ottimistico vs pessimistico

Due scommesse opposte sulla stessa domanda: quanto è probabile che qualcuno tocchi questo dato mentre lo sto usando?

Prima le due primitive

Il capitolo 1 ha definito il lock come una prenotazione tenuta fino al commit, e il capitolo 7 ha mostrato che il database ne prende uno esclusivo ogni volta che scrive. Qui interessano i due strumenti con cui l'applicazione governa la concorrenza su una riga, perché tutto il capitolo è un confronto tra loro.

Le due scommesse

SELECT ... FOR UPDATE
LockModeType.PESSIMISTIC_WRITE

UPDATE conto SET saldo=?, version=version+1
WHERE id=? AND version=7

È letteralmente la stessa idea a livelli diversi dello stack:

I costi reali

Il criterio di scelta

10 · Lost update, in laboratorio

Due thread, saldo iniziale 100. T1 preleva 10, T2 preleva 30. Il risultato corretto è 60. Scegli una strategia e avanza passo per passo.

È l'anomalia annunciata nel capitolo 2: la sequenza leggi → decidi → scrivi fatta in tre pezzi, dove la scrittura usa un valore che nel frattempo ha smesso di essere vero. Le quattro modalità del simulatore corrispondono a nessuna protezione e alle tre soluzioni elencate sotto.

Le tre soluzioni, in ordine di preferenza

1. Scrittura atomica. Non leggere per poi scrivere: fai calcolare al DB. UPDATE conto SET saldo = saldo - 10 WHERE id = ?. Nessuna finestra tra read e write, quindi nessun conflitto. L'invariante si sposta in un constraint (CHECK saldo >= 0). Se l'operazione è esprimibile così, finisce qui.
2. Optimistic lock. Quando la scrittura dipende da logica applicativa che non sta in una UPDATE. @Version come default su ogni aggregato.
3. Pessimistic lock. Quando la contesa è alta o il retry è insostenibile.

Due errori strutturali da escludere prima

• Lettura e scrittura in transazioni diverse. Se leggi in una richiesta HTTP e scrivi nella successiva, nessun lock di DB ti copre: è morto col primo commit. Serve la versione che viaggia al client (l'Optimistic Offline Lock del capitolo 9).
• Persistence context stale. Il persistence context è la cache di primo livello di JPA: le entità caricate in una transazione restano in memoria, e se l'entità è già nella sessione, find() non va nemmeno al DB e ti restituisce la copia in memoria. In transazioni lunghe è spesso il vero colpevole: solo em.refresh(entity) (anche nella forma em.refresh(entity, LockModeType.PESSIMISTIC_WRITE), che rilegge e blocca insieme) forza la rilettura; un lock da solo non aggiorna la copia già in memoria.

11 · Il predicato al posto giusto

Due casi reali in cui la mossa apparentemente più pulita — mettere il filtro dentro la query, rendere l'indice più piccolo — rompe silenziosamente qualcosa. E per lo stesso motivo.

Caso 1 · Il filtro che disattiva il lock

Due finder che cercano la stessa entità per id, deliberatamente diversi. Il codice è Kotlin con Spring Data JPA: @Lock chiede il lock pessimistico del capitolo 9, @Query fissa la query JPQL, takeIf restituisce l'oggetto solo se la condizione è vera (altrimenti null), e .left() incapsula un errore di dominio.

// A · lettura semplice, nessun lock — il filtro sta DENTRO
fun findByIdAndDeletedAtIsNull(id: UUID): MedicalRecordEntry?

// B · lettura per aggiornamento, con lock — il filtro sta FUORI
@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT e FROM MedicalRecordEntry e WHERE e.id = :id")
fun findByIdForUpdate(@Param("id") id: UUID): MedicalRecordEntry?

// il chiamante di B filtra dopo, a mano:
val entry = entries.findByIdForUpdate(entryId)?.takeIf { it.deletedAt == null }
    ?: return MedicalRecordErrors.entryNotFound().left()

La ragione sta in una frase che vale la pena imparare a memoria:

Il meccanismo, passo per passo

È la rivalutazione della WHERE (EvalPlanQual) del capitolo 7, vista sul campo. Anna ha due schede aperte: nella prima cancella la voce, nella seconda la chiude.

L'esito visibile all'utente può coincidere — in questo caso entrambe le strade arrivano a un 404 — ma la posizione del presidio no. Nella prima colonna il lock non è mai stato acquisito, quindi ogni ragionamento successivo della transazione avviene su una riga non protetta. Se dopo il controllo ci fossero altri passi (scrivere una riga collegata, decrementare un contatore, emettere un evento), quelli girerebbero senza alcuna esclusività.

La regola generale, e quella di progettazione

• Blocca su colonne immutabili, filtra su quelle mutabili dopo il lock. La chiave primaria è il predicato ideale per un FOR UPDATE proprio perché nessuno la cambia: la rivalutazione non può mai farti perdere la riga. Ogni colonna che qualcun altro può scrivere è un candidato pessimo.
• Una primitiva di lock non è una query di dominio. Se infili una regola di business dentro findByIdForUpdate, ogni chiamante futuro se la porta dietro in silenzio — e chi avesse bisogno di bloccare proprio una riga cancellata, per ripristinarla, non potrebbe. La primitiva resta minima, la politica sta al call site.
• Il finder senza lock è un altro discorso. Lì il filtro dentro va benissimo: non c'è nessun lock da restringere, il predicato non ha niente da portarsi via, e scriverlo nel nome del metodo è più corto e più chiaro.

Caso 2 · La trappola dell'indice parziale: «parziale» non è automaticamente meglio

L'indice parziale del capitolo 6 ha una controindicazione che non riguarda la consistenza ma il planner, il componente che decide come eseguire una query. PostgreSQL può usare un indice parziale solo se dimostra, al momento di pianificare la query, che il predicato della query implica quello dell'indice. È una dimostrazione simbolica sul testo, non una verifica sui dati.

Nel caso B il valore arriva come parametro bind. Finché PostgreSQL usa un piano custom (le prime esecuzioni, o quando il piano generico non conviene) il valore è noto e l'indice può servire; ma quando passa al piano generico il valore non c'è al momento del piano, e l'indice parziale resta inerte. Con un piano generico, riutilizzato per qualunque valore, l'implicazione non è dimostrabile e l'indice resta inutilizzato proprio nel caso per cui l'avevi costruito. Il costo non sparisce: l'indice va comunque mantenuto a ogni scrittura.

Il filo comune

In entrambi i casi la mossa apparentemente più naturale — «metti il filtro dove serve», «rendi l'indice più piccolo» — è quella che rompe qualcosa, e per lo stesso motivo di fondo: un predicato non è solo un filtro, è una promessa che il database deve poter valutare in un preciso momento. Nell'indice parziale il momento è la pianificazione, e con un parametro bind la promessa non è dimostrabile. Nel FOR UPDATE il momento è la contesa, e su una colonna mutabile la promessa può decadere proprio allora.

12 · Quando il confine si rompe

In un monolite l'atomicità te la regala il database. Appena spezzi il dominio in servizi con datasource separati, diventa un problema di protocollo.

La premessa: un database per servizio

Tutto ciò che precede vale dentro un database: il BEGIN e il COMMIT del capitolo 1 sono comandi che un motore esegue sui propri dati. Nelle architetture a servizi la regola di progetto è che ogni servizio possiede il proprio datastore e nessun altro vi accede direttamente (database per service): è ciò che permette a Ordini e Pagamenti di essere sviluppati, rilasciati e scalati in modo indipendente, e di scegliere ciascuno il datastore più adatto (il capitolo 2 ha mostrato che non tutti garantiscono le stesse cose). Il prezzo è che «crea l'ordine e addebita il cliente» ora scrive su due database diversi, e nessuno dei due può aprire una transazione che includa l'altro.

Il confine ACID coincide con il confine del datasource. Quando l'operazione ne attraversa due, hai solo due strategie: bloccare tutti finché non sono d'accordo, oppure procedere a passi e prevedere come disfare.

2PC (two-phase commit) e XA (eXtended Architecture) · che cosa sono

Il two-phase commit è descritto da Jim Gray nel 1978 (Notes on Data Base Operating Systems). Un coordinatore chiede a tutti i partecipanti se possono committare (fase di prepare, in cui ciascuno vota sì o no); se tutti votano sì, ordina il commit (fase di commit).

Il punto sottile è cosa promette un partecipante quando risponde «sì»: promette di poter committare comunque, anche dopo un crash. Per mantenerla deve rendere durevole il proprio lavoro (scrivere il proprio WAL, capitolo 3) e tenere i lock aperti fino all'ordine finale.

XA è lo standard che nel 1991 il consorzio X/Open pubblica dentro il modello DTP (Distributed Transaction Processing): definisce l'interfaccia tra un transaction manager (il coordinatore) e i resource manager (DB, code di messaggi). In Java lo vedi come JTA (Java Transaction API), UserTransaction e XAResource. Funziona bene tra un DB e una coda JMS (Java Message Service) nello stesso datacenter; non esiste per una chiamata REST (Representational State Transfer).

Perché 2PC/XA tra servizi quasi non si usa più

• È costoso in latenza. I lock restano aperti sui partecipanti per l'intera durata del protocollo, cioè per tutto il round-trip di rete (il «bloccante» in senso tecnico è il punto seguente).
• Stato in dubbio. Se il coordinatore muore tra prepare e commit, i partecipanti restano in-doubt: hanno votato sì, quindi non possono abortire da soli, ma non hanno ricevuto l'ordine, quindi non possono committare. E non possono rilasciare i lock. È dimostrato che il problema non si aggira: non esiste un protocollo di commit atomico non bloccante in presenza di partizioni di rete. Il 3PC (three-phase commit, che aggiunge una fase intermedia di «pre-commit» per permettere ai partecipanti di decidere senza il coordinatore) risolve i crash, non le partizioni.
• Supporto assente. REST, Kafka e la maggior parte dei NoSQL non parlano XA.
• Disponibilità accoppiata. Un partecipante giù significa transazione giù per tutti.

CAP, BASE, e il cambio di paradigma

Nel 2000 Eric Brewer enuncia la congettura CAP (Consistency, Availability, Partition tolerance), dimostrata formalmente da Gilbert e Lynch nel 2002 (con C intesa come linearizzabilità): in presenza di una partizione di rete (due parti del sistema che non riescono più a parlarsi) devi scegliere tra consistenza (la C «di CAP» del capitolo 6: tutti vedono lo stesso valore) e disponibilità (tutti ricevono una risposta). Dato che la partizione non è un'opzione ma un fatto, la scelta reale è sempre tra le altre due.

Abadi lo estende con PACELC (2010): if Partition then A or C, else L or C. Anche quando tutto funziona resta un compromesso tra latenza e consistenza — ed è quello che paghi ogni volta che usi 2PC.

BASE (Basically Available, Soft state, Eventually consistent) nasce come contrapposizione esplicita ad ACID: accettare stati intermedi visibili e convergenza nel tempo (la consistenza eventuale del capitolo 6), in cambio di disponibilità e scala. La saga è il modo di stare in BASE senza rinunciare alla correttezza del business.

13 · La saga

Nata nel 1987 per un problema completamente diverso. Prima il concetto, poi la macchina per farla fallire.

Origine · Garcia-Molina & Salem, Princeton, 1987

Il paper si intitola semplicemente Sagas e non parla di servizi né di reti: tratta il caso centralizzato, limitandosi a osservare che le saghe si possono implementare anche in un database distribuito. Il problema che affronta è un altro: le long-lived transaction (LLT). Un batch contabile che gira per sei ore dentro un solo database, tenendo lock su mezzo schema e bloccando tutti gli altri.

L'idea: spezzare quella transazione lunga in una sequenza di transazioni brevi che committano subito — liberando i lock — e associare a ciascuna una compensating transaction che ne annulla l'effetto. Una saga esegue T1 … Tn, oppure, se si ferma a metà, T1 … Tj seguita da Cj … C1 in ordine inverso.

Nel 2015 circa il pattern viene riscoperto per i microservizi (Caitie McCaffrey, poi Chris Richardson). Il problema era cambiato — non più lock troppo lunghi, ma database separati che non possono condividere una transazione — mentre la soluzione è rimasta identica. Ed è per questo che la saga ha caratteristiche che sorprendono chi la incontra oggi: non è stata progettata per sopravvivere alle partizioni di rete, quindi outbox e idempotenza (capitolo 14) sono aggiunte nostre, non sue.

Compensazione, non rollback

Non torni indietro nel tempo: esegui un'operazione di business che neutralizza la precedente. Non annulli un addebito cancellando la riga — emetti un rimborso. La traccia resta, ed è esattamente quello che vuole l'audit. Questa è la differenza concreta tra rollback e compensazione semantica.

Anche questa non è un'invenzione informatica: viene dalla partita doppia. In contabilità una scrittura errata non si cancella: si emette una scrittura di storno, uguale e contraria. Il libro mastro è append-only per obbligo di legge, ed è per questo che la compensazione è naturale nei domini finanziari e sembra strana solo a chi arriva dal CRUD.

Le tre categorie di passo

Classificarli in fase di design è la parte che conta davvero.

Provala: la saga di creazione ordine

Quattro transazioni locali, ognuna sul database del proprio servizio, con il pivot sull'addebito. «Esegui» la porta in fondo; «Fai fallire T3» simula lo stock esaurito e mostra le compensazioni che tornano indietro in ordine inverso.

Coreografia vs orchestrazione

Resta da decidere chi conosce la sequenza dei passi e chi lancia le compensazioni. Le due risposte possibili:

Regola con DDD (Domain-Driven Design): l'orchestratore conosce l'ordine dei passi, non le regole. Le regole restano negli aggregati.

14 · Il prezzo della saga: manca la I

Saga garantisce A (semantica, via compensazione), C (alla fine, non durante) e D. Non I — e stavolta gli stati intermedi li vedono tutti.

Mentre la saga è a metà, il credito è riservato ma l'ordine non è confermato. Chiunque legga in quel momento vede uno stato che potrebbe non esistere mai. Da qui nascono anomalie identiche a quelle dei database (capitolo 7), ma a livello di business. Le contromisure, catalogate da Lars Frank e Torben Zahle (1998) e riprese da Chris Richardson (che include anche il version file, un registro delle operazioni per riordinarle), hanno ciascuna un corrispettivo tra i meccanismi già visti.

I due pattern senza cui la saga si rompe

La saga del 1987 viveva in un solo database e non aveva reti da attraversare. Quella del 2015 comunica tra servizi tramite messaggi su un broker (Kafka, RabbitMQ), e questo introduce due problemi che il paper non poteva prevedere.

15 · Casi d'uso reali

Come si combinano i pezzi in quattro domini che conosci.

16 · Le altre famiglie di database

Una mappa: che cosa sono, da quale esigenza nascono, che cosa garantiscono e quando sceglierle. Tre famiglie hanno un approfondimento dedicato in documenti separati.

Da dove nasce il bisogno

Il modello relazionale ha una forza precisa: dati normalizzati in tabelle, ricomposti al momento della query con le JOIN, protetti da ACID su un unico server. Per decenni è bastato. Le altre famiglie nascono quando una di queste tre premesse smette di reggere.

Il termine ombrello NoSQL («not only SQL») raccoglie quasi tutte queste famiglie, ma dice solo che cosa non sono. Per capire ciò che sono conviene guardare due assi: il modello dei dati (come sono fatti gli oggetti che memorizzi) e il confine transazionale (fin dove arriva l'atomicità, che è il filo di tutto questo documento).

La mappa

Le prime due colonne dicono come pensi i dati; la quarta dice quanto puoi fidarti di una singola scrittura. È la stessa tabella del capitolo 2 («dove nemmeno la singola operazione è ACID»), vista dall'altra parte: non un elenco di mancanze, ma una scelta di progetto. Ogni famiglia restringe il confine atomico alla sua unità naturale (chiave, documento, partizione) proprio perché è quella che può garantire senza coordinare più nodi.

Focus 1 · Redis: il database in memoria

Redis (REmote DIctionary Server) tiene tutti i dati in RAM e li serve con latenze di poche decine di microsecondi. Non è una cache e basta: è un server di strutture dati. Una chiave può contenere una stringa, ma anche una lista, un insieme, un insieme ordinato per punteggio, una hash, uno stream di eventi, e su ognuna esistono comandi specifici (INCR, LPUSH, ZADD, HSET…). È il motivo per cui con Redis si costruiscono contatori, classifiche, code, rate limiter e lock distribuiti con una riga di codice ciascuno.

Il legame con il filo del documento è duplice. Atomicità: Redis esegue i comandi uno alla volta su un singolo thread, quindi ogni comando è atomico per costruzione (INCR non ha lost update, mai) e MULTI/EXEC raggruppa più comandi in un blocco che nessun altro può interrompere, ma senza rollback, come anticipato nel capitolo 2. Durabilità: è la lettera che Redis ti chiede di negoziare. Con la persistenza a snapshot (RDB) puoi perdere gli ultimi minuti; con il log append-only (AOF) puoi scegliere quanto spesso fare fsync, e la scelta ti riporta esattamente al capitolo 8: più sicurezza, meno velocità. Il lock distribuito con TTL del capitolo 9 vive proprio qui, e il fencing token è la sua correzione.

Approfondimento: Redis e i database non relazionali (documento separato, prima parte), con strutture dati, persistenza, transazioni, pattern di cache e lock.

Focus 2 · I database non relazionali orientati agli aggregati

Documentali e wide-column condividono un'idea che Martin Fowler ha chiamato aggregate-oriented: invece di spezzare un ordine in tre tabelle (ordini, righe_ordine, indirizzi) da ricomporre con le JOIN, memorizzi l'ordine intero, con le sue righe annidate dentro, e lo leggi e scrivi in un colpo solo. È letteralmente l'aggregato del DDD (Domain-Driven Design) del capitolo 6, reso unità fisica di memorizzazione.

{
  "id": 42,
  "righe": [ {"sku":"pen","q":2},
             {"sku":"ink","q":1} ],
  "indirizzo": { "via": "…" }
}

La conseguenza sul confine transazionale è immediata e spiega la tabella sopra: l'atomicità arriva fin dove arriva l'aggregato. Un documento in MongoDB, una partizione in Cassandra. Dentro quel confine hai tutto-o-niente gratis; fuori, devi coordinare, e ricadi nei problemi della Parte IV. Per questo questi database spingono a denormalizzare: duplicare il nome del cliente dentro l'ordine, invece di puntare alla riga cliente, così che leggere l'ordine non richieda una seconda lettura. Il prezzo è che aggiornare il nome del cliente significa aggiornare mille ordini, e quel «mille ordini» non è atomico.

La seconda peculiarità è la consistenza regolabile. In un sistema distribuito con repliche, Cassandra lascia scegliere per ogni operazione quante repliche devono confermare (ONE, QUORUM, ALL); DynamoDB offre una scelta più grossolana, lettura eventuale o fortemente consistente (ConsistentRead): è la manopola tra consistenza e latenza/disponibilità (CAP e PACELC, capitolo 12) messa in mano allo sviluppatore, e il valore di default è quasi sempre eventuale. MongoDB ha la stessa manopola con writeConcern e readConcern.

Approfondimento: Redis e i database non relazionali (documento separato, seconda parte), con documentali, wide-column e grafo, modellazione per aggregati, consistenza regolabile e casi d'uso.

Focus 3 · I database vettoriali

Un modello di machine learning può trasformare un testo, un'immagine o un prodotto in un embedding: un vettore di alcune centinaia o migliaia di numeri, costruito in modo che oggetti simili nel significato abbiano vettori vicini nello spazio. «Scarpe da corsa leggere» e «running shoes ultralight» finiscono a pochi gradi di distanza anche se non condividono una parola. La query non è più «trova dove id = 7» ma «trova i dieci vettori più vicini a questo».

Il problema che rende necessaria una famiglia a sé è che nessun indice tradizionale funziona: un B-tree ordina valori su una dimensione, qui le dimensioni sono centinaia e la domanda è una distanza. Confrontare la query con ogni vettore (scansione esatta) costa linearmente e su milioni di righe non regge. I database vettoriali usano indici approssimati (ANN, Approximate Nearest Neighbour: HNSW, IVF) che trovano quasi sempre i vicini giusti in tempo sublineare (circa logaritmico per HNSW), accettando di sbagliarne qualcuno. È un compromesso nuovo rispetto a tutto il documento: correttezza approssimata in cambio di velocità, misurata come recall.

Il legame con il filo transazionale è meno ovvio ma c'è. Gli indici ANN sono costosi da aggiornare: molti motori li ricostruiscono o li aggiornano in modo asincrono, quindi un vettore appena inserito può non essere ancora trovabile per qualche secondo. È consistenza eventuale a livello di indice, e va saputo quando si progetta un flusso «scrivi il documento, poi cercalo». E quando i vettori vivono in un database separato da quello dei dati (Qdrant accanto a PostgreSQL), aggiornare entrambi è di nuovo un problema a due datastore, con outbox e idempotenza (capitolo 14); è il motivo per cui pgvector, che mette i vettori in una colonna di PostgreSQL, è così attraente: il vettore e la riga stanno nella stessa transazione.

Approfondimento: I database vettoriali (documento separato), con embedding, metriche di distanza, indici HNSW e IVF, filtri, ricerca ibrida, pgvector contro motori dedicati e il flusso RAG.

Il filo comune: la persistenza poliglotta

Un sistema reale usa quasi sempre più di una famiglia: PostgreSQL per gli ordini, Redis per le sessioni, Elasticsearch per la ricerca, un vettoriale per le raccomandazioni. Si chiama persistenza poliglotta, ed è la regola, non l'eccezione. Ha però una conseguenza che tutto il documento ti ha preparato a riconoscere: ogni coppia di datastore è un confine transazionale spezzato. Scrivere l'ordine su PostgreSQL e invalidare la cache su Redis, oppure indicizzarlo su Elasticsearch, è lo stesso problema del capitolo 14 (scrivere sul DB e pubblicare su Kafka): due risorse, nessuna transazione che le abbracci. Le soluzioni sono le stesse: una sola fonte di verità dichiarata, outbox o CDC (Change Data Capture) per propagare, idempotenza a valle, e l'accettazione esplicita che i datastore secondari siano eventualmente allineati.

17 · Riferimenti

Quarant'anni in dieci righe

Nessuno dei pattern di questo documento è nato per i microservizi. Sapere da quale problema vengono spiega perché hanno la forma che hanno.

Glossario

18 · Test di autovalutazione

Quarantaquattro domande su tutto quello che c'è sopra. Ogni risposta mostra la spiegazione, giusta o sbagliata che sia.