En los sistemas de bases de datos , el aislamiento determina cómo la integridad de la transacción es visible para otros usuarios y sistemas.
Un nivel de aislamiento más bajo aumenta la capacidad de muchos usuarios para acceder a los mismos datos al mismo tiempo, pero aumenta el número de efectos de simultaneidad (como lecturas sucias o actualizaciones perdidas) que pueden encontrar los usuarios. Por el contrario, un nivel de aislamiento más alto reduce los tipos de efectos de simultaneidad que pueden encontrar los usuarios, pero requiere más recursos del sistema y aumenta las posibilidades de que una transacción bloquee otra. [1]
El aislamiento se define típicamente a nivel de base de datos como una propiedad que define cómo / cuándo los cambios realizados por una operación se vuelven visibles para otras. En sistemas más antiguos, se puede implementar de forma sistémica, por ejemplo, mediante el uso de tablas temporales. En los sistemas de dos niveles, se requiere un administrador de procesamiento de transacciones (TP) para mantener el aislamiento. En los sistemas de n niveles (como varios sitios web que intentan reservar el último asiento en un vuelo), se requiere una combinación de procedimientos almacenados y gestión de transacciones para confirmar la reserva y enviar la confirmación al cliente. [2]
El aislamiento es una de las cuatro propiedades del ACID , junto con la atomicidad , la consistencia y la durabilidad .
Control de concurrencia
El control de concurrencia comprende los mecanismos subyacentes en un DBMS que manejan el aislamiento y garantizan la corrección relacionada. Es muy utilizado por la base de datos y los motores de almacenamiento tanto para garantizar la correcta ejecución de transacciones concurrentes como (a través de diferentes mecanismos) la corrección de otros procesos DBMS. Los mecanismos relacionados con las transacciones normalmente limitan el tiempo de las operaciones de acceso a los datos de la base de datos ( programas de transacciones ) a ciertos pedidos caracterizados como las propiedades del programa de serialización y recuperabilidad . Restringir la ejecución de la operación de acceso a la base de datos generalmente significa un rendimiento reducido (medido por las tasas de ejecución) y, por lo tanto, los mecanismos de control de concurrencia generalmente están diseñados para proporcionar el mejor rendimiento posible bajo las restricciones. A menudo, cuando es posible sin dañar la corrección, la propiedad de serialización se ve comprometida para un mejor rendimiento. Sin embargo, la recuperabilidad no puede verse comprometida, ya que esto normalmente da como resultado una violación rápida de la integridad de la base de datos .
El bloqueo de dos fases es el método de control de simultaneidad de transacciones más común en los DBMS, y se utiliza para proporcionar tanto serializabilidad como recuperabilidad para la corrección. Para acceder a un objeto de base de datos, una transacción primero necesita adquirir un bloqueo para este objeto. Dependiendo del tipo de operación de acceso (por ejemplo, leer o escribir un objeto) y del tipo de bloqueo, la adquisición del bloqueo puede bloquearse y posponerse, si otra transacción mantiene un bloqueo para ese objeto.
Leer fenómenos
El estándar ANSI / ISO SQL 92 se refiere a tres fenómenos de lectura diferentes cuando la Transacción 1 lee datos que la Transacción 2 podría haber cambiado.
En los siguientes ejemplos, tienen lugar dos transacciones. En el primero, se realiza la Consulta 1. Luego, en la segunda transacción, se realiza y confirma la Consulta 2. Finalmente, en la primera transacción, se vuelve a realizar la Consulta 1.
Las consultas utilizan la siguiente tabla de datos:
identificación | nombre | edad |
---|---|---|
1 | José | 20 |
2 | Jill | 25 |
Lecturas sucias
Una lectura sucia (también conocida como dependencia no confirmada ) ocurre cuando una transacción puede leer datos de una fila que ha sido modificada por otra transacción en ejecución y aún no se ha confirmado.
Las lecturas sucias funcionan de manera similar a las lecturas no repetibles ; sin embargo, no es necesario confirmar la segunda transacción para que la primera consulta devuelva un resultado diferente. Lo único que puede evitarse en el nivel de aislamiento READ UNCOMMITTED son las actualizaciones que aparecen desordenadas en los resultados; es decir, las actualizaciones anteriores siempre aparecerán en un conjunto de resultados antes de las actualizaciones posteriores.
En nuestro ejemplo, la Transacción 2 cambia una fila, pero no confirma los cambios. La transacción 1 luego lee los datos no confirmados. Ahora bien, si la Transacción 2 revierte sus cambios (ya leídos por la Transacción 1) o actualiza diferentes cambios en la base de datos, entonces la vista de los datos puede ser incorrecta en los registros de la Transacción 1.
Transacción 1 | Transacción 2 |
---|---|
/ * Consulta * 1 / SELECT edad DE usuarios DONDE ID = 1 ; / * leerá 20 * / | |
/ * Consulta 2 * / ACTUALIZAR usuarios SET edad = 21 DONDE id = 1 ; / * No comprometerse aquí * / | |
/ * Consulta * 1 / SELECT edad DE usuarios DONDE ID = 1 ; / * leerá 21 * / | |
ROLLBACK ; / * LECTURA SUCIA basada en bloqueo * / |
Pero en este caso no existe ninguna fila que tenga una identificación de 1 y una edad de 21.
Lecturas no repetibles
Una lectura no repetible ocurre cuando, durante el curso de una transacción, una fila se recupera dos veces y los valores dentro de la fila difieren entre las lecturas.
El fenómeno de lecturas no repetibles puede ocurrir en un método de control de concurrencia basado en bloqueos cuando los bloqueos de lectura no se adquieren al realizar un SELECT , o cuando los bloqueos adquiridos en las filas afectadas se liberan tan pronto como se realiza la operación SELECT. Con el método de control de simultaneidad de múltiples versiones , las lecturas no repetibles pueden ocurrir cuando se relaja el requisito de que una transacción afectada por un conflicto de compromiso deba revertirse.
Transacción 1 | Transacción 2 |
---|---|
/ * Consulta 1 * / SELECCIONAR * DE usuarios DONDE id = 1 ; | |
/ * Consulta 2 * / ACTUALIZAR usuarios SET edad = 21 DONDE id = 1 ; COMPROMISO ; / * en control de simultaneidad multiversion , o READ COMMITTED basado en bloqueos * / | |
/ * Consulta 1 * / SELECCIONAR * DE usuarios DONDE id = 1 ; COMPROMISO ; / * LECTURA REPETIBLE basada en bloqueo * / |
En este ejemplo, la Transacción 2 se confirma con éxito, lo que significa que sus cambios en la fila con el ID 1 deberían ser visibles. Sin embargo, la Transacción 1 ya ha visto un valor diferente para la edad en esa fila. En los niveles de aislamiento SERIALIZABLE y REPEATABLE READ, el DBMS debe devolver el valor anterior para el segundo SELECT. En READ COMMITTED y READ UNCOMMITTED, el DBMS puede devolver el valor actualizado; esta es una lectura no repetible.
Hay dos estrategias básicas que se utilizan para evitar lecturas no repetibles. El primero es retrasar la ejecución de la Transacción 2 hasta que la Transacción 1 se haya confirmado o revertido. Este método se utiliza cuando se utiliza el bloqueo y produce el programa en serie T1, T2 . Un horario en serie exhibe un comportamiento de lecturas repetibles .
En la otra estrategia, como se usa en el control de concurrencia de múltiples versiones , se permite que la Transacción 2 se confirme primero, lo que proporciona una mejor concurrencia. Sin embargo, la Transacción 1, que comenzó antes de la Transacción 2, debe continuar operando en una versión anterior de la base de datos, una instantánea del momento en que se inició. Cuando la Transacción 1 finalmente intenta confirmarse, el DBMS comprueba si el resultado de la transacción 1 sería equivalente al programa T1, T2 . Si es así, la Transacción 1 puede continuar. Sin embargo, si no puede considerarse equivalente, la Transacción 1 debe revertirse con un error de serialización.
Usando un método de control de simultaneidad basado en bloqueo, en el modo de aislamiento REPEATABLE READ, la fila con ID = 1 se bloquearía, bloqueando así la Consulta 2 hasta que la primera transacción fuera confirmada o revertida. En el modo LEER COMPROMISO, la segunda vez que se ejecutó la Consulta 1, la antigüedad habría cambiado.
Bajo el control de concurrencia de múltiples versiones, en el nivel de aislamiento SERIALIZABLE, ambas consultas SELECT ven una instantánea de la base de datos tomada al comienzo de la Transacción 1. Por lo tanto, devuelven los mismos datos. Sin embargo, si la Transacción 2 intenta ACTUALIZAR esa fila también, se produciría un error de serialización y la Transacción 1 se vería obligada a retroceder.
En el nivel de aislamiento READ COMMITTED, cada consulta ve una instantánea de la base de datos tomada al comienzo de cada consulta. Por lo tanto, cada uno ve datos diferentes para la fila actualizada. No es posible ningún error de serialización en este modo (porque no se hace ninguna promesa de serialización), y no será necesario reintentar la Transacción 1.
Lecturas fantasma
Una lectura fantasma ocurre cuando, en el curso de una transacción, otra transacción agrega o elimina filas nuevas a los registros que se están leyendo.
Esto puede ocurrir cuando los bloqueos de rango no se adquieren al realizar una operación SELECT ... WHERE . La anomalía de lecturas fantasma es un caso especial de lecturas no repetibles cuando la Transacción 1 repite una consulta SELECT ... WHERE de rango y, entre ambas operaciones, la Transacción 2 crea (es decir, INSERT ) nuevas filas (en la tabla de destino) que cumplen ese DONDE cláusula.
Transacción 1 | Transacción 2 |
---|---|
/ * Consulta 1 * / SELECCIONAR * DE usuarios DONDE EDAD ENTRE 10 Y 30 ; | |
/ * Consulta 2 * / INSERT INTO users ( id , name , age ) VALUES ( 3 , 'Bob' , 27 ); COMPROMISO ; | |
/ * Consulta 1 * / SELECCIONAR * DE usuarios DONDE EDAD ENTRE 10 Y 30 ; COMPROMISO ; |
Tenga en cuenta que la Transacción 1 ejecutó la misma consulta dos veces. Si se mantuvo el nivel más alto de aislamiento, el mismo conjunto de filas debería devolverse en ambas ocasiones y, de hecho, eso es lo que debe ocurrir en una base de datos que opera en el nivel de aislamiento SERIALIZABLE de SQL. Sin embargo, en los niveles de aislamiento menores, se puede devolver un conjunto diferente de filas la segunda vez.
En el modo de aislamiento SERIALIZABLE, la Consulta 1 daría como resultado que todos los registros con antigüedad en el rango de 10 a 30 estén bloqueados, por lo que la Consulta 2 se bloqueará hasta que se confirme la primera transacción. En el modo REPEATABLE READ, el rango no se bloquearía, lo que permitiría insertar el registro. Sin embargo, la segunda ejecución de la Consulta 1 resulta igual que la primera. si inserta (3, 'Bob', 27) en la Transacción 1, se indicará el Error de clave principal duplicada. No consulté el resultado, pero inserté un error, esto es un fantasma
Niveles de aislamiento
De las cuatro propiedades de ACID en un DBMS (sistema de gestión de bases de datos), la propiedad de aislamiento es la más relajada. Al intentar mantener el nivel más alto de aislamiento, un DBMS generalmente adquiere bloqueos en los datos que pueden resultar en una pérdida de concurrencia , o implementa un control de concurrencia de múltiples versiones . Esto requiere agregar lógica para que la aplicación funcione correctamente.
La mayoría de los DBMS ofrecen varios niveles de aislamiento de transacciones , que controlan el grado de bloqueo que se produce al seleccionar datos. Para muchas aplicaciones de bases de datos, la mayoría de las transacciones de la base de datos se pueden construir para evitar requerir altos niveles de aislamiento (por ejemplo, nivel SERIALIZABLE), reduciendo así la sobrecarga de bloqueo del sistema. El programador debe analizar cuidadosamente el código de acceso a la base de datos para asegurarse de que cualquier relajación del aislamiento no cause errores de software que sean difíciles de encontrar. Por el contrario, si se utilizan niveles de aislamiento más altos, aumenta la posibilidad de un punto muerto , que también requiere un análisis cuidadoso y técnicas de programación para evitarlo.
Dado que cada nivel de aislamiento es más fuerte que los siguientes, dado que ningún nivel de aislamiento más alto permite una acción prohibida por uno más bajo, el estándar permite que un DBMS ejecute una transacción en un nivel de aislamiento más fuerte que el solicitado (por ejemplo, una "Lectura confirmada" la transacción puede realizarse en un nivel de aislamiento de "lectura repetible").
Los niveles de aislamiento definidos por el estándar ANSI / ISO SQL se enumeran a continuación.
Serializable
Este es el nivel de aislamiento más alto.
Con una implementación de DBMS de control de concurrencia basada en bloqueos , la serialización requiere que los bloqueos de lectura y escritura (adquiridos en datos seleccionados) se liberen al final de la transacción. También se deben adquirir los bloqueos de rango cuando una consulta SELECT usa una cláusula WHERE de rango , especialmente para evitar el fenómeno de lecturas fantasmas .
Cuando se utiliza el control de concurrencia no basado en bloqueos, no se adquieren bloqueos; sin embargo, si el sistema detecta una colisión de escritura entre varias transacciones simultáneas, solo se permite que se confirme una de ellas. Consulte el aislamiento de instantáneas para obtener más detalles sobre este tema.
De: (Segundo borrador de revisión informal) ISO / IEC 9075: 1992, Lenguaje de base de datos SQL - 30 de julio de 1992: Se garantiza que la ejecución de transacciones SQL concurrentes a nivel de aislamiento SERIALIZABLE es serializable. Una ejecución serializable se define como una ejecución de las operaciones de ejecución simultánea de transacciones SQL que produce el mismo efecto que una ejecución en serie de esas mismas transacciones SQL. Una ejecución en serie es aquella en la que cada transacción SQL se ejecuta hasta su finalización antes de que comience la siguiente transacción SQL.
Lecturas repetibles
En este nivel de aislamiento, una implementación de DBMS de control de concurrencia basada en bloqueos mantiene bloqueos de lectura y escritura (adquiridos en datos seleccionados) hasta el final de la transacción. Sin embargo, los bloqueos de rango no se administran, por lo que pueden producirse lecturas fantasmas .
El sesgo de escritura es posible en este nivel de aislamiento en algunos sistemas. El sesgo de escritura es un fenómeno en el que se permiten dos escrituras en la misma columna (s) en una tabla por dos escritores diferentes (que han leído previamente las columnas que están actualizando), lo que da como resultado que la columna tenga datos que son una combinación de las dos transacciones. . [3] [4]
Leer comprometido
En este nivel de aislamiento, una implementación de DBMS de control de concurrencia basada en bloqueos mantiene los bloqueos de escritura (adquiridos en los datos seleccionados) hasta el final de la transacción, pero los bloqueos de lectura se liberan tan pronto como se realiza la operación SELECT (por lo que el fenómeno de lecturas no repetibles puede ocurrir en este nivel de aislamiento). Como en el nivel anterior, los bloqueos de rango no se gestionan.
Dicho en palabras más simples, leer comprometido es un nivel de aislamiento que garantiza que cualquier dato leído está comprometido en el momento en que se lee. Simplemente impide que el lector vea cualquier lectura intermedia, no comprometida y "sucia". No promete en absoluto que si la transacción vuelve a emitir la lectura, encontrará los mismos datos; los datos pueden cambiar después de leerlos.
Leer sin compromiso
Este es el nivel de aislamiento más bajo. En este nivel, se permiten las lecturas sucias , por lo que una transacción puede ver los cambios aún no confirmados realizados por otras transacciones.
Nivel de aislamiento predeterminado
El nivel de aislamiento predeterminado de diferentes DBMS varía bastante. La mayoría de las bases de datos que cuentan con transacciones permiten al usuario establecer cualquier nivel de aislamiento. Algunos DBMS también requieren una sintaxis adicional al realizar una instrucción SELECT para adquirir bloqueos (por ejemplo, SELECT ... FOR UPDATE para adquirir bloqueos de escritura exclusivos en las filas a las que se accede).
Sin embargo, las definiciones anteriores han sido criticadas por ser ambiguas y por no reflejar con precisión el aislamiento proporcionado por muchas bases de datos:
- Este documento muestra una serie de debilidades en el enfoque de anomalías para definir los niveles de aislamiento. Los tres fenómenos ANSI son ambiguos, e incluso en sus interpretaciones más vagas no excluyen algún comportamiento anómalo ... Esto conduce a algunos resultados contraintuitivos. En particular, los niveles de aislamiento basados en cerraduras tienen características diferentes a sus equivalentes ANSI. Esto es desconcertante porque los sistemas de bases de datos comerciales suelen utilizar implementaciones de bloqueo. Además, los fenómenos ANSI no distinguen entre varios tipos de comportamiento de nivel de aislamiento que son populares en los sistemas comerciales. [5]
También hay otras críticas con respecto a la definición de aislamiento de ANSI SQL, ya que alienta a los implementadores a hacer "cosas malas":
- ... se basa de manera sutil en la suposición de que se usa un esquema de bloqueo para el control de concurrencia, en contraposición a un esquema de concurrencia optimista o de múltiples versiones. Esto implica que la semántica propuesta está mal definida . [6]
Niveles de aislamiento, fenómenos de lectura y bloqueos
Niveles de aislamiento frente a fenómenos de lectura
'+' - no es posible
'-' - posible
Leer fenómenos Nivel de aislamiento | Lecturas sucias | Actualizaciones perdidas [ inconsistentes ] | Lecturas no repetibles | Fantasmas |
---|---|---|---|---|
Leer sin compromiso | - | - | - | - |
Leer comprometido | + | - | - | - |
Lectura repetible | + | + | + | - |
Serializable | + | + | + | + |
Anomaly Serializable no es lo mismo que Serializable. Es decir, es necesario, pero no suficiente, que una programación serializable esté libre de los tres tipos de fenómenos. [5]
Ver también
- Atomicidad
- Consistencia
- Durabilidad
- Bloquear (base de datos)
- Control de concurrencia optimista
- Sistema de gestión de bases de datos relacionales
- Aislamiento de instantáneas
Referencias
- ^ "Niveles de aislamiento en el motor de base de datos", Technet, Microsoft, https://technet.microsoft.com/en-us/library/ms189122(v=SQL.105).aspx
- ^ "La arquitectura de los sistemas de procesamiento de transacciones", Capítulo 23, Evolución de los sistemas de procesamiento, Departamento de Ciencias de la Computación, Universidad de Stony Brook, consultado el 20 de marzo de 2014, http://www.cs.sunysb.edu/~liu/cse315/23 .pdf
- ↑ Vlad Mihalcea (20 de octubre de 2015). "Una guía para principiantes para leer y escribir fenómenos de sesgo" .
- ^ "Wiki de Postgresql - SSI" .
- ^ a b "Una crítica de los niveles de aislamiento ANSI SQL" (PDF) . Consultado el 29 de julio de 2012 .
- ^ Salesforce (6 de diciembre de 2010). "Testimonios de clientes (SimpleGeo, CLOUDSTOCK 2010)" . www.DataStax.com: DataStax . Consultado el 9 de marzo de 2010 .
(¡vea arriba aproximadamente a las 13:30 minutos del webcast!)
enlaces externos
- Conceptos de base de datos Oracle® , capítulo 13 Concurrencia y consistencia de datos, fenómenos prevenibles y niveles de aislamiento de transacciones
- Referencia SQL de la base de datos Oracle® , capítulo 19 Declaraciones SQL: SAVEPOINT para ACTUALIZAR , CONFIGURAR TRANSACCIÓN
- en JDBC : campos de constantes de conexión , Connection.getTransactionIsolation () , Connection.setTransactionIsolation (int)
- en Spring Framework : @Transactional , Aislamiento
- P. Bailis. ¿Cuándo es "ACID" ACID? Casi nunca