Fundamentos de Sistemas Distribuidos: Teorema CAP y Modelo BASE

El auge de las bases de datos NoSQL surgió a principios del siglo XXI impulsado por gigantes tecnológicos (Google, Amazon, Meta) que necesitaban almacenar petabytes de información y responder a millones de peticiones por segundo en clústeres de servidores distribuidos geográficamente.

Para comprender por qué los sistemas NoSQL sacrifican ciertas reglas relacionales clásicas, es imprescindible estudiar el Teorema CAP y el Modelo BASE.

1. El Teorema CAP de Brewer #

Propuesto por el científico informático Eric Brewer en 2000 y demostrado formalmente en 2002, el Teorema CAP establece que en cualquier sistema de datos distribuido es físicamente imposible garantizar simultáneamente las tres propiedades siguientes:

1▲  CONSISTENCIA (C)
2                    ╱ ╲
3                   ╱   ╲
4                  ╱  ▲  ╲
5                 ╱ CP│AP ╲
6                ╱    │    ╲
7DISPONIBILIDAD ◄─────┼─────► TOLERANCIA A PARTICIONES (P)
8     (A)             │  CA (Solo en un único nodo no distribuido)

Consistencia (C - Consistency):
- Cada lectura recibe la escritura más reciente o un error. Todos los nodos del clúster ven exactamente el mismo dato al mismo tiempo (Consistencia Linealizable / Fuerte).
Disponibilidad (A - Availability):
- Cada petición no fallida enviada por un cliente recibe una respuesta válida (no un error ni bloqueo), aunque no garantice contener la versión más reciente del dato.
Tolerancia a Particiones (P - Partition Tolerance):
- El sistema continúa funcionando a pesar de que la red se corte, se pierdan mensajes o haya latencias extremas entre servidores (partición de red).

IMPORTANT
La regla inmutable del mundo distribuido: En redes reales (especialmente en la nube e Internet), las particiones de red son inevitables tarde o temprano. Por tanto, en presencia de una partición siempre se debe elegir entre Consistencia (CP) o Disponibilidad (AP).

2. Clasificación de Bases de Datos según CAP #

Tipo	Prioridad ante caída de red	Comportamiento	Ejemplos
CP (Consistencia + Tolerancia)	Sacrifica la disponibilidad	Si un nodo queda aislado, rechaza peticiones antes de devolver un dato obsoleto o inconsistente.	HBase, MongoDB (nodo primario), Redis Sentinel.
AP (Disponibilidad + Tolerancia)	Sacrifica la consistencia estricta	Sigue respondiendo a todas las peticiones con los datos locales disponibles, aceptando consistencia eventual.	Apache Cassandra, DynamoDB, CouchDB.
CA (Consistencia + Disponibilidad)	No tolera particiones de red	Solo es posible en sistemas centralizados que residen en un único servidor físico.	PostgreSQL, MySQL, Oracle tradicionales (sin replicación asíncrona).

3. Modelo ACID vs. Modelo BASE #

Mientras que las bases de datos relacionales tradicionales priorizan la integridad estricta mediante garantías ACID, los sistemas NoSQL distribuidos suelen adoptar la filosofía BASE:

1┌─────────────────────────────────────────────────────────────────────────────┐
2│ ACID (Enfoque Pesimista y Estricto)  │ BASE (Enfoque Optimista y Escalable) │
3├──────────────────────────────────────┼──────────────────────────────────────┤
4│ Atomicidad (Todo o nada)             │ Básicamente Disponible (Basic Avail) │
5│ Consistencia (Reglas inmediatas)     │ Estado Flexible (Soft State)         │
6│ Aislamiento (Bloqueos serializables) │ Consistencia Eventual (Eventual Con) │
7│ Durabilidad (Persistencia en disco)  │                                      │
8└──────────────────────────────────────┴──────────────────────────────────────┘

Básicamente Disponible (Basically Available): El sistema garantiza la disponibilidad de la mayoría de las operaciones, aunque partes de la red o nodos secundarios fallen.
Estado Flexible (Soft State): El estado de los datos puede cambiar a lo largo del tiempo sin interacción del usuario, debido a procesos de sincronización en segundo plano entre réplicas.
Consistencia Eventual (Eventual Consistency): Si no se producen nuevas escrituras, con el tiempo (eventualmente) todas las réplicas del clúster convergerán y tendrán exactamente el mismo valor.

4. Quórums de Lectura y Escritura ( $R + W > N$ ) #

Para ajustar el nivel de consistencia en sistemas NoSQL como Cassandra o DynamoDB, se utiliza el modelo de quórums:

$N$ : Número de réplicas en las que se copia un dato.
$W$ : Número de réplicas que deben confirmar una escritura con éxito.
$R$ : Número de réplicas que deben responder en una lectura.

$\text{Si } R + W > N \implies \text{Consistencia Fuerte garantizada}$

Al menos una réplica leída contiene obligatoriamente la versión más reciente escrita.

Resumen del tema

Conceptos clave #

Teorema CAP: imposibilidad matemática de garantizar simultáneamente Consistencia, Disponibilidad y Tolerancia a Particiones en redes distribuidas.
Dilema CP vs. AP: ante un corte de red, un sistema NoSQL debe elegir entre devolver datos consistentes (CP bloqueando respuestas desactualizadas) o mantenerse disponible (AP aceptando datos desfasados).
Modelo BASE: alternativa al modelo ACID que prima la alta disponibilidad y la escalabilidad horizontal mediante consistencia eventual.
Consistencia Eventual: garantía de que todas las réplicas convergerán al mismo dato si cesan las actualizaciones.
Quórum ( $R + W > N$ ): fórmula matemática para calibrar si una lectura devolverá con certeza el dato más reciente en clústeres NoSQL.

Qué debes recordar #

En redes distribuidas las particiones de red son inevitables (P); los motores CP (MongoDB, Redis) eligen consistencia sacrificando disponibilidad, mientras que los motores AP (Cassandra, CouchDB) eligen disponibilidad con consistencia eventual.

Fundamentos de Sistemas Distribuidos: Teorema CAP y Modelo BASE

Para comprender por qué los sistemas NoSQL sacrifican ciertas reglas relacionales clásicas, es imprescindible estudiar el Teorema CAP y el Modelo BASE.

1. El Teorema CAP de Brewer #

1▲  CONSISTENCIA (C)
2                    ╱ ╲
3                   ╱   ╲
4                  ╱  ▲  ╲
5                 ╱ CP│AP ╲
6                ╱    │    ╲
7DISPONIBILIDAD ◄─────┼─────► TOLERANCIA A PARTICIONES (P)
8     (A)             │  CA (Solo en un único nodo no distribuido)

Consistencia (C - Consistency):
- Cada lectura recibe la escritura más reciente o un error. Todos los nodos del clúster ven exactamente el mismo dato al mismo tiempo (Consistencia Linealizable / Fuerte).
Disponibilidad (A - Availability):
- Cada petición no fallida enviada por un cliente recibe una respuesta válida (no un error ni bloqueo), aunque no garantice contener la versión más reciente del dato.
Tolerancia a Particiones (P - Partition Tolerance):
- El sistema continúa funcionando a pesar de que la red se corte, se pierdan mensajes o haya latencias extremas entre servidores (partición de red).

IMPORTANT
La regla inmutable del mundo distribuido: En redes reales (especialmente en la nube e Internet), las particiones de red son inevitables tarde o temprano. Por tanto, en presencia de una partición siempre se debe elegir entre Consistencia (CP) o Disponibilidad (AP).

2. Clasificación de Bases de Datos según CAP #

Tipo	Prioridad ante caída de red	Comportamiento	Ejemplos
CP (Consistencia + Tolerancia)	Sacrifica la disponibilidad	Si un nodo queda aislado, rechaza peticiones antes de devolver un dato obsoleto o inconsistente.	HBase, MongoDB (nodo primario), Redis Sentinel.
AP (Disponibilidad + Tolerancia)	Sacrifica la consistencia estricta	Sigue respondiendo a todas las peticiones con los datos locales disponibles, aceptando consistencia eventual.	Apache Cassandra, DynamoDB, CouchDB.
CA (Consistencia + Disponibilidad)	No tolera particiones de red	Solo es posible en sistemas centralizados que residen en un único servidor físico.	PostgreSQL, MySQL, Oracle tradicionales (sin replicación asíncrona).

3. Modelo ACID vs. Modelo BASE #

Mientras que las bases de datos relacionales tradicionales priorizan la integridad estricta mediante garantías ACID, los sistemas NoSQL distribuidos suelen adoptar la filosofía BASE:

1┌─────────────────────────────────────────────────────────────────────────────┐
2│ ACID (Enfoque Pesimista y Estricto)  │ BASE (Enfoque Optimista y Escalable) │
3├──────────────────────────────────────┼──────────────────────────────────────┤
4│ Atomicidad (Todo o nada)             │ Básicamente Disponible (Basic Avail) │
5│ Consistencia (Reglas inmediatas)     │ Estado Flexible (Soft State)         │
6│ Aislamiento (Bloqueos serializables) │ Consistencia Eventual (Eventual Con) │
7│ Durabilidad (Persistencia en disco)  │                                      │
8└──────────────────────────────────────┴──────────────────────────────────────┘

Básicamente Disponible (Basically Available): El sistema garantiza la disponibilidad de la mayoría de las operaciones, aunque partes de la red o nodos secundarios fallen.
Estado Flexible (Soft State): El estado de los datos puede cambiar a lo largo del tiempo sin interacción del usuario, debido a procesos de sincronización en segundo plano entre réplicas.
Consistencia Eventual (Eventual Consistency): Si no se producen nuevas escrituras, con el tiempo (eventualmente) todas las réplicas del clúster convergerán y tendrán exactamente el mismo valor.

4. Quórums de Lectura y Escritura ( $R + W > N$ ) #

Para ajustar el nivel de consistencia en sistemas NoSQL como Cassandra o DynamoDB, se utiliza el modelo de quórums:

$N$ : Número de réplicas en las que se copia un dato.
$W$ : Número de réplicas que deben confirmar una escritura con éxito.
$R$ : Número de réplicas que deben responder en una lectura.

$\text{Si } R + W > N \implies \text{Consistencia Fuerte garantizada}$

Al menos una réplica leída contiene obligatoriamente la versión más reciente escrita.

Resumen del tema

Conceptos clave #

Teorema CAP: imposibilidad matemática de garantizar simultáneamente Consistencia, Disponibilidad y Tolerancia a Particiones en redes distribuidas.
Dilema CP vs. AP: ante un corte de red, un sistema NoSQL debe elegir entre devolver datos consistentes (CP bloqueando respuestas desactualizadas) o mantenerse disponible (AP aceptando datos desfasados).
Modelo BASE: alternativa al modelo ACID que prima la alta disponibilidad y la escalabilidad horizontal mediante consistencia eventual.
Consistencia Eventual: garantía de que todas las réplicas convergerán al mismo dato si cesan las actualizaciones.
Quórum ( $R + W > N$ ): fórmula matemática para calibrar si una lectura devolverá con certeza el dato más reciente en clústeres NoSQL.

Fundamentos de Sistemas Distribuidos: Teorema CAP y Modelo BASE

1. El Teorema CAP de Brewer #

2. Clasificación de Bases de Datos según CAP #

3. Modelo ACID vs. Modelo BASE #

4. Quórums de Lectura y Escritura ( $R + W > N$ ) #

Conceptos clave #

Qué debes recordar #

Cuestionario: Teorema CAP y Modelo BASE

Fundamentos de Sistemas Distribuidos: Teorema CAP y Modelo BASE

1. El Teorema CAP de Brewer #

2. Clasificación de Bases de Datos según CAP #

3. Modelo ACID vs. Modelo BASE #

4. Quórums de Lectura y Escritura ( $R + W > N$ ) #

Conceptos clave #

Qué debes recordar #

Cuestionario: Teorema CAP y Modelo BASE

Fundamentos de Sistemas Distribuidos: Teorema CAP y Modelo BASE

1. El Teorema CAP de Brewer #

2. Clasificación de Bases de Datos según CAP #

3. Modelo ACID vs. Modelo BASE #

4. Quórums de Lectura y Escritura (R+W>NR + W > NR+W>N) #

Conceptos clave #

Qué debes recordar #

Cuestionario: Teorema CAP y Modelo BASE

Fundamentos de Sistemas Distribuidos: Teorema CAP y Modelo BASE

1. El Teorema CAP de Brewer #

2. Clasificación de Bases de Datos según CAP #

3. Modelo ACID vs. Modelo BASE #

4. Quórums de Lectura y Escritura (R+W>NR + W > NR+W>N) #

Conceptos clave #

Qué debes recordar #

Cuestionario: Teorema CAP y Modelo BASE

4. Quórums de Lectura y Escritura ( $R + W > N$ ) #

4. Quórums de Lectura y Escritura ( $R + W > N$ ) #