Submuestreo y niveles de retención para datos de series temporales

Objetivo

Responder preguntas de largo alcance (un año de latencia, tres años de lecturas de contadores) con una fracción del coste de almacenamiento y de escaneo que suponen las muestras en bruto, y conservar la resolución original durante el periodo en que realmente se consulta.

Requisitos previos

Una tabla o un almacén particionado por tiempo y una decisión sobre qué debe poder responder cada nivel. La documentación de almacenamiento de Prometheus (citada) muestra la política más sencilla: un tiempo de retención de las muestras (--storage.tsdb.retention.time, 15 días por defecto cuando no se define ni este parámetro ni un límite de tamaño) o un límite de tamaño que elimina primero los bloques más antiguos. Thanos (citado) describe el submuestreo como la reescritura de las series para reducir la resolución sin perder precisión en los rangos largos; para ello guarda en cada chunk submuestreado el count, sum, min, max y una serie de contador, de modo que los datos más gruesos aún puedan agregarse. La función date_bin de PostgreSQL (citada) agrupa una marca de tiempo en un intervalo alineado con un origen especificado, que es la primitiva que necesita una agregación en SQL.

Pasos

1. Anota los niveles como (resolución, retención, propósito): por ejemplo, datos en bruto durante 14 días para el análisis de incidentes, intervalos de 5 minutos durante 13 meses para tendencias de capacidad e intervalos de una hora durante 5 años para informes. Los periodos de retención son una decisión que hay que registrar, no una cifra que copiar de otra parte.
2. Para cada intervalo guarda solo estadísticas que puedan volver a agregarse: count, sum, min, max y, en el caso de los contadores, el incremento. Calcula las medias como sum dividido entre count en el momento de la consulta; no almacenes medias ni percentiles, porque no se pueden combinar en un intervalo más grueso. Si se necesitan percentiles, almacena un histograma con límites de bucket fijos.
3. Alinea los intervalos con date_bin(stride, ts, origin) usando un único origen fijo (la época Unix o la medianoche UTC), de modo que los intervalos de distintas ejecuciones y tablas coincidan.
4. Programa la agregación de un intervalo solo cuando haya pasado la ventana de datos tardíos de ese intervalo, y haz que sustituya el intervalo en lugar de sumarse a él, para que repetir la ejecución sea seguro.
5. Haz caducar un nivel eliminando particiones o bloques completos, nunca con borrados fila a fila; verifica la agregación de una partición (número de filas, suma de una medida) antes de eliminar su partición en bruto.
6. Expón los niveles a través de una única vista o capa de consulta que elija el nivel más fino que cubra el rango solicitado.

Resultado esperado

Las consultas de largo alcance escanean el nivel grueso y responden en un tiempo acotado; el almacenamiento crece solo con los niveles gruesos; los datos en bruto se conservan durante el periodo en que se usan.

Límites y base de verificación

Los datos submuestreados no pueden responder preguntas sobre picos más breves que un intervalo. Si una consulta cruza el límite entre dos niveles, el resultado mezcla dos resoluciones y debe indicarse con una etiqueta. El protocolo se deriva de la documentación citada; no se afirma ninguna medición.