ACID en Las Bases de Datos

ACID en las bases de datos
En el mundo de las bases de datos es muy común escuchar hablar del concepto ACID.
ACID es un grupo de 4 propiedades que garantizan que las transacciones en las bases de
datos se realicen de forma confiable. Veamos en detalle este interesante concepto.
Para empezar a definir ACID en el ámbito de las bases de datos, es necesario

comprender el concepto de transacción. En las bases de datos, se denomina transacción
a una única operación lógica ("de negocio"). Por ejemplo, es una sola transacción la
acción de transferir fondos de una cuenta bancaria a otra, aún cuando involucra varios
cambios en distintas tablas.
En 1970, Jim Gray definió las propiedades que necesitaba tener una transacción
confiable, y desarrolló tecnologías para automatizarlas. Más tarde, en 1983, Andreas
Reuter y Theo Härder crearon el término "ACID" para describir estas 4 propiedades.
ACID, letra por letra

Atomicidad
La Atomicidad requiere que cada transacción sea "todo o nada": si una parte de la
transacción falla, todas las operaciones de la transacción fallan, y por lo tanto la base de
datos no sufre cambios. Un sistema atómico tiene que garantizar la atomicidad en
cualquier operación y situación, incluyendo fallas de alimentación eléctrica, errores y
caidas del sistema.
Consistencia
La propiedad de Consistencia se asegura que cualquier transacción llevará a la base de
datos de un estado válido a otro estado válido. Cualquier dato que se escriba en la base
de datos tiene que ser válido de acuerdo a todas las reglas definidas, incluyendo (pero
no limitado a) los constraints, los cascades, los triggers, y cualquier combinación de
estos.
aIslamiento
El aislamiento ("Isolation" en inglés) se asegura que la ejecución concurrente de las
transacciones resulte en un estado del sistema que se obtendría si estas transacciones
fueran ejecutadas una atrás de otra. Cada transacción debe ejecutarse en aislamiento
total; por ejemplo, si T1 y T2 se ejecutan concurrentemente, luego cada una debe
mantenerse independiente de la otra.
Durabilidad
La durabilidad significa que una vez que se confirmó una transacción (commit), quedará
persistida, incluso ante eventos como pérdida de alimentación eléctrica, errores y caidas
del sistema. Por ejemplo, en las bases de datos relacionales, una vez que se ejecuta un
grupo de sentencias SQL, los resultados tienen que almacenarse inmediatamente
(incluso si la base de datos se cae inmediatamente luego).
Sobre la Atomicidad
En una transacción atómica, una serie de operaciones en la base de datos ocurren todas,
o no ocurre ninguna. La atomicidad previene que las actualizaciones a la base ocurren
de forma parcial, lo cual podría ocasionar mayores problemas que rechazar la
transacción entera. En otras palabras, la atomicidad significa indivisibilidad e
irreducibilidad.
Usualmente, los sistemas implementan la atomicidad mediante algún mecanismo que

indica qué transacción comenzó y cuál finalizó; o manteniendo una copia de los datos
antes de que ocurran los cambios. Las bases de datos en general implementan la
atomicidad usando algún sistema de logging para seguir los cambios. El sistema
sincroniza los logs a medida que resulta necesario una vez que los cambios ocurren con
éxito. Luego, el sistema de recuperación de caidas simplemente ignora las entradas
incompletas.
En los sistemas de almacenamiento NoSQL con consistencia eventual, la atomicidad se

especifica de forma más débil que en los sistemas relacionales, y existe sólo para las
filas.
Sobre la Consistencia
La consistencia asegura que los cambios a los valores de una instancia son consistentes
con cambios a otros valores de la misma instancia. Una restricción de consistencia es un
predicado sobre los datos que funcionan como precondición, postcondición, y condición
de transformación en cualquier transacción. El sistema de la base de datos asume que la
consistencia se mantiene para cada transacción en las instancias. Por otro lado, asegurar
la propiedad de consistencia de la transacción es responsabilidad del usuario.
Sobre el Aislamiento
De las 4 propiedades de ACID en los sistemas de bases de datos, generalmente la
propiedad de Aislamiento es la más relajada. Cuando se intenta mantener el más alto
nivel de aislamiento, las bases de datos adquieren un bloqueo o implementan un control
concurrente multiversión, que puede resultar en pérdida de concurrencia. Esto genera
que la aplicación agregue lógica para funcionar correctamente.
La mayoría de las bases de datos ofrecen una cantidad de niveles de aislamiento de

transacciones, que controlan el grado de bloqueo que ocurre cuando se seleccionan
datos. Para muchas aplicaciones, se pueden construir la mayoría de las transacciones
evitando los niveles más altos de aislamiento (por ejemplo, el nivel SERIALIZABLE),
y por lo tanto reduciendo la carga en el sistema por bloqueos. El programador tiene que
analizar el código de acceso para asegurar que se pueda relajar el nivel de aislamiento
sin generar bugs que luego serían dificiles de encontrar. Por otro lado, si se usan niveles
más altos de aislamiento, es más probable la aparición de dealocks, lo cual requieren de
analisis y la implementación de técnicas de programación para evitarlos.
ANSI/ISO SQL define los siguientes tipos de aislamiento:
Serializable
Este es el nivel más alto de aislamiento. En una base de datos con control concurrente
basado en bloqueos, la serialización requiere que los bloqueos de lectura y escritura
(que se adquieren en datos seleccionados) sean liberados al finalizar la transacción.
También se pueden adquierir bloqueos de rango cuando se realiza un query SELECT
con una cláusula WHERE, especialmente cuando se quieren evitar lecturas fantasma.
En una base de datos con control concurrente no basado en bloqueos, no se necesitan los
bloqueos; sin embargo, si el sistema detecta una colisión de escritura entre muchas
transacciones concurrentes, sólo se permite el commit de una de estas transacciones.
Lecturas repetibles (repeatable reads)
En este nivel de aislamiento, un sistema de control de concurrencia basado en bloqueos
mantiene los bloqueos de escritura y lectura (que se adquieren en datos seleccionados)
hasta el final de la transacción. Sin embargo, no se gestionan los bloqueos de rango, por
lo tanto podrían ocurrir lecturas fantasma.
Lecturas sobre commits (read commited)
En este nivel de aislamiento, un sistema de control de concurrencia basado en bloqueos
mantiene los bloqueos de escritura (que se adquieren en datos seleccionados) hasta el
final de la transacción, pero los bloqueos de lectura se liberan ni bien se realiza la
operación de SELECT (y por lo tanto pueden ocurrir lecturas no-repetibles). Igual que
el nivel anterior, no se permiten bloqueos de rango.
Lecturas sin commits (read uncommited)
Este es el nivel más bajo de aislamiento. En este nivel se permiten las lecturas sucias,
por lo cual una transacción podría ver cambios de otra transacción que todavía tuvieron
un commit.
Consecuencia sobre las lecturas
El estandar ANSI/ISO SQL 92 se refiere a tres distintos fenómenos sobre la lectura que
ocurren cuando la Transacción 1 lee datos que la Transacción 2 puede haber cambiado.
Lecturas sucias
Las lecturas sucias ("dirty reads") ocurren cuando se permite que una transacción lea
una fila que fue modificada por otra transacción que todavía no hizo commit. Las
lecturas sin commit funcionan igual que las lecturas no-repetibles; sin embargo, la
segunda transacción no necesita haber hecho commit para que el primer query devuelva
datos distintos. Lo único que puede prevenirse en el nivel de aislamiento "Lecturas sin
commit" es que las actualizaciones aparezcan fuera de órden.
Lecturas no-repetibles
Una lectura no-repetible ocurre cuando, durante el curso de una transacción, se recupera
una fila dos veces y el valor de la fila difiere entre las lecturas. En las bases de datos con
control de concurrencia basado en bloqueos, el fenómeno de lecturas no-repetibles
puede ocurrir cuando no se adquieren bloqueos de lectura al ejecutar un SELECT, o
cuando los bloqueos adquieridos en las filas afectadas se liberan ni bien se ejecuta la
operación de SELECT.
Lecturas fantasma
Una lectura fantasma ocurre cuando, durante el curso de una transacción, se ejecutan
dos queries idénticos, y la colección de filas retornada por el segundo query es diferente
al primero. Esto puede ocurrir cuando no se adquieren bloqueos de rango al ejecutar una
operación SELECT...WHERE. Las lecturas fantasma son un caso especial de las
lecturas no-repetibles, cuando la transacción 1 repite la consulta rango
SELECT...WHERE y, entre ambas consultas, la Transacción 2 crea (INSERT) nuevas
filas que cumplen con la condición del WHERE.
Sobre la Durabilidad
La durabilidad es la propiedad que garantiza que las transacciones que tuvieron un
commit sobrevivan de forma permanente.
La durabilidad puede lograrse almacenando los registros de log de la transacción en un

medio de almacenamiento no-volatil antes de aceptar los commit.
En las transacciones distribuidas, todos los participantes deben coordinarse antes de

aceptar un commit. Esto se suele realizar mediante el protocolo de "commit en dos
fases".
Muchas bases de datos implementan la durabilidad escribiendo las transacciones en un

log de transacciones que puede ser reprocesado para recrear el estado del sistema antes
de una falla. Una transacción se considera confirmada sólo luego de que haya sido
ingresada al log.

ACID en Las Bases de Datos

Cargado por

Copyright:

Formatos disponibles

ACID en Las Bases de Datos

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ACID en Las Bases de Datos

Cargado por

Copyright:

Formatos disponibles

ACID en las bases de datos

Para empezar a definir ACID en el ámbito de las bases de datos, es necesario

ACID, letra por letra

Usualmente, los sistemas implementan la atomicidad mediante algún mecanismo que

En los sistemas de almacenamiento NoSQL con consistencia eventual, la atomicidad se

La mayoría de las bases de datos ofrecen una cantidad de niveles de aislamiento de

ANSI/ISO SQL define los siguientes tipos de aislamiento:

La durabilidad puede lograrse almacenando los registros de log de la transacción en un

En las transacciones distribuidas, todos los participantes deben coordinarse antes de

Muchas bases de datos implementan la durabilidad escribiendo las transacciones en un

También podría gustarte