De Wikipedia, la enciclopedia libre
Saltar a navegación Saltar a búsqueda
Para otros usos, consulte Ácido (desambiguación) .

En ciencias de la computación , ACID ( atomicidad , consistencia , aislamiento , durabilidad ) es un conjunto de propiedades de transacciones de bases de datos destinadas a garantizar la validez de los datos a pesar de errores, fallas de energía y otros contratiempos. En el contexto de las bases de datos , una secuencia de operaciones de la base de datos que satisface las propiedades de ACID (que puede percibirse como una sola operación lógica sobre los datos) se denomina transacción . Por ejemplo, una transferencia de fondos de una cuenta bancaria a otra, incluso que implique cambios múltiples, como debitar una cuenta y acreditar otra, es una sola transacción.

En 1983, [1] Andreas Reuter y Theo Härder acuñaron el acrónimo ACID , basándose en trabajos anteriores de Jim Gray [2], 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 Reuter, IBM Information Management System admitía transacciones ACID desde 1973 (aunque el acrónimo se creó más tarde). [3]

Características [ editar ]

Las características de estas cuatro propiedades definidas por Reuter y Härder son las siguientes:

Atomicidad [ editar ]

Artículo principal: Atomicidad (sistemas de bases de datos)

Las transacciones suelen estar compuestas por varios extractos . La atomicidad garantiza que cada transacción se trata como una única "unidad", que tiene éxito por completo o falla 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, incluidas las fallas de energía, los errores y las caídas. [4]Una garantía de atomicidad evita que las actualizaciones de la base de datos se produzcan solo parcialmente, lo que puede causar mayores problemas que rechazar la serie completa. Como consecuencia, otro cliente de base de datos no puede observar que la transacción está en curso. En un momento en el tiempo, aún no ha sucedido, y en el siguiente ya ocurrió en su totalidad (o no sucedió nada si la transacción se canceló en curso).

Un ejemplo de transacción atómica es una transferencia monetaria de la cuenta bancaria A a la cuenta B. Consiste en dos operaciones, retirar el dinero de la cuenta A y guardarlo en la cuenta B. Realizar estas operaciones en una transacción atómica asegura que la base de datos permanece en un estado consistente , es decir, el dinero no se carga ni se acredita si alguna de esas dos operaciones falla. [5]

Coherencia [ editar ]

Artículo principal: Consistencia (sistemas de bases de datos)

La coherencia garantiza que una transacción solo puede llevar la base de datos de un estado válido a otro, manteniendo 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 las restricciones , cascadas , desencadenantes y cualquier combinación de los mismos. Esto evita la corrupción de la base de datos por una transacción ilegal, pero no garantiza que una transacción sea correcta . La integridad referencial garantiza la relación clave primaria - clave externa . [6]

Aislamiento [ editar ]

Artículo principal: Aislamiento (sistemas de bases de datos)

Las transacciones a menudo se ejecutan al mismo tiempo (por ejemplo, múltiples transacciones leyendo y escribiendo en una tabla al mismo tiempo). El aislamiento asegura que la ejecución concurrente de transacciones deja la base de datos en el mismo estado que se habría obtenido si las transacciones se hubieran ejecutado secuencialmente. El aislamiento es el objetivo principal del control de concurrencia ; Dependiendo del método utilizado, los efectos de una transacción incompleta podrían ni siquiera ser visibles para otras transacciones. [7]

Durabilidad [ editar ]

Artículo principal: Durabilidad (sistemas de bases de datos)

La durabilidad garantiza que una vez que se ha comprometido una transacción, seguirá comprometida incluso en el caso de una falla del sistema (por ejemplo, un corte de energía o un bloqueo ). Esto generalmente significa que las transacciones completadas (o sus efectos) se registran en una memoria no volátil . [ cita requerida ]

Ejemplos [ editar ]

Los siguientes ejemplos ilustran con más detalle las propiedades del 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 deben sumar 100. El siguiente código SQL crea una tabla como se describe arriba:

CREAR  TABLA  acidtest  ( A  INTEGER ,  B  INTEGER ,  CHECK  ( A  +  B  =  100 ));

Atomicidad [ editar ]

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 con solo algunas de ellas en ejecución, 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 produzcan solo parcialmente, lo que puede causar mayores problemas que rechazar la serie completa. En otras palabras, atomicidad significa indivisibilidad e irreductibilidad. [8]Alternativamente, podemos decir que una transacción lógica puede estar hecha o compuesta por una o más (varias) transacciones físicas. A menos que y hasta que se ejecuten todas las transacciones físicas de los componentes, la transacción lógica no habrá ocurrido, para los efectos de la base de datos. Digamos que nuestra transacción lógica consiste en transferir fondos de la cuenta A a la cuenta B. Esta transacción lógica puede estar compuesta por varias transacciones físicas que consisten en eliminar primero el monto de la cuenta A como primera transacción física y luego, como segunda transacción, depositar dicho monto. en la cuenta B. No quisiéramos ver la cantidad eliminada de la cuenta A antes de estar seguros de que se ha transferido a la cuenta B. Entonces, a menos que y hasta que se hayan realizado ambas transacciones y la cantidad se haya transferido a la cuenta B, la transferencia ha no,a los efectos de la base de datos, ocurrió.

Fallo de coherencia [ editar ]

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 un intento de transacción para restar 10 de A sin alterar B . Debido a que la consistencia 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, que es incompatible con las reglas de la base de datos. La transacción completa debe cancelarse 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 que se confirmara la transacción. Pueden surgir problemas similares con otras limitaciones. Es posible que hayamos requerido que los tipos de datos de A y B sean números enteros. Si tuviéramos que ingresar, digamos, el valor 13.5 para A, la transacción será cancelada, o el sistema puede dar lugar a una alerta en forma de disparador (si / cuando el disparador se ha escrito a tal efecto). Otro ejemplo sería con las restricciones de integridad, que no nos permitirían eliminar una fila en una tabla cuya clave principal es referida por al menos una clave externa en otras tablas.

Fallo de aislamiento [ editar ]

Para demostrar el aislamiento, asumimos que se ejecutan dos transacciones al mismo tiempo, cada una de las cuales intenta modificar los mismos datos. Uno de los dos debe esperar hasta que el otro se complete para mantener el aislamiento.

Considere dos transacciones: T 1 transfiere 10 de A a B. T 2 transfiere 20 de B a A.

Combinadas, hay cuatro acciones:

  1. T 1 resta 10 de A.
  2. T 1 agrega 10 a B.
  3. T 2 resta 20 de B.
  4. T 2 suma 20 a A.

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 intercalar las transacciones, el orden real de las acciones podría ser:

  1. T 1 resta 10 de A.
  2. T 2 resta 20 de B.
  3. T 2 suma 20 a A.
  4. T 1 agrega 10 a B.

De nuevo, 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 un conflicto de escritura-escritura , [ cita requerida ] porque dos transacciones intentaron escribir en el mismo campo de datos. En un sistema típico, el problema se resuelve volviendo al último estado bueno conocido, la cancelación de la transacción fallida T 1 , y reiniciar la operación interrumpida T 2 del estado buena.

Fallo de durabilidad [ editar ]

Considere una transacción que transfiere 10 de A a B. Primero elimina 10 de A, luego agrega 10 a B. En este punto, se le dice al usuario que la transacción fue un éxito. Sin embargo, los cambios aún se encuentran en cola en el búfer del disco a la espera de confirmarse en el disco. La energía falla y los cambios se pierden, pero el usuario asume (comprensiblemente) que los cambios persisten.

Implementación [ editar ]

El procesamiento de una transacción a menudo requiere una secuencia de operaciones que está sujeta a fallas por varias 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 sobre toda la información a actualizar y, dependiendo del nivel de aislamiento, posiblemente también sobre todos los datos que se puedan leer. En el registro de escritura anticipada, la durabilidad se garantiza copiando los datos originales (sin cambios) en un registro antes de cambiar la base de datos. [ dudoso - discutir ]Eso permite que la base de datos vuelva a un estado coherente en caso de un bloqueo. En el remedo, 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.

Bloqueo vs multiversión [ editar ]

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 la modifiquen hasta que la primera transacción tenga éxito o no. El bloqueo siempre debe adquirirse antes de procesar los datos, incluidos los datos que se leen pero no se modifican. Las transacciones no triviales generalmente 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. El bloqueo de dos fases se aplica a menudo para garantizar un aislamiento total.

Una alternativa al bloqueo es el control de concurrencia de múltiples versiones, en el que la base de datos proporciona a cada transacción de lectura la versión anterior, sin modificar, de los datos que está siendo modificada por otra transacción activa. Esto permite que los lectores funcionen 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ía 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 los datos. Una implementación, a saber, el aislamiento de instantáneas , relaja la propiedad de aislamiento.

Transacciones distribuidas [ editar ]

Artículo principal: transacción distribuida

Garantizar las propiedades de 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 a una transacción, presenta complicaciones adicionales. Las conexiones de red pueden fallar, o un nodo puede completar con éxito su parte de la transacción y luego tener que revertir sus cambios debido a una falla en otro nodo. El protocolo de compromiso 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. [9] Brevemente, en la primera fase, un nodo (el coordinador) interroga a los otros nodos (los participantes) y solo cuando todos responden que están preparados, el coordinador, en la segunda fase, formaliza la transacción.

Ver también [ editar ]

  • Consistencia eventual (BASE)
  • Teorema de CAP
  • Control de concurrencia
  • API de transacciones de Java
  • Sistemas abiertos de interconexión
  • NTFS transaccional
  • Protocolo de compromiso de dos fases
  • CRUD

Referencias [ editar ]

  1. ^ Haerder, T .; Reuter, A. (1983). "Principios de recuperación de bases de datos orientadas a transacciones". Encuestas de computación ACM . 15 (4): 287. CiteSeerX  10.1.1.115.8124 . doi : 10.1145 / 289.291 . S2CID  207235758 .
  2. ^ Gray, Jim (septiembre de 1981). "El concepto de transacción: virtudes y limitaciones" (PDF) . Actas de la 7ª Conferencia Internacional sobre Bases de Datos Muy Grandes . Cupertino, CA: Computadoras en tándem . págs. 144-154 . Consultado el 27 de marzo de 2015 .
  3. ^ Gray, Jim ; Reuter, Andreas (1993). Procesamiento de transacciones distribuidas: conceptos y técnicas . Morgan Kaufmann . ISBN 1-55860-190-2.
  4. ^ "Operación atómica" . webopedia.com . Webopedia . Consultado el 23 de marzo de 2011 . Una 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.
  5. ^ Amsterdam, Jonathan. "Transacciones de archivos atómicos, parte 1" . O'Reilly . Archivado desde el original el 3 de marzo de 2016 . Consultado el 28 de febrero de 2016 .
  6. ^ Fecha de CJ, "SQL y teoría relacional: cómo escribir código SQL preciso 2ª edición", O'reilly Media, Inc. , 2012, pág. 180.
  7. ^ "Niveles de aislamiento en el motor de base de datos", Technet, Microsoft, https://technet.microsoft.com/en-us/library/ms189122(v=SQL.105).aspx
  8. ^ "Atomicidad" . docs.oracle.com . Consultado el 13 de diciembre de 2016 .
  9. ^ Bernstein, Philip A .; Recién llegado, Eric (2009). "Capítulo 8". Principios del procesamiento de transacciones (2ª ed.). Morgan Kaufmann (Elsevier). ISBN 978-1-55860-623-4. Archivado desde el original el 7 de agosto de 2010.