En bases de datos y procesamiento de transacciones (administración de transacciones), el aislamiento de instantáneas es una garantía de que todas las lecturas realizadas en una transacción verán una instantánea consistente de la base de datos (en la práctica, lee los últimos valores confirmados que existían en el momento de su inicio), y la transacción en sí se confirmará exitosamente solo si ninguna actualización que haya realizado entre en conflicto con las actualizaciones simultáneas realizadas desde esa instantánea.
El aislamiento de instantáneas ha sido adoptado por varios sistemas importantes de gestión de bases de datos , como InterBase , Firebird , Oracle , MySQL , [1] PostgreSQL , SQL Anywhere , MongoDB [2] y Microsoft SQL Server (2005 y posteriores). La razón principal para su adopción es que permite un mejor rendimiento que la serialización , pero aún así evita la mayoría de las anomalías de concurrencia que evita la serialización (pero no todas). En la práctica, el aislamiento de instantáneas se implementa dentro del control de concurrencia multiversión (MVCC), donde se mantienen los valores generacionales de cada elemento de datos (versiones): MVCC es una forma común de aumentar la concurrencia y el rendimiento generando una nueva versión de un objeto de base de datos cada vez que el objeto está escrito y permite operaciones de lectura de transacciones de varias de las últimas versiones relevantes (de cada objeto). El aislamiento de instantáneas se ha utilizado [3] para criticar la definición de niveles de aislamiento del estándar ANSI SQL -92 , ya que no muestra ninguna de las "anomalías" que el estándar SQL prohibía, pero no es serializable (el nivel de aislamiento libre de anomalías definido por ANSI ).
A pesar de su distinción de la serialización, Oracle a veces se refiere al aislamiento de instantáneas como serializable .
Una transacción que se ejecuta bajo aislamiento de instantánea parece operar en una instantánea personal de la base de datos, tomada al inicio de la transacción. Cuando la transacción concluya, se confirmará con éxito solo si los valores actualizados por la transacción no se han modificado externamente desde que se tomó la instantánea. Tal conflicto de escritura-escritura hará que la transacción se cancele.
En una anomalía de sesgo de escritura , dos transacciones (T1 y T2) leen simultáneamente un conjunto de datos superpuestos (por ejemplo, los valores V1 y V2), realizan simultáneamente actualizaciones separadas (por ejemplo, T1 actualiza V1, T2 actualiza V2) y, finalmente, se confirman simultáneamente, sin haber visto la actualización realizada por el otro. Si el sistema fuera serializable, tal anomalía sería imposible, ya que T1 o T2 tendrían que ocurrir "primero" y ser visibles para el otro. Por el contrario, el aislamiento de instantáneas permite anomalías de sesgo de escritura.
Como ejemplo concreto, imaginemos que V1 y V2 son dos balanzas sostenidas por una sola persona, Phil. El banco permitirá que V1 o V2 tengan déficit, siempre que el total mantenido en ambos nunca sea negativo (es decir, V1 + V2 ≥ 0). Ambos saldos son actualmente de $100. Phil inicia dos transacciones al mismo tiempo: T1 retira $200 de V1 y T2 retira $200 de V2.
Si la base de datos garantiza transacciones serializables, la forma más sencilla de codificar T1 es deducir $200 de V1 y luego verificar que V1 + V2 ≥ 0 todavía se cumple, abortando si no. De manera similar, T2 deduce $200 de V2 y luego verifica que V1 + V2 ≥ 0. Dado que las transacciones deben serializarse, T1 ocurre primero, dejando V1 = −$100, V2 = $100 e impidiendo que T2 tenga éxito (ya que V1 + (V2 − $200) ahora es −$200), o T2 ocurre primero y de manera similar evita que T1 se comprometa.
Sin embargo, si la base de datos está bajo aislamiento de instantáneas (MVCC), T1 y T2 operan en instantáneas privadas de la base de datos: cada uno deduce $200 de una cuenta y luego verifica que el nuevo total sea cero, utilizando el otro valor de cuenta que tenía cuando se se tomó la instantánea. Dado que ninguna de las actualizaciones entra en conflicto, ambas se confirman correctamente, dejando V1 = V2 = −$100 y V1 + V2 = −$200.
Algunos sistemas creados con control de concurrencia multiversión (MVCC) pueden admitir (solo) el aislamiento de instantáneas para permitir que las transacciones continúen sin preocuparse por las operaciones concurrentes y, lo que es más importante, sin necesidad de volver a verificar todas las operaciones de lectura cuando la transacción finalmente se confirma. Esto es conveniente porque MVCC mantiene una serie de estados consistentes con la historia reciente. La única información que debe almacenarse durante la transacción es una lista de actualizaciones realizadas, que se pueden escanear en busca de conflictos con bastante facilidad antes de confirmarlas. Sin embargo, los sistemas MVCC (como MarkLogic) utilizarán bloqueos para serializar escrituras junto con MVCC para obtener algunas de las ganancias de rendimiento y aún admitir el nivel de aislamiento de "serialización" más fuerte.
Los posibles problemas de inconsistencia que surgen de anomalías de sesgo de escritura se pueden solucionar agregando actualizaciones (que de otro modo serían innecesarias) a las transacciones para hacer cumplir la propiedad de serialización . [4] [5] [6] [7]
En el ejemplo anterior, podemos materializar el conflicto agregando una nueva tabla que haga explícita la restricción oculta, asignando a cada persona su saldo total . Phil comenzaría con un saldo total de $200, y cada transacción intentaría restar $200 de esto, creando un conflicto de escritura que impediría que las dos tuvieran éxito al mismo tiempo. Sin embargo, este enfoque viola la forma normal .
Alternativamente, podemos promover una de las lecturas de la transacción a escritura. Por ejemplo, T2 podría establecer V1 = V1, creando un conflicto artificial de escritura-escritura con T1 y, nuevamente, impidiendo que los dos tengan éxito al mismo tiempo. Es posible que esta solución no siempre sea posible.
Por lo tanto, en general, el aislamiento de instantáneas plantea parte del problema de mantener restricciones no triviales al usuario, quien puede no apreciar ni los posibles problemas ni las posibles soluciones. La ventaja de esta transferencia es un mejor rendimiento.
El aislamiento de instantáneas se denomina modo "serializable" en las versiones de Oracle [8] [9] [10] y PostgreSQL anteriores a 9.1, [11] [12] [13], lo que puede causar confusión con el modo de " serialización real ". Hay argumentos tanto a favor como en contra de esta decisión; lo que está claro es que los usuarios deben ser conscientes de la distinción para evitar posibles comportamientos anómalos no deseados en la lógica de su sistema de base de datos.
El aislamiento de instantáneas surgió del trabajo en bases de datos de control de concurrencia de múltiples versiones , donde se mantienen múltiples versiones de la base de datos simultáneamente para permitir que los lectores ejecuten sin chocar con los escritores. Un sistema de este tipo permite una definición y una implementación naturales de dicho nivel de aislamiento. [3] Se reconoció que InterBase , posteriormente propiedad de Borland , proporcionaba SI en lugar de serialización completa en la versión 4, [3] y probablemente permitió anomalías de sesgo de escritura desde su primer lanzamiento en 1985. [14]
Desafortunadamente, el estándar ANSI SQL-92 se escribió teniendo en mente una base de datos basada en bloqueos y, por lo tanto, es bastante vago cuando se aplica a sistemas MVCC. Berenson et al. escribió un artículo en 1995 [3] criticando el estándar SQL y citó el aislamiento de instantáneas como un ejemplo de un nivel de aislamiento que no exhibía las anomalías estándar descritas en el estándar ANSI SQL-92, pero aún tenía un comportamiento anómalo en comparación con las transacciones serializables . .
En 2008, Cahill et al. demostró que las anomalías de sesgo de escritura se podían prevenir detectando y abortando tripletes "peligrosos" de transacciones concurrentes. [15] Esta implementación de serialización se adapta bien a bases de datos de control de concurrencia multiversión y se adoptó en PostgreSQL 9.1, [12] [13] [16], donde se conoce como aislamiento de instantáneas serializables (SSI). Cuando se usa de manera consistente, esto elimina la necesidad de las soluciones alternativas anteriores. La desventaja del aislamiento de instantáneas es un aumento en las transacciones abortadas. Esto puede funcionar mejor o peor que el aislamiento de instantáneas con las soluciones alternativas anteriores, según la carga de trabajo.