Modelo ACID de transacciones

Modelo ACID de transacciones

En las bases de datos es común trabajar con lo que llamamos transacciones, una transacción es un conjunto de operaciones que se deben realizar en una base de datos de manera conjunta, que se deben realizar todas las operaciones o ninguna.

Para que exista un buen manejo de la información, en bases de datos se denomina ACID a las características de los parámetros que permiten clasificar las transacciones de los sistemas de gestión de BD.

En qué consisten estas características/requerimientos se muestra a continuación:

Atomicity (Atomicidad): Se define como “todo o nada” en el proceso de la transacción, es decir si cualquier parte de la transacción falla, entonces todas las operaciones realizadas durante esa transacción fallaran, esto provoca que la base de datos no se actualice y no sufra cambios.

Un sistema con atomicidad debe garantizar esta característica en cualquier operación y situación. Por lo tanto en una transacción atómica, una serie de operaciones en la base de datos ocurren todas, o no ocurre ninguna.

Consistency (Consistencia): La consistencia se refiere a que la base de datos debe mantener la integridad de los datos durante todo el proceso de la transacción (inicio, durante y al final) considerando los atributos y reglas, es decir, los tipos de datos, unicidad de registros, llaves y constraints.

Isolation (Aislamiento): Esta característica se refiere a que el motor de BD debe tener la capacidad de procesar transacciones simultáneamente, con el objetivo de que el intermediario de una transacción no pueda ser visto por otra, manteniéndose “aisladas” unas de otras”.

Durability (Durabilidad): La durabilidad consiste en que una vez los datos obtenidos mediante una transacción se hayan guardado en nuestra base de datos permanentemente, por lo que bajo ninguna circunstancia se puedan perder, ya sea debido a caídas de sistema, errores, crasheos, etc.

Teorema CAP

Aparte de las bases de datos relacionales existen otro tipo conocidas como bases de datos NoSQL, que están diseñadas específicamente para modelos de datos específicos y tienen esquemas flexibles para crear aplicaciones modernas.

Las bases de datos NoSQL son ampliamente reconocidas porque son fáciles de desarrollar, su funcionalidad y el rendimiento a escala, lo cual permite que sean escalables y distribuidas. Y por ser distribuidas tendremos que tener en cuenta el teorema CAP.

El teorema CAP o teorema Brewer dice que el diseño y despliegue sistemas distribuidos es imposible garantizar a la vez los 3 requerimientos: consistencia, disponibilidad y tolerancia a particiones, siendo solo posible 2 de estos.

En qué consisten estas características/requerimientos se muestra a continuación:

Consistency (Consistencia): Al realizar una consulta o inserción siempre se tiene que recibir la misma información, con independencia del nodo o servidor que procese la petición.

Availability (Disponibilidad): El sistema continúa funcionando y sirviendo datos a pesar de fallas de nodos.

Partition Tolerance (Tolerancia al Particionado de Red): El sistema debe estar disponible así existan problemas de comunicación entre los nodos, cortes de red que dificulten su comunicación o cualquier otro aspecto que genere su particionamiento.

Debido a que en este tipo de base de datos solamente podemos cumplir con dos de los requerimientos, es necesario tomar en cuenta las características que tendrán la aplicación o sistema que se desea implementar. Los diferentes escenarios que pueden presentarse son los siguientes:

1. CP (Consistency – Partition Tolerance)

El sistema siempre garantizará Consistencia aunque existan problemas de conexión entre los nodos (Particiones de red) y no se asegura Disponibilidad.

[pic 1]

Como toleramos particiones de red, nuestro sistema recibe la petición, pero como además priorizamos consistencia, es necesario que el pedido se aplique y confirme en todos los nodos, como uno de ellos no está disponible entonces la transacción no se puede completar no se puede realizar.

Existe riesgo de que algunos datos no estén disponibles.

Bases de datos que utilizan esta clasificación son:

• HBase
• MongoDB
• Redis
• Memcache

2. AP (Availability – Partition Tolerance)

El sistema siempre estará Disponible aunque existan problemas de conexión entre los nodos (Particiones de red). Aunque pueda mostrar datos temporalmente Inconsistentes.

[pic 2]

Se toleran particiones de red  por lo cual el sistema recibe y aplica la petición, como no se garantizamos la consistencia, no es necesario que se confirme el pedido en todos los nodos.

Los clientes de este tipo de clasificación pueden enfrentarse a la lectura de información inconsistente.

Bases de datos que utilizan esta clasificación son:

• Riak
• Cassandra DB
• Couch DB
• Dynamo DB

3. CA (Consistency – Availability)

El sistema siempre estará Disponible con información Consistente. Por lo cual el sistema no soporta perdida de comunicación entre los nodos (Particiones de red).[pic 3]

Debido a la falta de particionamiento, el sistema fallaría  y  debería presentar un mensaje al usuario puesto que prácticamente no estaríamos garantizando ningún tipo de consistencia.

...