Una guía de las propiedades ACID en los sistemas de gestión de bases de datos
El uso de aplicaciones en tiempo real y dispositivos de Internet de las cosas (IoT), más el crecimiento exponencial de los activos de datos no estructurados, hace que las organizaciones realicen la transición a bases de datos NoSQL cada vez más. De hecho, se prevé que el mercado NoSQL alcance los USD 74,500 millones para 2032, lo que representa una tasa de crecimiento (CAGR) del 24.9 % de 2024 a 2032 (Grupo IMARC, 2024).
Este crecimiento no es sorprendente dada la capacidad de los sistemas de gestión de bases de datos NoSQL (DBMS) para gestionar de forma eficaz conjuntos de datos grandes y diversos y el análisis de big data asociado necesario.
Sin embargo, muchos todavía creen que los DBMS NoSQL no pueden direccionar un requisito clave de muchas organizaciones: la gestión y el cumplimiento de las transacciones ACID. ¡La buena noticia es que algunos DBMS NoSQL definitivamente pueden hacerlo!
En este artículo, analizaremos qué son las transacciones ACID, las propiedades de las transacciones ACID, por qué son importantes estas transacciones y un ejemplo de transacción ACID en un DBMS NoSQL.
Índice
- Una breve historia de las transacciones ACID
- ¿Qué son las transacciones ACID ?
- ¿Por qué son importantes las transacciones ACID?
- Ejemplo de transacciones ACID en DBMS
- ¿Cómo funcionan las transacciones ACID en MongoDB?
- ¿Cuándo debería usar transacciones multidocumento de MongoDB?
- ¿Cuáles son las mejores prácticas para las transacciones en MongoDB?
- Preguntas frecuentes
Una breve historia de las transacciones ACID
El concepto de transacciones ACID ha sido fundamental para la evolución de los sistemas de bases de datos modernos desde finales de los años 70.
A medida que las empresas y las instituciones de investigación comenzaron a depender más de los datos digitales, se hizo evidente la necesidad de formas confiables para procesar operaciones complejas en varios registros. Las primeras bases de datos relacionales, como System R de IBM y Oracle, fueron unas de las primeras en experimentar con la aplicación de garantías más estrictas sobre la integridad de los datos y la fiabilidad de las transacciones.
En 1983, el científico informático Andreas Reuter y Theo Härder definieron formalmente las cuatro propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad) en un documento histórico. Su trabajo dio a la comunidad de bases de datos un lenguaje común para describir los requisitos para transacciones de bases de datos confiables. Cada propiedad estaba destinada a direccionar un desafío específico al garantizar que los datos permanecieran válidos y procesados de manera confiable, incluso cuando ocurrieran fallas:
- La atomicidad garantiza que varias operaciones en una transacción actúen como una única unidad: ya sea que todas tengan éxito o todas fallen.
- La coherencia asegura que la base de datos permanezca en un estado válido que cumpla con las reglas y restricciones definidas.
- El aislamiento evita que las transacciones simultáneas interfieran entre sí.
- La durabilidad asegura que una vez que se confirma una transacción, los resultados son permanentes, incluso después de fallas del sistema.
Este marco se convirtió en el estándar de oro para los sistemas de gestión de bases de datos relacionales (RDBMS), especialmente cuando las empresas los adoptaron para la banca, la venta minorista y las telecomunicaciones: sectores donde las transacciones financieras y el cumplimiento normativo requieren una precisión absoluta.
Durante las décadas de 1990 y principios de la de 2000, las bases de datos relacionales, como Oracle, IBM DB2 y Microsoft SQL Server, continuaron refinando la forma en que se implementaban las garantías de ACID, a menudo mediante técnicas como el registro de escritura anticipada, bloqueos y control de concurrencia de múltiples versiones.
Estos métodos permitieron a las organizaciones procesar millones de operaciones de bases de datos manteniendo una coherencia estricta.
Con el auge de las bases de datos NoSQL en la década de 2010, algunos cuestionaron si las garantías de ACID podrían preservarse en sistemas diseñados para la escala horizontal y la alta disponibilidad. Las primeras plataformas NoSQL a menudo relajaban la coherencia en favor del rendimiento y la disponibilidad, lo que llevó a asumir que la compatibilidad con ACID y la escalabilidad NoSQL se excluían mutuamente.
Sin embargo, a medida que crecía la demanda de integridad de datos en los sistemas distribuidos, proveedores como MongoDB demostraron que era posible admitir transacciones multi-documento sin dejar de escalar a través de múltiples nodos.
Hoy en día, las transacciones ACID siguen siendo más relevantes que nunca. Proporcionan la base para mantener la integridad de los datos en industrias donde los errores son inaceptables, desde las transferencias de cuentas bancarias hasta los registros de salud.
Al mismo tiempo, las plataformas modernas como MongoDB han extendido las garantías de ACID a datos flexibles y no estructurados, y a operaciones complejas en clústeres distribuidos. Esta combinación de fiabilidad y escalabilidad garantiza que los principios ACID, definidos por primera vez hace más de cuarenta años, sigan impulsando el futuro de la gestión de bases de datos.
¿Qué son las transacciones ACID ?
Explicación de las transacciones
En su nivel más básico, las transacciones de bases de datos son un grupo de operaciones de lectura y escritura de bases de datos que se han completado con éxito de acuerdo con las definiciones del DBMS (p. ej., los criterios de transacción definidos). Hay dos tipos principales de transacciones:
- Transacciones únicas: una transacción única se refiere a una serie de una o más operaciones de base de datos que dan como resultado una acción, completada correctamente. Una vez completada, la transacción se acepta y se puede encontrar en un registro de transacciones. Un ejemplo común de una transacción única es la retirada de dinero de un cajero automático.
- Multitransacciones: una multitransacción, a veces denominada transacción distribuida, consiste en múltiples transacciones interdependientes repartidas en diferentes bases de datos y sistemas (p. ej., sistemas distribuidos). Los registros de estas transacciones también se encuentran en un registro de transacciones. Un ejemplo de estas transacciones incluye la transferencia de dinero de una cuenta a otra o que un empleador emita a un nuevo empleado una credencial de seguridad con una foto.
Es importante tener en cuenta que algunas transacciones deben cumplir con estándares estrictos de integridad de los datos (p. ej., que los datos sean completos y correctos) y coherencia de los datos (p. ej., el valor es el mismo en todas las tablas o bases de datos). Este suele ser el caso cuando hay responsabilidad fiduciaria o cumplimiento normativo.
Los ejemplos incluyen banca comercial, corretaje de inversiones y acuerdos legales.
En estas situaciones, el cumplimiento de las definiciones estándar de DBMS no es suficiente y se requieren transacciones ACID .
Transacciones ACID
ACID es un acrónimo que significa atomicidad, coherencia, aislamiento y durabilidad. Juntas, las propiedades ACID garantizan que un conjunto de operaciones de base de datos (agrupadas en una transacción) dejen la base de datos en un estado válido incluso en caso de errores inesperados.
Además, las transacciones ACID proporcionan el nivel de garantías transaccionales que requieren muchas agencias reguladoras.
A continuación, se presenta una descripción general de cada elemento de ACID transaction, así como una descripción de cómo una base de datos de documentos NoSQL puede gestionar ese elemento de ACID. A los efectos de este artículo, se utilizará MongoDB Atlas.
Atomicidad
La atomicidad garantiza que todos los comandos que componen una transacción se traten como una sola unidad y se ejecuten correctamente o fallen juntos. Esto es importante en caso de falla del sistema o corte de energía, ya que si una transacción no se procesó completamente, se descartará y la base de datos mantiene la integridad de sus datos.
Cómo gestiona MongoDB la atomicidad
En MongoDB, una operación de escritura es atómica en el nivel de un solo documento, incluso si la operación modifica varios documentos incrustados dentro de un solo documento.
Para situaciones que requieren atomicidad de las lecturas y escrituras en varios documentos (en una sola colección o en varias), MongoDB admite transacciones distribuidas, incluidas las transacciones en sets de réplicas y clústeres particionados.
Coherencia
La coherencia garantiza que los cambios realizados en una transacción se propaguen en todo el sistema de base de datos (p. ej., nodos) y de conformidad con las restricciones del DBMS. Si la coherencia de los datos se va a ver afectada negativamente por una transacción en un estado incoherente, toda la transacción fallará.
Cómo gestiona MongoDB la coherencia
MongoDB ofrece la flexibilidad necesaria para normalizar o duplicar datos para optimizar las aplicaciones. Si los datos están duplicados en el esquema, el desarrollador debe decidir cómo mantener la coherencia de los datos duplicados en varias colecciones. Algunas aplicaciones requieren que los datos duplicados sean coherentes de inmediato, mientras que otras aplicaciones pueden tolerar la lectura de datos obsoletos. A continuación se ilustran ejemplos:
Nota: Obtenga más información sobre la coherencia de datos.
Aislamiento
Cada transacción se aísla de las demás transacciones para evitar conflictos de datos. Esto también ayuda a las operaciones de bases de datos en relación con la gestión de entradas múltiples y transacciones de varios niveles.
Por ejemplo, si dos usuarios intentan modificar los mismos datos (o incluso la misma transacción), el DBMS utiliza un mecanismo llamado administrador de bloqueos para suspender a otros usuarios hasta que se completen los cambios que está realizando el primer usuario.
Cómo MongoDB maneja el aislamiento
MongoDB emplea una técnica llamada aislamiento de snapshot (por ejemplo, cada transacción parece operar en un snapshot personal de la base de datos tomado al comienzo de la transacción). Las transacciones pueden leer datos del "snapshot" de datos confirmados en el momento en que se inicia la transacción, y cualquier actualización conflictiva hará que la transacción se anule.
Además, las transacciones de MongoDB asistencia técnica un nivel de confirmación de escritura (write concern) a nivel de transacción. Los clientes pueden establecer un nivel apropiado de preocupación por la lectura y la escritura, siendo el más riguroso la preocupación por las lecturas de snapshot combinada con la preocupación por la escritura mayoritaria. Un problema de escritura de la mayoría significa que las operaciones de escritura se han comprometido de forma duradera con una mayoría calculada de los nodos que contienen datos (configurable por el desarrollador).
Durabilidad
La durabilidad garantiza que una vez que se completa la transacción y se escriben los cambios en la base de datos, persisten. Esto garantiza que los datos dentro del sistema persistan incluso en caso de fallas del sistema como fallas o cortes de energía. El concepto de durabilidad es un elemento clave en la fiabilidad de los datos.
Cómo gestiona MongoDB la durabilidad
MongoDB crea un OpLog que contiene la ubicación del disco y los bytes cambiados para cada "escritura". Si hay un evento imprevisto (por ejemplo, un corte de energía) durante la escritura de la transacción, se puede usar el OpLog cuando el sistema se inicia de nuevo para reproducir cualquier escritura que no se haya vaciado en el disco antes del apagado.
Además, las operaciones se cambian antes de que se escriban en el OpLog, por lo que son idempotentes y se pueden reintentar varias veces. Las transacciones, o "escrituras", se vacían en el disco aproximadamente cada 60 segundos de forma predeterminada.
¿Por qué son importantes las transacciones ACID?
Las transacciones ACID ayudan a mantener la integridad y confiabilidad de los datos, al tiempo que garantizan que los datos vitales que están sujetos a regulaciones gubernamentales o del sector (p. ej., cuentas bancarias, cartera de acciones) cumplan con los estándares requeridos. Además, el cumplimiento de ACID suele ser un requisito previo para implementar la replicación de datos y lograr una alta disponibilidad en los sistemas de bases de datos distributed .
Ejemplo de ACID transaction en DBMS
Utilizando la base de datos de documentos NoSQL MongoDB Atlas, aquí se presenta un ejemplo de cómo se manejan las transacciones multi-documento ACID y cómo las transacciones ACID garantizan la alineación con los estándares mínimos de las propiedades ACID.
Transacciones ACID multidocumento
Imagine que está creando una función para transferir dinero de una cuenta bancaria a otra donde cada cuenta es su propio registro. Si el dinero se retira con éxito de la cuenta de origen pero nunca se acredita en la cuenta de destino, se ha creado un problema contable grave. Por el contrario, si se acredita la cuenta de destino pero nunca se carga la cuenta de origen, se produce otro problema contable grave.
Estas dos operaciones de escritura tienen que suceder o no ambas para mantener la coherencia del sistema y sus datos. Además, esto significa que si falla algún comando de la transacción, la base de datos debe revertir (p. ej., deshacer) todos los cambios que había escrito en el curso de la transacción.
Nota: Para obtener más información, visite el repositorio de GitHub de inicio rápido de Node.js para obtener una copia del código de muestra completo y ejecutarlo usted mismo.
Impactos que hay que recordar
Cuando se trate de transacciones de varios documentos en un sistema distributed , recuerde que existe un impacto en la gastos en general del rendimiento que puede afectar a las limitaciones de recursos y a los objetivos de rendimiento. Además, dado que la base de datos tiene que “bloquear” los recursos involucrados para evitar que las escrituras concurrentes interfieran entre sí (por ejemplo, que falle la transacción), otros clientes que intenten escribir datos pueden quedarse atascados esperando a que se complete la transacción, lo que puede afectar la latencia de la aplicación y experiencia de usuario.
¿Cómo funcionan las transacciones ACID en MongoDB?
El modelo de documento de MongoDB permite que los datos relacionados se almacenen juntos en un solo documento. El modelo de documento, combinado con las actualizaciones de documentos atómicos, obvia la necesidad de transacciones en la mayoría de los casos de uso. No obstante, hay casos en los que las verdaderas transacciones MongoDB de varios documentos y varias colecciones son la mejor opción.
Las transacciones de MongoDB funcionan de manera similar a las transacciones de otras bases de datos. Para usar una transacción, inicie una sesión de MongoDB a través de un controlador. Luego, use esa sesión para ejecutar su grupo de operaciones de base de datos. Puede ejecutar cualquiera de las CRUD (crear, leer, actualizar y eliminar) en múltiples documentos, colecciones y fragmentos.
Para ver muestras de código específicas sobre cómo implementar transacciones, consulte las siguientes guías de inicio rápido:
- Transacciones ACID multidocumento en MongoDB con Golang
- Transacciones ACID multidocumento en MongoDB con Java
- Transacciones ACID multidocumento en MongoDB con Node.js
- Transacciones ACID multidocumento en MongoDB con Python
Visite la documentación de los drivers de MongoDB para obtener guías específicas de cada idioma para cada uno de los idiomas admitidos oficialmente por MongoDB. También puede ver una lista de mejores prácticas de transacciones y consideraciones de producción.
¿Cuándo debería usar transacciones multidocumento de MongoDB?
Las aplicaciones que requieren transacciones suelen tener casos de uso en los que se intercambian valores entre diferentes partes. Por lo general, se trata de aplicaciones de "Sistema de registro" o "Línea de negocio".
Algunos ejemplos de aplicaciones que pueden beneficiarse de las transacciones multi-documento incluyen:
- Sistemas que mueven fondos de una cuenta a otra (p. ej., aplicaciones bancarias, sistemas de procesamiento de pagos, plataformas de comercio).
- Cadena de suministro y sistemas de reserva donde la propiedad de los bienes y servicios se transfiere de una parte a otra.
- Sistemas de facturación que almacenan información en registros detallados, así como registros de resúmenes.
¿Cuáles son las mejores prácticas para las transacciones en MongoDB?
En general, se recomienda modelar datos de modo que los datos a los que se accede en conjunto se almacenen juntos. Cuando los datos se modelan de esta manera, no solo se logrará un mejor rendimiento, sino que también no se requerirán transacciones.
Para las aplicaciones que requieren transacciones, siga estas mejores prácticas:
- Divida las transacciones de larga duración en partes más pequeñas para que no excedan el tiempo de espera predeterminado de 60 segundos. (Tenga en cuenta que este tiempo de espera puede ampliarse). Asegúrese de que las operaciones en las transacciones utilicen índices para que se ejecuten rápidamente.
- Limite cada transacción a 1.000 modificaciones de documentos.
- Asegúrese de que los niveles de confirmación de lectura y escritura adecuados estén configurados (tenga en cuenta que a partir de la versión 5.0, MongoDB establece por defecto el nivel de confirmación de escritura (write concern) de mayoría necesario).
- Agregue un manejo de errores apropiado y vuelva a intentar las transacciones que fallan debido a errores transitorios.
- Recuerde el costo de rendimiento de las transacciones que afectan a múltiples particiones. Para obtener más información sobre estas mejores prácticas, consulte el informe técnico sobre transacciones ACID multidocumento en MongoDB, así como la documentación de MongoDB sobre transacciones.