Hola a todos. Vladislav Rodin está en contacto. Actualmente soy el líder del curso de Arquitecto de alta carga de trabajo en OTUS y también imparto cursos de arquitectura de software.
Además de enseñar, como habrás notado, estoy escribiendo material original para el blog de OTUS sobre Habré y quiero coincidir con el artículo de hoy para que coincida con el lanzamiento del curso. , que ya está abierto para inscripciones.
introducción
В Hablamos del hecho de que las transacciones en bases de datos sirven para resolver dos problemas: garantizar la tolerancia a fallos y el acceso a los datos en un entorno competitivo. Para realizar completamente estas tareas, la transacción debe tener propiedades ACID. Hoy hablaremos en detalle sobre la carta. yo (aislamiento) en esta abreviatura.
Изоляция
El aislamiento resuelve el problema de acceder a datos en un entorno competitivo, esencialmente brindando protección contra las condiciones de carrera. Idealmente, aislamiento significa serialización, que es una propiedad que garantiza que el resultado de ejecutar transacciones en paralelo sea el mismo que si se ejecutaran secuencialmente. El principal problema con esta propiedad es que es muy difícil de proporcionar técnicamente y, como resultado, tiene un impacto significativo en el rendimiento del sistema. Por eso muchas veces se debilita el aislamiento, aceptando los riesgos de determinadas anomalías, de las que hablaremos más adelante. La posibilidad de que se produzcan determinadas anomalías caracteriza precisamente el nivel de aislamiento de las transacciones.
Las anomalías más conocidas son: lectura sucia, lectura no repetible, lectura fantasma, pero en realidad hay 5 más: escritura sucia, actualización perdida del cursor, actualización perdida, lectura sesgada, escritura sesgada.
escritura sucia
La esencia de la anomalía es que las transacciones pueden sobrescribir datos no confirmados.
Esta anomalía es peligrosa no sólo porque los datos pueden entrar en conflicto después de confirmar ambas transacciones (como en la imagen), sino también porque se viola la atomicidad: dado que permitimos que se sobrescriban los datos no confirmados, no está claro cómo revertir una transacción sin afectar a otra. .
La anomalía se puede tratar de manera bastante simple: adjuntamos un candado al registro antes de iniciar la grabación, prohibiendo que otras transacciones cambien el registro hasta que se elimine el bloqueo.
lectura sucia
Lectura sucia significa leer datos no confirmados.
Los problemas surgen cuando es necesario tomar acciones o decisiones basadas en la muestra.
Para corregir la anomalía, puede adjuntar un bloqueo de lectura, pero esto afectará en gran medida el rendimiento. Es mucho más sencillo decir que para una transacción de reversión, el estado inicial de los datos (antes del inicio de la grabación) debe guardarse en el sistema. ¿Por qué no leer desde allí? Es lo suficientemente económico como para que la mayoría de las bases de datos eliminen las lecturas sucias de forma predeterminada.
Actualización perdida
Actualización perdida significa actualizaciones perdidas y la traducción refleja con bastante precisión la esencia del problema:
De hecho, se revirtió el resultado de la transacción T2. Esta situación se puede corregir mediante bloqueos de escritura explícitos o implícitos. Es decir, simplemente actualizamos el registro y luego se produce un bloqueo implícito, o realizamos seleccionar para actualizar, provocando que se produzca un bloqueo de lectura y escritura. Tenga en cuenta que esta operación es bastante peligrosa: con nuestra lectura "inocente", bloqueamos otras lecturas. Algunas bases de datos ofrecen más seguridad seleccionar para compartir, permitiendo leer los datos pero no modificarlos.
Actualización perdida del cursor
Para un control más preciso, las bases pueden ofrecer otras herramientas, como un cursor. Un cursor es una estructura que contiene un conjunto de filas y le permite iterar sobre ellas. declarar cursor_name para select_statement. El contenido del cursor se describe mediante selección.
¿Por qué necesitas un cursor? El hecho es que algunas bases de datos ofrecen un bloqueo en todos los registros seleccionados mediante selección (estabilidad de lectura), o solo en el registro en el que se encuentra actualmente el cursor (estabilidad del cursor). Con la estabilidad del cursor, se implementa un bloqueo corto, lo que nos permite reducir la cantidad de bloqueos si iteramos sobre una muestra grande de datos. Por lo tanto, la anomalía de actualización perdida se aísla por separado para el cursor.
Lectura no repetible
La lectura no repetible es que durante la ejecución de nuestra transacción, 2 lecturas consecutivas del mismo registro conducirán a resultados diferentes, porque entre estas dos lecturas intervino otra transacción, cambió nuestros datos y se confirmó.
¿Por qué es esto siquiera un problema? Imagine que el objetivo de la transacción T2 en la imagen es seleccionar todos los bienes cuyo precio sea inferior a 150 USD. Alguien más actualizó el precio a $200. Por tanto, el filtro instalado no funcionó.
Estas anomalías dejan de ocurrir cuando se agregan enclavamientos de dos fases o cuando se usa el mecanismo MVCC, que me gustaría discutir por separado.
lectura fantasma
Phantom es una lectura de datos agregados por otra transacción.
Como ejemplo podemos observar la selección incorrecta del producto más barato cuando se produce esta anomalía.
Deshacerse de las lecturas fantasmas ya es bastante difícil. El bloqueo regular no es suficiente, porque no podemos bloquear algo que aún no existe. Los sistemas 2PL utilizan bloqueo predictivo, mientras que los sistemas MVCC tienen un programador de transacciones que revierte las transacciones que podrían verse interrumpidas por una inserción. Tanto el primer como el segundo mecanismo son bastante pesados.
leer sesgado
El sesgo de lectura ocurre cuando trabajamos con varias tablas, cuyo contenido debe cambiar constantemente.
Digamos que tenemos tablas que representan publicaciones y su metainformación:
Una transacción lee las tablas, la otra las modifica:
Como resultado de la transacción T1, la publicación tiene título = Bueno y actualizado_por = T2, lo cual es algún tipo de inconsistencia.
De hecho, se trata de una lectura no repetible, sino como parte de varias tablas.
Para solucionar este problema, T1 puede bloquear todas las filas que leerá, lo que evitará que la transacción T2 cambie la información. En el caso de MVCC, se cancelará la transacción T2. La protección contra esta anomalía puede llegar a ser importante si utilizamos cursores.
escribir sesgado
Esta anomalía también es más fácil de explicar con un ejemplo: supongamos que en nuestro sistema al menos un médico debería estar de guardia, pero ambos médicos decidieron cancelar su guardia:
La anomalía significó que ninguno de los médicos estaría de servicio. ¿Por qué pasó esto? Porque la transacción estaba verificando una condición que podría ser violada por otra transacción y debido al aislamiento no vimos este cambio.
Esta es la misma lectura no repetible. Alternativamente, las selecciones pueden colocar bloqueos en estos registros.
La inclinación de escritura y la inclinación de lectura son combinaciones de las anomalías anteriores. Puede considerar la escritura sesgada, que es esencialmente una lectura fantasma. Considere una tabla que contiene los nombres de los empleados, sus salarios y el proyecto en el que trabajan:
Como resultado, obtenemos la siguiente imagen: cada gerente pensó que su cambio no conduciría a sobrepasar el presupuesto, por lo que hicieron cambios de personal que en conjunto condujeron a sobrecostos.
La causa del problema es exactamente la misma que en la lectura fantasma.
Hallazgos
Relajar el nivel de aislamiento de transacciones en la base de datos es una compensación entre seguridad y rendimiento; la elección de este nivel debe abordarse en función de los riesgos potenciales para el negocio si ocurren ciertas anomalías.
Fuente: habr.com
