¿Alguna vez ha visto un anuncio de un paisajista, pintor de casas o algún otro comerciante que comience con el titular, "Barato, Bueno y Rápido: Elija Dos"? El teorema de CAP aplica un tipo similar de lógica a los sistemas distribuidos.
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 comprender la teoría de 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 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 del sistema distribuido a las que se refiere la 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 suceda, cada vez que se escriben datos en un nodo, se deben reenviar o replicar instantáneamente a todos los demás nodos del sistema antes de que la escritura se considere "exitosa".
Disponibilidad
La disponibilidad significa que cualquier cliente que realice una solicitud de datos obtiene una respuesta, incluso si uno o más nodos están inactivos. Otra forma de expresar esto: todos los nodos de trabajo en el sistema distribuido devuelven una respuesta válida para cualquier solicitud, sin excepción.
Tolerancia de partición
Una partición es una interrupción de comunicaciones dentro de un sistema distribuido: una conexión perdida o temporalmente retrasada entre dos nodos. La tolerancia de partición significa que el clúster debe continuar funcionando a pesar de cualquier número de interrupciones de comunicación entre los nodos del sistema.
Manténgase al día sobre las tendencias más importantes e intrigantes de la industria sobre IA, automatización, datos y más con el boletín Think. Consulte la Declaración de privacidad de IBM.
Las bases de datos NoSQL son ideales para aplicaciones de red distribuidas. A diferencia de sus contrapartes SQL (relacionales) escalables verticalmente, las bases de datos NoSQL son escalables horizontalmente y están distribuidas por diseño—pueden escalar rápidamente a través de una red en crecimiento que consta de múltiples nodos interconectados. (Consulte "Bases de datos SQL vs. NoSQL: ¿Cuál es la diferencia?" 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 de CAP que admiten:
Enumeramos el tipo de base de datos CA en último lugar por una razón—en un sistema distribuido, no se pueden evitar las particiones. Entonces, si bien podemos discutir una base de datos distribuida de CA en teoría, para todos los fines prácticos, no puede existir una base de datos distribuida de CA. 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, tales como PostgreSQL, ofrecen coherencia y disponibilidad, y se pueden desplegar en varios nodos mediante la replicación.
MongoDB es un sistema popular de gestión de bases de datos NoSQL que almacena datos como documentos BSON (JSON binario). Se utiliza con frecuencia para big data y aplicaciones en tiempo real que se ejecutan en múltiples ubicaciones diferentes. En relación con el teorema de 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 puede tener solo un nodo principal que recibe 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 principal y lo aplican a su propio conjunto de datos. De forma predeterminada, los clientes también leen desde el nodo principal, pero también pueden especificar una preferencia de lectura que les permita 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 principal. Una vez que todos los demás nodos secundarios se pongan al día con el nuevo maestro, el clúster volverá a estar disponible. Como los clientes no pueden realizar ninguna solicitud 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 Apache Software Foundation. Es una base de datos de columna ancha que le 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 falla, 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. Debido a que Cassandra no tiene un nodo maestro, todos los nodos deben estar disponibles continuamente. Sin embargo, Cassandra proporciona coherencia eventual al permitir que los clientes escriban en cualquier nodo en cualquier momento y conciliando incoherencias lo más rápido posible.
Como los datos solo se vuelven incoherentes en el caso de una partición de red y las incoherencias se resuelven rápidamente, Cassandra ofrece una funcionalidad de "reparación" para ayudar a los nodos a ponerse al día con sus pares. Sin embargo, la disponibilidad constante resulta en un sistema de alto rendimiento que puede merecer la pena en muchos casos.
Los microservicios son componentes de aplicaciones que se despliegan de forma independiente y se acoplan de manera laxa, que incorporan su propia pila—incluyendo su propia base de datos y modelo de base de datos—y se comunican entre sí a través de una red. Como es posible ejecutar microservicios tanto en servidores en la nube como en centros de datos on-premises, se volvieron muy populares para aplicaciones híbridas y multicloud.
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 la coherencia eventual (en lugar de estricta), una base de datos AP como Cassandra o Apache CouchDB puede satisfacer sus requisitos y simplificar su despliegue. 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—usted puede optar por una base de datos relacional como PostgreSQL.
Cree y gestione canalizaciones de datos de streaming inteligentes a través de una interfaz gráfica intuitiva, y facilite una integración de datos fluida en entornos híbridos y multinube.
watsonx.data le permite escalar los analytics y la IA con todos sus datos, residan donde residan, a través de un almacén de datos abierto, híbrido y gestionado.
Desbloquee el valor de los datos empresariales con IBM Consulting, y construya una organización impulsada por insights que ofrezca ventajas empresariales.
