Hispanopedia Wiki
Articulo de referencia

Aislamiento de instantánea

En las bases de datos y en el procesamiento de transacciones (gestión de transacciones), el aislamiento de instantáneas garantiza que todas las lecturas realizadas en una transa...

Hispanopedia WikiContenido en espanolLectura gratuita

En las bases de datos y en el procesamiento de transacciones (gestión de transacciones), el aislamiento de instantáneas garantiza 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 confirmados que existían en el momento en que comenzó), y la transacción en sí solo se confirmará correctamente si ninguna de las actualizaciones que haya realizado entra en conflicto con ninguna actualización simultánea realizada desde esa instantánea.

El aislamiento de instantáneas ha sido adoptado por varios sistemas de administración de bases de datos importantes , 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 así evita la mayoría de las anomalías de concurrencia que la serialización evita (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 valores generacionales de cada elemento de datos (versiones): MVCC es una forma común de aumentar la concurrencia y el rendimiento al generar una nueva versión de un objeto de base de datos cada vez que el objeto es escrito, y permitir operaciones de lectura de transacciones de varias versiones relevantes más recientes (de cada objeto). El aislamiento de instantánea 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 respecto a la serializabilidad, Oracle a veces se refiere al aislamiento de instantáneas como serializable .

Definición

Una transacción que se ejecuta bajo aislamiento de instantánea parece operar sobre una instantánea personal de la base de datos, tomada al inicio de la transacción. Al finalizar, la transacción se confirmará correctamente solo si los valores actualizados por la transacción no han sido modificados externamente desde que se tomó la instantánea. Un conflicto de escritura de este tipo provocará la cancelación de la transacción.

En una anomalía de sesgo de escritura , dos transacciones (T1 y T2) leen simultáneamente un conjunto de datos superpuesto (por ejemplo, los valores V1 y V2), realizan actualizaciones disjuntas simultáneamente (por ejemplo, T1 actualiza V1 y T2 actualiza V2) y, finalmente, confirman la transacción simultáneamente, sin que ninguna haya visto la actualización realizada por la otra. 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 la otra. En cambio, el aislamiento de instantáneas permite anomalías de sesgo de escritura.

Como ejemplo concreto, imaginemos que V1 y V2 son dos saldos que posee una misma persona, Phil. El banco permite que V1 o V2 ​​tengan un saldo negativo, siempre que el total en ambos nunca sea negativo (es decir, V1 + V2 ≥ 0). Ambos saldos son actualmente de $100. Phil realiza dos transacciones simultáneamente: T1, retirando $200 de V1, y T2, retirando $200 de V2.

Si la base de datos garantiza transacciones serializables, la forma más sencilla de codificar T1 es restar $200 de V1 y luego verificar que V1 + V2 ≥ 0 siga siendo válido, abortando en caso contrario. De manera similar, T2 resta $200 de V2 y luego verifica que V1 + V2 ≥ 0. Dado que las transacciones deben serializarse, o bien T1 se ejecuta primero, dejando V1 = −$100, V2 = $100, e impidiendo que T2 tenga éxito (ya que V1 + (V2 − $200) ahora es −$200), o bien T2 se ejecuta primero e impide de manera similar que T1 se confirme.

Sin embargo, si la base de datos está aislada mediante instantáneas (MVCC), T1 y T2 operan sobre instantáneas privadas de la base de datos: cada una deduce 200 dólares de una cuenta y luego verifica que el nuevo total sea cero, utilizando el valor de la otra cuenta que existía cuando se tomó la instantánea. Dado que ninguna actualización entra en conflicto, ambas se confirman correctamente, dejando V1 = V2 = -100 dólares y V1 + V2 = -200 dólares.

Algunos sistemas construidos con control de concurrencia multiversión (MVCC) pueden admitir (solo) aislamiento de instantánea para permitir que las transacciones procedan 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 recientes consistentes con el historial. La única información que debe almacenarse durante la transacción es una lista de las actualizaciones realizadas, que se puede escanear en busca de conflictos con bastante facilidad antes de la confirmación. Sin embargo, los sistemas MVCC (como MarkLogic) utilizan bloqueos para serializar las escrituras junto con MVCC para obtener algunas de las mejoras de rendimiento y, al mismo tiempo, admitir el nivel de aislamiento de "serializabilidad" más fuerte.

Soluciones alternativas

Los posibles problemas de inconsistencia derivados de anomalías de sesgo de escritura pueden corregirse añadiendo actualizaciones (de otro modo innecesarias) a las transacciones para garantizar la propiedad de serializabilidad . [ 4 ] [ 5 ] [ 6 ] [ 7 ]

Materializar el conflicto
Agregue una tabla de conflictos especial, que ambas transacciones actualizan para crear un conflicto directo de escritura-escritura.
Promoción
Hacer que una transacción "actualice" una ubicación de solo lectura (reemplazando un valor por el mismo valor) para crear un conflicto directo de escritura-escritura (o usar 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 este, creando un conflicto de escritura-escritura que impediría que los dos se realizaran simultáneamente. Sin embargo, este enfoque viola la forma normal .

Como alternativa, podemos convertir una de las lecturas de la transacción en una escritura. Por ejemplo, T2 podría establecer V1 = V1, creando un conflicto artificial de escritura-escritura con T1 y, de nuevo, impidiendo que ambas operaciones se completen simultáneamente. Esta solución no siempre es posible.

En general, por lo tanto, el aislamiento de instantáneas traslada parte del problema de mantener restricciones complejas al usuario, quien podría no comprender ni los posibles inconvenientes ni las posibles soluciones. La ventaja de esta transferencia es un mejor rendimiento.

Terminología

El aislamiento de instantáneas se denomina modo "serializable" en Oracle [ 8 ] [ 9 ] [ 10 ] y en versiones de PostgreSQL anteriores a la 9.1 [ 11 ] [ 12 ] [ 13 ] , lo que puede generar confusión con el modo de " serializabilidad real ". Existen argumentos a favor y en contra de esta decisión; lo que está claro es que los usuarios deben conocer esta distinción para evitar posibles comportamientos anómalos no deseados en la lógica de su sistema de base de datos.

Historia

El aislamiento de instantáneas surgió del trabajo en bases de datos de control de concurrencia multiversión , donde se mantienen múltiples versiones de la base de datos simultáneamente para permitir que los lectores se ejecuten sin colisionar con los escritores. Dicho sistema permite una definición e implementación natural de dicho nivel de aislamiento. [ 3 ] Se reconoció que InterBase , posteriormente propiedad de Borland , proporcionaba SI en lugar de serializabilidad 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 redactó pensando en una base de datos basada en bloqueos , por lo que resulta bastante vago al aplicarse a sistemas MVCC. Berenson et al. publicaron un artículo en 1995 [ 3 ] criticando el estándar SQL y citaron el aislamiento de instantáneas como ejemplo de un nivel de aislamiento que no presentaba las anomalías estándar descritas en el estándar ANSI SQL-92, pero que aún mostraba un comportamiento anómalo en comparación con las transacciones serializables .

En 2008, Cahill et al. demostraron que las anomalías de sesgo de escritura podían prevenirse detectando y abortando tríos "peligrosos" de transacciones concurrentes. [ 15 ] Esta implementación de serializabilidad es muy adecuada para bases de datos de control de concurrencia multiversión y se ha adoptado en PostgreSQL 9.1, [ 12 ] [ 13 ] [ 16 ] donde se conoce como Aislamiento de Instantáneas Serializables (SSI). Cuando se usa de forma consistente, esto elimina la necesidad de las soluciones alternativas anteriores. La desventaja sobre el aislamiento de instantáneas es un aumento en las transacciones abortadas. Esto puede tener un mejor o peor rendimiento que el aislamiento de instantáneas con las soluciones alternativas anteriores, dependiendo de la carga de trabajo.

Referencias

  1. ↑ "MySQL  :: Manual de referencia de MySQL 8.0  :: 15.5.2.3 Lecturas consistentes sin bloqueo" . dev.mysql.com . Consultado el 27 de agosto de 2018 .
  2. ↑ Control de concurrencia multiversión en MongoDB, CTO de MongoDB: Cómo nuestro nuevo motor de almacenamiento WiredTiger demostrará su valía
  3. 1 2 3 4 Berenson, Hal; Bernstein, Phil; Gray, Jim; Melton, Jim; O'Neil, Elizabeth ; O'Neil, Patrick (1995), "Una crítica de los niveles de aislamiento SQL de ANSI", Actas de la Conferencia Internacional ACM SIGMOD de 1995 sobre Gestión de Datos , págs. 1–10 , arXiv : cs/0701157 , doi : 10.1145/223784.223785 , ISBN  978-0897917315, S2CID 2316540 
  4. ↑ 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 , S2CID 1815415   
  5. ↑ Michael J. Cahill, Uwe Röhm, Alan D. Fekete (2008): "Aislamiento serializable para bases de datos de instantáneas" , Actas de la conferencia internacional ACM SIGMOD de 2008 sobre gestión de datos , págs. 729-738, Vancouver, Canadá, junio de 2008, ISBN 978-1-60558-102-6(Premio al mejor artículo de SIGMOD 2008)
  6. ↑ Michael J. Cahill, Uwe Röhm, Alan D. Fekete (2008): "Aislamiento serializable para bases de datos de instantáneas" , Actas de la conferencia internacional ACM SIGMOD de 2008 sobre gestión de datos , págs. 729-738, Vancouver, Canadá, junio de 2008, ISBN 978-1-60558-102-6(Premio al mejor artículo de SIGMOD 2008)
  7. ↑ Alan Fekete (2009), "Aislamiento de instantáneas y ejecución serializable" , Presentación, página 4, 2009, Universidad de Sídney (Australia). Consultado el 16 de septiembre de 2009.
  8. ↑ Conceptos de Oracle Database 10g Release 1 (10.1) Capítulo 13 : Concurrencia y consistencia de datos : niveles de aislamiento de Oracle 
  9. ↑ Pregúntale a Tom : Sobre los niveles de aislamiento de transacciones 
  10. ↑ Pregúntale a Tom  : "Transacción serializable"
  11. ↑ Documentación de PostgreSQL 9.0: 13.2.2.1. Aislamiento serializable frente a serializabilidad verdadera
  12. 1 2 Comunicado de prensa de PostgreSQL 9.1
  13. 1 2 Documentación de PostgreSQL 9.1.14: 13.2.3. Nivel de aislamiento serializable
  14. ↑ Stuntz, Craig. "Control de concurrencia multiversión antes de InterBase" . Archivado del original el 23 de octubre de 2007. Recuperado el 30 de octubre de 2014 .
  15. ↑ Michael J. Cahill, Uwe Röhm, Alan D. Fekete (2008) "Aislamiento serializable para bases de datos de 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 de SIGMOD 2008)
  16. ↑ Ports, Dan RK; Grittner, Kevin (2012). "Aislamiento de instantáneas serializables en PostgreSQL" (PDF) . Actas de la Fundación VLDB . 5 (12): 1850–1861 . arXiv : 1208.4179 . CiteSeerX 10.1.1.294.3803 . doi : 10.14778/2367502.2367523 . S2CID 16006111 .  

Lecturas adicionales

  • Bettina Kemme, Gustavo Alonso, Un nuevo enfoque para desarrollar e implementar protocolos de replicación de bases de datos ansiosos , ACM Transactions on Database Systems (TODS), vol. 25, n.º 3, págs.  333-379, septiembre de 2000.
  • Gerhard Weikum, Gottfried Vossen, Sistemas de información transaccionales: teoría, algoritmos y práctica del control y la 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 Conferencia Internacional ACM SIGMOD 2005, 2005.
  • Marta Patiño-Martínez, Ricardo Jiménez-Peris, Bettina Kemme, Gustavo Alonso. MIDDLE-R: Replicación consistente de bases de datos a nivel de middleware . ACM Transactions on Computer Systems (TOCS). Volumen 23, número 4. Páginas 375-423.
  • Khuzaima Daudjee, Kenneth Salem, Replicación diferida de bases de datos con aislamiento de instantáneas , VLDB 2006: páginas 715-726