En 1970, Jim Gray propuso el concepto de transacción (Gray and Reuter, 1992), una unidad de trabajo en un sistema de base de datos que contiene un conjunto de operaciones. Para que una transacción se comporte de una manera segura debe exhibir cuatro propiedades principales: atomicidad (atomicity), consistencia (consistency), aislamiento (isolation) y durabilidad (dura- bility). Estas propiedades, conocidas como ACID, aumentan la complejidad del diseño de los sistemas de base de datos y aún más en las bases de datos distribuidas, que diseminan datos en varias particiones a través de una red informática. Esta característica, sin embargo, simplifica
el trabajo de los desarrolladores mediante la garantía de que cada operación dejará la base de datos en un estado consistente. En este contexto, las operaciones son susceptibles a los fallos y retrasos de la propia red, por lo que se deben tomar precauciones para garantizar el éxito de una transacción.
Los RDBMS distribuidos permiten, desde hace algún tiempo, realizar transacciones uti- lizando protocolos específicos para mantener la consistencia de los datos entre las particiones. Uno de los protocolos más utilizados para este propósito es 2PC (Two-phase commit), que ha sido fundamental en la ejecución de operaciones en entornos distribuidos. La aplicación de este protocolo se ha extendido incluso al ámbito de los Servicios Web, que permite transac- ciones en arquitecturas REST (REpresentational State Transfer) que de lo contrario no serían posibles (da Silva Maciel and Hirata, 2010). El protocolo 2PC consta de dos partes principales:
1. Una etapa en la que un componente coordinador pide a las bases de datos implicadas en la transacción hacer una operación depre-commit. Si todas las bases de datos puede cumplir la operación, se lleva a cabo el escenario 2.
2. El coordinador pide a las bases de datos realizar una operacióncommit. Si alguna de las bases de datos rechaza elcommit, se realiza unrollback.
De acuerdo con el teorema CAP el uso de un protocolo como 2PC impacta negativamente en la disponibilidad del sistema. Con el fin de medir el grado de este impacto, una operación de disponibilidad se puede calcular como el producto de la disponibilidad individual de los componentes involucrados en dicha operación. Por ejemplo, si cada partición de base de datos tiene un 99,9% de disponibilidad, es decir, se les permiten 43 minutos fuera de servicio por mes, uncommitusando 2PC sobre 2 particiones reduce la disponibilidad a 99,8%, que se traduce a 86 minutos al mes fuera de servicio (Pritchett, 2008).
Además, 2PC es un protocolo de bloqueo, lo que significa que las bases de datos implicadas en una transacción no se pueden utilizar en paralelo mientras que uncommitestá en curso. Esto aumenta la latencia del sistema cuando el número de transacciones que ocurren crece. Debido a esto, muchos enfoques de bases de datos NoSQL decidieron relajar las restricciones de con- sistencia. Estos enfoques se conocen como BASE (Basically Available, Soft State, Eventually Consistent) (Pritchett, 2008). La idea detrás de los sistemas implementando este concepto es per- mitir fallos parciales en lugar de un fallo del sistema completo, lo que conduce a una percepción de una mayor disponibilidad del sistema.
El diseño de los sistemas BASE, y en particular las bases de datos NoSQL BASE, permite que se realicen ciertas operaciones dejando las réplicas (es decir, copias de los datos) en un estado inconsistente. Precisamente, esto se conoce comoSoft-State, en contraste con sistemas Hard-State, como las bases de datos transaccionales a los que no se les permite inconsistencias. Una inconsistencia en un sistema necesita ser resuelta sobre la base de criterios que aseguran
volver a un estado consistente. Por ejemplo, la base de datos NoSQL Cassandra (Lakshman and Malik, 2010) implementa las siguientes políticas de actualización de alto nivel:
• Read-repair: las inconsistencias se corrigen durante la lectura de datos. Esto significa que la escritura podría dejar algunas inconsistencias detrás, que sólo se resolverán después de una operación de lectura. Por lo tanto, el componente coordinador que consulta las réplicas es responsable de actualizar esas réplicas que tienen datos obsoletos, ralentizando la operación de lectura. Vale la pena notar que los conflictos se resuelven solamente para los datos que intervienen en la operación de lectura.
• Write-repair: la corrección de una inconsistencia se produce durante la escritura, lo que frena la operación. Como Read-repair, cuando se encuentra una inconsistencia mientras se escriben nuevos datos, el sistema decide qué información correcta deben tener las réplicas y las réplicas obsoletas se sincronizan.
• Asynchronous-repair: la corrección no es ni parte de la lectura ni de la escritura. La sincronización puede dispararse por el tiempo transcurrido desde la última sincronización, la cantidad de escrituras o cualquier otro evento que pueda indicar que la base de datos no está actualizada.
Además de la consistencia de las lecturas y escrituras, en los sistemas de almacenamiento dis- tribuidos surge el concepto de durabilidad, que es la capacidad de un sistema dado de persistir los datos, incluso en presencia de fallos. Esto provoca que los datos se escriban en un número de dispositivos de memoria no volátil antes de informar el éxito de una operación a un cliente. En los sistemas eventualmente consistentes existen mecanismos para calibrar la durabilidad del sistema y su consistencia (Vogels, 2009). Por ejemplo, seaNel número de nodos en los que una clave está replicada,W el número de nodos necesarios para considerar un escritura un éxito yR el número de nodos en los que se realiza una lectura. La Tabla A.3 muestra diferentes configu- raciones deW yR, así como el resultado de aplicar este tipo de configuraciones. Cada valor se refiere al número de réplicas necesarias para confirmar una operación exitosa.
Para brindar la denominada Consistencia Fuerte (Strong Consistency) se alcanza al cumplir W+R>N, es decir, el conjunto de escrituras y lecturas se superpone de manera que una de las lecturas siempre obtiene la versión más reciente de una pieza de datos. Por lo general, RDBMs tienenW=N, es decir, todas las réplicas se conservan yR=1, ya que cualquier lectura devolverá datos hasta a la fecha. La Consistencia Débil (Weak Consistency) tiene lugar cuando W+R≤N, en el que las lecturas pueden obtener datos actualizados. La Consistencia Eventual (Eventual Consistency) es un caso especial de consistencia débil en el que hay garantías de que si una pieza de datos se escriben en el sistema, con el tiempo llegará a todas las réplicas. Esto dependerá de la latencia de la red, la cantidad de réplicas y la carga del sistema, entre otros factores.
Réplicas involucradas Writing (W) Reading (R) 0 No se espera confirmación de ningún
nodo (puede fallar)
N/D
1 Una única confirmación es suficiente (optimizada para escrituras)
La lectura se realiza desde una única réplica (optimizada para lectura) M, con M < N (Quorum) Se espera las confirmaciones de varias
réplicas
La lectura se realiza desde un conjunto de réplicas (conflictos en el cliente
necesitan ser resueltos) N (todos los nodos) Se espera las confirmaciones de todas
las réplicas (reduce disponibilidad, pero incrementa la durabilidad)
La lectura se realiza desde todas las réplicas incrementando la latencia de
lectura
Table A.3: Configuraciones de consistencia eventual.
Si las operaciones de escritura necesitan ser más rápidas, se pueden realizar sobre un único o un conjunto de nodos con la desventaja de menor durabilidad. SiW =0, el cliente percibe una escritura más rápida, pero la durabilidad más baja posible ya que no hay confirmación de que la escritura fue exitosa. En el caso deW =1, es suficiente con que un solo nodo persista la escritura para devolver al cliente, mejorando así la durabilidad en comparación conW =0. De la misma manera es posible optimizar la lectura de datos. La configuraciónR=0 no es una opción, ya que la misma operación de lectura confirma. Para alcanzar el rendimiento óptimo en la lectura, se puede usarR=1. En algunas situaciones (por ejemplo, si se usa Read-repair), podría ser necesario leer desde todos los nodos, esto esR=N, y luego fusionar las diferentes versiones de los datos, lo que frena la mencionada operación. Un esquema intermedio para la escritura o lectura es el de quórum, en el que la operación (lectura o escritura) se realiza sobre un subconjunto de nodos. Con frecuencia, el valor utilizado para el quórum es deN/2+1, tal que 2 escrituras o lecturas subsecuentes comparten al menos un nodo.