Topología Masterless Peer-to-Peer: Anillo de Hashing Consistente (Murmur3), VNodes y Protocolo Gossip

1. Cero Punto Único de Fallo (Zero SPOF) en Cassandra y ScyllaDB

A diferencia de las arquitecturas Primario-Secundario (PostgreSQL, MongoDB, Redis) que sufren una ventana de indisponibilidad de segundos durante una elección de líder, Apache Cassandra y ScyllaDB son 100% simétricos (Masterless): - El espacio de tokens de 64 bits ($[-2^{63}, 2^{63}-1]$ calculado con Murmur3Partitioner sobre la Partition Key) forma un anillo continuo dividido en Virtual Nodes (VNodes). - Cualquier nodo puede actuar como Coordinador de una petición, aunque los drivers modernos (Token-Aware Driver) calculan el hash Murmur3 en el cliente y envían la petición directamente a una de las $N$ réplicas propietarias del token.

flowchart LR
    CLIENT["Token-Aware Driver (Calcula Murmur3(PK) = Token 48291)"] --> N1["Réplica 1 (Rack A - Propietaria Primaria)"]
    N1 -->|"Replicación Asíncrona / Quórum"| N2["Réplica 2 (Rack B)"]
    N1 -->|"Replicación Asíncrona / Quórum"| N3["Réplica 3 (Rack C)"]

2. Por Qué ScyllaDB (C++ Seastar Shard-per-Core) Elimina las Pausas de GC de Cassandra (JVM)

ScyllaDB reimplementa la arquitectura de Cassandra en C++ sobre el framework asíncrono Seastar bajo un modelo Shared-Nothing Shard-per-Core: cada núcleo físico de CPU posee su propia porción de RAM, su propia cola NIC de red y su propio planificador de I/O directo (O_DIRECT evitando el OS Page Cache), reduciendo la latencia p99 de $15\text{ ms}$ a $< 1.5\text{ ms}$ sin pausas de Garbage Collection.

Ruta de Escritura y Lectura en un LSM-Tree: CommitLog, Memtables, SSTables Inmutables y Bloom Filters

1. Por Qué las Escrituras en un LSM-Tree Son $\mathcal{O}(1)$ en Disco Sin Lectura Previa

En un árbol B+ (PostgreSQL/InnoDB), actualizar una fila exige leer una página aleatoria de disco, modificarla y reescribirla (Read-Modify-Write). En un Log-Structured Merge-Tree (LSM-Tree), toda escritura (INSERT, UPDATE o DELETE) es secuencial y libre de lecturas: 1. Se anexa secuencialmente al CommitLog en disco para durabilidad. 2. Se inserta en la Memtable ordenada en memoria RAM y retorna éxito inmediato al cliente. 3. Cuando la Memtable se llena, se vuelca a disco como una SSTable (Sorted String Table) 100% inmutable.

2. Cómo Se Evita Leer 50 SSTables en Cada Consulta Puntual

Para que una lectura no tenga que inspeccionar cada archivo SSTable en disco, cada SSTable posee en RAM: - Un Filtro de Bloom (Bloom Filter) que descarta con $0$ IOPS cualquier SSTable que garantizadamente no contiene la Partition Key. - Un Partition Index / Summary que salta directamente al offset exacto del bloque comprimido.

Estrategias de Compactación (STCS, LCS, TWCS) y la Anatomía Mortal de los Tombstones

1. Selección de Estrategia de Compactación Según la Carga de Trabajo

| Estrategia | Mecanismo Interno | Caso de Uso Ideal | Costo de Espacio / I/O | | :--- | :--- | :--- | :--- | | STCS (Size-Tiered) | Fusiona 4 SSTables de tamaño similar en una mayor | Cargas intensivas en escritura (Write-Heavy) | Requiere hasta $50\%$ de disco libre para compactar la tabla mayor | | LCS (Leveled) | Organiza SSTables pequeñas ($160\text{ MB}$) en niveles exponenciales disjuntos $L_1, L_2, \dots$ | Cargas intensivas en lectura y actualizaciones (Read-Heavy — el $90\%$ de lecturas tocan 1 sola SSTable) | Bajo uso de disco ($10\%$), mayor consumo de IOPS de compactación | | TWCS (Time-Window) | Agrupa SSTables por ventana temporal (ej. 1 día) con TTL uniforme | Series temporales y logs inmutables con expiración TTL | Elimina ventanas completas en $\mathcal{O}(1)$ al vencer el TTL |

2. El Peligro de los Tombstones (DELETE y Celdas NULL)

Dado que las SSTables son inmutables, ejecutar un DELETE (o insertar explícitamente un valor NULL) no libera espacio inmediatamente: escribe un marcador de borrado llamado Tombstone que debe conservarse durante gc_grace_seconds (10 días por defecto) para evitar que un nodo caído resucite datos borrados (Zombie Data). Escanear miles de Tombstones en una consulta hace que el nodo aborte con TombstoneOverwhelmingException (tombstone_failure_threshold = 100000).

Ecuación de Consistencia Fuerte (R + W > RF), LOCAL_QUORUM Multi-DC, Read Repair y Hinted Handoff

1. El Principio del Palomar Aplicado a Quórums de Lectura y Escritura

Con un factor de replicación $\text{RF} = N$, logramos consistencia fuerte de lectura tras escritura si el número de réplicas que confirman la escritura ($W$) más el número de réplicas consultadas en lectura ($R$) supera estrictamente a $N$:

$R + W > N \implies \text{Al menos 1 nodo en la intersección posee el último timestamp}$

Con $N = 3$, utilizar LOCAL_QUORUM en escritura ($W = 2$) y LOCAL_QUORUM en lectura ($R = 2$) cumple $2 + 2 = 4 > 3$, tolerando la caída completa de 1 nodo sin cruzar enlaces WAN inter-continentales.

2. Mecanismos de Auto-Sanación (Anti-Entropy)

1. Hinted Handoff: Si una réplica está temporalmente inalcanzable durante una escritura, el coordinador guarda un hint local hasta por max_hint_window_in_ms (3 horas) y lo reproduce apenas la réplica vuelve. 2. Read Repair: Cuando el coordinador detecta divergencia de digest entre las réplicas consultadas en $R$, devuelve al cliente el valor con el mayor timestamp (Last-Write-Wins) y repara asíncronamente la réplica desactualizada. 3. Merkle Tree Repair: Intercambio periódico de árboles hash criptográficos entre réplicas para sincronizar rangos fríos antes de que venza gc_grace_seconds.

Modelado CQL Query-First: Claves Compuestas ((pk1, pk2), ck1, ck2) y Prevención de Particiones Gigantes

1. Anatomía de una PRIMARY KEY ((tenant_id, bucket_month), event_ts, event_id)

En CQL (Cassandra / ScyllaDB), la clave primaria se divide en dos partes con funciones físicas completamente distintas: 1. Partition Key (tenant_id, bucket_month): Determina en qué nodo y shard físico reside toda la partición mediante Murmur3. 2. Clustering Columns event_ts DESC, event_id ASC: Determina el orden físico en disco dentro de la SSTable para esa partición, permitiendo consultas de rango (event_ts >= ? AND event_ts <= ?) en una sola lectura secuencial.

[!CAUTION]

Regla de Dimensionamiento de Partición (Time-Bucketing Obligatorio): Si usas únicamente (tenant_id) como Partition Key para una tabla de eventos históricos, la partición crecerá a decenas de gigabytes y millones de celdas (Unbounded Wide Partition), degradando las compactaciones y saturando un único núcleo de CPU. Siempre añade un cubo temporal (bucket_day o bucket_month) dentro del paréntesis de la Partition Key para mantener cada partición física por debajo de $100\text{ MB}$.

Transacciones Ligeras (LWT / Compare-And-Set): Paxos en Cassandra vs. Raft en ScyllaDB

1. El Costo de 4 Rondas de Red en INSERT ... IF NOT EXISTS

Las escrituras normales en Cassandra utilizan Last-Write-Wins (LWW) basado en relojes de cliente y requieren 1 sola ronda de red (1 RTT). Cuando necesitas unicidad estricta o actualización condicional (IF status = 'PENDING'), una Lightweight Transaction (LWT) basada en Paxos requiere 4 rondas de red (Prepare/Promise, Read, Propose/Accept, Commit), multiplicando la latencia por $4\times$. ScyllaDB 5.2+ optimiza esto utilizando grupos de consenso Raft por tabla.

Arquitectura Interna de Amazon DynamoDB: Storage Partitions (10 GB / 3000 RCU / 1000 WCU) y Write Sharding

1. Los Límites Físicos Duros de una Partición Individual en DynamoDB

Independientemente de si configuras tu tabla en modo On-Demand o aprovisionas $100,000\text{ WCU}$ globales, cada Partición Física de Almacenamiento en DynamoDB (respaldada por un grupo de replicación Paxos en 3 zonas de disponibilidad) tiene tres techos físicos inamovibles: - Almacenamiento máximo por partición: $10\text{ GB}$ (límite duro para colecciones de ítems que comparten el mismo PK cuando existe un Local Secondary Index). - Throughput máximo de lectura por partición: $3,000\text{ RCU/s}$ (1 RCU = 1 lectura fuertemente consistente por segundo de hasta $4\text{ KB}$, o 2 lecturas eventualmente consistentes). - Throughput máximo de escritura por partición: $1,000\text{ WCU/s}$ (1 WCU = 1 escritura por segundo de hasta $1\text{ KB}$).

Si una única Partition Key (ej. PK = "PROMO#BLACKFRIDAY") recibe $2,500$ escrituras por segundo, sufrirás ProvisionedThroughputExceededException (Hot Partition Throttling) aunque tu tabla tenga $99\%$ de capacidad libre. La solución es Write Sharding con Sufijo Calculado o Aleatorio (PK = "PROMO#BLACKFRIDAY#" + (hash(userId) % 10)).

Ingeniería Single-Table Design (Rick Houlihan Pattern): Claves Compuestas PK/SK, GSI Overloading y Sparse Indexes

1. Pre-Joining de Entidades Jerárquicas 1:N en una Sola Partición

Dado que DynamoDB no posee JOIN relacional, Single-Table Design co-localiza entidades relacionadas dentro de la misma colección de ítems usando prefijos tipados en PK (Partition Key) y SK (Sort Key) para recuperar un agregado completo en una sola petición Query de $< 5\text{ ms}$:

| Tipo de Entidad | PK (Partition Key) | SK (Sort Key) | GSI1PK | GSI1SK | | :--- | :--- | :--- | :--- | :--- | | Perfil de Organización | ORG#acme | METADATA#acme | COUNTRY#CL | ORG#acme | | Miembro / Usuario | ORG#acme | USER#u_104 | USEREMAIL#[email protected] | ORG#acme | | Factura Emitida | ORG#acme | INVOICE#2026-10-21#inv_88 | STATUS#UNPAID (Sparse) | 2026-10-21 |

Ejecutar Query(PK = "ORG#acme", SK begins_with "INVOICE#2026-10") devuelve instantáneamente todas las facturas de octubre de esa organización ordenadas cronológicamente.

Transacciones ACID en DynamoDB (TransactWriteItems), DynamoDB Streams y Expiración TTL Gratuita

1. Costo y Semántica de TransactWriteItems

TransactWriteItems permite agrupar hasta 100 operaciones (Put, Update, Delete, ConditionCheck) con aislamiento serializable ACID a través de múltiples particiones y tablas: - Consume el doble de WCU ($2\times$) que una escritura estándar debido al protocolo de preparación y confirmación en dos fases (2PC) del coordinador transaccional. - Acepta un parámetro ClientRequestToken que garantiza idempotencia exacta durante 10 minutos ante reintentos de red.

Matriz de Decisión Arquitectónica: Cuándo Elegir ScyllaDB/Cassandra vs. Amazon DynamoDB

- Amazon DynamoDB: Ideal para arquitecturas Serverless, tráfico con picos impredecibles y cero operación de infraestructura cuando el acceso se modela con $\le 20$ patrones de acceso conocidos. - ScyllaDB / Apache Cassandra: Ideal para cargas sostenidas de ultra-alto throughput ($> 200,000\text{ ops/s}$ donde DynamoDB resulta $5\times - 10\times$ más costoso), soberanía multi-cloud/on-premise y latencias p99 sub-milisegundo predecibles.

Laboratorio Práctico: Detección de Hot Partitions y Cálculo de Consumo WCU en DynamoDB

Contexto del Desafío NoSQL

En DynamoDB, cada escritura consume 1 WCU por cada 1 KB de tamaño de ítem (redondeado hacia arriba con CEIL), y una partición física individual soporta como máximo 1,000 WCU por segundo antes de sufrir throttling.

La tabla dynamodb_partition_traffic contiene la telemetría de tráfico por segundo de nuestras claves de partición: - partition_key (TEXT) - writes_per_sec (INTEGER: escrituras por segundo hacia esa clave) - item_size_kb (INTEGER: tamaño entero en KB de cada ítem escrito)

Objetivo de la Consulta SQL

Evaluación de Certificación: DB-1201

Valida tu dominio sobre motores LSM-Tree, quórums sintonizables, Tombstones, ScyllaDB y diseño Single-Table en DynamoDB.