Teorema CAP: entendiendo las limitaciones de los sistemas distribuidos

¿Te has preguntado alguna vez cómo funciona una aplicación tecnológica? Sin duda, son muchos los pequeños engranajes que tienen que colaborar para que responda como debe (código, interfaz, etc.), pero uno de los más importantes es su infraestructura. Estas herramientas se apoyan en un sistema distribuido, es decir, un grupo de servidores que trabajan juntos para realizar procesos y responder a las peticiones de los usuarios. Para ello, emplean bases de datos distribuidas (las que guardan y distribuyen los datos entre los nodos), y es aquí donde entra en juego el famoso teorema CAP... ¡Vamos a explicarlo!

¿Qué es el teorema CAP?

El teorema CAP es una teoría establecida por el profesor Eric A. Brewer, que determina las limitaciones de los sistemas de datos distribuidos. El nombre es una abreviatura de Consistencia, Disponibilidad y tolerancia a Particiones, los tres atributos de los sistemas que analiza.

Según esta teoría (que ya se ha constatado), cuando se produce un fallo en la red, los sistemas solo pueden garantizar dos de estos tres atributos. Por eso, es fundamental conocer a fondo el teorema: se necesita a expertos formados en gestión de bases de datos SQL o NoSQL (bases de datos no relacionales) para elegir la infraestructura correcta, que priorice las dos características más importantes de acuerdo con el propósito de la aplicación que se vaya a diseñar.

Componentes del teorema: consistencia, disponibilidad y tolerancia a particiones

Con el eje del teorema CAP explicado, llega el momento de profundizar un poco más. Hemos hablado de los atributos o componentes que lo forman, pero, ¿qué significan cada uno de ellos? ¡Veámoslo en detalle!

Consistencia

Como la información está distribuida en distintas bases de datos, es importante que todas tengan la misma versión. La consistencia (también llamada coherencia) implica que todos los nodos tienen que tener la misma información. Eso significa que cualquier cambio deberá replicarse en todos los nodos, para que los usuarios accedan al mismo estado del sistema con independencia del punto al que se conecten.

Disponibilidad

¿Y qué pasa si “se cae” un nodo? Pues ahí es cuando cobra relevancia la disponibilidad. Si un sistema distribuido cumple este atributo, siempre le dará una respuesta al usuario, aunque puede que no se base en la última información disponible.

Tolerancia a particiones

La última de las características del teorema CAP se centra en los fallos de comunicación (“particiones”) entre nodos. En estos casos, habrá problemas, a no ser que el sistema garantice la conocida como tolerancia a particiones.

Si esta se ha priorizado en el diseño de la infraestructura, el sistema seguirá tramitando y resolviendo las solicitudes de los usuarios hasta que se solucione el error.

Ejemplos de sistemas según el teorema CAP

Como hemos visto, las bases de datos distribuidas solo pueden garantizar dos de los tres principios del teorema CAP. Los especialistas tienen que evaluar muy bien las características de sus sistemas y decidir cuál sacrificar (lo que se conoce como trade-off), perjudicando lo mínimo posible el funcionamiento de la aplicación. Dependiendo de cuáles escojan, tendremos tres tipos de combinaciones posibles:

Hay que tener en cuenta que esta clasificación es más habitual en las bases de datos NoSQL, especialmente las de tipo AP, porque las SQL suelen diseñarse para entornos más centralizados. Sin embargo, estas también se pueden clasificar con el teorema CAP si se distribuyen. Por ejemplo, Google Spanner (modelo CP) o SQLite (modelo CA).

Implicaciones en el diseño de bases de datos distribuidas

Ya hemos visto que el teorema CAP determina la elección de trade-off. Pero también tiene implicaciones en otras partes del diseño de bases de datos distribuidas:

• Nivel de sincronización: en función de la capacidad que tengan los datos para replicarse, hablaremos de bases de datos eventualmente consistentes (como Cassandra) o fuertemente consistentes (como MongoDB).
• Experiencia de usuario: en función de los principios del teorema CAP que se prioricen, el usuario tendrá una experiencia diferente. Un sistema AP, por ejemplo, le dará respuestas rápidas, pero sin garantizar que los datos estén actualizados. Un sistema CP, por el contrario, ralentizará la respuesta en favor de la precisión.
• Arquitectura: el teorema CAP ha dado lugar a dos tipos de arquitectura en el diseño de las bases de datos, la ACID y la BASE.

Cómo afecta el teorema CAP a la elección de tecnologías

La teoría de Brewer no especifica la tecnología a emplear, pero sí los parámetros en los que hay que fijarse para acertar con el diseño de los sistemas distribuidos. A continuación, te damos algunos consejos para que sepas cómo elegir una base de datos según el teorema CAP:

• Evalúa tus necesidades: en función del objetivo de la aplicación y el tipo de datos que maneje, será conveniente priorizar una combinación CAP u otra. Por ejemplo, lo que ocurría con la app del banco que mencionamos en epígrafes anteriores.
• Analiza los tipos de bases de datos existentes y determina el más adecuado en función de la infraestructura que necesitas.
• Decide la clase de escalabilidad (vertical u horizontal) apropiada para que tu producto crezca respetando los principios CAP.
• Haz pruebas para garantizar que la base de datos que has elegido es la correcta.

¡Especialízate en bases de datos!

La administración de la información es clave tanto para el funcionamiento de las aplicaciones como para el propio negocio que las sustenta. Por eso, en Tokio School hemos diseñado un Curso de Gestión de Bases de Datos SQL, que te proporcionará un conocimiento avanzado en bases de datos relacionales.

Aprenderás a diseñar y normalizar estos sistemas a través de tecnologías avanzadas de IA, Big Data y Blockchain. Además, contarás con hasta 300 horas de prácticas profesionales, para llegar a tu próxima entrevista de trabajo con un currículum de primera. ¡Infórmate y da el paso!