En informática , ACID ( atomicidad , consistencia , aislamiento , durabilidad ) es un conjunto de propiedades de las transacciones de bases de datos destinadas a garantizar la validez de los datos a pesar de errores, cortes de energía y otros percances. [1] En el contexto de las bases de datos , una secuencia de operaciones de base de datos que satisface las propiedades ACID (que pueden percibirse como una única operación lógica sobre los datos) se denomina transacción . Por ejemplo, una transferencia de fondos de una cuenta bancaria a otra, incluso si implica múltiples cambios, como debitar una cuenta y acreditar en otra, es una sola transacción.
En 1983, [2] Andreas Reuter y Theo Härder acuñaron el acrónimo ACID , basándose en trabajos anteriores de Jim Gray [3] quien nombró atomicidad, consistencia y durabilidad, pero no aislamiento, al caracterizar el concepto de transacción. Estas cuatro propiedades son las principales garantías del paradigma de transacciones, que ha influido en muchos aspectos del desarrollo de los sistemas de bases de datos .
Según Gray y Reuters, el IBM Information Management System admitía transacciones ACID ya en 1973 (aunque el acrónimo se creó más tarde). [4]
Las características de estas cuatro propiedades definidas por Reuters y Härder son las siguientes:
Las transacciones a menudo se componen de múltiples declaraciones . La atomicidad garantiza que cada transacción se trate como una única "unidad", que tiene éxito o fracasa por completo: si alguna de las declaraciones que constituyen una transacción no se completa, toda la transacción falla y la base de datos no se modifica. Un sistema atómico debe garantizar la atomicidad en todas y cada una de las situaciones, incluidos los cortes de energía, los errores y las caídas. [5] Una garantía de atomicidad evita que las actualizaciones de la base de datos se realicen solo parcialmente, lo que puede causar mayores problemas que rechazar toda la serie de plano. Como consecuencia, otro cliente de base de datos no puede observar que la transacción esté en curso. En un momento, aún no ha sucedido, y en el siguiente, ya ha ocurrido en su totalidad (o no pasó nada si la transacción se canceló en curso).
La coherencia garantiza que una transacción solo pueda llevar la base de datos de un estado consistente a otro, preservando las invariantes de la base de datos : cualquier dato escrito en la base de datos debe ser válido de acuerdo con todas las reglas definidas, incluidas restricciones , cascadas , desencadenadores y cualquier combinación de los mismos. Esto evita la corrupción de la base de datos por una transacción ilegal. La integridad referencial garantiza la relación clave primaria – clave externa . [6]
Las transacciones a menudo se ejecutan simultáneamente (por ejemplo, múltiples transacciones leen y escriben en una tabla al mismo tiempo). El aislamiento garantiza que la ejecución simultánea de transacciones deje la base de datos en el mismo estado que se habría obtenido si las transacciones se ejecutaran secuencialmente. El aislamiento es el objetivo principal del control de concurrencia ; Según el nivel de aislamiento utilizado, es posible que los efectos de una transacción incompleta no sean visibles para otras transacciones. [7]
La durabilidad garantiza que una vez que se ha confirmado una transacción, permanecerá comprometida incluso en caso de una falla del sistema (por ejemplo, un corte de energía o una falla ). Esto generalmente significa que las transacciones completadas (o sus efectos) se registran en una memoria no volátil . [ cita necesaria ]
Los siguientes ejemplos ilustran con más detalle las propiedades de ACID. En estos ejemplos, la tabla de la base de datos tiene dos columnas, A y B. Una restricción de integridad requiere que el valor en A y el valor en B sumen 100. El siguiente código SQL crea una tabla como se describe anteriormente:
CREAR TABLA acidtest ( A INTEGER , B INTEGER , CHECK ( A + B = 100 )); La atomicidad es la garantía de que una serie de operaciones de base de datos en una transacción atómica ocurrirán todas (una operación exitosa) o ninguna (una operación fallida). La serie de operaciones no se puede separar ejecutando sólo algunas de ellas, lo que hace que la serie de operaciones sea "indivisible". Una garantía de atomicidad evita que las actualizaciones de la base de datos se realicen solo parcialmente, lo que puede causar mayores problemas que rechazar toda la serie de plano. En otras palabras, atomicidad significa indivisibilidad e irreductibilidad. [8] Alternativamente, podemos decir que una transacción lógica puede estar compuesta de varias transacciones físicas. A menos y hasta que se ejecuten todas las transacciones físicas de los componentes, la transacción lógica no habrá ocurrido.
Un ejemplo de transacción atómica es una transferencia monetaria de la cuenta bancaria A a la cuenta B. Consta de dos operaciones, retirar el dinero de la cuenta A y guardarlo en la cuenta B. No nos gustaría ver el monto retirado de la cuenta A antes. estamos seguros de que también se ha transferido a la cuenta B. Realizar estas operaciones en una transacción atómica garantiza que la base de datos permanezca en un estado consistente , es decir, que no se debita ni acredita dinero si alguna de esas dos operaciones falla. [9]
La coherencia es un término muy general que exige que los datos cumplan con todas las reglas de validación. En el ejemplo anterior, la validación es un requisito de que A + B = 100 . Todas las reglas de validación deben verificarse para garantizar la coherencia. Supongamos que una transacción intenta restar 10 de A sin alterar B. Como la coherencia se verifica después de cada transacción, se sabe que A + B = 100 antes de que comience la transacción. Si la transacción elimina 10 de A con éxito, se logrará la atomicidad. Sin embargo, una verificación de validación mostrará que A + B = 90 , lo cual es inconsistente con las reglas de la base de datos. Se debe cancelar toda la transacción y las filas afectadas deben revertirse a su estado anterior a la transacción. Si hubiera habido otras restricciones, desencadenantes o cascadas, cada operación de cambio se habría verificado de la misma manera que antes antes de confirmar la transacción. Pueden surgir problemas similares con otras restricciones. Es posible que hayamos requerido que los tipos de datos de A y B sean números enteros. Si luego introdujéramos, digamos, el valor 13,5 para A , la transacción se cancelará o el sistema puede generar una alerta en forma de disparador (si/cuando el disparador se haya escrito a este efecto). Otro ejemplo serían las restricciones de integridad, que no nos permitirían eliminar una fila en una tabla cuya clave principal esté referida por al menos una clave externa en otras tablas.
Para demostrar el aislamiento, asumimos que dos transacciones se ejecutan al mismo tiempo y cada una intenta modificar los mismos datos. Uno de los dos deberá esperar hasta que el otro complete para poder mantener el aislamiento.
Considere dos transacciones:
Combinadas, hay cuatro acciones:
Si estas operaciones se realizan en orden se mantiene el aislamiento, aunque T 2 debe esperar. Considere lo que sucede si T 1 falla a la mitad. La base de datos elimina los efectos de T 1 y T 2 solo ve datos válidos.
Al entrelazar las transacciones, el orden real de las acciones podría ser:
Nuevamente, considere lo que sucede si T 1 falla mientras modifica B en el Paso 4. Para cuando T 1 falla, T 2 ya ha modificado A; no se puede restaurar al valor que tenía antes de T 1 sin dejar una base de datos no válida. Esto se conoce como conflicto de escritura-escritura , [ cita necesaria ] porque dos transacciones intentaron escribir en el mismo campo de datos. En un sistema típico, el problema se resolvería volviendo al último estado correcto conocido, cancelando la transacción fallida T1 y reiniciando la transacción interrumpida T2 desde el estado correcto.
Considere una transacción que transfiere 10 de A a B. Primero, elimina 10 de A, luego suma 10 a B. En este punto, se le dice al usuario que la transacción fue un éxito. Sin embargo, los cambios todavía están en cola en el búfer del disco esperando ser confirmados en el disco. Se corta la energía y los cambios se pierden, pero el usuario asume (comprensiblemente) que los cambios persisten.
Procesar una transacción a menudo requiere una secuencia de operaciones que está sujeta a fallas por diversas razones. Por ejemplo, es posible que al sistema no le quede espacio en sus unidades de disco o que haya agotado el tiempo de CPU asignado. Hay dos familias de técnicas populares: registro de escritura anticipada y paginación oculta . En ambos casos, se deben adquirir bloqueos en toda la información que se va a actualizar y, dependiendo del nivel de aislamiento, posiblemente también en todos los datos que se puedan leer. En el registro de escritura anticipada, la durabilidad se garantiza escribiendo el posible cambio en un registro persistente antes de cambiar la base de datos. Eso permite que la base de datos vuelva a un estado consistente en caso de falla. En el sombreado, las actualizaciones se aplican a una copia parcial de la base de datos y la nueva copia se activa cuando se confirma la transacción.
Muchas bases de datos dependen del bloqueo para proporcionar capacidades ACID. Bloquear significa que la transacción marca los datos a los que accede para que el DBMS sepa que no debe permitir que otras transacciones los modifiquen hasta que la primera transacción tenga éxito o falle. El bloqueo siempre debe adquirirse antes de procesar los datos, incluidos los datos que se leen pero no modifican. Las transacciones no triviales normalmente requieren una gran cantidad de bloqueos, lo que genera una sobrecarga sustancial y bloquea otras transacciones. Por ejemplo, si el usuario A está ejecutando una transacción que tiene que leer una fila de datos que el usuario B desea modificar, el usuario B debe esperar hasta que se complete la transacción del usuario A. A menudo se aplica un bloqueo de dos fases para garantizar un aislamiento total.
Una alternativa al bloqueo es el control de concurrencia multiversión , en el que la base de datos proporciona a cada transacción de lectura la versión anterior, no modificada, de los datos que está siendo modificada por otra transacción activa. Esto permite a los lectores operar sin adquirir bloqueos, es decir, las transacciones de escritura no bloquean las transacciones de lectura y los lectores no bloquean a los escritores. Volviendo al ejemplo, cuando la transacción del usuario A solicita datos que el usuario B está modificando, la base de datos proporciona a A la versión de esos datos que existían cuando el usuario B inició su transacción. El usuario A obtiene una vista coherente de la base de datos incluso si otros usuarios están cambiando datos. Una implementación, concretamente el aislamiento de instantáneas , relaja la propiedad de aislamiento.
Garantizar las propiedades ACID en una transacción distribuida a través de una base de datos distribuida , donde ningún nodo es responsable de todos los datos que afectan una transacción, presenta complicaciones adicionales. Las conexiones de red pueden fallar, o un nodo puede completar exitosamente su parte de la transacción y luego se le solicita que revierta sus cambios debido a una falla en otro nodo. El protocolo de confirmación de dos fases (que no debe confundirse con el bloqueo de dos fases ) proporciona atomicidad para las transacciones distribuidas para garantizar que cada participante en la transacción esté de acuerdo sobre si la transacción debe confirmarse o no. [10] Brevemente, en la primera fase, un nodo (el coordinador) interroga a los otros nodos (los participantes), y sólo cuando todos responden que están preparados, el coordinador, en la segunda fase, formaliza la transacción.
Operación durante la cual un procesador puede leer simultáneamente una ubicación y escribirla en la misma operación de bus.
Esto evita que cualquier otro procesador o dispositivo de E/S escriba o lea la memoria hasta que se complete la operación.