Transacciones y ACID en bases de datos

Una transacción es un grupo de operaciones que la base de datos trata como una única unidad indivisible, de modo que o se completan todas las operaciones del grupo, o no se aplica ninguna de ellas. Es lo que se conoce como el principio de todo o nada. La necesidad de las transacciones surge de que muchas acciones del mundo real no consisten en una sola operación, sino en varias que deben ocurrir juntas para tener sentido. El ejemplo canónico es una transferencia de dinero entre dos cuentas, que en realidad implica dos operaciones: restar una cantidad de la cuenta de origen y sumar esa misma cantidad a la de destino. Si estas dos operaciones se ejecutaran de forma independiente y el sistema fallara justo después de la primera y antes de la segunda, el dinero desaparecería de una cuenta sin llegar a la otra, dejando la base de datos en un estado imposible e inaceptable. La transacción evita exactamente eso: agrupa ambas operaciones de manera que se comporten como una sola, garantizando que se apliquen las dos o ninguna. Cuando todas las operaciones de una transacción se completan con éxito, se realiza una operación de confirmación, llamada commit, que hace que los cambios queden permanentes. Si en cambio algo falla durante la transacción, se realiza una operación de deshacer, llamada rollback, que revierte todos los cambios y devuelve la base de datos exactamente al estado en que estaba antes de comenzar, como si la transacción nunca hubiera ocurrido. De este modo, las transacciones garantizan que la base de datos nunca quede en un estado intermedio incoherente.

ACID es un acrónimo que resume las cuatro propiedades fundamentales que garantizan que las transacciones de una base de datos sean fiables, y cada letra corresponde a una de ellas. La A es de atomicidad, que expresa el principio de todo o nada: las operaciones que componen una transacción se aplican todas o ninguna, nunca a medias, de modo que si algo falla, se deshace todo. La C es de consistencia, que garantiza que una transacción lleve la base de datos de un estado válido a otro estado también válido, respetando siempre todas las reglas de integridad definidas, como las claves, las restricciones y las relaciones, de manera que una transacción nunca pueda dejar los datos violando esas reglas. La I es de aislamiento, que garantiza que las transacciones que se ejecutan simultáneamente no interfieran entre sí, de modo que cada una se comporte como si se ejecutara sola, evitando que operaciones concurrentes que tocan los mismos datos se pisen y produzcan resultados incorrectos. La D es de durabilidad, que garantiza que, una vez que una transacción se ha confirmado, sus cambios quedan guardados de forma permanente y sobreviven incluso a un fallo inmediato del sistema, como un corte de luz o una caída, de modo que lo confirmado no se pierde jamás. Estas cuatro propiedades, tomadas en conjunto, son la promesa que hace una base de datos de que los datos nunca quedarán en un estado incoherente, incompleto o perdido a causa de errores, fallos o concurrencia, y son precisamente la razón por la que se confían a las bases de datos que las cumplen los datos más críticos y sensibles.

La atomicidad es la primera de las propiedades ACID y probablemente la más intuitiva e importante de entender, ya que expresa el principio de todo o nada que da sentido a las transacciones. Su nombre proviene de la idea de que la transacción es como un átomo en el sentido clásico de indivisible: no puede partirse en pedazos que se apliquen por separado, sino que se aplica entera o no se aplica en absoluto. En términos prácticos, la atomicidad garantiza que, si una transacción está compuesta por varias operaciones, o bien todas ellas se completan con éxito y sus efectos quedan reflejados, o bien, si cualquiera de ellas falla o si ocurre un problema en medio, se deshacen todas las que se hubieran realizado hasta ese momento y la base de datos vuelve al estado exacto en que estaba antes de comenzar la transacción. Esto es crucial porque evita los estados intermedios incoherentes, que son la fuente de las corrupciones de datos más graves. Volviendo al ejemplo de la transferencia de dinero, la atomicidad es lo que garantiza que nunca ocurra el escenario en que se resta el dinero de una cuenta pero no se suma a la otra: si por cualquier motivo la segunda operación no puede completarse, la atomicidad hace que también se revierta la primera, de modo que el dinero nunca desaparece ni se duplica. Sin atomicidad, cualquier fallo en medio de una secuencia de operaciones relacionadas dejaría los datos en un estado imposible, y sería responsabilidad del programador detectar y reparar manualmente esas situaciones, algo extremadamente difícil y propenso a errores. Por eso la atomicidad es una de las garantías más valiosas que ofrece una base de datos transaccional.

El aislamiento, la letra I de ACID, es la propiedad que garantiza que las transacciones que se ejecutan al mismo tiempo no interfieran entre sí, de modo que cada una se comporte como si fuera la única que se está ejecutando, aunque en realidad haya muchas ocurriendo en paralelo. El problema que resuelve es el de la concurrencia, que surge cuando dos o más transacciones acceden y modifican los mismos datos simultáneamente. Sin aislamiento, esta situación puede producir resultados incorrectos y corrupción de datos por interferencias sutiles. Un ejemplo clásico es el de dos clientes que intentan comprar al mismo tiempo la última unidad disponible de un producto: sin aislamiento, ambas transacciones podrían leer que hay una unidad en stock, y ambas proceder a venderla, resultando en dos ventas de un único producto y un stock que queda en negativo. Otro ejemplo es el de dos transferencias simultáneas que leen el mismo saldo de una cuenta antes de que la otra lo haya actualizado, pisándose mutuamente los cambios y provocando que uno de los movimientos se pierda. El aislamiento evita estos problemas garantizando que las transacciones concurrentes se comporten como si se ejecutaran una tras otra, en algún orden, en lugar de entremezclarse de forma caótica. Para lograrlo, las bases de datos emplean diversos mecanismos de control de la concurrencia, y ofrecen distintos niveles de aislamiento que permiten equilibrar el grado de protección frente a las interferencias con el rendimiento del sistema, ya que un aislamiento más estricto ofrece más garantías pero puede reducir la cantidad de operaciones simultáneas posibles. Elegir el nivel adecuado es una decisión importante en aplicaciones con alta concurrencia.

No, las propiedades ACID y las copias de seguridad protegen cosas distintas y ambas son necesarias, por lo que en absoluto una sustituye a la otra. Las propiedades ACID garantizan la integridad y la fiabilidad de los datos durante el funcionamiento normal de la base de datos y frente a los fallos que pueden ocurrir en el curso de las operaciones, como un error a mitad de una transacción, una caída del sistema en medio de una escritura o el acceso concurrente de varias transacciones a los mismos datos. Gracias a ACID, la base de datos nunca queda en un estado incoherente por estas causas, y lo que se ha confirmado no se pierde ante un corte de luz. Sin embargo, ACID no protege frente a otro tipo de amenazas que quedan fuera de su alcance. Por ejemplo, ACID no impide un borrado accidental pero confirmado correctamente: si alguien ejecuta y confirma una transacción que elimina datos importantes por error, ACID garantizará que ese borrado se aplique de forma íntegra y duradera, que es justo lo contrario de lo que se querría en ese caso. Tampoco protege ante la destrucción física del medio de almacenamiento, como un disco que se avería, ni ante corrupciones a nivel de hardware, ataques que cifren o dañen los datos, o errores humanos y de la aplicación que introduzcan datos incorrectos. Para todas esas situaciones hacen falta las copias de seguridad, que permiten restaurar los datos a un estado anterior conocido y bueno. En resumen, ACID protege la coherencia durante la operación, y los backups protegen ante desastres, pérdidas y errores; son capas de protección complementarias y una estrategia sólida de datos requiere las dos.

No todas las bases de datos garantizan ACID de la misma manera ni con el mismo alcance, y esta es de hecho una de las diferencias importantes entre las distintas familias de bases de datos. Las bases de datos relacionales tradicionales han hecho históricamente del cumplimiento estricto de las propiedades ACID una de sus señas de identidad y de sus principales fortalezas, ofreciendo garantías completas de atomicidad, consistencia, aislamiento y durabilidad, lo que las convierte en la elección natural para aplicaciones donde la integridad de los datos es crítica, como las financieras. En cambio, muchas bases de datos de la familia no relacional surgieron con un enfoque distinto, priorizando otras cualidades como la capacidad de escalar horizontalmente a lo largo de muchos servidores, el rendimiento en escenarios de enorme volumen o la flexibilidad del modelo de datos, y para lograrlo algunas relajaron deliberadamente ciertas garantías ACID, especialmente en entornos distribuidos, adoptando modelos de consistencia más flexibles en los que, por ejemplo, los datos pueden tardar un tiempo en ser coherentes en todas las réplicas. Esto no significa que unas sean mejores que otras, sino que responden a compromisos y necesidades diferentes: hay casos donde la coherencia inmediata y las garantías fuertes son imprescindibles, y otros donde la escala y la disponibilidad importan más y se puede tolerar una consistencia más laxa. Además, el panorama ha evolucionado y muchas bases de datos no relacionales modernas ofrecen hoy soporte transaccional y garantías más fuertes que en sus orígenes, mientras que las relacionales han ganado capacidades de escalado. Lo esencial es no dar por sentado que cualquier base de datos garantiza ACID de forma completa, sino conocer qué ofrece exactamente la que se va a usar y elegir en función de las necesidades reales de integridad del proyecto.