Una transacción de base de datos simboliza una unidad de trabajo , realizada dentro de un sistema de gestión de bases de datos (o sistema similar) contra una base de datos , que se trata de manera coherente y confiable independientemente de otras transacciones. Una transacción generalmente representa cualquier cambio en una base de datos. Las transacciones en un entorno de base de datos tienen dos propósitos principales:
En un sistema de gestión de bases de datos, una transacción es una única unidad lógica o de trabajo, a veces compuesta por múltiples operaciones. Cualquier cálculo lógico realizado de forma coherente en una base de datos se conoce como transacción. Un ejemplo es una transferencia de una cuenta bancaria a otra: la transacción completa requiere restar el monto a transferir de una cuenta y sumar ese mismo monto a la otra.
Una transacción de base de datos, por definición, debe ser atómica (debe estar completa en su totalidad o no tener efecto alguno), consistente (debe ajustarse a las restricciones existentes en la base de datos), aislada (no debe afectar a otras transacciones) y duradera. (debe escribirse en un almacenamiento persistente). [1] Los profesionales de bases de datos a menudo se refieren a estas propiedades de las transacciones de bases de datos utilizando el acrónimo ACID .
Las bases de datos y otros almacenes de datos que tratan la integridad de los datos como primordial a menudo incluyen la capacidad de manejar transacciones para mantener la integridad de los datos. Una sola transacción consta de una o más unidades de trabajo independientes, cada una de las cuales lee y/o escribe información en una base de datos u otro almacén de datos. Cuando esto sucede, suele ser importante asegurarse de que todo ese procesamiento deje la base de datos o el almacén de datos en un estado coherente.
Los ejemplos de sistemas de contabilidad por partida doble suelen ilustrar el concepto de transacciones. En la contabilidad por partida doble, cada débito requiere el registro de un crédito asociado. Si uno escribe un cheque por $100 para comprar alimentos, un sistema de contabilidad transaccional de partida doble debe registrar las dos entradas siguientes para cubrir la transacción única:
Un sistema transaccional haría que ambas entradas pasaran o ambas entradas fallarían. Al tratar el registro de múltiples entradas como una unidad de trabajo transaccional atómica, el sistema mantiene la integridad de los datos registrados. En otras palabras, nadie termina con una situación en la que se registra un débito pero no se registra ningún crédito asociado, o viceversa.
Una base de datos transaccional es un DBMS que proporciona las propiedades ACID para un conjunto entre corchetes de operaciones de base de datos (comienzo-compromiso). Las transacciones garantizan que la base de datos esté siempre en un estado consistente, incluso en caso de actualizaciones y fallas simultáneas. [2] Todas las operaciones de escritura dentro de una transacción tienen un efecto de todo o nada, es decir, la transacción se realiza correctamente y todas las escrituras surten efecto o, de lo contrario, la base de datos pasa a un estado que no incluye ninguna de las escrituras. de la transacción. Las transacciones también aseguran que el efecto de las transacciones concurrentes satisfaga ciertas garantías, conocidas como nivel de aislamiento . El nivel de aislamiento más alto es la serialización , que garantiza que el efecto de las transacciones concurrentes es equivalente a su ejecución en serie (es decir, secuencial).
La mayoría de los sistemas modernos de gestión de bases de datos relacionales admiten transacciones. Las bases de datos NoSQL priorizan la escalabilidad junto con el soporte de transacciones para garantizar la coherencia de los datos en caso de actualizaciones y accesos simultáneos.[update]
En un sistema de base de datos, una transacción puede consistir en una o más declaraciones y consultas de manipulación de datos, cada una de las cuales lee y/o escribe información en la base de datos. Los usuarios de sistemas de bases de datos consideran muy importantes la coherencia y la integridad de los datos. Generalmente se envía una transacción simple al sistema de base de datos en un lenguaje como SQL envuelto en una transacción, usando un patrón similar al siguiente:
Una operación de confirmación de transacción conserva todos los resultados de las manipulaciones de datos dentro del alcance de la transacción en la base de datos. Una operación de reversión de transacción no conserva los resultados parciales de las manipulaciones de datos dentro del alcance de la transacción en la base de datos. En ningún caso se puede confirmar una transacción parcial en la base de datos, ya que eso dejaría la base de datos en un estado inconsistente.
Internamente, las bases de datos multiusuario almacenan y procesan transacciones, a menudo utilizando un ID de transacción o XID.
Existen varias formas diferentes de implementar transacciones además de la forma sencilla documentada anteriormente. Las transacciones anidadas , por ejemplo, son transacciones que contienen declaraciones que inician nuevas transacciones (es decir, subtransacciones). Las transacciones multinivel son una variante de las transacciones anidadas donde las subtransacciones tienen lugar en diferentes niveles de una arquitectura de sistema en capas (por ejemplo, con una operación en el nivel del motor de base de datos, una operación en el nivel del sistema operativo). [3] Otro tipo de transacción es la transacción compensatoria .
Las transacciones están disponibles en la mayoría de las implementaciones de bases de datos SQL, aunque con distintos niveles de solidez. Por ejemplo, MySQL comenzó a admitir transacciones desde la versión 3.23, pero el motor de almacenamiento InnoDB no era predeterminado antes de la versión 5.5. El motor de almacenamiento disponible anteriormente, MyISAM, no admite transacciones.
Normalmente, una transacción se inicia mediante el comando BEGIN
(aunque el estándar SQL lo especifica START TRANSACTION
). Cuando el sistema procesa un COMMIT
extracto, la transacción finaliza con éxito. Una ROLLBACK
declaración también puede finalizar la transacción, deshaciendo cualquier trabajo realizado desde BEGIN
. Si la confirmación automática se deshabilitó al inicio de una transacción, la confirmación automática también se volverá a habilitar al finalizar la transacción.
Se puede establecer el nivel de aislamiento para operaciones transaccionales individuales y a nivel global. En el nivel más alto ( READ COMMITTED
), el resultado de cualquier operación realizada después de que se haya iniciado una transacción permanecerá invisible para otros usuarios de la base de datos hasta que la transacción haya finalizado. En el nivel más bajo ( READ UNCOMMITTED
), que ocasionalmente se puede utilizar para garantizar una alta simultaneidad, dichos cambios serán visibles de inmediato.
Las bases de datos relacionales se componen tradicionalmente de tablas con campos y registros de tamaño fijo. Las bases de datos de objetos comprenden blobs de tamaño variable , posiblemente serializables o que incorporan un tipo mime . Las similitudes fundamentales entre las bases de datos relacionales y de objetos son el inicio y el compromiso o reversión .
Después de iniciar una transacción, los registros u objetos de la base de datos se bloquean, ya sea de solo lectura o de lectura y escritura. Entonces pueden ocurrir lecturas y escrituras. Una vez que la transacción está completamente definida, los cambios se confirman o revierten de forma atómica , de modo que al final de la transacción no haya inconsistencia .
Los sistemas de bases de datos implementan transacciones distribuidas [4] como transacciones que acceden a datos a través de múltiples nodos. Una transacción distribuida impone las propiedades ACID en múltiples nodos y puede incluir sistemas como bases de datos, administradores de almacenamiento, sistemas de archivos, sistemas de mensajería y otros administradores de datos. En una transacción distribuida normalmente hay una entidad que coordina todo el proceso para garantizar que todas las partes de la transacción se apliquen a todos los sistemas relevantes. Además, la integración del almacenamiento como servicio (StaaS) dentro de estos entornos es crucial, ya que ofrece un conjunto prácticamente infinito de recursos de almacenamiento, que se adapta a una variedad de clases de almacenes de datos basados en la nube con diferentes disponibilidad, escalabilidad y propiedades ACID. Esta integración es esencial para lograr una mayor disponibilidad, un menor tiempo de respuesta y una rentabilidad en aplicaciones con uso intensivo de datos implementadas en almacenes de datos basados en la nube. [5]
El sistema de archivos Namesys Reiser4 para Linux [6] admite transacciones y, a partir de Microsoft Windows Vista , el sistema de archivos Microsoft NTFS [7] admite transacciones distribuidas entre redes. Se están realizando investigaciones sobre sistemas de archivos más coherentes con los datos, como el Warp Transactional Filesystem (WTF). [8]