PostGres - Transacções

Apresentação em tema: "PostGres - Transacções"— Transcrição da apresentação:

1 PostGres - Transacções
TBD Vladimir Luz

2 Sumário Níveis de isolamento Gestor de Transacções Locks em Índices
Read Committed Serializable Gestor de Transacções MVCC Locks Deadlock Locks em Índices

3 Níveis de Isolamento (1)
No SQL estão definidos quatro tipos de isolamento de transacções em função de três fenómenos que devem ser evitados Dirty read – uma transacção lê dados escritos por uma transacção que ainda não fez commit Nonrepeatable read – Uma transacção lê dados que já tinha lido antes e que entretanto foram modificados por outra transacção que fez commit Phantom read – uma transacção volta a executar uma query devolvendo um conjunto de tuplos e verifica que o conjunto dos tuplos devolvidos é diferente da execução anterior

4 Níveis de Isolamento (2)
Níveis de isolamento e comportamento Nivel de Isolamento Dirty Read Unrepeatable Read Phantom Read Read Uncommitted  Read Committed  Reapeted read Serializable Pode ser requerido qualquer dos níveis de isolamento Internamente: Apenas existe os níveis read commited e serializable read uncommitted é tratado como read committed e o repeated read é tratado como serializable Os quatro níveis apenas determinam que fenómenos não podem ocorrer

5 Níveis de Isolamento (3)
Read Committed Nível de isolamento por defeito no PostGres Um SELECT vê apenas dados que já fizeram commit. Vê um snapshot da base de dados na altura em que começa a query Comandos de UPDATE e DELETE comportam se da mesma forma Nunca vê dados que não fizeram commit ou dados que fizeram commit depois da execução da transacção ter começado O select vê apenas um snapshot da base dados na altura em que se inicia No caso do UPDATE os dados podem já ter sido alterados, neste caso updater espera que a transacção que alterou os dados faça commit ou roll back. Se fizer roll back o segundo UPDATE pode proceder, se fizer commit, no caso de ter sido apagado o segundo UPDATE ignora os dados, caso contrario, Vai tentar escrever os dados. A condição de procura é reavaliada (WHERE) para ver se a versão dos dados ainda satisfazem a condição, se sim o UPDATE procede partindo da informação actualizada.

6 Níveis de Isolamento (4)
Serializable Simula as execução das transacções em série como se elas fossem executadas uma depois da outra No caso de SELECT o funcionamento é análogo ao read commited Difere no snapshot que vê, pois vê o snapshot na altura do início da transacção Comandos de UPDATE E DELETE também vêem o snapshot do inicio da transacção Selects sucessivos na mesma transacção vêem sempre os mesmo dados No caso do UPDATE os dados podem já ter sido alterados, neste caso updater espera que a transacção que alterou os dados faça commit ou roll back. Se fizer roll back o segundo UPDATE pode proceder, se fizer commit, no caso de ter sido apagado o segundo UPDATE ignora os dados, caso contrario, se o primeiro update fizer commit, a transacção faz rollback com uma mensagem de erro ERROR: could not serialize access due to concurrent update

7 Gestor de Transacções Usa um modelo multi-versão
Multiversion Concurrency Control, MVCC Usado em Statements DML Usa um sistema de locks Two-Phase-Locking Usado em statements DDL DML – Data Manipulation Language DLL – Data Definition Language

8 MVCC(1) MVCC A ideia é mater duas versões de uma linha que corresponde a diferentes instancias da linha em pontos diferentes no tempo Garante que as transacções apenas vêem os dados que são consistentes nessa altura Vê um snapshot da base de dados com apenas os dados que fizeram commit Não implementa locks para os comandos DML

9 MVCC (2) Vantagens Os leitores nunca bloqueiam os escritores
Os escritores criam as suas próprias para as actualizarem Os leitores acedem a versão mais recente dos dados que é parte do snapshot. Como não usa locks não precisa interagir com o lock manager

10 MVCC (3) Desvantagens Sobrecarga extra para o storage manager porque tem de manter diferentes versões para os tuplos O desenvolvimento de aplicações concorrentes requer mais cuidado, pois leva a diferentes comportamentos na forma como as transacções se comportam. A performance depende das características da carga de trabalho a correr Não protege em relação a procedimentos que afectem a tabela inteira Para suavizar o primeiro problema o PostGres liberta espaço periodicamente identificando e apagando versões dos dados que já não são necessários Não protege os dados fase a drops de tabelas de transacções concorrentes

11 Locks Usa um sistema de two-phase locking
Comandos DDL são forçados a adquirir um lock antes de iniciarem a sua execução Locks são guardados numa tabela de locks que é implementada com uma tabela de hash de memória partilhada. Os locks são implementados através de semáforos Cada transacção tem um semáforo associado a ela A tabela de locks é implementada no ficheiro lmrg.c Quando uma transacção espera por um lock, ela na realidade espera no semáforo associado a transacção que detém o loc. Quando a transacção que tem o lock o liberta, avisa a outra transacção através do lock

12 Deadlocks A detecção de deadlocks é baseada num sistema de time-outs
O sistema de detecção é activado se uma transacção espera por mais de um segundo pela obtenção de um lock O algoritmo constrói um grafo baseado na informação na tabela de locks e procura dependências circulares Se encontrar alguma, então é porque há um deadlock A transacção que originou a detecção é abortada e retorna um erro para o utilizador Caso contrario continua a espera do lock

13 Locks em Índices Os locks dependem do tipo de índice B-Tree e GiST
Locks partilha/exclusivos ao nível das paginas Locks são libertados logo depois de cada folha é acedida Não origina deadlocks Hash Locks partilha/exclusivos ao nível dos buckets Melhor nível de concorrência mas pode gerar deadlocks R-Tree Locks partilha/exclusivos ao nível do índice Locks libertados depois de todo o comando estar terminado O tipo de índice recomendado para aplicações com um elevado grau de concorrência são índices B-tree porque não geram deadlocks

14 Bibliografia Silberschatz, Abraham, Database System Concepts, 5ª Edição PostgreSQL Documentation Lane, Tom, Transaction Processing in PostgreSQL