ACID, BASE y el teorema CAP

ACID son las cuatro garantías de una transacción en una base de datos relacional. Atomicidad: la transacción se ejecuta entera o no se ejecuta. Consistencia: al terminar, la base cumple todas sus reglas de integridad. Aislamiento: dos transacciones a la vez no se estorban, el resultado es como si hubieran ido una detrás de otra. Durabilidad: lo confirmado sobrevive a un corte de luz.

Muchos sistemas NoSQL no garantizan del todo ese paquete, y ofrecen en su lugar consistencia eventual: una escritura se acepta en un nodo y se propaga a las copias, de modo que durante un intervalo hay lecturas que todavía devuelven el valor antiguo. No es un fallo, es el precio de responder sin esperar a que todos los nodos estén de acuerdo.

Ese modelo se resume con el acrónimo BASE, elegido a propósito como opuesto químico de ACID: Basically Available (básicamente disponible), Soft state (estado blando, que puede cambiar sin que nadie escriba, según se propagan las copias) y Eventually consistent (consistente con el tiempo).

Consistencia eventual no significa «inconsistente»: significa que, si dejan de entrar escrituras, todas las copias acaban coincidiendo.

El teorema CAP, también llamado teorema de Brewer, es el marco con el que se razona sobre cualquier base de datos distribuida. Enuncia tres propiedades deseables, y las siglas salen de sus nombres en inglés: Consistency (consistencia), Availability (disponibilidad) y Partition Tolerance (tolerancia a particiones).

• Consistency: hay un único valor visible del dato, lo pregunte quien lo pregunte y en el nodo que sea.
• Availability: cualquier petición obtiene respuesta, sin errores ni esperas indefinidas.
• Partition Tolerance: el sistema sigue operando aunque la red se corte entre grupos de nodos.

La formulación clásica, y la que se pregunta en examen con estas palabras, es que un sistema distribuido no puede asegurar las tres a la vez: como mucho garantiza dos de las tres simultáneamente. Esa formulación tiene matices importantes, que se ven en el punto «Cómo se lee bien el CAP».

CAP: Consistency, Availability, Partition Tolerance. Dos de tres, nunca las tres.

Consistency, en CAP, es más fuerte de lo que suena: significa que hay un único estado visible del dato, de manera que cualquier lectura, contra el nodo que sea, devuelve la última escritura confirmada. Técnicamente es linealizabilidad. Si un sistema acepta que dos nodos respondan valores distintos al mismo tiempo, no es consistente en el sentido de CAP.

Availability significa que toda petición que llega a un nodo que funciona recibe una respuesta con sentido, ni un error ni un tiempo de espera infinito. Ojo: no habla de rapidez, habla de que haya respuesta. Un sistema que se bloquea esperando a que otro nodo confirme está sacrificando disponibilidad, aunque el nodo esté encendido.

Partition Tolerance significa que el sistema sigue operando aunque la red pierda o retrase indefinidamente los mensajes entre grupos de nodos. La partición no es que un nodo se caiga: es que la red se rompe por en medio y quedan dos grupos vivos, cada uno atendiendo peticiones, sin poder hablarse y sin saber si el otro está caído o simplemente incomunicado. Esa incertidumbre es lo que hace difícil el problema.

La C de CAP no es la C de ACID. En CAP es que todos vean el mismo valor; en ACID es que la transacción respete las reglas de integridad de la base.

El enunciado «dos de tres» es cómodo para memorizar, pero deja pensar que un arquitecto elige tranquilamente dos propiedades de un catálogo de tres. No es así, y conviene saberlo porque los enunciados de examen bien redactados lo tienen en cuenta.

Primero: la tolerancia a particiones no se elige. Si el sistema está repartido entre máquinas, la red se cortará antes o después, y no renunciar a P equivale a decidir que el sistema se romperá cuando pase. Por eso la elección real de cualquier base distribuida es entre CP y AP.

Segundo: la disyuntiva solo aparece durante la partición. Mientras la red va bien, un sistema puede ofrecer consistencia y disponibilidad a la vez sin contradecir el teorema. El teorema dice qué pasa cuando llega el corte: entonces, o el nodo aislado responde con datos que quizá estén obsoletos (elige A) o se niega a responder para no mentir (elige C).

Ese doble régimen es lo que recoge PACELC, una extensión posterior del modelo: si hay Partición, hay que elegir entre Availability y Consistency; y en caso contrario (Else), hay que elegir entre Latency y Consistency, porque mantener las copias de acuerdo cuesta tiempo aunque la red funcione.

En un sistema distribuido la P no es opcional. La pregunta útil no es «qué dos elijo», sino «qué hago cuando la red se parta: responder o esperar».

La clasificación habitual reparte los productos en tres grupos, aunque el tercero es más teórico que real.

La fila CA hay que leerla con cuidado. Un sistema que no está distribuido no puede sufrir particiones, así que decir que es CA no es tanto una elección de diseño como una descripción de que no hay reparto. En cuanto un relacional se despliega en clúster, vuelve a tener que decidir entre C y A como todos los demás.

Otra advertencia útil: varios de estos productos son configurables. Cassandra permite exigir que una lectura consulte a la mayoría de las réplicas, con lo que se acerca a CP en esa operación concreta, y MongoDB permite leer de una réplica secundaria y comportarse como AP. La etiqueta describe el comportamiento por defecto, no una ley del producto.