Gestão de Transações e Concorrência
A gestão de transações e o controlo de concorrência permitem que uma base de dados execute muitas transações concorrentes corretamente e sobreviva a falhas, garantindo as propriedades de atomicidade, consistência, isolamento e durabilidade (ACID).
Definition
Uma transação é uma sequência de operações de base de dados executadas como uma única unidade lógica que é atómica, preserva a consistência, é isolada de transações concorrentes e durável uma vez confirmada; a gestão de transações é o conjunto de mecanismos que impõem estas propriedades sob concorrência e falha.
Scope
Esta área abrange a transação como unidade de trabalho e os mecanismos que tornam correta a execução concorrente e propensa a falhas: as propriedades ACID; a serializabilidade como critério de correção para a concorrência; os protocolos de bloqueio, carimbo de tempo e multiversão que a impõem; os níveis de isolamento mais fracos que trocam consistência por desempenho; e as técnicas de registo e recuperação que garantem atomicidade e durabilidade em caso de falhas. Exclui o commit distribuído em múltiplos locais, que é tratado na área de bases de dados distribuídas e paralelas.
Sub-topics
Core questions
- O que as propriedades ACID garantem e por que são necessárias?
- O que torna um agendamento concorrente correto, ou seja, serializável?
- Como os protocolos de bloqueio, carimbo de tempo e multiversão impõem a serializabilidade?
- Como o registo e a recuperação restauram um estado consistente após uma falha?
- Como os níveis de isolamento mais fracos trocam consistência por concorrência?
Key concepts
- transação e commit/abort
- propriedades ACID
- serializabilidade e o grafo de precedência
- bloqueio em duas fases
- ordenação por carimbo de tempo
- controlo de concorrência multiversão
- deteção e prevenção de deadlock
- registo write-ahead
- níveis de isolamento
Key theories
- Propriedades ACID
- Atomicidade (execução tudo ou nada), consistência (preservação de restrições de integridade), isolamento (transações concorrentes parecem ser executadas sozinhas) e durabilidade (efeitos confirmados sobrevivem a falhas) definem em conjunto o comportamento transacional correto.
- Serializabilidade
- Um agendamento concorrente é correto se for equivalente a alguma execução serial; a serializabilidade de conflito, testada através do grafo de precedência (serialização), é o critério prático que os protocolos de controlo de concorrência impõem.
- Controlo de concorrência e recuperação
- Os métodos de bloqueio, ordenação por carimbo de tempo e multiversão previnem intercalações não serializáveis, enquanto os algoritmos de registo write-ahead e recuperação garantem atomicidade e durabilidade, as duas metades do processamento correto de transações.
Clinical relevance
A gestão de transações é o que torna as bases de dados fiáveis para dinheiro e registos: garante que uma transferência bancária nunca debita uma conta sem creditar outra, que uma companhia aérea nunca reserva duplamente um lugar sob pedidos concorrentes, e que os dados confirmados sobrevivem a falhas, sustentando todos os sistemas transacionais fiáveis.
History
O conceito de transação e as propriedades ACID foram formalizados no System R da IBM na década de 1970; Eswaran e colegas (1976) estabeleceram noções de consistência e bloqueio, Jim Gray definiu transações e recuperação, e Bernstein, Hadzilacos e Goodman (1987) sistematizaram a teoria da serializabilidade. As contribuições de Gray para o processamento de transações valeram-lhe o Prémio Turing.
Key figures
- Jim Gray
- Philip Bernstein
- Andreas Reuter
Related topics
Seminal works
- gray1992
- bernstein1987
- eswaran1976
Frequently asked questions
- O que significa para um agendamento de transações ser serializável?
- Um agendamento concorrente é serializável se o seu efeito geral for idêntico à execução das mesmas transações uma após a outra em alguma ordem. A serializabilidade é o critério de correção padrão-ouro: embora as transações se intercalem para desempenho, o resultado é como se tivessem sido executadas serialmente, de modo que nenhuma transação vê um estado intermediário inconsistente.
- Por que são permitidos níveis de isolamento mais fracos se eles podem produzir anomalias?
- Impor a serializabilidade completa tem um custo de desempenho em contenção de bloqueios e abortos. Muitas aplicações podem tolerar certas anomalias em troca de maior concorrência, então o padrão SQL define níveis de isolamento mais fracos (leitura confirmada, leitura repetível, e assim por diante) que permitem aos desenvolvedores trocar deliberadamente algum isolamento por throughput.