Ola a todos. Vladislav Rodin está en contacto. Actualmente son o líder do curso do curso de arquitecto de alta carga de traballo na OTUS e tamén imparto cursos de arquitectura de software.
Ademais de ensinar, como podedes notar, estou a escribir material orixinal para o blog de OTUS en Habré e quero coincidir co artigo de hoxe para coincidir co lanzamento do curso. , que xa está aberto para a inscrición.
Introdución
В falamos de que as transaccións nas bases de datos serven para resolver dous problemas: garantir a tolerancia a fallos e o acceso aos datos nun entorno competitivo. Para realizar plenamente estas tarefas, a transacción debe ter propiedades ACID. Hoxe falaremos en detalle da carta eu (illamento) nesta abreviatura.
Illamento
O illamento resolve o problema de acceder aos datos nun ambiente competitivo, proporcionando esencialmente protección contra as condicións de carreira. Idealmente, illamento significa serialización, que é unha propiedade que garante que o resultado de executar transaccións en paralelo sexa o mesmo que se se executasen secuencialmente. O principal problema con esta propiedade é que é moi difícil de proporcionar tecnicamente e, como resultado, ten un impacto significativo no rendemento do sistema. É por iso que o illamento adoita debilitarse, aceptando os riscos de certas anomalías, que se comentarán a continuación. A posibilidade de que se produzan certas anomalías caracteriza precisamente o nivel de illamento das transaccións.
As anomalías máis coñecidas son: lectura sucia, lectura non repetible, lectura fantasma, pero de feito hai 5 máis: escritura sucia, actualización perdida do cursor, actualización perdida, lectura sesgada, escritura sesgada.
Escritura sucia
A esencia da anomalía é que as transaccións poden sobrescribir os datos non comprometidos.
Esta anomalía é perigosa non só porque os datos poden entrar en conflito despois de cometer ambas transaccións (como na imaxe), senón tamén porque se infrinxe a atomicidade: dado que permitimos que se sobrescriban os datos non comprometidos, non está claro como retrotraer unha transacción sen afectar a outra. .
A anomalía pódese tratar de forma moi sinxela: adjuntamos un bloqueo ao rexistro antes de comezar a gravación, prohibindo que outras transaccións cambien o rexistro ata que se elimine o bloqueo.
Lectura sucia
A lectura sucia significa ler datos non comprometidos.
Os problemas xorden cando hai que tomar accións ou decisións en función da mostra.
Para corrixir a anomalía, podes engadir un bloqueo de lectura, pero isto afectará moito o rendemento. É moito máis sinxelo dicir que para unha transacción de retroceso, o estado inicial dos datos (antes do inicio da gravación) debe ser gardado no sistema. Por que non ler dende alí? É o suficientemente barato como para que a maioría das bases de datos eliminen as lecturas sucias por defecto.
Actualización perdida
A actualización perdida significa actualizacións perdidas, e a tradución reflicte con bastante precisión a esencia do problema:
De feito, o resultado da transacción T2 foi revertido. Esta situación pódese corrixir mediante bloqueos de escritura explícitos ou implícitos. É dicir, simplemente actualizamos o rexistro e, a continuación, ocorre un bloqueo implícito, ou realizamos seleccione para actualizar, facendo que se produza un bloqueo de lectura e escritura. Teña en conta que tal operación é bastante perigosa: coa nosa lectura "inocente", bloqueamos outras lecturas. Algunhas bases de datos ofrecen máis seguridade seleccionar para compartir, permitindo ler os datos pero non modificar.
O cursor perdeu a actualización
Para un control máis fino, as bases poden ofrecer outras ferramentas, como un cursor. Un cursor é unha estrutura que contén un conxunto de filas e permite iterar sobre elas. declara cursor_name para select_statement. O contido do cursor descríbese mediante select.
Por que necesitas un cursor? O caso é que algunhas bases de datos ofrecen un bloqueo en todos os rexistros seleccionados mediante select (estabilidade de lectura), ou só no rexistro no que se atopa actualmente o cursor (estabilidade do cursor). Coa estabilidade do cursor, implícase un bloqueo curto, o que nos permite reducir o número de bloqueos se iteramos sobre unha gran mostra de datos. Polo tanto, a anomalía de actualización perdida está illada por separado para o cursor.
Lectura non repetible
A lectura non repetible é que durante a execución da nosa transacción, 2 lecturas consecutivas do mesmo rexistro darán lugar a resultados diferentes, porque outra transacción interveu entre estas dúas lecturas, cambiou os nosos datos e comprometeuse.
Por que isto é un problema? Imaxina que o obxectivo da transacción T2 na imaxe é seleccionar todos os bens cuxo prezo sexa inferior a 150 USD. Outra persoa actualizou o prezo a 200 $. Así, o filtro instalado non funcionou.
Estas anomalías deixan de producirse cando se engaden bloqueos de dúas fases ou cando se utiliza o mecanismo MVCC, que me gustaría comentar por separado.
Lectura fantasma
Phantom é unha lectura de datos engadidos por outra transacción.
Como exemplo, podemos observar a selección incorrecta do produto máis barato cando se produce esta anomalía.
Desfacerse das lecturas fantasmas xa é bastante difícil. O bloqueo regular non é suficiente, porque non podemos bloquear algo que aínda non existe. Os sistemas 2PL usan o bloqueo preditivo, mentres que os sistemas MVCC teñen un programador de transaccións que retrotrae as transaccións que poden verse interrompidas por unha inserción. Tanto o primeiro como o segundo mecanismos son bastante pesados.
Ler sesgo
O sesgo de lectura prodúcese cando traballamos con varias táboas, cuxo contido debe cambiar de forma coherente.
Digamos que temos táboas que representan as publicacións e a súa metainformación:
Unha transacción le das táboas, a outra modifícaas:
Como resultado da transacción T1, a publicación ten título = Bo e updated_by = T2, o que é algún tipo de incoherencia.
De feito, esta é unha lectura non repetible, pero como parte de varias táboas.
Para solucionar isto, T1 pode poñer bloqueos en todas as filas que vai ler, o que evitará que a transacción T2 cambie a información. No caso de MVCC, a transacción T2 cancelarase. A protección contra esta anomalía pode chegar a ser importante se usamos cursores.
Escribir sesgo
Esta anomalía tamén é máis fácil de explicar cun exemplo: supoñamos que no noso sistema polo menos un médico debería estar de garda, pero ambos os dous decidiron cancelar o seu servizo:
A anomalía fixo que ningún dos médicos estaría de servizo. Por que pasou isto? Porque a transacción estaba comprobando unha condición que podería ser violada por outra transacción, e debido ao illamento non vimos este cambio.
Esta é a mesma lectura non repetible. Alternativamente, os seleccionados poden bloquear estes rexistros.
O sesgo de escritura e o sesgo de lectura son combinacións das anomalías anteriores. Podes considerar a escritura sesgada, que é esencialmente unha lectura fantasma. Considere unha táboa que contén os nomes dos empregados, os seus salarios e o proxecto no que traballan:
Como resultado, obtemos a seguinte imaxe: cada xerente pensaba que o seu cambio non levaría a exceder o orzamento, polo que fixeron cambios de persoal que en conxunto provocaron sobrecostos.
A causa do problema é exactamente a mesma que na lectura fantasma.
Descubrimentos
Relaxar o nivel de illamento das transaccións na base de datos é unha compensación entre seguridade e rendemento; a elección deste nivel debe abordarse en función dos riscos potenciais para a empresa se se producen certas anomalías.
Fonte: www.habr.com