Isolamento instantâneo
Content
Definição
Uma transação em execução em isolamento de instantâneos parece operar com um instantâneo pessoal do banco de dados, tirado no início da transação. Quando a transação terminar, ela se comprometerá apenas se os valores atualizados pela transação não tiverem sido alterados externamente, pois o instantâneo foi obtido. Esse conflito de gravação e escrita fará com que a transação seja abortada.
Em uma anomalia de gravação, duas transações (T1 e T2) liam simultaneamente um conjunto de dados sobrepostos (por exemplo, valores v1 e v2), simultaneamente faz atualizações disjuntas (por exemplo, atualizações T1 V1, T2 Atualizações V2) e, finalmente A atualização realizada pelo outro. Se o sistema fosse serializável, essa anomalia seria impossível, pois T1 ou T2 teria que ocorrer "primeiro" e seria visível para o outro. Por outro lado, o isolamento de instantâneos permite gravar anomalias de inclinação.
Como exemplo concreto, imagine V1 e V2 são dois saldos mantidos por uma única pessoa, Phil. O banco permitirá que V1 ou V2 execute um déficit, desde que o total mantido em ambos nunca seja negativo (ou seja, V1 + V2 ≥ 0). Ambos os saldos são atualmente US $ 100. Phil inicia duas transações simultaneamente, a retirada de US $ 200 de V1 e T2 retirando US $ 200 de V2.
Se o banco de dados garantiu transações serializáveis, a maneira mais simples de codificar T1 é deduzir US $ 200 da V1 e verifique se V1 + V2 ≥ 0 ainda se mantém, abortando se não. T2 deduz -se da mesma forma US $ 200 do V2 e verifica V1 + V2 ≥ 0. Como as transações devem ser serializadas, o T1 acontece primeiro, deixando V1 = - $ 100, V2 = $ 100 e impedindo o T2 de ter sucesso (desde V1 + (V2 - $ 200) agora - US $ 200), ou T2 acontece primeiro e impede de que o T1 seja cometido.
Se o banco de dados estiver em isolamento de instantâneos (MVCC), no entanto, T1 e T2 operam com instantâneos privados do banco de dados: cada um deduz $ 200 de uma conta e verifica que o novo total é zero, usando o outro valor da conta que mantinha quando o O instantâneo foi tirado. Como nenhum dos conflitos de atualização, ambos se comprometem com sucesso, deixando v1 = v2 = - $ 100 e v1 + v2 = - $ 200.
Alguns sistemas construídos usando o controle de concorrência multiverso (MVCC) podem suportar (somente) isolamento de instantâneos para permitir que as transações prossigam sem se preocupar com operações simultâneas e, mais importante, sem precisar re-verificar todas as operações de leitura quando a transação finalmente se compromete. Isso é conveniente porque o MVCC mantém uma série de estados consistentes da história recente. A única informação que deve ser armazenada durante a transação é uma lista de atualizações feitas, que podem ser digitalizadas para conflitos com bastante facilidade antes de serem comprometidos. No entanto, os sistemas MVCC (como o MarkLogic) usarão bloqueios para serializar gravações juntamente com o MVCC para obter alguns dos ganhos de desempenho e ainda suportar o nível mais forte de "serialização" de isolamento.
Soluções alternativas
Problemas potenciais de inconsistência decorrentes de anomalias de gravação podem ser corrigidos adicionando atualizações (caso contrário desnecessárias) às transações para fazer cumprir a propriedade de serialização.
Materialize the conflictAdd a special conflict table, which both transactions update in order to create a direct write–write conflict.PromotionHave one transaction "update" a read-only location (replacing a value with the same value) in order to create a direct write–write conflict (or use an equivalent promotion, e.g. Oracle's SELECT FOR UPDATE).No exemplo acima, podemos materializar o conflito adicionando uma nova tabela que torna explícita a restrição oculta, mapeando cada pessoa para seu equilíbrio total. Phil começaria com um saldo total de US $ 200, e cada transação tentaria subtrair US $ 200 disso, criando um conflito de gravação -escrita que impediria que os dois tenham sucesso simultaneamente. No entanto, essa abordagem viola a forma normal.
Como alternativa, podemos promover uma das leituras da transação para uma gravação. Por exemplo, T2 pode definir v1 = v1, criando um conflito artificial de gravação -escrita com T1 e, novamente, impedindo que os dois tenham sucesso simultaneamente. Esta solução nem sempre é possível.
Em geral, portanto, o isolamento do instantâneo coloca parte do problema de manter restrições não triviais ao usuário, que pode não apreciar as armadilhas em potencial ou as possíveis soluções. A vantagem dessa transferência é melhor desempenho.
Terminologia
O isolamento do instantâneo é chamado de modo "serializável" nas versões Oracle e PostgreSQL antes de 9.1, o que pode causar confusão com o modo "serialização real". Existem argumentos a favor e contra essa decisão; O que está claro é que os usuários devem estar cientes da distinção para evitar possíveis comportamentos anômalos indesejados em sua lógica do sistema de banco de dados.
História
O isolamento de instantâneos surgiu do trabalho nos bancos de dados de controle de simultaneidade multiverso, onde várias versões do banco de dados são mantidas simultaneamente para permitir que os leitores sejam executados sem colidir com escritores. Esse sistema permite uma definição e implementação naturais de um nível de isolamento. A Interbase, posteriormente de propriedade de Borland, foi reconhecida por fornecer SI em vez de serializabilidade total na versão 4, e provavelmente permitiu anomalias de distribuição de gravação desde o seu primeiro lançamento em 1985.
Infelizmente, o padrão ANSI SQL-92 foi escrito com um banco de dados baseado em bloqueio em mente e, portanto, é bastante vago quando aplicado aos sistemas MVCC. Berenson et al. escreveu um artigo em 1995, criticando o padrão SQL e citou o isolamento de instantâneos como um exemplo de um nível de isolamento que não exibia as anomalias padrão descritas no padrão ANSI SQL-92, mas ainda assim teve um comportamento anômalo quando comparado às transações serializáveis.
Em 2008, Cahill et al. mostraram que as anomalias de composição de gravação poderiam ser evitadas detectando e abortando trigêmeos "perigosos" de transações simultâneas. Essa implementação da serialização é adequada aos bancos de dados de controle de simultaneidade de multiverso e foi adotada no PostgreSQL 9.1, onde é referida como "isolamento serializável de instantâneos", abreviado ao SSI. Quando usado de forma consistente, isso elimina a necessidade das soluções alternativas acima. A desvantagem sobre o isolamento do instantâneo é um aumento nas transações abortadas. Isso pode ter um desempenho melhor ou pior do que o isolamento do instantâneo com as soluções alternativas acima, dependendo da carga de trabalho.