La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Tecnologie di un database server: la gestione della concorrenza Paolo Atzeni Roma – Rovereto 13/05/2011.

Presentazioni simili


Presentazione sul tema: "Tecnologie di un database server: la gestione della concorrenza Paolo Atzeni Roma – Rovereto 13/05/2011."— Transcript della presentazione:

1 Tecnologie di un database server: la gestione della concorrenza Paolo Atzeni Roma – Rovereto 13/05/2011

2 Gestione della concorrenza2 Base 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à

3 Molte richieste contemporanee o quasi Conti correnti bancari, prenotazioni aeree o ferroviarie: anche centinaia o migliaia di aggiornamenti attivi in un ogni momento 13/05/2011Gestione della concorrenza3

4 Due 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 è /05/2011Gestione della concorrenza4

5 13/05/2011Gestione della concorrenza5 Qual è 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

6 Lettura, scrittura, lettura 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: /05/2011Gestione della concorrenza sul conto A 1000 sul conto B

7 Lettura prima della conferma (commit) Quanto c'è sul conto? – Abbiamo !?! Paperina ha letto un dato sbagliato! Ecco un assegno da –Bene, il nuovo saldo è –Ma l'assegno è falso! –Annulliamo l'operazione –Il saldo resta /05/2011Gestione della concorrenza sul conto

8 13/05/2011Gestione della concorrenza8 La concorrenza va governata: –va permessa per favorire l'efficienza –ma limitata, per evitare i problemi

9 07/10/2010Atzeni-Ceri-Paraboschi-Torlone, Basi di dati, Capitolo 19 Un concetto importante Transazione: –Sequenza di operazioni da considerare indivisibile ("atomica"), corretta anche in presenza di concorrenza e con effetti definitivi

10 13/05/2011Gestione della concorrenza10 Transazioni, 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)

11 Una transazione Quanto c'è sul conto? –1000 Bene, allora prelevo 200 –Ok, il nuovo saldo è 800 declare s money; select saldo into s from conti where numero = 101; update conti set saldo = s where numero = 101; commit; 13/05/2011Gestione della concorrenza11

12 Un'altra transazione Sposta 500 da A a B –Nuovo saldo A: 500 –Nuovo saldo B: /05/2011Gestione della concorrenza12 update conti set saldo = saldo where codice = 'A' update conti set saldo = saldo where codice = 'B' commit

13 Un'altra ancora Ecco un assegno da –Bene, il nuovo saldo è –Ma l'assegno è falso! –Annulliamo l'operazione –Il saldo resta 1000 – 13/05/2011Gestione della concorrenza13 update conti set saldo = saldo where codice = 'A' rollback

14 07/10/2010Atzeni-Ceri-Paraboschi-Torlone, Basi di dati, Capitolo 114 Caratteristiche delle transazioni Le proprietà ACIDe –Atomicità –Consistenza –Isolamento –Durabilità (persistenza)

15 07/10/2010Atzeni-Ceri-Paraboschi-Torlone, Basi di dati, Capitolo 115 Atomicità 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

16 31/03/2011Basi di dati, vol.2 cap.2 Gestione delle transazioni...16 Consistenza 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

17 31/03/2011Basi di dati, vol.2 cap.2 Gestione delle transazioni...17 Isolamento 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

18 31/03/2011Basi di dati, vol.2 cap.2 Gestione delle transazioni...18 Durabilità (Persistenza) Gli effetti di una transazione andata in commit non vanno perduti ("durano per sempre"), anche in presenza di guasti –"commit" significa "impegno"

19 13/05/2011Gestione della concorrenza19 Transazioni 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)

20 13/05/2011Gestione della concorrenza20 Controllo 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

21 13/05/2011Gestione della concorrenza21 Anomalie Perdita di aggiornamento W-W Lettura sporca R-W (o W-W) con abort Letture inconsistentiR-W Un'altra, che non abbiamo visto Inserimento fantasma R-W su dato "nuovo"

22 13/05/2011Gestione della concorrenza22 Livelli di isolamento in SQL:1999 (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

23 13/05/2011Gestione della concorrenza23 Anomalie 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 inconsistentiR-W repeatable read Inserimento fantasma R-W su dato "nuovo" serializable

24 13/05/2011Gestione della concorrenza24 Livelli di isolamento, perché? La gestione del controllo della concorrenza è costosa, se non serve, possiamo rinunciarci Nota bene: per le letture, non per le scritture

25 13/05/2011Gestione della concorrenza25 Livelli 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

26 13/05/2011Gestione della concorrenza26 Controllo 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

27 Due 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 è /05/2011Gestione della concorrenza27

28 13/05/2011Gestione della concorrenza28 Schedule 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) read 1 (x) read 2 (x) write 1 (x) write 2 (x) –Paperino scrive fra due letture di Paperina (letture inconsistenti) read 1 (x) write 2 (x) write 2 (y) read 1 (y)

29 13/05/2011Gestione della concorrenza29 Controllo di concorrenza Obiettivo: evitare le anomalie Schedule seriale: –le transazioni sono separate, una alla volta read 1 (x) write 1 (x) read 2 (x) write 2 (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

30 13/05/2011Gestione della concorrenza30 Schedule non serializzabili Paperina e Paperino leggono e scrivono lo stesso dato x, il saldo del conto (con perdita di aggiornamento) read 1 (x) read 2 (x) write 1 (x) write 2 (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) read 1 (x) write 2 (x) write 2 (y) read 1 (y) –Le due letture vedono, complessivamente, uno stato della base di dati che non esiste e non è mai esistito

31 13/05/2011Gestione della concorrenza31 Idea base Individuare classi di schedule serializzabili per i quali la proprietà di serializzabilità sia verificabile a costo basso Schedule Seriali Schedule Serializzabili

32 13/05/2011Gestione della concorrenza32 Gestore della concorrenza BD Gestore della memoria secondaria Gestore dei metodi daccesso Gestore delle transazioni Gestore della concorrenza read, writebegin, commit, abort read, write (non tutte e in ordine ev. diverso) Tabella dei lock

33 13/05/2011Gestione della concorrenza33 Controllo della concorrenza in pratica Saltiamo la teoria … Le tecniche utilizzate –2PL (two-phase locking) –multiversion (evoluzione delle tecniche su timestamp)

34 13/05/2011Gestione della concorrenza34 Lock 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;

35 I 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) 13/05/2011Gestione della concorrenza35

36 13/05/2011Gestione della concorrenza36 Locking 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)

37 Il 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) 13/05/2011Gestione della concorrenza37

38 13/05/2011Gestione della concorrenza38 Stallo (deadlock) I lock possono portare a situazioni indesiderate: –attese incrociate: due transazioni detengono ciascuna una risorsa e aspettano la risorsa detenuta dall'altra

39 Stallo 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 13/05/2011Gestione della concorrenza39 Aspetta e … spera!!!

40 13/05/2011Gestione della concorrenza40 Risoluzione 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)

41 2PL, 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 scrivere? –ok, puoi scrivere Bene, allora prelevo 200 –Ok, il nuovo saldo è 700 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 è /05/2011Gestione della concorrenza41

42 13/05/2011Gestione della concorrenza42 Livelli 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

43 13/05/2011Gestione della concorrenza43 Controllo 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

44 Lettura, scrittura, lettura con multiversioni 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: /05/2011Gestione della concorrenza sul conto A 1000 sul conto B

45 Due prelevamenti con 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 è /05/2011Gestione della concorrenza45

46 Conclusioni 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 13/05/2011Gestione della concorrenza46

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: 13/05/2011Gestione della concorrenza47

48 Grazie! 13/05/2011Gestione della concorrenza48


Scaricare ppt "Tecnologie di un database server: la gestione della concorrenza Paolo Atzeni Roma – Rovereto 13/05/2011."

Presentazioni simili


Annunci Google