Title: Tecnologie di un database server: la gestione della concorrenza
1Tecnologie di un database server la gestione
della concorrenza
- Paolo Atzeni
- Roma Rovereto
- 13/05/2011
2Base di dati
- Collezione di dati potenzialmene
- grande
- persistente
- di interesse per molti utenti e applicazioni
- Esempi
- Conti correnti bancari
- Prenotazioni aeree o ferroviarie
- La base di dati è spesso una risorsa importante,
da gestire con - efficienza
- affidabilità
3Molte richieste contemporanee o quasi
- Conti correnti bancari, prenotazioni aeree o
ferroviarie - anche centinaia o migliaia di aggiornamenti
attivi in un ogni momento
4Due prelevamenti da un conto corrente
- Quanto c'è sul conto?
- 1000
- Bene, allora prelevo 200
- Ok, il nuovo saldo è 800
- Quanto c'è sul conto?
- 1000
- Bene, allora prelevo 100
- Ok, il nuovo saldo è 900
5Qual è il problema?
- Le operazioni ("transazioni", vediamo fra poco)
sono concorrenti - le azioni si alternano (Paperina, Paperino,
Paperina, ) in modo inaccettabile - Se eseguissimo prima tutte le azioni di Paperina
e poi tutte quelle di Paperino - non ci sarebbe problema
- Potremmo allora separare tutte le operazioni?
- no, perché le richieste possono essere tante e
introdurremmo tempi di attesa eccessivi
6Lettura, scrittura, lettura
1000 sul conto A 1000 sul conto B
- Quanto c'è sul conto A?
- 1000
- Quanto c'è sul conto B?
- 1500
- Ehi, abbiamo 2500!
- Sposta 500 da A a B
- Nuovo saldo A 500
- Nuovo saldo B 1500
7Lettura prima della conferma (commit)
1000 sul conto
- Quanto c'è sul conto?
- 11.000
- Abbiamo 11.000 !?!
- Paperina ha letto un dato sbagliato!
- Ecco un assegno da 10.000
- Bene, il nuovo saldo è 11.000
- Ma l'assegno è falso!
- Annulliamo l'operazione
- Il saldo resta 1000
8Gestione della concorrenza
- La concorrenza va governata
- va permessa per favorire l'efficienza
- ma limitata, per evitare i problemi
9Un concetto importante
- Transazione
- Sequenza di operazioni da considerare
indivisibile ("atomica"), corretta anche in
presenza di concorrenza e con effetti definitivi
10Transazioni, in pratica
- Sequenza di operazioni caratterizzata da
- un inizio (non sempre esplicitato) e
- da una conclusione
- commit per terminare ed eseguire tutto
- rollback per annullare (abortire)
11Una transazione
- declare s money
- select saldo into s from conti where numero
101 - update conti set saldo s - 200 where numero
101 - commit
- Quanto c'è sul conto?
- 1000
- Bene, allora prelevo 200
- Ok, il nuovo saldo è 800
12Un'altra transazione
- update conti set saldo saldo - 500 where
codice 'A' - update conti set saldo saldo 500 where
codice 'B' - commit
- Sposta 500 da A a B
- Nuovo saldo A 500
- Nuovo saldo B 1500
13Un'altra ancora
- update conti set saldo saldo 10.000 where
codice 'A' - rollback
- Ecco un assegno da 10.000
- Bene, il nuovo saldo è 11.000
- Ma l'assegno è falso!
- Annulliamo l'operazione
- Il saldo resta 1000
-
14Caratteristiche delle transazioni
- Le proprietà ACIDe
- Atomicità
- Consistenza
- Isolamento
- Durabilità (persistenza)
15Atomicità
- Una sequenza di operazioni correlate
- trasferimento di fondi da un conto A ad un conto
B - deve essere eseguita per intero o per niente
- o si fanno il prelevamento da A e il versamento
su B - o nessuno dei due
16Consistenza
- La transazione rispetta i vincoli di integrità
- Conseguenza
- se lo stato iniziale è corretto
- anche lo stato finale è corretto
- Se lo stato finale non è corretto, la transazione
deve fallire
17Isolamento
- La transazione non risente degli effetti delle
altre transazioni concorrenti - l'esecuzione concorrente di una collezione di
transazioni deve produrre un risultato che si
potrebbe ottenere con una esecuzione sequenziale - esempio
- due prelevamenti quasi contestuali
18Durabilità (Persistenza)
- Gli effetti di una transazione andata in commit
non vanno perduti ("durano per sempre"), anche in
presenza di guasti - "commit" significa "impegno"
19Transazioni e moduli di DBMS
- Atomicità e durabilità
- Gestore dell'affidabilità (Reliability manager)
- Isolamento
- Gestore della concorrenza
- Consistenza
- Gestore dell'integrità a tempo di esecuzione (con
il supporto del compilatore del DDL)
20Controllo di concorrenza, anomalie
- I tre esempi corrispondono a situazioni tipiche
- Due prelevamenti sullo stesso conto
- Perdita di aggiornamento (lost update)
- Interferenza fra due scritture
- Lettura prima del commit
- Lettura sporca (dirty read)
- Interferenza fra scrittura non confermata e
lettura - Scrittura fra le due letture
- Letture inconsistenti (inconsistent read)
- Interferenza fra lettura e scrittura
21Anomalie
- Perdita di aggiornamento W-W
- Lettura sporca R-W (o W-W) con abort
- Letture inconsistenti R-W
- Un'altra, che non abbiamo visto
- Inserimento fantasma R-W su dato "nuovo"
22Livelli di isolamento in SQL1999 (e JDBC)
- Il livello di isolamento può essere scelto per
ogni transazione - read uncommitted permette letture sporche,
letture inconsistenti, aggiornamenti fantasma e
inserimenti fantasma - read committed evita letture sporche ma permette
letture inconsistenti, aggiornamenti fantasma e
inserimenti fantasma - repeatable read evita tutte le anomalie esclusi
gli inserimenti fantasma - serializable evita tutte le anomalie
- Nota
- la perdita di aggiornamento dovrebbe essere
sempre evitata, ma non è così conviene usare
sempre serializable per le transazioni che
scrivono
23Anomalie e livelli di isolamento(per le
transazioni che leggono)
- Perdita di aggiornamento W-W
- read uncommitted
- Lettura sporca R-W (o W-W) con abort
- read committed
- Letture inconsistenti R-W
- repeatable read
- Inserimento fantasma R-W su dato "nuovo"
- serializable
24Livelli di isolamento, perché?
- La gestione del controllo della concorrenza è
costosa, se non serve, possiamo rinunciarci - Nota bene per le letture, non per le scritture
25Livelli di isolamento, esempi
- Una base di dati complessa, in un momento in cui
non ci sono aggiornamenti ("tempo morto") - non c'è bisogno di controllo di concorrenza
- read uncommitted
- Una banca, molti conti correnti, molte piccole
modifiche in corso, ci interessa un dato
indicativo sulla media dei saldi dei conti
correnti - le inconsistenze sono tollerabili (perché
presumibilmente piccole) - read committed
- Idem, ma ci interessa sapere qual è il conto con
il saldo più alto - ci serve un valore preciso, non possiamo
tollerare inconsistenze, nemmeno piccole - serializable
26Controllo di concorrenza
- Esistono libri interi dedicati alla teoria e alla
tecnologia, quindi in dieci minuti possiamo
vedere solo l'idea di base, accennando alle
tecniche
27Due prelevamenti da un conto corrente
- Quanto c'è sul conto?
- 1000
- Bene, allora prelevo 200
- Ok, il nuovo saldo è 800
- Quanto c'è sul conto?
- 1000
- Bene, allora prelevo 100
- Ok, il nuovo saldo è 900
28Schedule
- Sequenza di operazioni di input/output di
transazioni concorrenti (tralasciando le altre
operazioni) - Esempi
- Paperina e Paperino leggono e scrivono lo stesso
dato x, il saldo del conto (con perdita di
aggiornamento) - read1(x) read2(x) write1(x) write2(x)
- Paperino scrive fra due letture di Paperina
(letture inconsistenti) - read1(x) write2(x) write2(y) read1(y)
29Controllo di concorrenza
- Obiettivo evitare le anomalie
- Schedule seriale
- le transazioni sono separate, una alla volta
- read1(x) write1(x) read2(x) write2(x)
- uno schedule seriale non presenta anomalie
- Schedule serializzabile
- produce lo stesso risultato di uno schedule
seriale sulle stesse transazioni e quindi è
accettabile - Controllore di concorrenza (Scheduler)
- un sistema che accetta o rifiuta (o riordina) le
operazioni richieste dalle transazioni
(mantenendo l'ordine delle azioni in ciascuna
transazione) - deve ammettere solo schedule serializzabili
30Schedule non serializzabili
- Paperina e Paperino leggono e scrivono lo stesso
dato x, il saldo del conto (con perdita di
aggiornamento) - read1(x) read2(x) write1(x) write2(x)
- Le due letture vedono lo stesso dato, mentre in
caso di schedule seriale la seconda dovrebbe
vedere il dato modificato dalla prima e questo ha
conseguenze sulla seconda scriuttura - Paperino scrive fra due letture di Paperina
(letture inconsistenti) - read1(x) write2(x) write2(y) read1(y)
- Le due letture vedono, complessivamente, uno
stato della base di dati che non esiste e non è
mai esistito
31Idea base
- Individuare classi di schedule serializzabili per
i quali la proprietà di serializzabilità sia
verificabile a costo basso
Schedule
Schedule Serializzabili
32Gestore della concorrenza
Gestore dei metodi daccesso
Gestore delle transazioni
read, write
begin, commit, abort
Gestore della concorrenza
Tabella dei lock
read, write(non tutte e in ordine ev. diverso)
Gestore della memoria secondaria
BD
33Controllo della concorrenza in pratica
- Saltiamo la teoria
- Le tecniche utilizzate
- 2PL (two-phase locking)
- multiversion (evoluzione delle tecniche su
timestamp)
34Lock
- Principio
- su ciascun dato
- si scrive uno per volta
- non si può leggere se qualcuno sta scrivendo
- Analogo a quanto accade in altri contesti (ad
esempio, file system) ma con una granularità più
fine (o comunque flessibile) - Come si realizza
- Si chiede il permesso
- lo si ottiene se la risorsa (il dato) non è
utilizzata, in modo conflittuale, da altri - altrimenti si viene messi in attesa
- dopo l'uso, si rilascia la risorsa
35I lock da soli non bastano
- Posso leggere A?
- ok
- Quanto c'è sul conto A?
- 1000
- Ho finito con A (unlock)
- Posso leggere B?
- ok
- Quanto c'è sul conto B?
- 1500
- Ho finito con B (unlock)
- Ehi, abbiamo 2500!
- Posso scrivere A? Posso scrivere B?
- ok, ok
- Sposta 500 da A a B
- Nuovi saldi A 500, B 1500
- Ho finito con A e con B (unlock)
36Locking a due fasi (2PL)
- Protezione con lock di tutte le letture e
scritture, con - vincolo sulle richieste e i rilasci dei lock
- una transazione, dopo aver rilasciato un lock,
non può acquisirne altri - meglio ancora, per evitare le letture sporche
- ogni transazione mantiene i propri lock fino alla
fine (cioè fino al commit o al rollback)
37Il 2PL risolve
- Posso leggere A?
- ok
- Quanto c'è sul conto A?
- 1000
- Posso leggere B?
- ok
- Quanto c'è sul conto B?
- 1000
- Ho finito con A e con B (unlock)
- OK, abbiamo 2000!
- Posso scrivere A?
- No, aspetta!
- Ora puoi scrivere A
- Posso scrivere B?
- ok
- Sposta 500 da A a B
- Nuovi saldi A 500, B 1500
- Ho finito con A e con B (unlock)
38Stallo (deadlock)
- I lock possono portare a situazioni indesiderate
- attese incrociate due transazioni detengono
ciascuna una risorsa e aspettano la risorsa
detenuta dall'altra
39Stallo
- Posso leggere?
- ok
- Quanto c'è sul conto?
- 1000
- Posso scrivere?
- No, aspetta, qualcuno sta leggendo
- Posso leggere?
- ok
- Quanto c'è sul conto?
- 1000
- Posso scrivere?
- No, aspetta, qualcuno sta leggendo
Aspetta e spera!!!
40Risoluzione dello stallo
- La tecnica più semplice
- timeout
- si fissa un tempo limite per l'attesa da parte di
una transazione, dopo di che essa viene annullata
(ed eventualmente riparte)
412PL, stallo e riavvio
- Posso leggere?
- ok
- Quanto c'è sul conto?
- 1000
- Posso scrivere?
- No, aspetta, qualcuno sta leggendo
- Mi sono stancata di aspettare, smetto
- Ricomincio. Posso leggere?
- ok
- Quanto c'è sul conto?
- 900
- Posso leggere?
- ok
- Quanto c'è sul conto?
- 1000
- Posso scrivere?
- no, aspetta, qualcuno sta leggendo
- ora puoi scrivere
- Bene, allora prelevo 100
- ok, il nuovo saldo è 900
42Livelli di isolamento implementazione
- Sulle scritture si ha sempre il 2PL stretto (e
nonostante ciò che dicono i manuali non sempre si
evita la perdita di aggiornamento le transazioni
in scrittura debbono avere il livello massimo di
isolamento) - read uncommitted
- nessun lock in lettura (e non rispetta i lock
altrui) - read committed
- lock in lettura (e rispetta quelli altrui), ma
senza 2PL - repeatable read
- 2PL stretto anche in lettura, con lock sui dati
- serializable
- 2PL stretto con lock di predicato
43Controllo di concorrenza basato su multiversioni
- Per le letture
- si legge il valore valido all'inizio della
transazione - Per le scritture
- si usano lock per la sola scrittura e
- una transazione T viene annullata se deve
scrivere un dato che è stato modificato da altre
transazioni dopo l'inizio di T
44Lettura, scrittura, lettura con multiversioni
1000 sul conto A 1000 sul conto B
- Quanto c'è sul conto A?
- 1000
- Quanto c'è sul conto B?
- 1000 (il valore all'inizio della transazione)
- OK, abbiamo 2000!
- Sposta 500 da A a B
- Nuovo saldo A 500
- Nuovo saldo B 1500
45Due prelevamenticon multiversioni
- Quanto c'è sul conto?
- 1000
- Bene, allora prelevo 200
- Ok, il nuovo saldo è 800
- Ho finito (commit)
- Quanto c'è sul conto?
- 1000
- Bene, allora prelevo 100
- Aspetta, qualcuno sta scrivendo
- Ho provato a scrivere, ma qualcun altro ha
modificato il valore nel frattempo, debbo
annullare (rollback) - Ricomincio. Quanto c'è sul conto?
- 800
- Bene, allora prelevo 100
- Ok, il nuovo saldo è 700
46Conclusioni
- Il controllo di concorrenza è fondamentale per
garantire che le operazioni concorrenti - leggano dati coerenti
- non compromettano il contenuto della base di dati
- Il tutto deve essere fatto senza penalizzare
troppo l'efficienza - I sistemi offrono buone funzionalità per la
gestione della concorrenza basate su due tecniche - Locking a due fasi (2PL)
- Multiversioni
- Permettono anche di "rinunciare" ad un controllo
stringente, ma l'utente deve essere consapevole
di ciò che ottiene
47- Per approfondire il tutto ci vorrebbe molto più
tempo - Molti dettagli in rete o su libri.
- Ad esempio il sito del corso di Basi di dati II
- e quello dei libri di basi di dati,
- link sulla mia pagina
- http//www.dia.uniroma3.it/atzeni/
48Grazie!