Architetture distribuite

Transcript

1 Architetture distribuite -ARC 1

2 Basi di dati distribuite a RETE : LAN (Local Area Network) WAN (Wide Area Network) b DBMS : Sistema omogeneo Sistema eterogeneo SYBASE ORACLE DB2 CLIENT -ARC 2

3 Problemi delle basi di dati distribuite Autonomia vs cooperazione Trasparenza Efficienza Affidabilità -ARC 3

4 Autonomia e cooperazione L'esigenza di autonomia: - Portare competenze e controllo laddove vengono gestiti i dati - Rendere la maggior parte delle applicazioni NON distribuite (!) L'esigenza di cooperazione: - Alcune applicazioni sono intrinsecamente distribuite e richiedono l'accesso a piu' basi di dati -ARC 4

5 Frammentazione dei dati Scomposizione delle tabelle in modo da consentire la loro distribuzione proprieta': - Completezza - Ricostruibilita' -ARC 5

6 Frammentazione orizzontale FRAMMENTI: insiemi di tuple COMPLETEZZA: presenza di tutte le tuple FR1 FR2 FR3 RICOSTRUZIONE: unione -ARC 6

7 Frammentazione verticale FRAMMENTI: insiemi di attributi COMPLETEZZA: presenza di tutti gli attributi FR1 FR2 FR3 RICOSTRUZIONE: join sulla chiave -ARC 7

8 Esempio: conti correnti bancari CONTO-CORRENTE (NUM-CC,NOME,FILIALE,SALDO) TRANSAZIONE (NPROG, NUM-CC,DATA, OPERAZIONE, AMMONTARE, CAUSALE) CENTRO FILIALE1 FILIALE2 FILIALE3 -ARC 8

9 Frammentazione orizzontale principale Ri = σ Pi R esempio: CONTO1 = σ Filiale=1 CONTO-CORRENTE CONTO2 = σ Filiale=2 CONTO-CORRENTE CONTO3 = σ Filiale=3 CONTO-CORRENTE -ARC 9

10 Frammentazione orizzontale derivata Si = S < Ri esempio: TRANS1 = TRANSAZIONE < CONTO1 TRANS2 = TRANSAZIONE < CONTO2 TRANS3 = TRANSAZIONE < CONTO3 -ARC 10

11 Allocazione dei frammenti CENTRO CONTO1 CONTO2 CONTO3 TRANS1 TRANS2 TRANS3 CONTO1 CONTO2 CONTO3 TRANS1 TRANS2 TRANS3 FILIALE 1 FILIALE 2 FILIALE 3 -ARC 11

12 Livelli di trasparenza Modalita per esprimere interrogazioni offerte dai DBMS commerciali: LIVELLI: FRAMMENTAZIONE ALLOCAZIONE LINGUAGGIO -ARC 12

13 Trasparenza di frammentazione QUERY : estrarre il saldo del conto corrente 45 SELECT SALDO FROM CONTO-CORRENTE WHERE NUM-CC=45 -ARC 13

14 Trasparenza di allocazione IPOTESI : Allocazione incerta, probabilmente alla filiale 1 SELECT SALDO FROM CONTO1 WHERE NUM-CC=45 IF (NOT FOUND) THEN ( SELECT SALDO FROM CONTO2 WHERE NUM-CC=45 UNION SELECT SALDO FROM CONTO3 WHERE NUM-CC=45 ) -ARC 14

15 Trasparenza di linguaggio SELECT SALDO FROM WHERE NUM-CC=45 IF (NOT FOUND) THEN ( SELECT SALDO FROM CONTO2@2 WHERE NUM-CC=45 UNION SELECT SALDO FROM CONTO3@3 WHERE NUM-CC=45 ) -ARC 15

16 Efficienza Ottimizzazione delle query Modalita' di esecuzione - seriale - parallela -ARC 16

17 Esecuzione seriale CENTRO CONTO2 CONTO3 CLIENT CONTO1 FILIALE1 -ARC 17

18 Esecuzione parallela CLIENT CONTO1 CONTO2 CONTO3 FILIALE1 FILIALE2 FILIALE3 -ARC 18

19 Protocolli di commit -ARC 19

20 Transazioni distribuite BEGIN TRANSACTION UPDATE SET SALDO=SALDO WHERE NUM-CC=45; UPDATE CONTO2@2 SET SALDO=SALDO WHERE NUM-CC=35; COMMIT-WORK END TRANSACTION -ARC 20

21 Transazioni distribuite CLIENT FILIALE1 FILIALE2 -ARC 21

22 Proprieta' ACIDe dell esecuzione distribuita Isolamento se ciascuna sottotransazione e' a due fasi la transazione e' globalmente serializzabile Persistenza se ciascuna sottotransazione gestisce correttamente i log, i dati sono globalmente persistenti Consistenza se ciascuna sottotransazione preserva l'integrita' locale i dati sono globalmente consistenti Atomicita' e' il principale problema delle transazioni distribuite -ARC 22

23 Guasti in un sistema distribuito Caduta di nodi Perdita di messaggi Interruzione della rete MSG -ARC 23

24 Protocolli distribuiti e perdita di messaggi A: SEND(B,MSG) B: RECEIVE(MSG) SEND(A,ACK) A: RECEIVE(ACK) -ARC 24

25 Commit a due fasi Protocollo per garantire l'atomicita' di sotto-transazioni distribuite Protagonisti - un coordinatore (Transaction Manager, TM) - molti partecipanti (Resource Manager, RM) Come un matrimonio - fase uno: dichiarazione di intenti - fase due: dichiarazione del matrimonio -ARC 25

26 Record nel log del coordinatore a PREPARE: identita' dei partecipanti b GLOBAL COMMIT/ABORT: decisione c COMPLETE: termine del protocollo Record nel log del partecipante a READY: disponibilita' al commit b LOCAL COMMIT/ABORT: decisione ricevuta -ARC 26

27 Fase 1 C: WRITE-LOG(PREPARE) SET TIME-OUT SEND (Pi,PREPARE) Pi: RECEIVE(C,PREPARE) IF OK THEN WRITE-LOG(READY) MSG=READY ELSE MSG=NO SEND (C,MSG) -ARC 27

28 Fase 2 C: RECEIVE(Pi,MSG) IF TIME-OUT OR ONE(MSG)=NO THEN WRITE-LOG(GLOBAL-ABORT) DECISION=ABORT ELSE WRITE-LOG(GLOBAL-COMMIT) DECISION=COMMIT SEND(Pi,DECISION) C: RECEIVE(Pi,ACK) WRITE-LOG(COMPLETE) Pi: RECEIVE(C,DECISION) IF COMMIT THEN WRITE-LOG(COMMIT) ELSE WRITE-LOG(ABORT) SEND (C,ACK) -ARC 28

29 Diagramma del commit a due fasi PREPARE coordinatore GLOBAL DECISION COMPLETE t PREPARE MSG DECISION ACK partecipante READY LOCAL DECISION t -ARC 29

30 Protocollo 2PCommit con time-out e finestra di incertezza Prepare Global Decision Complete time-out 1 time-out 2 TM prepare msg ready msg decision msg ack msg Ready Local Decision RM Finestra di incertezza -ARC 30

31 Incertezza Un RM dopo essersi dichiarato ready perde la sua autonomia e attende la decisione del TM. Un guasto del TM lascia l RM in uno stato di incertezza, in cui tutte le risorse acquisite con lock sono bloccate. L intervallo tra la scrittura dei record ready e commit o abort è chiamato finestra di incertezza. Il protocollo è progettato per minimizzare la sua durata. -ARC 31

32 Complessità del protocollo Deve poter gestire tutti i guasti: - caduta del coordinatore - caduta di uno o più partecipanti - perdite di messaggi I protocolli di recovery sono svolti dai TM o RM dopo i guasti; ristabiliscono uno stato finale corretto -ARC 32

33 Perdita di messaggi La perdita dei messaggi di prepare o ready sono indistinguibili; in entrambi i casi scatta il time-out sul TM e viene deciso un global abort. La perdita dei messaggi decision or ack sono pure indistinguibili. In entrambi i casi scatta il time-out sul TM e viene ripetuta la seconda fase. -ARC 33

34 Recovery dei partecipanti Viene svolto con ripresa a caldo; per ogni transazione dipende dall ultimo record (azione) nel log: Se è una azione generica oppure un abort tutte le azioni sono disfatte; se è un commit, le azioni vengono rifatte; Se è un ready, il guasto è accaduto durante il commit a due fasi; il partecipante è in dubbio circa l esito della transazione. Durante il protocollo di ripresa a caldo, si collezionano tutte le transazioni in dubbio; di esse si chiede l esito ai rispettivi TM (richiesta di recovery remota). -ARC 34

35 Recovery del coordinatore Quando l ultimo record nel log è un prepare, il guasto del TM può essere la causa di un blocco di qualche RM. Il TM ha due opzioni: Scrivere global abort sul log, e comunicare decisione ripetendo la seconda fase del protocollo di commit a due fasi (Ripetere la prima fase, provando a raggiungere un commit globale) Quando l ultimo record è la una decisione globale, alcuni RM potrebbero essere bloccati. Il TM deve ripetere la seconda fase del protocollo, ricomunicando la decisione. -ARC 35

36 Protocollo di abort presunto E una ottimizzazione, usata da tutti i sistemi commerciali: Se un TM riceve una richiesta di remote recovery da un RM in dubbio di cui non ha traccia, risponde per default che la transazione ha fatto un global abort -ARC 36

37 Ottimizzazione read-only Quando un RM svolge solo operazioni di lettura, Risponde read-only al messaggio di prepare message e esce dal protocollo. Il TM ignora tutti gli RM read-only nella seconda fase del protocollo. -ARC 37

38 Standardizzazione del protocollo Standard X-open Distributed Transaction Processing (DTP): - commit a 2 fasi con ottimizzazioni - molti DBMS sul mercato -ARC 38