Propiedad ACID de una Base 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.

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.

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.

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.

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.

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.

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

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 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.

Lo que usted guardo guardado se quedo