¿Qué es el teorema CAP?

El teorema CAP dice que un sistema distribuido solo puede ofrecer dos de las tres características deseadas:
consistencia, disponibilidad y tolerancia a la partición (la "C", la"A"y la "P"de CAP).

¿Recuerda haber visto alguna vez un anuncio de un paisajista, pintor de casas u otro comerciante que empezara con el siguiente titular: "Barato, rápido y de buena calidad: seleccione dos"? El teorema CAP aplica un tipo similar de lógica a los sistemas distribuidos.

Un sistema distribuido es una red que almacena datos en varios nodos (máquinas virtuales o físicas) al mismo tiempo. Como todas las aplicaciones en la nube son sistemas distribuidos, es esencial comprender el teorema CAP a la hora de diseñar una aplicación en la nube para poder elegir un sistema de gestión de datos que ofrezca las características que más necesita su aplicación.

El teorema CAP también recibe el nombre de teorema de Brewer, porque fue expuesto por primera vez por el profesor Eric A. Brewer durante una charla que dio sobre informática distribuida en 2000. Dos años después, los profesores del MIT Seth Gilbert y Nancy Lynch publicaron una prueba de la "Conjetura de Brewer".

Veamos en detalle las tres características de los sistemas distribuidos a las que se refiere el teorema CAP.

Coherencia

La coherencia significa que todos los clientes ven los mismos datos al mismo tiempo, independientemente del nodo al que se conecten. Para que esto ocurra, cada vez que se escriben datos en un nodo, deben reenviarse o replicarse instantáneamente a todos los demás nodos del sistema antes de que la escritura se considere "correcta".

Disponibilidad

Disponibilidad significa que cualquier cliente que solicite datos obtiene una respuesta, aunque uno o más nodos estén caídos. En otras palabras, todos los nodos que funcionan en el sistema distribuido devuelven una respuesta válida para cualquier solicitud, sin excepción.

Tolerancia a la partición

Una partición es una interrupción de las comunicaciones dentro de un sistema distribuido, una conexión perdida o temporalmente retrasada entre dos nodos. La tolerancia a las particiones significa que el clúster debe seguir funcionando a pesar de cualquier número de cortes de comunicación entre los nodos del sistema.

Las bases de datos NoSQL son ideales para aplicaciones de redes distribuidas. A diferencia de sus homólogas SQL (relacionales), escalables verticalmente, las bases de datos NoSQL son escalables horizontalmente y distribuidas por diseño, pueden ampliarse rápidamente a través de una red en crecimiento formada por múltiples nodos interconectados. (Consulte "SQL vs. NoSQL Databases: What's the Difference?" para obtener más información.)

Hoy en día, las bases de datos NoSQL se clasifican en función de las dos características CAP que soportan:

• Base de datos CP: una base de datos CP ofrece coherencia y tolerancia a la partición a costa de la disponibilidad. Cuando se produce una partición entre dos nodos cualesquiera, el sistema tiene que apagar el nodo no coherente (es decir, hacerlo no disponible) hasta que se resuelva la partición.
  
  
• Base de datos AP: una base de datos AP ofrece disponibilidad y tolerancia a la partición a costa de coherencia. Cuando se produce una partición, todos los nodos siguen disponibles, pero los que se encuentran en el extremo equivocado de una partición pueden devolver una versión de datos más antigua que los demás. (Cuando se resuelve la partición, las bases de datos AP suelen resincronizar los nodos para reparar todas las incoherencias del sistema.)
  
  
• Base de datos de CA: una base de datos de CA ofrece coherencia y disponibilidad en todos los nodos. Sin embargo, no puede hacerlo si hay una partición entre dos nodos cualesquiera del sistema y, por tanto, no puede ofrecer tolerancia a fallos.

Las bases de datos CA se mencionan en último lugar por una razón: en un sistema distribuido, la partición es inevitable. Por lo tanto, aunque en teoría podemos hablar de una base de datos CA distribuida, a efectos prácticos no puede existir una base de datos CA distribuida. Esto no significa que no pueda tener una base de datos CA para su aplicación distribuida si la necesita. Muchas bases de datos relacionales, como PostgreSQL, ofrecen coherencia y disponibilidad y se pueden implementar en varios nodos mediante replicación.

MongoDB es un popular sistema de gestión de bases de datos NoSQL que almacena datos como documentos BSON (JSON binario). Se utiliza con frecuencia para aplicaciones de big data y en tiempo real que se ejecutan en varias ubicaciones diferentes. En relación con el teorema CAP, MongoDB es un almacén de datos CP, resuelve las particiones de red manteniendo la coherencia, pero comprometiendo la disponibilidad.

MongoDB es un sistema maestro único: cada conjunto de réplicas solo puede tener un nodo principal que reciba todas las operaciones de escritura. Todos los demás nodos del mismo conjunto de réplicas son nodos secundarios que replican el registro de operaciones del nodo primario y lo aplican a su propio conjunto de datos. Por defecto, los clientes también leen del nodo primario, pero también pueden especificar una preferencia de lectura que les permita leer de los nodos secundarios.

Cuando el nodo primario deja de estar disponible, el nodo secundario con el registro de operaciones más reciente será elegido como nuevo nodo primario. Una vez que todos los demás nodos secundarios se ponen al día con el nuevo maestro, el clúster vuelve a estar disponible. Como los clientes no pueden hacer ninguna petición de escritura durante este intervalo, los datos permanecen coherentes en toda la red.

Apache Cassandra es una base de datos NoSQL de código abierto mantenida por la Apache Software Foundation. Es una base de datos de columnas anchas que permite almacenar datos en una red distribuida. Sin embargo, a diferencia de MongoDB, Cassandra tiene una arquitectura sin maestro y, como resultado, tiene múltiples puntos de fallo, en lugar de uno solo.

En relación con el teorema CAP, Cassandra es una base de datos AP: ofrece disponibilidad y tolerancia a las particiones, pero no puede ofrecer coherencia en todo momento. Como Cassandra no tiene un nodo maestro, todos los nodos deben estar disponibles continuamente Sin embargo, Cassandra ofrece consistencia eventual al permitir a los clientes escribir en cualquier nodo en cualquier momento y resolver las inconsistencias lo más rápido posible.

Dado que los datos solo se vuelven inconsistentes en caso de una partición de red y las inconsistencias se resuelven rápidamente, Cassandra ofrece una función de "reparación" que ayuda a los nodos a ponerse al día con sus pares. No obstante, la disponibilidad constante da como resultado un sistema de alto rendimiento que, en muchos casos, compensa.

Los microservicios son componentes de aplicaciones independientes y ligeramente acoplados que incorporan su propia pila, incluida su propia base de datos y su modelo de base de datos, y se comunican entre sí a través de una red. Dado que los microservicios se pueden ejecutar tanto en servidores en la nube como en centros de datos locales, se han vuelto muy populares para aplicaciones híbridas y multinube.

Comprender el teorema CAP puede ayudarle a elegir la mejor base de datos cuando diseñe una aplicación basada en microservicios que se ejecute desde varias ubicaciones. Por ejemplo, si la capacidad de iterar rápidamente el modelo de datos y escalar horizontalmente es esencial para su aplicación, pero puede tolerar una consistencia eventual (en lugar de estricta), una base de datos AP como Cassandra o Apache CouchDB puede satisfacer sus requisitos y simplificar su implementación. Por otro lado, si su aplicación depende en gran medida de la coherencia de los datos, como en una aplicación de comercio electrónico o un servicio de pago, podría optar por una base de datos relacional como PostgreSQL.