Cuándo Migrar de STCS a TWCS en Prod. (Apache Cassandra)

3 minuto(s)

En esta página:

En Apache Cassandra, las operaciones de escritura son ridículamente rápidas porque los datos se escriben de forma secuencial en archivos inmutables llamados SSTables. Sin embargo, esta velocidad inicial tiene un costo diferido: la acumulación de datos duplicados o eliminados (fantasmas o tombstones). Para limpiar el almacenamiento, Cassandra ejecuta de fondo un proceso llamado Compactación. Si dejas la estrategia por defecto en entornos con flujos constantes de datos basados en tiempo, tu servidor sufrirá picos letales de lectura/escritura (Read/Write Amplification) que devorarán el espacio del disco y degradarán la latencia de tu API.

¿Qué es STCS (Size-Tiered Compaction Strategy) y por qué viene por defecto?

Es una estrategia de comptación, que se encarga de agrupar las SSTables que tienen tamaños similares. Cuando se acumula un número determinado de archivos del mismo tamaño (por defecto 4), Cassandra los fusiona en una sola SSTable más grande.

Esta estrategia puede ser un peligro en producción, porque requiere hasta un 50% de espacio libre en disco para poder ejecutar la compactación en tablas gigantes, ya que el archivo temporal resultante puede ser tan grande como la suma de los anteriores. Además, mezcla datos nuevos con antiguos si sus tamaños coinciden, lo cual destruye la eficiencia si tus queries suelen buscar solo lo más reciente.

La Alternativa Eficiente: TWCS (Time-Window Compaction Strategy)

Esta estrategia introduce una solución ideal para logs, métricas, telemetría o series temporales.

Divide el tiempo en ventanas virtuales (por ejemplo, 1 hora o 1 día). Las SSTables se compactan utilizando STCS solo dentro de esa ventana de tiempo. Una vez que la ventana se cierra (ya pasó esa hora o día), esos archivos ya no se vuelven a tocar ni a mezclar con datos nuevos.

Nunca migres a TWCS si tu aplicación realiza operaciones frecuentes de UPDATE o DELETE sobre datos antiguos. Debido a que TWCS “congela” las ventanas de tiempo pasadas, si modificas un registro de hace tres días, Cassandra creará una nueva SSTable en la ventana de hoy. Esto generará duplicación de datos entre archivos que nunca se fusionarán, rompiendo la optimización y aumentando el espacio en disco de forma innecesaria.

Cómo cambiar la estrategia dinámicamente en CQL

Mediante el lenguaje de consulta de Cassandra (CQL), no es necesario apagar el clúster ni reiniciar los nodos. Cassandra permite modificar la estrategia al vuelo mediante sentencias CQL estándares:


-- 1. Verificar la estrategia actual de tu tabla
DESCRIBE TABLE mi_keyspace.metricas_iot;

-- 2. Migrar de forma segura a Time-Window Compaction Strategy (TWCS)
ALTER TABLE mi_keyspace.metricas_iot 
WITH compaction = {
    'class': 'TimeWindowCompactionStrategy',
    'compaction_window_unit': 'DAYS',
    'compaction_window_size': '1',
    'timestamp_resolution': 'MILLISECONDS'
};

-- 1. Verificar la estrategia actual de tu tabla

DESCRIBE TABLE mi_keyspace.metricas_iot;

-- 2. Migrar de forma segura a Time-Window Compaction Strategy (TWCS)

ALTER TABLE mi_keyspace.metricas_iot

WITH compaction = {

'class': 'TimeWindowCompactionStrategy',

'compaction_window_unit': 'DAYS',

'compaction_window_size': '1',

'timestamp_resolution': 'MILLISECONDS'

};

Los parámetros compaction_window_unit y size le dicen a Cassandra que cierre y congele las SSTables cada 1 día. timestamp_resolution debe coincidir con cómo insertas los datos desde tu backend (generalmente milisegundos en Node.js o Java).

¿Cómo verificar que el clúster se está compactando bien?

Para verificar el estado del proceso en caliente, puedes ysar la herramienta de línea de comandos de Cassandra (nodetool):


# Verificar cuántas tareas de compactación están pendientes en el nodo
nodetool compactionstats

# Verificar cuántas tareas de compactación están pendientes en el nodo

nodetool compactionstats

Si el número de pending tasks crece de forma descontrolada tras la migración, significa que el tamaño de la ventana elegida (compaction_window_size) es demasiado grande para el volumen de escrituras por segundo que recibe el nodo.

Conoce sobre el El “Eng Metrics Dashboard” de Uber Para Medir La Productividad De Sus Ingenieros “Eng Metrics Dashboard” de Uber Para Medir La Productividad De Sus Ingenieros.

Conclusión

Elegir la estrategia de compactación adecuada en Apache Cassandra no es una tarea de mantenimiento secundaria; es una decisión de arquitectura de software que dicta directamente la viabilidad financiera y operativa de tu infraestructura clúster. Mantener la configuración por defecto STCS en entornos modernos saturados de logs, eventos en tiempo real o métricas de telemetría es una bomba de tiempo para los discos de tus nodos debido al descontrol del Read Amplification.

La migración hacia TWCS representa el enfoque óptimo para cualquier flujo de datos modelado como series temporales, permitiendo aislar el impacto de la inmutabilidad de las SSTables en ventanas de tiempo predecibles y estables. Al dominar el ajuste de estos parámetros, no solo garantizas que las consultas del backend respondan en microsegundos al acotar los archivos que Cassandra debe escanear, sino que reduces a la mitad el almacenamiento de reserva requerido en tus servidores cloud, logrando un balance perfecto entre rendimiento extremo, escalabilidad lineal y eficiencia de costos en producción.