Olá a todos. Vladislav Rodin está em contato. Atualmente sou o Líder do curso High Workload Architect na OTUS e também ministro cursos de arquitetura de software.
Além de lecionar, como vocês devem ter notado, estou escrevendo material original para o blog OTUS em Habré e quero coincidir com o artigo de hoje para coincidir com o lançamento do curso , que está com inscrições abertas no momento.
Introdução
В falamos sobre o fato de que as transações em bancos de dados servem para resolver dois problemas: garantir tolerância a falhas e acesso aos dados em um ambiente competitivo. Para executar totalmente essas tarefas, a transação deve ter propriedades ACID. Hoje falaremos detalhadamente sobre a carta Eu (isolamento) nesta abreviatura.
Isolamento
O isolamento resolve o problema de acesso a dados em um ambiente competitivo, fornecendo essencialmente proteção contra condições de corrida. Idealmente, isolamento significa serialização, que é uma propriedade que garante que o resultado da execução de transações em paralelo seja o mesmo como se fossem executadas sequencialmente. O principal problema com esta propriedade é que ela é muito difícil de ser fornecida tecnicamente e, como resultado, tem um impacto significativo no desempenho do sistema. É por isso que o isolamento muitas vezes é enfraquecido, aceitando os riscos de certas anomalias, que serão discutidas a seguir. A possibilidade de ocorrência de certas anomalias caracteriza precisamente o nível de isolamento das transações.
As anomalias mais conhecidas são: leitura suja, leitura não repetível, leitura fantasma, mas na verdade existem mais 5: escrita suja, atualização perdida do cursor, atualização perdida, distorção de leitura, distorção de gravação.
Escrita suja
A essência da anomalia é que as transações podem substituir dados não confirmados.
Esta anomalia é perigosa não apenas porque os dados podem entrar em conflito após a confirmação de ambas as transações (como na imagem), mas também porque a atomicidade é violada: como permitimos que os dados não confirmados sejam sobrescritos, não está claro como reverter uma transação sem afetar outra .
A anomalia pode ser tratada de forma bastante simples: anexamos um bloqueio ao registro antes de iniciar a gravação, proibindo outras transações de alterar o registro até que o bloqueio seja removido.
Leitura suja
Leitura suja significa ler dados não confirmados.
Os problemas surgem quando ações ou decisões precisam ser tomadas com base na amostra.
Para corrigir a anomalia, você pode anexar um bloqueio de leitura, mas isso terá um grande impacto no desempenho. É muito mais simples dizer que para uma transação de rollback, o estado inicial dos dados (antes do início da gravação) deve ser salvo no sistema. Por que não ler a partir daí? É barato o suficiente para que a maioria dos bancos de dados remova leituras sujas por padrão.
Atualização perdida
Atualização perdida significa atualizações perdidas, e a tradução reflete com bastante precisão a essência do problema:
Na verdade, o resultado da transação T2 foi revertido. Esta situação pode ser corrigida por bloqueios de gravação explícitos ou implícitos. Ou seja, simplesmente atualizamos o registro e então ocorre um bloqueio implícito ou executamos selecione para atualização, causando a ocorrência de um bloqueio de leitura e gravação. Observe que tal operação é bastante perigosa: com nossa leitura “inocente”, bloqueamos outras leituras. Alguns bancos de dados oferecem mais segurança selecione para compartilhar, permitindo que os dados sejam lidos, mas não modificados.
Atualização perdida do cursor
Para um controle mais preciso, as bases podem oferecer outras ferramentas, como um cursor. Um cursor é uma estrutura que contém um conjunto de linhas e permite iterar sobre elas. declare cursor_name para select_statement. O conteúdo do cursor é descrito por select.
Por que você precisa de um cursor? O fato é que alguns bancos de dados oferecem bloqueio em todos os registros selecionados pelo select (estabilidade de leitura), ou apenas no registro onde o cursor está atualmente localizado (estabilidade do cursor). Com a estabilidade do cursor, o bloqueio curto é implementado, o que nos permite reduzir o número de bloqueios se iterarmos em uma grande amostra de dados. Portanto, a anomalia de atualização perdida é isolada separadamente para o cursor.
Leitura não repetível
Leitura não repetível é que durante a execução de nossa transação, 2 leituras consecutivas do mesmo registro levarão a resultados diferentes, pois outra transação interveio entre essas duas leituras, alterou nossos dados e foi confirmada.
Por que isso é um problema? Imagine que o objetivo da transação T2 na imagem é selecionar todos os bens cujo preço seja inferior a 150 USD. Alguém atualizou o preço para US$ 200. Assim, o filtro instalado não funcionou.
Essas anomalias deixam de ocorrer quando são adicionados intertravamentos bifásicos ou quando o mecanismo MVCC é utilizado, o que gostaria de discutir separadamente.
Leitura fantasma
Phantom é uma leitura de dados que foram adicionados por outra transação.
Como exemplo, podemos observar a seleção incorreta do produto mais barato quando ocorre esta anomalia.
Livrar-se de leituras fantasmas já é bastante difícil. O bloqueio regular não é suficiente, porque não podemos bloquear algo que ainda não existe. Os sistemas 2PL usam bloqueio preditivo, enquanto os sistemas MVCC possuem um agendador de transações que reverte transações que podem ser interrompidas por uma inserção. Tanto o primeiro como o segundo mecanismos são bastante pesados.
Leitura distorcida
A distorção de leitura ocorre quando trabalhamos com várias tabelas, cujo conteúdo deve mudar de forma consistente.
Digamos que temos tabelas representando postagens e suas metainformações:
Uma transação lê as tabelas, a outra as modifica:
Como resultado da transação T1, a postagem tem título = Bom e atualizado_by = T2, o que é algum tipo de inconsistência.
Na verdade, esta é uma leitura não repetível, mas como parte de várias tabelas.
Para corrigir isso, T1 pode colocar bloqueios em todas as linhas que irá ler, o que impedirá que a transação T2 altere as informações. No caso de MVCC, a transação T2 será cancelada. A proteção contra esta anomalia pode se tornar importante se usarmos cursores.
Escrever distorcido
Esta anomalia também é mais fácil de explicar com um exemplo: suponha que em nosso sistema pelo menos um médico deveria estar de plantão, mas ambos os médicos decidiram cancelar o plantão:
A anomalia significava que nenhum dos médicos estaria de plantão. Por quê isso aconteceu? Porque a transação estava verificando uma condição que poderia ser violada por outra transação, e devido ao isolamento não vimos essa alteração.
Esta é a mesma leitura não repetível. Alternativamente, os selects podem colocar bloqueios nesses registros.
A distorção de gravação e a distorção de leitura são combinações das anomalias anteriores. Você pode considerar a distorção de gravação, que é essencialmente uma leitura fantasma. Considere uma tabela que contém os nomes dos funcionários, seus salários e o projeto em que trabalham:
Como resultado, obtemos a seguinte imagem: cada gestor pensou que a sua mudança não iria levar a um estouro do orçamento, por isso fizeram mudanças de pessoal que, em conjunto, levaram a estouros de custos.
A causa do problema é exatamente a mesma da leitura fantasma.
Descobertas
Relaxar o nível de isolamento de transações no banco de dados é uma troca entre segurança e desempenho; a escolha desse nível deve ser abordada com base nos riscos potenciais para o negócio caso ocorram determinadas anomalias.
Fonte: habr.com