BDD - Gerencia de Transacoes Distribuidas
Propaganda
Transação Gerência de Transações Distribuídas Fernanda Baião [email protected] Uma transação é uma unidade de computação consistente e confiável Transparência de concorrência Transparência de falhas Banco de dados em um estado consistente Banco de dados pode estar em um estado inconsistente durante a execução Begin Transaction execução da transação Banco de dados em um estado consistente Outubro de 2003 End Transaction © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Transação – Exemplo Consulta SQL Simples 2 Banco de Dados exemplo Transaction BUDGET_UPDATE Considere uma base de reservas aéreas com as relações begin EXEC SQL FLIGHT(FNO, DATE, SRC, DEST, STSOLD, CAP) CUST(CNAME, ADDR, BAL) FC(FNO, DATE, CNAME,SPECIAL) UPDATE PROJ SET BUDGET = BUDGET * 1.1 WHERE PNAME = “CAD/CAM” end. © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 3 Transação exemplo – Versão SQL 4 Terminação de Transações Begin_transaction Reservation begin input(flight_no, date, customer_name); EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date; EXEC SQL INSERT INTO FC(FNO, DATE, CNAME, SPECIAL); VALUES (flight_no, date, customer_name, null); output(“reservation completed”) end . {Reservation} © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 5 Begin_transaction Reservation begin input(flight_no, date, customer_name); EXEC SQL SELECT STSOLD,CAP INTO temp1,temp2 FROM FLIGHT WHERE FNO = flight_no AND DATE = date; if temp1 = temp2 then output(“no free seats”); Abort else EXEC SQL UPDATEFLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date; EXEC SQL INSERT INTO FC(FNO, DATE, CNAME, SPECIAL); VALUES (flight_no, date, customer_name, null); Commit output(“reservation completed”) endif end . {Reservation} © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 6 1 Transação exemplo – Leituras e Escritas Caracterização Begin_transaction Reservation begin input(flight_no, date, customer_name); temp ← Read(flight_no(date).stsold); if temp = flight(date).cap then begin output(“no free seats”); Abort end else begin Write(flight(date).stsold, temp + 1); Write(flight(date).cname, customer_name); Write(flight(date).special, null); Commit; output(“reservation completed”) end end. {Reservation} ATOMICIDADE Tudo ou nada Em caso de falha, resultados parciais são desfeitos Recuperação de transação x recuperação de falha Read(x) Read(y) x ←x + y Write(x) Commit CONSISTÊNCIA Não viola restrições de integridade (programa correto) Vários “graus”: T não sobrescreve dados ainda em atualização por outra transação (“sujos”), T não efetiva nenhuma escrita entes do EOT, T não lê dados sujos, dados lidos por T não são sujos antes do seu término ISOLAMENTO Atualizações concorrentes são invisíveis Se várias transações são executadas concorrentemente, os resultados devem ser os mesmos como se elas fossem executadas serialmente em alguma ordem DURABILIDADE Atualizações completadas com sucesso (commit) são persistentes 9 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Isolamento - Exemplo T2: Read(x) x ←x+1 Write(x) Commit Read(x) x ←x+1 Write(x) Commit Read(x) x ←x+1 Write(x) Commit T1: T1: T2: T1: T2: T2: T1: T2: Áreas das aplicações Duração da transação Organização das ações de leitura e atualização © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Dados sujos e atualização perdida! on-line (curta duração) x batch (longa duração) duas etapas (primeiro leituras, depois escritas) restrita (toda atualização é precedida de uma leitura) modelo de ação (restrita, cada par <leitura, escrita> é executado de forma atômica) Estrutura 11 não distribuídas x distribuídas transações compensatórias transações heterogêneas Read(x) x ←x+1 Read(x) Write(x) x ←x+1 Write(x) Commit Commit 10 Baseados em Sequências de execução possíveis T1: T1: T1: T1: T2: T2: T2: T2: © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Tipos de Transações Considere as 2 transações Read(x) x ←x+1 Write(x) Commit 8 Propriedades das Transações Considere a transação T1: RS ∪ WS © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Conjunto de itens de dados modificados por uma transação Conjunto base (BS) Representação DAG Conjunto de itens de dados lidos por uma transação Conjunto escrita (WS) 7 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Conjunto leitura (RS) transações planas transações aninhadas workflows © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 12 2 Workflow - Exemplo © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Modelo de Arquitetura 13 Execução de Transações Centralizadas © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Execução de Transações Distribuídas 15 Escalonamento (Schedule, ou History) de Execução O problema de sincronizar transações concorrentes de forma a manter a consistência do banco de dados e atingir, ao mesmo tempo, nível elevado de concorrência Anomalias: Atualizações perdidas 16 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Controle Distribuído da Concorrência 14 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Os efeitos de algumas transações não são refletidos no banco A ordem na qual as operações de um conjunto de transações são executadas, intercaladamente T1: Read(x) Write(x) Commit T2: Write(x) Write(y) Read(z) Commit T3: Read(x) Read(y) Read(z) Commit Leituras inconsistentes Se uma transação lê um mesmo item de dado mais de uma vez, deve sempre encontrar o mesmo valor © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) H1={W2(x),R1(x), R3(x),W1(x),C1,W2(y),R3(y),R2(z),C2,R3(z),C3} 17 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 18 3 Escalonamento de Execução Escalonamento Completo - Exemplo Dadas 3 transações T1 : Read(x) Write(x) Commit 2 operações Oij(x) e Okl(x) estão em conflito se pelo menos 1 delas é operação de gravação leitura-gravação, gravação-gravação ordem de execução é importante T2 :Write(x) Write(y) Read(z) Commit T3 :Read(x) Read(y) Read(z) Commit Um possível escalonamento completo é dado como o DAG Escalonamento completo estabelece a ordem de execução de todas as operações em seu domínio falhas resultam em escalonamentos incompletos... como lidar com eles? 19 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Algoritmos de Controle de Concorrência Sincronizam execução concorrente de transações mais cedo Algoritmos de Controle da Concorrência Pessimistas Bloqueio (2PL) Ordenação de timestamp Algoritmos de Controle de Concorrência Atrasam a sincronização das transações até o seu término Bloqueio Ordenação de timestamp Centralizado Básicos Cópia Primária Várias Versões Distribuídos Conservativos © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 21 rl yes no Write Compute Validate Write 22 Bloqueio em 2 fases (2PL) Transações indicam suas intenções solicitando bloqueios do escalonador (gerenciador de bloqueios). Bloqueios podem ser de leitura (rl) [bloqueio compartilhado] ou bloqueio de gravação (wl) [bloqueio exclusivo] Bloqueios de leitura e de gravação conflitam (porque operações de leitura e escrita são incompatíveis rl wl Compute © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Read Otimistas Read Algoritmos de Bloqueio Pessimistas Validate Otimistas Híbridos 20 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Uma transação bloqueia um objeto antes de usá-lo Quando um objeto está bloqueado por outra transação, a transação solicitante do bloqueio deve aguardar Quando uma transação libera um bloqueio, não pode solicitar outro bloqueio wl no no Bloqueios funcionam bem ao permitir processamento concorrente de transações © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 23 © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 24 4 Ordenação por timestamp Algoritmos de CC Otimistas É atribuído um timestamp único global ts(Ti ) para cada transação (Ti ) Gerenciador de transações atribui o timestamp a todas as operações da transação A cada item de dado é atribuído um timestamp de gravação (wts) e um timestamp de leitura (rts) rts(x) = maior timestamp das transações que leram x wts(x) = maior timestamp das transações que gravaram x Operações conflitantes são resolvidas pela ordem do timestamp. Algoritmo básico: for Ri (x) if ts(Ti) < wts(x) then reject Ri(x) else accept Ri(x) rts(x) <- ts(Ti) for Wi (x) if ts(Ti)<rts(x) and ts(Ti)<wts(x) then reject Wi(x) else accept Wi(x) wts(x) <- ts(Ti) © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 25 Teste de Validação de CC Otimistas Nível mais alto de concorrência Custo de armazenamento mais elevado Um impasse pode ocorrer porque as transações esperam uma pela outra Uma transação está em “deadlock” se está bloqueada e permanecerá assim até que ocorra uma intervenção externa Algoritmos de CC baseados em bloqueio podem resultar em impasses Algoritmos de ordenação de timestamp que exigem a espera de transações também podem causar impasses Gráfico de espera (Wait-for graph – WFG) 27 WFG locais x globais Existe um arco Ti →Tj no WFG se a transação Ti estiver esperando que outra transação Tj libere um bloqueio sobre alguma entidade. © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 28 Gerência de Impasses Ignorar… Prevenção Garantir que os impasses nunca ocorram. Gerenciador de transações verifica uma transação quando ela é iniciada e não permite que ela prossiga se houver possibilidade de impasse. Não exigem suporte em tempo de execução. Não adequada p/ SGBD Detectam situações potenciais de impasse com antecedência e asseguram que eles não ocorrerão (ordem pré-definida, timestamp). Exigem suporte em tempo de execução. Detecção e Recuperação (mais popular) 29 Deixe que o programador da aplicação lide com ele, ou re-inicie o sistema Anulação © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 26 Impasses (Deadlocks) Ordens possíveis © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Tij : transação Ti que executa no nó j Transações executam independentemente em cada nó até que alcançam o final da sua fase de leitura Todas as subtransações recebem um timestamp no final da sua fase de leitura Teste de Validação realizado durante a fase de validação. Se um falha, todas são rejeitadas © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) Modelo de execução da transação: dividir em subtransações, cada uma executando em um nó Permitem que impasses ocorram, detectam-nos monitorando formação de ciclos no WFG e rompendo-os. Exigem suporte em tempo de execução © 1998 M. Tamer Özsu e Patrick Valduriez (tradução livre e adaptações Fernanda Baião) 30 5
