25 min. Una base de series de tiempo está optimizada para una sola pregunta: ¿cómo cambió esto con el tiempo? Meterle datos relacionales la vuelve lenta y cara.
Los datos de telemetría son append-only, ordenados por tiempo, y casi siempre se consultan por rango temporal con agregación. Una TSDB aprovecha eso: compresión por columnas (los valores contiguos se parecen), índices por tiempo, y downsampling automático. Una SQL de propósito general puede hacerlo, pero pagando en espacio y en velocidad de consulta.
measurement,tag1=v1,tag2=v2 field1=x,field2=y timestamp
minibaja,car=01,session=race1 rpm=3847,temp_motor=92.4 1724371200000000000
minibaja; cada proyecto de competencia tiene el suyo (quantum, etc.)cardinalidad ≈ Π (valores únicos de cada tag)
Cada combinación única de tags crea una serie, y cada serie cuesta memoria de índice. Poner algo de alta cardinalidad como tag — un timestamp, un ID de paquete, un valor continuo — genera millones de series y tumba el servidor. Es el error #1 en InfluxDB.
Regla: tag = algo por lo que filtrarías y que tiene pocos valores distintos (coche, sesión, tipo de sensor). Todo lo demás es field.
| Bucket | Resolución | Retención | Para qué |
|---|---|---|---|
| LIVE | completa (5–10 Hz) | días | dashboard de pits durante la carrera |
| ANALYSIS | downsampled (1 Hz o menos) | meses/años | comparar carreras, tendencias entre temporadas |
Una tarea programada agrega de LIVE a ANALYSIS. Guardar todo a resolución completa para siempre es innecesario — pero decidir qué agregación (media, máx, mín, p95) tiene consecuencias: la media borra los picos, y los picos suelen ser justo el evento que interesa. Para señales de alarma se guarda el máximo, no la media.