Hispanopedia WikiEn los sistemas de bases de datos , el aislamiento es una de las propiedades ACID ( Atomicidad , Consistencia , Aislamiento, Durabilidad ) de las transacciones . Determina cómo se percibe la integridad de las transacciones para otros usuarios y sistemas. Un nivel de aislamiento menor permite que varios usuarios accedan a los mismos datos simultáneamente, pero también incrementa la cantidad de efectos de concurrencia (como lecturas sucias o actualizaciones perdidas ) que los usuarios podrían experimentar. Por el contrario, un nivel de aislamiento mayor reduce los tipos de efectos de concurrencia que los usuarios pueden experimentar, pero requiere más recursos del sistema y aumenta las probabilidades de que una transacción bloquee a otra. [ 1 ]
control de concurrencia del DBMS
El control de concurrencia comprende los mecanismos subyacentes en un sistema de gestión de bases de datos (DBMS) que gestionan el aislamiento y garantizan la corrección relacionada. Es ampliamente utilizado por los motores de bases de datos y almacenamiento para garantizar la correcta ejecución de transacciones concurrentes y (a través de diferentes mecanismos) la corrección de otros procesos del DBMS. Los mecanismos relacionados con las transacciones suelen restringir la temporización de las operaciones de acceso a los datos de la base de datos ( planificaciones de transacciones ) a ciertos órdenes caracterizados por las propiedades de serialización y recuperabilidad . Restringir la ejecución de las operaciones de acceso a la base de datos generalmente implica una reducción del rendimiento (medido por las tasas de ejecución), por lo que los mecanismos de control de concurrencia suelen diseñarse para proporcionar el mejor rendimiento posible dentro de las restricciones. A menudo, cuando es posible sin perjudicar la corrección, la propiedad de serialización se sacrifica para obtener un mejor rendimiento. Sin embargo, la recuperabilidad no puede verse comprometida, ya que esto generalmente resulta en una violación de la integridad de la base de datos .
El bloqueo en dos fases es el método de control de concurrencia de transacciones más común en los sistemas de gestión de bases de datos (DBMS), utilizado para garantizar la serialización y la recuperabilidad de las transacciones. Para acceder a un objeto de la base de datos, una transacción primero necesita adquirir un bloqueo para dicho objeto. Dependiendo del tipo de operación de acceso (por ejemplo, lectura o escritura de un objeto) y del tipo de bloqueo, la adquisición del bloqueo puede bloquearse y posponerse si otra transacción ya lo tiene bloqueado.
Aislamiento del lado del cliente
El aislamiento se suele aplicar a nivel de base de datos. Sin embargo, también se pueden utilizar varios sistemas del lado del cliente. Se puede controlar en marcos de aplicación o contenedores de tiempo de ejecución como J2EE Entity Beans [ 2 ]. En sistemas más antiguos, puede implementarse de forma sistémica (por los desarrolladores de la aplicación), por ejemplo, mediante el uso de tablas temporales. En aplicaciones web de dos, tres o n capas , se puede utilizar un gestor de transacciones para mantener el aislamiento. Un gestor de transacciones es un middleware que se sitúa entre un servicio de aplicación (servicio de aplicación de back-end) y el sistema operativo . Un gestor de transacciones puede proporcionar aislamiento global y atomicidad. Realiza un seguimiento de cuándo nuevos servidores se unen a una transacción y coordina un protocolo de confirmación atómica entre los servidores. Los detalles se abstraen de la aplicación, lo que hace que las transacciones sean más simples y fáciles de codificar. Un monitor de procesamiento de transacciones (TPM) es una colección de middleware que incluye un gestor de transacciones. Un TPM puede proporcionar aislamiento local a una aplicación con un gestor de bloqueos. [ 2 ]
Fenómenos de lectura
La norma ANSI/ISO SQL 92 hace referencia a tres fenómenos de lectura diferentes que se producen cuando una transacción recupera datos que otra transacción podría haber actualizado.
En los siguientes ejemplos, se realizan dos transacciones. En la transacción 1, se realiza una consulta; luego, en la transacción 2, se realiza una actualización; y finalmente, en la transacción 1, se vuelve a realizar la misma consulta.
Los ejemplos utilizan la siguiente relación:
Lecturas obscenas
Una lectura sucia (también conocida como dependencia no confirmada ) ocurre cuando una transacción recupera una fila que ha sido actualizada por otra transacción que aún no se ha confirmado.
En este ejemplo, la transacción 1 recupera la fila con ID 1, luego la transacción 2 actualiza la fila con ID 1, y finalmente la transacción 1 recupera la fila con ID 1 nuevamente. Ahora bien, si la transacción 2 revierte su actualización (ya recuperada por la transacción 1) o realiza otras actualizaciones, la vista de la fila en la transacción 1 podría ser incorrecta. En el nivel de aislamiento READ UNCOMMITTED, la segunda consulta SELECT en la transacción 1 recupera la fila actualizada: esto es una lectura sucia. En los niveles de aislamiento READ COMMITTED, REPEATABLE READ y SERIALIZABLE, la segunda consulta SELECT en la transacción 1 recupera la fila inicial.
Lecturas no repetibles
Se produce una lectura no repetible cuando una transacción recupera una fila dos veces y esa fila es actualizada por otra transacción que se confirma entre medias.
En este ejemplo, la transacción 1 recupera la fila con ID 1, luego la transacción 2 actualiza la fila con ID 1 y se confirma, y finalmente la transacción 1 recupera la fila con ID 1 nuevamente. En los niveles de aislamiento READ UNCOMMITTED y READ COMMITTED, la segunda consulta SELECT en la transacción 1 recupera la fila actualizada: esta es una lectura no repetible. En los niveles de aislamiento REPEATABLE READ y SERIALIZABLE, la segunda consulta SELECT en la transacción 1 recupera la fila inicial.
Phantom lee
Se produce una lectura fantasma cuando una transacción recupera un conjunto de filas dos veces y otra transacción, que se confirma entre ambas, inserta o elimina nuevas filas de ese conjunto.
En este ejemplo, la transacción 1 recupera el conjunto de filas con edad mayor a 17, luego la transacción 2 inserta una fila con edad 26 y se confirma, y finalmente la transacción 1 recupera nuevamente el conjunto de filas con edad mayor a 17. En los niveles de aislamiento READ UNCOMMITTED, READ COMMITTED y REPEATABLE READ, la segunda instrucción SELECT en la transacción 1 recupera el nuevo conjunto de filas que incluye la fila insertada: esto es una lectura fantasma. En el nivel de aislamiento SERIALIZABLE, la segunda instrucción SELECT en la transacción 1 recupera el conjunto inicial de filas.
Existen dos estrategias básicas para prevenir lecturas no repetibles y lecturas fantasma. En la primera, el control de concurrencia basado en bloqueos , la transacción 2 se confirma después de que la transacción 1 se haya confirmado o revertido. Esto produce la secuencia de operaciones T1, T2 . En la otra estrategia, el control de concurrencia multiversión , la transacción 2 se confirma inmediatamente mientras que la transacción 1, que comenzó antes que la transacción 2, continúa operando sobre una instantánea antigua de la base de datos tomada al inicio de la transacción 1. Cuando la transacción 1 intenta confirmarse, si el resultado de la confirmación es equivalente a la secuencia de operaciones T1, T2 , entonces la transacción 1 se confirma; de lo contrario, hay un conflicto de confirmación y la transacción 1 se revierte con un fallo de serialización.
Bajo el control de concurrencia basado en bloqueos, pueden producirse lecturas no repetibles y lecturas fantasma cuando no se adquieren bloqueos de lectura al realizar una consulta SELECT, o cuando los bloqueos adquiridos en las filas afectadas se liberan tan pronto como se realiza la consulta SELECT. Bajo el control de concurrencia multiversión, pueden producirse lecturas no repetibles y lecturas fantasma cuando se relaja el requisito de que una transacción afectada por un conflicto de confirmación deba revertirse.
Niveles de aislamiento
De las cuatro propiedades ACID de un SGBD (Sistema de Gestión de Bases de Datos), la de aislamiento es la que con mayor frecuencia se flexibiliza. Al intentar mantener el máximo nivel de aislamiento, un SGBD suele adquirir bloqueos sobre los datos, lo que puede provocar una pérdida de concurrencia , o bien implementa un control de concurrencia multiversión . Esto requiere añadir lógica para que la aplicación funcione correctamente.
La mayoría de los sistemas de gestión de bases de datos (DBMS) ofrecen varios niveles de aislamiento de transacciones , que controlan el grado de bloqueo que se produce al seleccionar datos. En muchas aplicaciones de bases de datos, la mayoría de las transacciones pueden diseñarse para evitar la necesidad de altos niveles de aislamiento (por ejemplo, el 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 garantizar que cualquier relajación del aislamiento no provoque errores de software difíciles de detectar. Por el contrario, si se utilizan niveles de aislamiento más altos, aumenta la posibilidad de interbloqueo , lo 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 inferiores, ya que ningún nivel de aislamiento superior permite una acción prohibida por uno inferior, el estándar permite que un sistema de gestión de bases de datos (DBMS) ejecute una transacción en un nivel de aislamiento más fuerte que el solicitado (por ejemplo, una transacción de "Lectura confirmada" puede realizarse en realidad 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 .
En una implementación de DBMS con control de concurrencia basado en bloqueos , la serialización requiere que los bloqueos de lectura y escritura (adquiridos sobre los datos seleccionados) se liberen al final de la transacción. Además, se deben adquirir bloqueos de rango cuando una consulta SELECT utiliza una cláusula WHERE con rango , especialmente para evitar el fenómeno de lecturas fantasma .
Al utilizar el control de concurrencia sin bloqueo, no se adquieren bloqueos; sin embargo, si el sistema detecta una colisión de escritura entre varias transacciones concurrentes, solo se permite que una de ellas se confirme. Consulte el apartado de 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 en el nivel de aislamiento SERIALIZABLE sea serializable. Una ejecución serializable se define como una ejecución de las operaciones de transacciones SQL que se ejecutan concurrentemente y que produce el mismo efecto que una ejecución serial de esas mismas transacciones SQL. Una ejecución serial es aquella en la que cada transacción SQL se ejecuta por completo antes de que comience la siguiente.
Lecturas repetibles
En este nivel de aislamiento, una implementación de DBMS con control de concurrencia basado en bloqueos mantiene los bloqueos de lectura y escritura (adquiridos sobre datos seleccionados) hasta el final de la transacción. Sin embargo, los bloqueos de rango no se gestionan, por lo que pueden producirse lecturas fantasma .
En algunos sistemas, es posible que se produzca una asimetría de escritura a este nivel de aislamiento. La asimetría de escritura es un fenómeno en el que dos escritores diferentes (que previamente han leído las columnas que están actualizando) permiten dos escrituras en la misma columna o columnas de una tabla, lo que da como resultado que la columna contenga datos que son una mezcla de ambas transacciones. [ 3 ] [ 4 ]
Leer comprometido
En este nivel de aislamiento, una implementación de DBMS con control de concurrencia basado en bloqueos mantiene los bloqueos de escritura (adquiridos sobre 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). Al igual que en el nivel anterior, no se gestionan los bloqueos de rango .
En pocas palabras, la lectura confirmada es un nivel de aislamiento que garantiza que cualquier dato leído se confirme en el momento de la lectura. Simplemente impide que el lector vea cualquier lectura intermedia, no confirmada o "sucia". No garantiza en absoluto que si la transacción vuelve a realizar la lectura, encontrará los mismos datos; los datos pueden cambiar después de ser leídos.
Leer sin compromiso
Este es el nivel de aislamiento más bajo . En este nivel, se permiten lecturas no confirmadas , por lo que una transacción puede ver cambios aún no confirmados realizados por otras transacciones.
Nivel de aislamiento predeterminado
El nivel de aislamiento predeterminado de los distintos sistemas de gestión de bases de datos ( DBMS ) varía considerablemente. La mayoría de las bases de datos que admiten transacciones permiten al usuario configurar cualquier nivel de aislamiento. Algunos DBMS también requieren sintaxis adicional al ejecutar 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 que proporcionan muchas bases de datos:
- Este artículo muestra varias 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 laxas no excluyen cierto comportamiento anómalo... Esto conduce a algunos resultados contraintuitivos. En particular, los niveles de aislamiento basados en bloqueos 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 comunes en los sistemas comerciales. [ 5 ]
También existen otras críticas con respecto a la definición de aislamiento de ANSI SQL, ya que anima a los implementadores a hacer "cosas malas":
- ... se basa de forma sutil en la suposición de que se utiliza un esquema de bloqueo para el control de concurrencia, en contraposición a un esquema de concurrencia optimista o multiversión. Esto implica que la semántica propuesta está mal definida . [ 6 ]
Niveles de aislamiento frente a fenómenos de lectura
Ser serializable de forma anómala no es lo mismo que ser serializable. Es decir, es necesario, pero no suficiente, que una planificación serializable esté libre de los tres tipos de fenómenos. [ 5 ]
Véase también
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
- 1 2 "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 (2015-10-20). "Una guía para principiantes para leer y escribir fenómenos de sesgo" .
- ↑ "Wiki de PostgreSQL - SSI" .
- 1 2 "Una crítica de los niveles de aislamiento de ANSI SQL" (PDF) . Consultado el 29 de julio de 2012 .
- ↑ salesforce (06/12/2010). "Testimonios de clientes (SimpleGeo, CLOUDSTOCK 2010)" . www.DataStax.com: DataStax . Consultado el 09/03/2010 .
(¡Véase arriba, aproximadamente a los 13:30 minutos de la transmisión web!)
Enlaces externos
- Conceptos de bases de datos Oracle® , capítulo 13: Concurrencia y consistencia de datos, fenómenos prevenibles y niveles de aislamiento de transacciones.
- Referencia SQL de Oracle® Database , capítulo 19 Sentencias SQL: SAVEPOINT a UPDATE , SET TRANSACTION
- En JDBC : campos constantes de conexión , Connection.getTransactionIsolation() , Connection.setTransactionIsolation(int)
- En Spring Framework : @Transactional , Aislamiento
- P. Bailis. ¿Cuándo es "ÁCIDO" ÁCIDO? Rara vez.
- Gestión de datos
- Procesamiento de transacciones
