💔 🔜 🧗🏻 ¿Qué puede resultar de debilitar el nivel de aislamiento de transacciones en bases de datos? 🔀 👎🏽 〰️

Hola a todos. En contacto Vladislav Rodin. Actualmente, soy el jefe del curso High Load Architect en OTUS, y también doy cursos sobre arquitectura de software.

Además de la enseñanza, como habrás notado, también estoy escribiendo material de copyright para el blog OTUS en el centro y quiero coincidir con el artículo de hoy para lanzar el curso "PostgreSQL" , que actualmente está abierto para reclutamiento.

Introducción

La última vez que usted y yo hablamos sobre esa transacción en bases de datos utilizadas para dos propósitos: garantizar la tolerancia a fallas y el acceso a datos en un entorno competitivo. Para completar estas tareas, una transacción debe tener propiedades ACID. Hoy hablaremos en detalle sobre la letra I (aislamiento) en esta abreviatura.

Aislamiento

El aislamiento resuelve el problema de acceder a los datos en un entorno competitivo, proporcionando protección efectiva contra las condiciones de carrera. Idealmente, aislamiento significa serialización, es decir, una propiedad que garantiza que el resultado de la ejecución de transacciones en paralelo sea el mismo que si se ejecutaran secuencialmente. El principal problema de esta propiedad es que es técnicamente muy difícil de proporcionar y, como resultado, tiene un impacto significativo en el rendimiento del sistema. Es por eso que el aislamiento a menudo se debilita, aceptando los riesgos de algunas anomalías, que se discutirán a continuación. La posibilidad de que ocurran ciertas anomalías de la misma manera caracteriza el nivel de aislamiento de la transacción.

Las anomalías más famosas son: lectura sucia, lectura no repetible, lectura fantasma, pero de hecho hay 5 más: escritura sucia, actualización perdida del cursor, actualización perdida, sesgo de lectura, sesgo de escritura.

Escritura sucia

La esencia de la anomalía es que las transacciones pueden sobrescribir datos no comprometidos.

imagen

Esta anomalía es peligrosa no solo porque los datos pueden entrar en conflicto después de cometer ambas transacciones (como en la imagen), sino también porque se viola la atomicidad: debido a que permitimos sobrescribir datos no bloqueados, no está claro cómo deshacer una transacción sin presionar la otra .

La anomalía se trata de manera bastante simple: colgamos el bloqueo de escritura antes de que comience la grabación, prohibiendo que otras transacciones cambien el registro hasta que se libere el bloqueo.

Lectura sucia

Lectura sucia significa leer datos no confirmados.

imagen

Los problemas surgen cuando, en base a una muestra, es necesario llevar a cabo algunas acciones o tomar decisiones.

Para solucionar la anomalía, puede colgar un bloqueo de lectura, pero afectará mucho el rendimiento. Es mucho más simple decir que para una transacción de reversión, el estado inicial de los datos (antes de la grabación) debe almacenarse en el sistema. ¿Por qué no leer desde allí? Esto es bastante económico, por lo que la mayoría de las bases de datos eliminan la lectura sucia de forma predeterminada.

Actualización perdida

La actualización perdida significa actualizaciones perdidas, y la traducción refleja con precisión la esencia del problema: de

imagen

hecho, el resultado de la transacción T2 se canceló. Esta situación se soluciona 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 la selección para la actualización , lo que provoca un bloqueo de lectura y escritura. Tenga en cuenta que tal operación es bastante peligrosa: con nuestra lectura "inocente", bloqueamos otras lecturas. Algunas bases de datos ofrecen una selección para compartir más segura que le permite leer datos, pero no les permite cambiar.

El cursor perdió la actualización

Para un control más preciso, las bases pueden ofrecer otras herramientas, por ejemplo, un cursor. Un cursor es una estructura que contiene un conjunto de líneas y le permite iterar sobre ellas. declarar cursor_name para select_statement . El contenido del cursor se describe mediante select.

¿Por qué necesitamos un cursor? El hecho es que algunas bases de datos ofrecen bloqueo en todos los registros seleccionados por select (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, que nos permite reducir el número de bloqueos si iteramos sobre una muestra de datos grande. Por lo tanto, la anomalía de actualización perdida se resalta 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 otra transacción intervino entre estas dos lecturas, cambió nuestros datos y se confirmó.

imagen

¿Por qué es esto un problema en absoluto? Imagine que el propósito de la transacción T2 en la imagen es seleccionar todos los productos cuyo precio sea inferior a 150 pies cúbicos Alguien más actualizó el precio a $ 200 Por lo tanto, el filtro instalado no funcionó.

Estas anomalías dejan de ocurrir cuando se agregan bloqueos de dos fases o cuando se usa el mecanismo MVCC, del cual me gustaría hablar por separado.

Lectura fantasma

Phantom está leyendo datos que ha sido agregado por otra transacción.

imagen

Como ejemplo, puede 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 normal no es suficiente, porque no podríamos bloquear lo que aún no está disponible. Los sistemas 2PL usan bloqueo predictivo, mientras que los sistemas MVCC usan un planificador de transacciones para cancelar transacciones que podrían ser interrumpidas por una inserción. Tanto el primer como el segundo mecanismo son bastante pesados.

Leer sesgo

El sesgo de lectura surge cuando trabajamos con varias tablas, cuyo contenido debería cambiar de manera consistente.

Supongamos que hay tablas que representan publicaciones y su metainformación:

imagen

una transacción lee de las tablas, otra las cambia:

imagen

Como resultado de la transacción T1, la publicación tiene título = Bueno y updated_by = T2, lo cual es una inconsistencia.

De hecho, esta es una lectura no repetible, pero como parte de varias tablas.

Para su corrección, T1 puede bloquear bloqueos en todas las líneas que leerá, lo que evitará que T2 cambie la información. En el caso de MVCC, la transacción T2 se cancelará. La protección contra esta anomalía puede ser importante si usamos cursores.

Escribir sesgada

Esta anomalía también es más fácil de explicar usando un ejemplo: supongamos que en nuestro sistema al menos un médico debe estar de servicio, pero ambos médicos deciden cancelar su deber: la

imagen

anomalía ha llevado al hecho de que ninguno de los médicos irá a trabajar. ¿Por qué pasó esto? Debido a que la transacción verificó 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 bloquear bloqueos en estos registros.

El sesgo de escritura y el sesgo de lectura son combinaciones de anomalías anteriores. Puede considerar escribir sesgo, que es esencialmente una lectura fantasma. Considere una tabla en la que hay nombres de empleados, su salario y el proyecto en el que trabajan:

imagen

Como resultado, obtenemos la siguiente imagen: cada gerente pensó que su cambio no conduciría al presupuesto, por lo que hicieron cambios de personal, lo que en total condujo a un desbordamiento.

La causa del problema es exactamente la misma que en la lectura fantasma.

recomendaciones

El debilitamiento del nivel de aislamiento de transacciones en la base de datos es un compromiso entre la seguridad y el rendimiento, la elección de este nivel debe abordarse en función de los riesgos potenciales para el negocio en caso de anomalías.

Aprende más sobre el curso.

¿Qué puede resultar de debilitar el nivel de aislamiento de transacciones en bases de datos?