La conjetura de Brewer en los sistemas distribuidos (CAP)
El proceso de elección de un mecanismo de persistencia de datos es una de la actividades más complejas en la arquitectura de software. El creciente volumen de datos que se recopilan desde cientos de fuentes que generan eventos es cada vez más difícil de gestionar coordinadamente.
A inicios de los 2000 cuando la computación distribuida estaba en sus inicios se formalizó el teorema de CAP por Erick Brewer.
¿Qué es el teorema de CAP?
Antes de entrar a enunciar el teorema es importante explicar las siglas CAP, las cuales están asociadas a los principales pilares deseados en un sistema computacional distribuido, y en especial en los sistemas de almacenamiento de datos.
Como ilustra la figura anterior los pilares para la puesta en operación de un sistema distribuido deben tener en cuenta la consistencia, disponibilidad y capacidad de tener un sistema particionado.
Definamos cada uno de estos aspectos:
Consistencia: Es la capacidad de un sistema que le permite ver los mismos datos al mismo tiempo, lo normal es que en los sistemas distribuidos hablemos de consistencia eventual. (En este libro de microservicios hablamos al respecto de la consistencia eventual).
Disponibilidad: Entiéndase como la característica de un sistema que sea capaz de responder siempre que sea requerido, en algunas bibliografías se refiere a que funcione 24/7.
Tolerancia al particionado: Refiere a que el sistema puede ser dividido en partes, en diversos nodos y aún cuando una parte deje de funcionar por cualquiera que sea la causa aún así el sistema debe de seguir disponible.
El teorema especifica que no es posible lograr las tres características juntas en un sistema de persistencia de datos. Solo pueden lograrse totalmente la combinación de dos de los pilares.
Combinación CA
Esta combinación incluye sistemas que son capaces de garantizar una alta disponibilidad y consistencia en la información, normalmente emplean el patrón master -> esclavo, lo cual favorece la consistencia de la información, pero su capacidad de escalabilidad es limitada.
En este grupo entran las bases de datos relacionales como MySQL, MariaDB o PostgreSQL.
Combinación CP
El aseguramiento de la consistencia y la capacidad de particionado son las características de este grupo de sistemas, aunque ocurran fallos de comunicación temporales entre los nodos se garantizará la consistencia de los datos, la debilidad de este grupo de sistemas radica en la disponibilidad.
Uno de los engines de bases de datos NoSQL que más resalta en este segmento es MongoDB.
Combinación AP
En esta combinación pueden tener lugar inconsistencias (eventualmente) entre los nodos de almacenamiento, pero se logra una mayor disponibilidad. Los sistemas en este grupo lo general no implementan el patrón maestro esclavo, utilizan P2P (por ejemplo), lo que lleva consigo que se escriba en varios nodos y la conciliación se alcance en un intervalo de tiempo t !=0 (Quiero expresar que existirá un delta t en la sincronización)
En este grupo de sistemas entran algunas bases de datos del mercado como Apache Cassandra, DynamoDB, Riak, etc.
Cuestiones importantes
Los ejemplos de gestores propuestos pueden variar de acuerdo a algunas configuraciones individuales que se pueden aplicar en los engines en tiempo de configuración, por ejemplo si usamos MongoDB (CP) pero no implementamos particiones distribuidas no aplicaría. Los ejemplos son de forma general.
Los criterios del teorema aplican para los diversos tipos de bases de datos: relacionales, llave-valor, documentos, grafos y familia de columnas.
Es importante tener en cuenta estos principios siempre a la hora de elegir un sistema de persistencia de datos.
Puede consultar más información en este artículo: CAP
