En las bases de datos y el procesamiento de transacciones (gestió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 coherente de la base de datos (en la práctica, lee los últimos valores comprometidos que existían en el momento de su inicio), y la transacción en sí se confirmará con éxito solo si ninguna actualización ha entrado en conflicto con las actualizaciones simultáneas realizadas desde esa instantánea.
El aislamiento de instantáneas ha sido adoptado por varios de los principales sistemas de administració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 de su adopción es que permite un mejor rendimiento que la serialización , pero aún evita la mayoría de las anomalías de concurrencia que evita la serialización (pero no siempre todas). En la práctica, el aislamiento de instantáneas se implementa dentro del control de concurrencia de múltiples versiones.(MVCC), donde se mantienen los valores generacionales de cada elemento de datos (versiones): MVCC es una forma común de aumentar la simultaneidad y el rendimiento al generar una nueva versión de un objeto de base de datos cada vez que se escribe el objeto y permitir las operaciones de lectura de transacciones de varias últimas versiones relevantes (de cada objeto). El aislamiento instantáneo se ha utilizado [3] para criticar la definición de niveles de aislamiento del estándar ANSI SQL -92 , ya que no presenta ninguna de las "anomalías" que prohibía el estándar SQL, pero no es serializable (el nivel de aislamiento libre de anomalías definido por ANSI ).
A pesar de su distinción con la serialización, Oracle a veces se refiere al aislamiento de instantáneas como serializable .
Definición
Una transacción que se ejecuta bajo aislamiento de instantáneas parece operar en una instantánea personal de la base de datos, tomada al inicio de la transacción. Cuando la transacción concluye, se confirmará con éxito solo si los valores actualizados por la transacción no se han cambiado externamente desde que se tomó la instantánea. Tal conflicto de escritura-escritura hará que la transacción se anule.
En una anomalía de sesgo de escritura , dos transacciones (T1 y T2) leen simultáneamente un conjunto de datos superpuestos (p. Ej., Valores V1 y V2), realizan actualizaciones disjuntas (p. Ej., T1 actualiza V1, T2 actualiza V2) y finalmente se comprometen simultáneamente, sin haber visto ninguna 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 escribir anomalías de sesgo.
Como ejemplo concreto, imagine que V1 y V2 son dos saldos mantenidos por una sola persona, Phil. El banco permitirá que V1 o V2 tengan un déficit, siempre que el total retenido 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 mantiene, abortando si no. T2 de manera similar deduce $ 200 de V2 y luego verifica V1 + V2 ≥ 0. Dado que las transacciones deben serializarse, T1 ocurre primero, dejando V1 = - $ 100, V2 = $ 100 y evitando que T2 tenga éxito (ya que V1 + (V2 - $ 200) es ahora - $ 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 una deduce $ 200 de una cuenta y luego verifica que el nuevo total es cero, utilizando el otro valor de cuenta que tenía cuando el Se tomó una instantánea. Dado que ninguna de las actualizaciones entra en conflicto, ambas se comprometen con éxito, dejando V1 = V2 = - $ 100 y V1 + V2 = - $ 200.
Algunos sistemas construidos con control de concurrencia de múltiples versiones (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 coherentes con la historia reciente. La única información que debe almacenarse durante la transacción es una lista de actualizaciones realizadas, que se puede escanear en busca de conflictos con bastante facilidad antes de comprometerse. Sin embargo, los sistemas MVCC (como MarkLogic) usará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 "serializabilidad" más fuerte.
Soluciones alternativas
Los posibles problemas de inconsistencia que surgen de las anomalías de sesgo de escritura se pueden solucionar agregando actualizaciones (de lo contrario innecesarias) a las transacciones para hacer cumplir la propiedad de serialización . [4]
- Materializar el conflicto
- Agregue una tabla de conflictos especial, que ambas transacciones actualizan para crear un conflicto directo de escritura-escritura.
- Promoción
- Haga que una transacción "actualice" una ubicación de solo lectura (reemplazando un valor con el mismo valor) para crear un conflicto directo entre escritura y escritura (o use una promoción equivalente, por ejemplo, SELECT FOR UPDATE de Oracle).
En el ejemplo anterior, podemos materializar el conflicto agregando una nueva tabla que hace 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-escritura que evitaría que los 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 de escritura-escritura artificial con T1 y, nuevamente, evitando que los dos tengan éxito al mismo tiempo. Es posible que esta solución no siempre sea posible.
En general, por lo tanto, el aislamiento de las instantáneas coloca parte del problema de mantener restricciones no triviales en el usuario, que puede no apreciar los posibles obstáculos o las posibles soluciones. La ventaja de esta transferencia es un mejor rendimiento.
Terminología
El aislamiento de instantáneas se denomina modo "serializable" en las versiones de Oracle [5] [6] [7] y PostgreSQL anteriores a 9.1, [8] [9] [10], 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 conocer la distinción para evitar posibles comportamientos anómalos no deseados en la lógica del sistema de su base de datos.
Historia
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 al mismo tiempo para permitir que los lectores se ejecuten sin colisionar con los escritores. Tal sistema permite una definición e implementación natural de tal nivel de aislamiento. [3] Se reconoció que InterBase , luego propiedad de Borland , proporcionaba SI en lugar de serialización total en la versión 4, [3] y probablemente permitía anomalías de escritura sesgada desde su primer lanzamiento en 1985. [11]
Desafortunadamente, el estándar ANSI SQL-92 se escribió con una base de datos basada en bloqueos en mente y, por lo tanto, es bastante vago cuando se aplica a sistemas MVCC. Berenson y col. 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. mostró que las anomalías de sesgo de escritura se pueden prevenir detectando y abortando tripletes "peligrosos" de transacciones concurrentes. [12] Esta implementación de serialización es adecuada para bases de datos de control de concurrencia multiversión y ha sido adoptada en PostgreSQL 9.1, [9] [10] [13] donde se conoce como "Aislamiento de instantáneas serializables", abreviado como SSI. Cuando se usa de manera consistente, esto elimina la necesidad de las soluciones 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 anteriores, según la carga de trabajo.
En 2011, Jimenez-Peris et al. presentó una patente [14] donde se mostró cómo era posible escalar a muchos millones de transacciones de actualización por segundo con un nuevo método para lograr el aislamiento de instantáneas de manera distribuida. El método se basa en la observación de que es posible realizar transacciones completamente en paralelo sin ninguna coordinación y, por lo tanto, eliminando el cuello de botella de los métodos tradicionales de procesamiento transaccional. El método utiliza un secuenciador de confirmación que genera marcas de tiempo de confirmación y un servidor de instantáneas que avanza la instantánea actual a medida que se llenan los espacios en el orden de serialización. Este método es la base de la base de datos LeanXcale. [15] La primera implementación de este método se realizó en 2010 como parte del Proyecto Europeo CumuloNimbo. [dieciséis]
Referencias
- ^ "MySQL :: MySQL 8.0 Reference Manual :: 15.5.2.3 Lecturas sin bloqueo consistentes" . dev.mysql.com . Consultado el 27 de agosto de 2018 .
- ^ Control de concurrencia de múltiples versiones en MongoDB, CTO de MongoDB: cómo nuestro nuevo motor de almacenamiento WiredTiger ganará sus rayas
- ^ a b c d Berenson, Hal; Bernstein, Phil; Gray, Jim; Melton, Jim; O'Neil, Elizabeth ; O'Neil, Patrick (1995), "A Critique of ANSI SQL Isolation Levels", Actas de la Conferencia internacional ACM SIGMOD sobre gestión de datos de 1995 , págs. 1-10, arXiv : cs / 0701157 , doi : 10.1145 / 223784.223785 , ISBN 978-0897917315
- ^ Fekete, Alan; Liarokapis, Dimitrios; O'Neil, Elizabeth ; O'Neil, Patrick ; Shasha, Dennis (2005), "Making Snapshot Isolation Serializable", ACM Transactions on Database Systems , 30 (2): 492–528, CiteSeerX 10.1.1.503.3169 , doi : 10.1145 / 1071610.1071615 , ISSN 0362-5915
- ^ Oracle Database Concepts 10g Release 1 (10.1) Capítulo 13: Concurrencia y consistencia de datos - Niveles de aislamiento de Oracle
- ^ Pregúntele a Tom: sobre niveles de aislamiento de transacciones
- ^ Pregúntele a Tom: "Transacción serializable"
- ^ Documentación de PostgreSQL 9.0: 13.2.2.1. Aislamiento serializable versus serialización real
- ^ a b Comunicado de prensa de PostgreSQL 9.1
- ^ a b Documentación de PostgreSQL 9.1.14: 13.2.3. Nivel de aislamiento serializable
- ^ Stuntz, Craig. "Control de concurrencia multiversión antes de InterBase" . Consultado el 30 de octubre de 2014 .
- ^ Michael J. Cahill, Uwe Röhm, Alan D. Fekete (2008) "Aislamiento serializable para bases de datos instantáneas" , Actas de la conferencia internacional ACM SIGMOD de 2008 sobre gestión de datos , págs. 729-738, ISBN 978-1-60558-102-6 (premio al mejor artículo SIGMOD 2008)
- ^ Puertos, Dan RK; Grittner, Kevin (2012). "Aislamiento de instantáneas serializables en PostgreSQL" (PDF) . Actas de la Dotación VLDB . 5 (12): 1850–1861. arXiv : 1208.4179 . CiteSeerX 10.1.1.294.3803 . doi : 10.14778 / 2367502.2367523 .
- ^ [1] , JIMÉNEZ-PERIS, Ricardo & Marta PATIÑO-MARTINEZ, "Sistema y método para procesamiento transaccional altamente escalable, descentralizado y de baja contención"
- ^ "LeanXcale" . leanxcale.com . Consultado el 20 de agosto de 2017 .
- ^ Jiménez-Peris, Ricardo; Patiño-Martínez, Marta; Magoutis, Kostas; Bilas, Angelos; Brondino, Ivan (abril de 2012). "CumuloNimbo: una plataforma de procesamiento de transacciones altamente escalable como servicio" . Noticias Ercim .
Otras lecturas
- Bettina Kemme, Gustavo Alonso, Un nuevo enfoque para desarrollar e implementar protocolos de replicación de bases de datos ávidos , ACM Transactions on Database Systems (TODS), v.25 n.3, p. 333-379, septiembre de 2000.
- Gerhard Weikum, Gottfried Vossen, Sistemas de información transaccional: teoría, algoritmos y la práctica del control y recuperación de la concurrencia , Morgan Kaufmann, 2002, ISBN 1-55860-508-8
- Yi Lin, Bettina Kemme, Marta Patiño-Martínez, Ricardo Jiménez-Peris. Replicación de datos basada en middleware que proporciona aislamiento de instantáneas . Actas de la Conf. Internacional ACM SIGMOD 2005, 2005.
- Marta Patiño-Martinez, Ricardo Jiménez-Peris, Bettina Kemme, Gustavo Alonso. MIDDLE-R: replicación consistente de la base de datos a nivel de middleware . Transacciones ACM en sistemas informáticos (TOCS). Volumen 23 Número 4. Páginas 375-423.
- Khuzaima Daudjee, Kenneth Salem, replicación perezosa de bases de datos con aislamiento de instantáneas , VLDB 2006: páginas 715-726