Aislamiento de instantánea

En bases de datos, y procesamiento de transacciones (administración de transacciones), aislamiento de instantánea es una garantía de que todas las lecturas hechas en un transacción podrá ver una instantánea consistente de la base de datos (en la práctica que se lee los valores comprometidos por última que existía en el momento que empezó), y la transacción se comprometerá con éxito solamente si no hay actualizaciones que ha hecho conflicto con cualquier actualización concurrente desde esa instantánea.

Aislamiento de instantánea ha sido adoptado por varias grandes sistemas de gestión de base de datos, tales como SQL en cualquier lugar, InterBase, Firebird, Oracle, PostgreSQL y Microsoft SQL Server (2005 y versiones posteriores). La razón principal para su adopción es que permite mejor rendimiento que serializabilidad, sin embargo aún evita la mayoría de las anomalías de la concurrencia que serializabilidad evita (pero no siempre todas). En la práctica el aislamiento de instantánea se implementa dentro de control de concurrencia multiversión (MVCC), donde se mantienen los valores generacionales de cada elemento de datos (versiones): MVCC es una forma común para aumentar la concurrencia y el rendimiento mediante la generación de una nueva versión de un objeto de base de datos cada vez que el objeto está escrito, y las transacciones que permite Lee las operaciones de varias versiones pasadas relevantes (de cada objeto). Aislamiento de instantánea también se ha utilizado al criticar la ANSI SQL-92 estándar es la definición de aislamiento los niveles, como exhibe ninguna de las "anomalías" que el SQL estándar prohibidas, sin embargo no es serializable (el nivel de aislamiento libre de anomalía definido por ANSI).

Aislamiento de instantánea se llama "serializable" modo en Oracle y PostgreSQL versiones anteriores a 9.1, que pueda causar confusión con el verdadero" serializabilidad"modo. Hay argumentos a favor y contra esta decisión; lo que está claro es que los usuarios deben ser conscientes de la distinción para evitar el posible comportamiento anómalo no deseado en su lógica de sistema de base de datos.

Definición

La ejecución de una transacción bajo aislamiento de instantánea aparece funcionar con un personal instantánea de la base de datos, asumido al inicio de la transacción. Cuando concluye la transacción, se comprometerá con éxito solamente si no se han cambiado los valores actualizados por la transacción externamente desde que fue tomada la instantánea. Tal un escritura-escritura conflicto causará la transacción para abortar.

En un escribir para sesgar anomalía, dos transacciones (T1 y T2) leer simultáneamente un conjunto de datos superpuesto (e.g. valores V1 y V2), simultáneamente hacen actualizaciones disjuntas (versiones V1 de T1, T2 actualizaciones V2) y finalmente al mismo tiempo comprometen, ni después de haber visto la actualización realizada por el otro. El sistema serializable, tal anomalía sería imposible, como T1 o T2 tendría que ocurrir "primero" y ser visible a los demás. En contraste, permisos de aislamiento de instantáneas escriben sesgar las anomalías.

Como ejemplo concreto, imaginar V1 y V2 son dos saldos por una sola persona, Phil. El Banco permitirá V1 o V2 a tener un déficit previsto el total en ambos nunca es negativo (es decir V1 + V2 ≥ 0). Ambos saldos son actualmente $100. Phil inicia dos transacciones concurrentemente, T1 retirar $200 de V1 y T2 retirar $200 de V2.

Si la base de datos garantiza las transacciones serializables, es la forma más sencilla de codificación T1 a deducir $200 de V1 y luego verificar que V1 + V2 ≥ 0 sigue en pie, abortar si no es así. T2 semejantemente descuenta $200 de V2 y luego verifica V1 + V2 ≥ 0. Puesto que las transacciones deben serializar, o T1 pasa en primer lugar, dejando V1 =-$100, V2 = $100 e impidiendo el éxito de T2 (desde V1 + (V2 - $200) es ahora-$200), o T2 pasa primero y evita asimismo T1 de cometer.

Bajo aislamiento de instantánea, sin embargo, T1 y T2 operan en fotos privadas de la base de datos: cada uno descuenta 200 dólares a una cuenta y luego verifica que el nuevo total es cero, usando el otro valor cuenta que realizó cuando fue tomada la instantánea. Ya que ninguno actualización los conflictos, tanto cometen con éxito, dejando V1 = V2 =-$100 y V1 + V2 =-$200.

Si construido control de concurrencia multiversión, aislamiento de instantánea permite que las transacciones proceder sin preocuparse de operaciones simultáneas, y lo más importante sin necesidad de volver a comprobar todos leer las operaciones cuando la transacción finalmente comete. La única información que debe ser almacenada durante la transacción es una lista de actualizaciones hechas, que puede ser escaneados de conflictos bastante fácilmente antes de comprometerse.

Soluciones

Posibles problemas de inconsistencia derivadas de escritura para sesgar anomalías pueden fijarse mediante la adición de cambios (de lo contrario innecesarios) a las transacciones con el fin de hacer cumplir la serializabilidad propiedad.

• Materializar el conflicto:: Añadir una tabla especial de conflicto, que ambas transacciones actualización con el fin de crear un conflicto de escritura-escritura directa.
• Promoción:: Tengo una transacción "actualizar" un lugar de sólo lectura (sustituyendo un valor con el mismo valor) con el fin de crear un conflicto directo escribir-escribir (o utilizar una promoción equivalente, por ejemplo de Oracle selecciona para actualizar).

En el ejemplo anterior, podemos materializamos el conflicto mediante la adición de una nueva tabla que explicita la restricción oculta, mapeo de cada persona a su saldo total. Phil empezaría con un saldo total de $200, y cada transacción tratarían de restar $200, creando un conflicto de escritura y escritura que impediría que los dos de éxito simultáneamente. Este enfoque viola el forma normal.

Alternativamente, podemos promover uno de lecturas de la transacción para una escritura. Por ejemplo, T2 podría fijar V1 = V1, creando un conflicto artificial escritura-escritura con T1 y prevenir otra vez, logrando al mismo tiempo los dos. Esta solución no siempre es posible.

En general, por lo tanto, aislamiento de instantánea pone a algunos de los problema de mantener restricciones no trivial sobre el usuario, quien no podrá apreciar los peligros potenciales o las posibles soluciones. Lo bueno de esta transferencia es mejor rendimiento.

Historia

Aislamiento de instantánea surgió del trabajo en control de concurrencia multiversión bases de datos, donde se mantienen simultáneamente varias versiones de la base de datos para permitir a los lectores a ejecutar sin chocar con los escritores. Este sistema permite una natural definición e implantación de tal nivel de aislamiento. InterBase, luego propiedad de Borland, fue reconocida para proporcionar SI en lugar de serializabilidad completo en la versión 4, y probables permitidas write-sesgo anomalías desde su primer lanzamiento en 1985.

Desafortunadamente, el ANSI SQL-92 estándar fue escrito con un cerradura-basado en base de datos en mente y por lo tanto es bastante impreciso cuando se aplica a los sistemas MVCC. Berenson et al. escribió un libro en 1995 criticando el SQL aislamiento de instantánea estándar y citan como ejemplo de un nivel de aislamiento que no exhibió las anomalías estándar descrito en el estándar ANSI SQL-92, sin embargo, todavía tenía comportamientos anómalos en comparación con serializable transacciones.

En 2008, Cahill et al. demostró que escribir-sesgo anomalías podrían prevenirse mediante la detección y abortar a "peligrosos" trillizas de transacciones simultáneas. Esta implementación de serializabilidad es adecuada para control de concurrencia multiversión bases de datos y ha sido adoptado en PostgreSQL 9.1, donde se refiere como "Serializable aislamiento de instantánea", abreviado a SSI. Cuando se utiliza constantemente, esto elimina la necesidad de las soluciones anteriores. La desventaja sobre aislamiento de instantánea es un aumento en las transacciones abortadas. Esto puede realizar mejor o peor que el aislamiento de instantánea con las soluciones anteriores, dependiendo de la carga de trabajo.

Lectura adicional

• Gerhard Weikum, Gottfried Vossen, Sistemas de información transaccional: teoría, algoritmos y la práctica del control de concurrencia y recuperación, Morgan Kaufmann, 2002, ISBN 1-55860-508-8
• Khuzaima Daudjee, Kenneth Salem, Perezoso de base de datos replicación con aislamiento de instantánea, VLDB 2006: páginas 715-726

Otras Páginas

• Editor hexadecimal
• Rio Noguera Pallaresa
• Psicoterapia interpersonal
• DudaMobile
• Real de plata
• Caja de dinero (radio)
• Benjamin Bristow (categoria abogados de Estados Unidos para el districto de Kentucky)