Cuándo migrar de STCS a TWCS en producción (Apache Cassandra)

En el vertiginoso mundo de las bases de datos NoSQL, Apache Cassandra se ha consolidado como una elección robusta para cargas de trabajo de alta disponibilidad y escalabilidad masiva. Sin embargo, para extraer el máximo rendimiento de este poderoso sistema distribuido, no basta con una buena configuración inicial; es crucial entender y optimizar sus componentes internos. Uno de los aspectos más críticos y a menudo subestimados es la estrategia de compactación de SSTables. Si trabajas con Cassandra en un entorno de producción, es muy probable que hayas escuchado hablar de STCS (SizeTieredCompactionStrategy) y TWCS (TimeWindowCompactionStrategy). La decisión de cuándo y cómo migrar de la estrategia por defecto STCS a TWCS en un sistema en producción puede marcar una diferencia abismal en el rendimiento, el uso del disco y la estabilidad general de tu clúster, especialmente si manejas grandes volúmenes de datos con patrones de acceso basados en tiempo. Este artículo explorará en profundidad cuándo considerar esta migración, qué pasos seguir y qué precauciones tomar para asegurar una transición exitosa y sin sobresaltos.

Comprendiendo las estrategias de compactación: STCS y TWCS

Antes de sumergirnos en el proceso de migración, es fundamental tener una comprensión clara de qué son STCS y TWCS, y cómo operan bajo el capó de Cassandra. La compactación es el proceso mediante el cual Cassandra fusiona los archivos de datos inmutables (SSTables) en el disco, eliminando datos obsoletos (como las tumbas o "tombstones"), filas eliminadas y actualizaciones, y liberando espacio. Este proceso es vital para mantener la salud del clúster.

STCS (SizeTieredCompactionStrategy): El caballo de batalla predeterminado

STCS es la estrategia de compactación por defecto en Apache Cassandra y, por una buena razón, es adecuada para una amplia gama de cargas de trabajo. Su funcionamiento es relativamente simple: agrupa SSTables de tamaños similares y los compacta en uno o más SSTables más grandes. Este proceso se repite continuamente, llevando a la creación de SSTables progresivamente más grandes.

Ventajas de STCS:

• Buena para cargas de trabajo generales: Funciona bien donde los datos no tienen un patrón de envejecimiento claro o donde el acceso es uniforme a través de todo el conjunto de datos.
• Fácil de entender: Su lógica basada en el tamaño es intuitiva.

Desventajas de STCS:

• Ineficiente para datos con TTL o series temporales: Aquí es donde STCS comienza a mostrar sus limitaciones. Cuando se tienen datos con tiempo de vida (TTL) o datos de series temporales que expiran y son eliminados con frecuencia, STCS tiende a mantener SSTables muy grandes que contienen tanto datos "vivos" como muchas tumbas. Para compactar estas tumbas y liberar espacio, Cassandra necesita compactar estos SSTables grandes, lo que puede consumir muchos recursos de I/O y CPU.
• Explosión de disco: El almacenamiento puede crecer desproporcionadamente. Como los SSTables se hacen cada vez más grandes, se necesita mucho espacio temporal para la compactación, lo que puede llevar a una utilización del disco cercana al 50% o incluso más en algunos casos solo para compactaciones.
• Read amplification: Una consulta puede necesitar leer de un gran número de SSTables si no se han compactado eficientemente, aumentando la latencia de lectura.
• Write amplification: Aunque la escritura inicial es rápida, la reescritura constante de datos durante la compactación puede ser una carga.

TWCS (TimeWindowCompactionStrategy): El especialista en series temporales

Introducida en Cassandra 3.0, TWCS fue diseñada específicamente para manejar datos de series temporales (time-series data) y datos con TTL que expiran con el tiempo. Su enfoque es diferente: divide los SSTables en "ventanas de tiempo" lógicas. Dentro de cada ventana de tiempo (por ejemplo, una hora, un día), TWCS utiliza una estrategia de compactación similar a STCS (o a LeveledCompactionStrategy, LCS, si se configura, aunque STCS es el valor predeterminado dentro de cada ventana). Cuando una ventana de tiempo se cierra, todos los SSTables de esa ventana se compactan en un único SSTable grande.

Ventajas de TWCS:

• Excelente para datos de series temporales y con TTL: Al crear SSTables por ventanas de tiempo, los datos más antiguos se agrupan de manera más eficiente. Esto permite que las tumbas y los datos expirados en las ventanas más antiguas sean compactados y eliminados de forma más predecible y eficiente, reduciendo drásticamente el uso de disco y la read amplification.
• Rendimiento predecible: La compactación es menos intensiva en I/O y CPU porque las ventanas de tiempo controlan el tamaño de los SSTables a compactar.
• Mejor gestión de tumbas: Las tumbas son compactadas y eliminadas más rápidamente, lo que reduce los problemas de rendimiento.
• Reduce la read amplification: Al tener menos SSTables por ventana para leer, las consultas son más rápidas.

Desventajas de TWCS:

• No apta para todos los casos de uso: Si tu tabla no es predominantemente de series temporales o no utiliza TTL de manera significativa, TWCS puede no ser la mejor opción y, de hecho, podría ser menos eficiente que STCS.
• Configuración delicada: Elegir el compaction_window_unit y compaction_window_size correctos es crucial y requiere un buen entendimiento de tus patrones de datos y TTL. Una ventana mal configurada puede generar muchos SSTables pequeños o, por el contrario, SSTables muy grandes que anulen las ventajas de TWCS.

Señales de que es tiempo de considerar la migración a TWCS en producción

La decisión de migrar no debe tomarse a la ligera, especialmente en un entorno de producción. Sin embargo, existen claras señales de advertencia que indican que STCS podría estar obstaculizando el rendimiento de tu clúster y que TWCS podría ser la solución.

1. Explosión constante del espacio en disco: Si tus discos se llenan rápidamente y las compactaciones parecen estar siempre ocupadas, pero el espacio no se libera tan eficientemente como esperarías, es una fuerte señal. STCS tiende a necesitar una cantidad considerable de espacio libre para operar, y si tu espacio en disco es una preocupación constante, TWCS podría ayudar a gestionar esto.
2. Altas latencias de lectura y escritura inesperadas: Aunque Cassandra es conocido por su baja latencia, si observas picos inusuales en las latencias de lectura o escritura que se correlacionan con actividades de compactación, podría ser que STCS esté luchando por manejar la carga. Una alta read amplification debido a la necesidad de leer de muchos SSTables es un culpable común.
3. Monitoreo de nodetool compactionstats revela problemas:
   • Pending tasks elevado: Si el número de tareas de compactación pendientes es consistentemente alto, significa que Cassandra no puede mantenerse al día.
   • Total bytes compacted alto sin reducción del espacio lógico: Si se están compactando muchos bytes pero el espacio en disco utilizado por la tabla no disminuye significativamente, podría ser que se estén compactando muchos datos redundantes o tumbas ineficientemente.
   • Compacted bytes / Read bytes o Compacted bytes / Written bytes ratios altos: Esto indica una alta write/read amplification.
4. Uso intensivo de CPU y I/O por compactaciones: Si tus nodos están constantemente bajo presión de CPU y I/O, y las métricas apuntan a los hilos de compactación como los mayores consumidores de recursos, STCS podría ser el culpable.
5. Tablas con TTLs agresivos o datos puramente de series temporales: Este es el escenario ideal para TWCS. Si tienes tablas con datos que expiran después de unas horas, días o semanas, y se accede a ellos principalmente por rangos de tiempo, STCS es subóptimo. Las tumbas generadas por la expiración de TTL permanecerán en SSTables grandes por mucho tiempo antes de ser compactadas y eliminadas, afectando el rendimiento. Puedes aprender más sobre las estrategias de compactación de Cassandra en la documentación oficial de Apache Cassandra: Apache Cassandra Compaction Strategies.

Planificación y prerrequisitos para la migración

Una migración en producción requiere una planificación meticulosa. No se trata simplemente de cambiar una línea en la configuración.

1. Entender tus datos y patrones de acceso

• ¿Es realmente una tabla de series temporales? Asegúrate de que los datos de la tabla se ajustan al modelo de series temporales, es decir, que se escriben en orden cronológico y se leen principalmente por rangos de tiempo, y que los datos antiguos son menos relevantes o se eliminan.
• ¿Cuál es el patrón de expiración de tus datos (TTL)? Si tus datos tienen TTL, ¿cuál es su duración promedio? Esto es crucial para configurar el tamaño de la ventana de TWCS.
• Volumen de datos y tasas de escritura/lectura: Evalúa cuánto dato se escribe por unidad de tiempo y cómo se leen.

2. Pruebas exhaustivas en entornos de no producción

¡Esto es innegociable! Nunca, bajo ninguna circunstancia, realices cambios en la estrategia de compactación directamente en producción sin haberlos probado a fondo.

• Monta un entorno idéntico: Utiliza datos representativos y replica las cargas de trabajo de producción tanto como sea posible.
• Experimenta con compaction_window_size y compaction_window_unit: Prueba diferentes configuraciones para encontrar el equilibrio óptimo.
  • Regla general: El tamaño de la ventana debe ser lo suficientemente grande para capturar un buen volumen de escrituras, pero no tan grande como para que las compactaciones dentro de la ventana se vuelvan ineficientes. A menudo, se alinea con el TTL más común de tus datos o con la granularidad con la que se suelen consultar los datos. Por ejemplo, si los datos expiran en 7 días y los consultas por día, una ventana de 1 día podría ser adecuada.
• Monitorea métricas clave: Observa de cerca el uso del disco, la CPU, la I/O, las latencias de lectura/escritura y las estadísticas de compactación.
• Simula fallos: ¿Qué ocurre si un nodo se cae durante la compactación?

3. Compatibilidad de la versión de Cassandra

TWCS está disponible a partir de Cassandra 3.0. Asegúrate de que tu clúster cumple con este requisito. Puedes encontrar más detalles en este blog de DataStax sobre la gestión de datos de series temporales: DataStax Blog - Time Series Data Management.

4. Plan de contingencia y retroceso

Ten un plan claro para revertir los cambios si algo sale mal. Aunque cambiar la estrategia de compactación es un metadato y no debería corromper los datos, un mal rendimiento puede requerir volver a STCS.

Proceso de migración a TWCS en producción

La migración no implica una reescritura inmediata de todos los datos existentes. Los SSTables que ya existen seguirán gestionándose bajo la estrategia anterior hasta que se compacten con SSTables nuevos.

1. Elección de la ventana de compactación (crucial)

Esta es la decisión más importante. Define compaction_window_unit (segundos, minutos, horas, días) y compaction_window_size.

• Ejemplo: Si tu TTL es de 7 días y sueles consultar datos por día, podrías empezar con {'class': 'TimeWindowCompactionStrategy', 'compaction_window_unit': 'DAYS', 'compaction_window_size': 1}. Esto significa que cada día, todos los SSTables generados en ese día se compactarán en un solo SSTable para ese día.
• Mi opinión: Personalmente, siempre empiezo con ventanas que reflejen la granularidad más natural de mis datos o el TTL más corto. Por ejemplo, para datos con TTL de un día o unas horas, una ventana de 'HOURS' suele ser un buen punto de partida. Para datos que se retienen por semanas o meses, 'DAYS' es más apropiado. Es mejor errar en el lado de ventanas ligeramente más pequeñas y luego ajustarlas si el número de SSTables crece demasiado.

2. Aplicación del cambio

El cambio se realiza mediante una instrucción ALTER TABLE en CQL.

ALTER TABLE my_keyspace.my_table
WITH compaction = {
   'class': 'TimeWindowCompactionStrategy',
   'compaction_window_unit': 'HOURS',
   'compaction_window_size': 1,
   'bucket_low': 0.5,
   'bucket_high': 1.5,
   'min_threshold': 4,
   'max_threshold': 32
};

• bucket_low y bucket_high: Parámetros avanzados para el tamaño de las cubetas de compactación. Los valores predeterminados (0.5, 1.5) suelen ser adecuados.
• min_threshold y max_threshold: Controlan cuándo se activa la compactación dentro de una ventana. Son similares a los umbrales de STCS y normalmente los valores predeterminados (4, 32) funcionan bien.

Procedimiento recomendado para producción (por fases):

1. Un nodo a la vez (o un subconjunto pequeño): No apliques el ALTER TABLE a todo el clúster a la vez. Aunque es una operación de metadatos, siempre es prudente ir nodo por nodo, o al menos un DC a la vez, monitoreando el impacto.
2. Monitoreo exhaustivo post-cambio:
   • nodetool compactionstats: Observa cómo cambian las compactaciones. Deberías empezar a ver nuevas compactaciones específicas de TWCS.
   • Uso del disco: Espera que el uso del disco se estabilice o incluso disminuya con el tiempo, a medida que los SSTables viejos de STCS se compactan con los nuevos de TWCS o expiran y se eliminan. Esto puede llevar días o incluso semanas, dependiendo del volumen de datos y el tamaño de la ventana.
   • CPU y I/O: Asegúrate de que no haya picos inesperados.
   • Latencias y rendimiento de la aplicación: Las latencias de lectura y escritura deberían mejorar con el tiempo.

3. Gestionar SSTables existentes (opcional y con precaución)

Una vez que se cambia la estrategia a TWCS, los nuevos SSTables se crearán y gestionarán bajo esa estrategia. Sin embargo, los SSTables existentes que se crearon bajo STCS se seguirán compactando con SSTables nuevos utilizando la estrategia recién configurada. Esto puede generar una mezcla que no aprovecha al máximo TWCS de inmediato.

• nodetool upgradesstables: Esta herramienta reescribe los SSTables existentes bajo la nueva estrategia de compactación.
  • Advertencia: upgradesstables es una operación intensiva en recursos. Genera una carga significativa en CPU, I/O y espacio en disco (puede duplicar el espacio temporalmente).
  • Recomendación: Solo considera upgradesstables si tienes una ventana de mantenimiento o recursos de cómputo y disco holgados. Preferiblemente, hazlo un nodo a la vez, dejando suficiente tiempo entre nodos para que se recuperen. En muchos casos, es mejor permitir que los SSTables existentes se compacten de forma natural con los nuevos datos a medida que pasa el tiempo, especialmente si los datos antiguos eventualmente expiran. Este blog de DataStax ofrece buenas prácticas: DataStax Best Practices.

Optimización y seguimiento post-migración

Una vez que la migración se ha completado y el clúster está funcionando con TWCS, el trabajo no termina. La optimización continua es clave.

1. Ajuste de `compaction_window_size`

Monitorea la cantidad de SSTables por ventana y el rendimiento general. Si ves demasiados SSTables pequeños, es posible que la ventana sea demasiado pequeña. Si las compactaciones siguen siendo muy pesadas dentro de las ventanas, quizás la ventana es demasiado grande o el min_threshold/max_threshold necesiten ajuste.

2. Gestión de TTL y `gc_grace_seconds`

TWCS trabaja de la mano con TTLs. Asegúrate de que tu gc_grace_seconds sea apropiado para tu aplicación y para la replicación del clúster. Un gc_grace_seconds muy alto puede retrasar la eliminación de tumbas, incluso con TWCS. Sin embargo, reducirlo demasiado puede llevar a la resurrección de datos en un clúster distribuido. Puedes consultar la documentación de Cassandra sobre TTL y gc_grace_seconds para más detalles: Cassandra TTL and gc_grace_seconds.

3. Observa las métricas de read/write amplification

Con TWCS, deberías ver una reducción en estos números a medida que las compactaciones se vuelven más eficientes y los SSTables más antiguos se consolidan o eliminan. Puedes usar nodetool cfstats o nodetool tablehistograms para obtener métricas útiles.

4. Espacio en disco

El uso del disco debería ser más estable y predecible. Si aún ves picos de uso de disco o un crecimiento injustificado, revisa tu estrategia de ventana y tu modelo de datos.

Conclusiones

La migración de STCS a TWCS en un entorno de producción de Apache Cassandra no es una tarea trivial, pero puede ofrecer recompensas sustanciales en términos de rendimiento, eficiencia del almacenamiento y estabilidad del clúster, especialmente para cargas de trabajo de series temporales. Requiere una comprensión profunda de tus datos, una planificación meticulosa y una fase de pruebas exhaustiva.

Mi experiencia me dice que, para cualquier tabla que gestione datos de series temporales o que dependa en gran medida de TTLs para la gestión del ciclo de vida de los datos, TWCS es una elección superior a STCS. Los beneficios en cuanto a la reducción de la amplificación de lectura y escritura, la gestión de tumbas y el uso predecible del disco son demasiado significativos como para ignorarlos. Sin embargo, la clave del éxito reside en una implementación gradual y un monitoreo constante. No hay una fórmula mágica para la configuración perfecta de TWCS, pero con un enfoque basado en datos y pruebas, puedes ajustar tu clúster de Cassandra para que rinda al máximo.

Cassandra