Teorema CAP

menu icon

Teorema CAP

En esta guía, examinamos el teorema CAP y su relevancia a la hora de diseñar aplicaciones distribuidas y elegir un NoSQL o un almacén de datos relacional.

¿Qué es el teorema CAP?

¿Has visto alguna vez un anuncio de un paisajista, un pintor o alguna otra persona que empiece con el titular "Barato, rápido y bueno: elija dos"?

El teorema CAP aplica un tipo similar de lógica a los sistemas distribuidos, es decir, que un sistema distribuido puede entregar sólo dos de las tres características deseadas: consistencia, disponibilidad, y tolerancia a la partición (CAP, en inglés).

Un sistema distribuido es una red que almacena datos en más de un nodo (máquinas físicas o virtuales) al mismo tiempo. Debido a que todas las aplicaciones en la nube son sistemas distribuidos, es esencial entender el teorema CAP al diseñar una aplicación en la nube para que pueda 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 se llama Teorema de Brewer, porque fue promovido por primera vez por el profesor Eric A. Brewer, durante una charla que dio sobre la computación distribuida en 2000. Dos años más tarde, los profesores de MIT, Seth Gilbert y Nancy Lynch, publicaron una prueba de la "Conjetura de Brewer".

Explicación de ‘CAP’ en el teorema CAP

Vamos a ver de manera detallada las tres características del sistema distribuido al que se refiere el teorema CAP.

Consistencia

Consistencia significa que todos los clientes ven los mismos datos al mismo tiempo, independientemente del nodo al que se conecten. Para que esto suceda, siempre que se escriban datos en un nodo, se debe reenviar o replicar al instante a todos los demás nodos del sistema antes de que la escritura se considere 'satisfactoria'.

Disponibilidad

Disponibilidad significa que cualquier cliente que realiza una solicitud de datos obtiene una respuesta, incluso si uno o más nodos están inactivos. Otra forma de indicar esto: todos los nodos activos del sistema distribuido devuelven una respuesta válida para cualquier solicitud, sin excepción.

Tolerancia de partición

Una partición es un quiebre de las comunicaciones dentro de un sistema distribuido: una conexión perdida o temporalmente retardada entre dos nodos. La tolerancia a las particiones significa que el clúster debe continuar trabajando a pesar de las interrupciones de comunicación que se produzcan entre los nodos del sistema.

Tipos de base de datos NoSQL del teorema CAP

Bases de datos de NoSQL (no relacional) son ideales para aplicaciones de red distribuida. A diferencia de sus equivalentes SQL (relacionales) verticalmente escalables, las bases de datos NoSQL son horizontalmente escalables y están distribuidas por diseño: pueden escalarse rápidamente en una red creciente formada por múltiples nodos interconectados. (Consulte "Bases de datos SQL o NoSQL: ¿cuál es la diferencia?" para obtener más información).

Actualmente, las bases de datos NoSQL se clasifican en función de las dos características de CAP a las que dan soporte:

  • Base de datos CP: una base de datos CP ofrece consistencia y tolerancia de partición a costa de la disponibilidad. Cuando se produce una partición entre dos nodos, el sistema tiene que cerrar el nodo no consistente (es decir, dejarlo indisponible) hasta que se solucione la partición.
  • Base de datos AP: una base de datos AP ofrece disponibilidad y tolerancia de partición a costa de la consistencia. Cuando se produce una partición, todos los nodos permanecen disponibles, pero los que están en el extremo incorrecto de una partición pueden devolver una versión anterior de los datos, cuando comparados con otros. (Cuando se soluciona la partición, las bases de datos AP suelen resincronizar los nodos para reparar todas las inconsistencias del sistema).
  • Base de datos CA: una base de datos de CA ofrece consistencia y disponibilidad en todos los nodos. Sin embargo, no podrá hacerlo si hay una partición entre dos nodos en el sistema; por lo tanto, no puede ofrecer tolerancia a errores.

Listamos este tipo por una razón: en un sistema distribuido, las particiones no se pueden evitar. Por lo tanto, aunque podemos discutir una base de datos CA distribuida en teoría, para todos los propósitos prácticos, una base de datos CA distribuida no puede existir. Sin embargo, esto no significa que no pueda tener una base de datos de CA para su aplicación distribuida si necesita una. Muchas bases datos relacionales, como PostgreSQL, entregan consistencia y disponibilidad y se pueden implementar en varios nodos utilizando réplicas.

MongoDB y el teorema CAP (CP)

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

MongoDB es un sistema mono-maestro, cada conjunto de réplicas (enlace externo a IBM) sólo puede tener un nodo primario 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. De forma predeterminada, los clientes también leen desde el nodo primario, pero también pueden especificar una preferencia de lectura (enlace externo a IBM) que les permite leer desde nodos secundarios.

Cuando el nodo primario deja de estar disponible, el nodo secundario con el registro de operaciones más reciente se elegirá como el 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 realizar ninguna solicitud de grabación durante este intervalo, los datos permanecen consistentes en toda la red.

Cassandra y el teorema CAP (AP)

Apache Cassandra es una base de datos NoSQL de código abierto mantenida por Apache Software Foundation. Es una base de datos de amplia columna que permite almacenar datos en una red distribuida. Sin embargo, a diferencia de MongoDB, Cassandra tiene una arquitectura sin maestría y, como resultado, tiene múltiples puntos de falla, en lugar de una sola.

En relación con el teorema CAP, Cassandra es una base de datos de AP que ofrece disponibilidad y tolerancia de partición, pero no puede entregar consistencia todo el tiempo. Puesto que Cassandra no tiene un nodo maestro, todos los nodos deben estar disponibles continuamente. Sin embargo, Cassandra proporciona consistencia final permitiendo a los clientes escribir en cualquier nodo en cualquier momento y reconciliar las inconsistencias lo más rápido posible.

Dado que los datos sólo se vuelven inconsistentes en el caso de una partición de red, y las inconsistencias se solucionan rápidamente, Cassandra ofrece la funcionalidad "reparación" (enlace externo a IBM) para ayudar a los nodos a ponerse al día con sus compañeros. Sin embargo, la disponibilidad constante resulta en un sistema de alto rendimiento que podría valer el equilibrio en muchos casos.

Trabajar con microservicios

Microservicios están acoplados de forma flexible, independientemente de los componentes de aplicación implementables que incorporan su propia solución, incluyendo su propia base de datos y modelo de base de datos, y se comunican entre sí a través de una red. Como puede ejecutar microservicios en los servidores de nube y en los centros de datos locales, se han vuelto muy populares para las aplicaciones híbridas y de multinube.

Comprender el teorema CAP puede ayudarle a elegir la mejor base de datos al diseñar una aplicación basada en microservicios que se ejecuta 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 de AP como Cassandra o Apache CouchDB puede satisfacer sus requisitos y simplificar la implementación. Por otro lado, si su aplicación depende en gran medida de la consistencia de los datos, como en una aplicación de eCommerce o un servicio de pago, puede optar por una base de datos relacional como PostgreSQL.

Teorema CAP e IBM Cloud

IBM ofrece todo un espectro de servicios de base de datos gestionados. Además de los sistemas de gestión de bases de datos relacionales, también puede ejecutar MongoDB, Cloudant (otro almacén de datos distribuidos de AP), Elasticsearch, etcd y otras soluciones de base de datos en IBM Cloud.

Para consultar nuestra selección de base de datos completa (sin compromiso alguno), inscríbase para obtener un ID de IBM y cree su cuenta de IBM Cloud.