El equipo de ingeniería de Sodatone, plataforma de inteligencia de A&R de Warner Music Group, explica cómo y por qué redujo el intervalo de chunk de sus hipertablas de TimescaleDB de 30 a 7 días, y qué mejoras concretas obtuvieron en producción.
TimescaleDB es una extensión de PostgreSQL para series temporales. Una hypertable aparenta ser una sola tabla, pero por dentro se compone de "chunks" que agrupan filas por rango temporal. Esa arquitectura permite que las consultas por rango de tiempo solo toquen los chunks relevantes y salten el resto sin leerlos, lo que acelera los escaneos temporales. El tamaño de cada chunk condiciona cinco factores que se acumulan: el conjunto de trabajo en memoria, la poda de chunks por el planificador, el tamaño de lote de la compresión, el coste de reabsorber datos en chunks comprimidos y la granularidad de la retención.
El problema surgió a finales de 2024 en una de las hipertablas con mayor volumen: millones de filas por semana y varios TB en disco antes de comprimir. La compresión empezó a rezagarse respecto a la ingesta, las lecturas de datos recientes se volvieron más pesadas y, cada vez que una fuente upstream republicaba unos días de histórico, había que descomprimir meses enteros. En septiembre el trabajo de compresión de esa tabla falló al no caber el chunk en una sola ejecución. Bajaron el intervalo de 30 a 7 días con set_chunk_time_interval y el job volvió a completarse limpio. Dos meses después, el mismo fallo se reprodujo en otra tabla de datos de listas musicales; aplicaron el mismo cambio y, dado que el patrón se repitió, en diciembre migraron de una sola vez el resto de tablas calientes de engagement de plataformas.
La migración se ejecuta en una línea: TimescaleRecord.set_chunk_time_interval("hypertable", interval: "7 days"). Solo afecta a los chunks futuros, no requiere reescritura, ni bloqueos exclusivos, ni backfill; la hypertable transiciona de forma natural al cerrarse el siguiente chunk. Es totalmente reversible.
Los resultados: la compresión se puso al día más rápido, los backfills pasaron de descomprimir un mes a un chunk de 7 días, las consultas sobre las últimas 24 horas o 7 días nunca cruzan más de uno o dos chunks y la granularidad de la retención es ahora más fina. Como advertencia, los autores señalan que más chunks implican más filas en el catálogo interno de TimescaleDB y más trabajo del planificador en consultas que abarcan periodos muy amplios, aunque en su caso no detectaron regresiones. La regla de TimescaleDB —que el chunk activo quepa en alrededor del 25% de la memoria disponible— no es estática: al crecer la ingesta, el mismo intervalo temporal representa más bytes, y un chunk válido hace un año puede dejar de serlo. Recomiendan revisar este ajuste en cualquier hypertable en producción desde hace más de un año.