Inicio/Glosario/Series temporales
AnalíticaSeries temporales
Una serie temporal es una secuencia de datos indexados por el tiempo: cada punto lleva una marca temporal y uno o más valores. Su patrón de uso —escritura masiva en modo append y lectura por agregación sobre rangos— la distingue de un dato transaccional.
Qué es
Una serie temporal es una secuencia de observaciones ordenadas por su marca temporal (timestamp). Cada punto asocia un instante a una o varias métricas. En analítica web y SEO son magnitudes como clics, impresiones, posiciones, tráfico, Core Web Vitals o eventos de servidor, registradas a intervalos regulares o como flujo continuo de eventos. Lo que define a una serie temporal no es solo "tener fechas": es su patrón de uso. Se escribe mucho y casi siempre añadiendo al final (append-only, rara vez se corrige el pasado), y se lee agregando sobre rangos amplios —media diaria del último año, tendencia mensual— en lugar de buscar un registro suelto por clave.
Esa asimetría justifica las bases de datos de series temporales (TSDB) y el almacenamiento columnar. En un store por filas (OLTP) los campos de un registro se guardan juntos, lo que optimiza la transacción individual. En uno columnar (OLAP/TSDB) los valores de una misma columna van contiguos: para agregar se lee solo la columna necesaria, se reduce la I/O, se comprime mejor porque los datos contiguos son del mismo tipo y se permite ejecución vectorizada. Agregaciones que en un row store tardarían minutos pueden resolverse en milisegundos. Por ese motivo es habitual montar la capa de analítica sobre motores como TimescaleDB —extensión de PostgreSQL que conserva SQL estándar— o pilas como InfluxDB con Grafana. Es una alternativa a un Data warehouse (BigQuery), que resuelve el mismo perfil analítico OLAP pero como servicio gestionado en la nube.
Sobre ese motor se gestiona el ciclo de vida del dato con tres mecanismos. Las agregaciones continuas son vistas materializadas que se refrescan en background de forma incremental, recalculando solo los cubos temporales que han cambiado desde el último refresco, para servir resúmenes al instante. El downsampling baja la resolución del dato antiguo agregándolo a cubos temporales mayores —de segundos a horas o días—, conservando la tendencia con muchos menos puntos. La retención expira el dato crudo pasado un umbral; en TimescaleDB es eficiente porque elimina "chunks" (particiones por tiempo) enteros, no fila a fila. La estrategia combinada habitual: conservar el crudo unos días, downsamplear a un agregado continuo, comprimir los chunks antiguos y dejar caer el crudo manteniendo los resúmenes a largo plazo.
Por qué importa
Analizar métricas longitudinales —posiciones, clics, rendimiento— sobre una base transaccional suele degradarse a medida que crece el histórico: las consultas de tendencia consumen recursos y se vuelven lentas, y guardar todo el dato crudo a máxima resolución dispara el almacenamiento. Un motor de series temporales y una política de ciclo de vida del dato abordan ese problema de raíz, separando lo que se consulta a menudo (resúmenes pre-agregados) de lo que se conserva por si acaso (crudo, comprimido o expirado). Es la capa de destino natural de un proceso de ETL / pipelines de datos que extrae métricas de fuentes como Google Analytics 4 (GA4) o la Search Console, las normaliza y las carga ordenadas por tiempo; el Modelado de datos previo —decidir qué dimensiones acompañan a cada métrica— condiciona luego cuánto se puede agregar y a qué coste. No es una bala de plata: hay que dimensionar la cardinalidad, elegir resoluciones y definir qué se conserva. La elección de motor y de políticas depende del volumen, de la frecuencia de lectura y del horizonte histórico que se quiera mantener.
En profundidad
Columnar frente a row store: por qué OLAP y OLTP optimizan cosas distintas
Un row store (OLTP) guarda juntos todos los campos de un registro: ideal para escribir o leer una fila completa con baja latencia, como una transacción de usuario. Un columnar (OLAP/TSDB) guarda contiguos los valores de cada columna: ideal para agregar sobre muchos registros leyendo pocas columnas. El columnar reduce I/O (solo lee lo necesario), comprime mejor —datos del mismo tipo y a menudo similares, contiguos— y permite ejecución vectorizada (SIMD). No es que uno sea mejor: optimizan cargas opuestas. La misma lógica explica por qué un Data warehouse (BigQuery) —columnar y orientado a consulta analítica— se usa para reporting y no como base operativa.
| Dimensión | Row store (OLTP) | Columnar (OLAP/TSDB) |
|---|---|---|
| Disposición física | Campos de una fila juntos | Valores de una columna contiguos |
| Carga ideal | Leer/escribir una fila completa | Agregar muchos registros, pocas columnas |
| I/O | Lee toda la fila | Lee solo las columnas necesarias |
| Compresión | Tipos mezclados, menor ratio | Mismo tipo contiguo, mejor ratio |
| Ejecución | Punto a punto, baja latencia | Vectorizada (SIMD) sobre lotes |
Ciclo de vida del dato: agregaciones continuas, downsampling y retención
Tres mecanismos encadenados. Agregación continua: vista materializada refrescada en background de forma incremental, que recalcula solo los cubos que han cambiado y pre-computa resúmenes (media, suma) para consulta instantánea. Downsampling: reducir la resolución del dato histórico agregándolo a cubos mayores, conservando la tendencia con menos puntos y menos disco. Retención: política que expira el crudo pasado un umbral; en TimescaleDB elimina chunks (particiones por tiempo) enteros, mucho más eficiente que borrar fila a fila. La compresión columnar de los chunks antiguos completa el cuadro. Estas políticas son la parte del ciclo de vida que el ETL / pipelines de datos no cubre: el pipeline carga el dato, pero el motor decide cuánto vive y a qué resolución.
Cardinalidad alta y hot spots al escalar muchas series
El número de series distintas (cardinalidad) crece con cada combinación de dimensiones: keyword × URL × país × dispositivo. Una cardinalidad muy alta degrada el rendimiento y el almacenamiento de muchas TSDB. Aparte, particionar la clave solo por timestamp concentra todas las escrituras recientes en la misma partición (hot spot); se mitiga prefijando con otra dimensión antes del tiempo. Ambos son los límites reales al escalar analítica de series. Por eso el Modelado de datos —qué dimensiones se indexan y cuáles se dejan como atributo— es una decisión de diseño, no un detalle: cada dimensión añadida multiplica la cardinalidad.
Funciones de serie temporal: cubos, primero/último y relleno de huecos
Las TSDB añaden funciones que SQL estándar no resuelve cómodamente: agrupar por cubos temporales (time_bucket) para alinear puntos a intervalos regulares; obtener el primer o último valor de cada cubo; y rellenar huecos donde falta dato —por ejemplo arrastrando el último valor conocido (LOCF) o interpolando. Son la base para construir series regulares a partir de datos irregulares o con gaps, un paso de Limpieza y calidad de datos imprescindible antes de comparar periodos o detectar tendencias sobre fuentes con lagunas.
Qué observar
Las señales que importan.
Las consultas de tendencia histórica tardan minutos o saturan recursos
Síntoma típico de agregar sobre muchos registros en un store por filas. Las agregaciones continuas y el almacenamiento columnar existen precisamente para resolver ese patrón en milisegundos.
El almacenamiento crece sin control guardando todo a máxima resolución
Sin downsampling ni retención, el dato crudo se acumula indefinidamente. El histórico rara vez se consulta a resolución de segundos; conservarlo así es coste sin retorno.
Se analizan métricas longitudinales sobre una base transaccional
Posiciones, clics o impresiones encajan mal en un esquema OLTP. El patrón de lectura por agregación pide un motor orientado a series.
Las escrituras se concentran en una sola partición
Particionar solo por timestamp manda todas las escrituras recientes al mismo sitio (hot spot). Conviene prefijar la clave con otra dimensión —proyecto, URL— antes del tiempo.
Muchas series simultáneas degradan el rendimiento
Combinaciones como keyword × URL × país disparan la cardinalidad. Es el reto real de escala en analítica de series y condiciona la elección de motor y modelado.
Conceptos clave
El vocabulario del término.
- TSDB (base de datos de series temporales)
- Motor especializado en datos indexados por tiempo, optimizado para escritura append-only masiva y lectura por agregación sobre rangos. Ejemplos: TimescaleDB, InfluxDB.
- TimescaleDB
- Extensión de PostgreSQL para series temporales que conserva SQL estándar. Particiona por tiempo en chunks y añade agregaciones continuas, compresión columnar y políticas de retención.
- Almacenamiento columnar
- Modelo físico que guarda contiguos los valores de cada columna en lugar de los campos de cada fila. Reduce I/O en agregaciones, comprime mejor y habilita ejecución vectorizada (SIMD).
- OLTP vs OLAP
- OLTP optimiza transacciones: leer/escribir registros completos con baja latencia (orientado a filas). OLAP optimiza analítica: agregar sobre muchos registros y pocas columnas (orientado a columnas).
- Agregación continua
- Vista materializada que se refresca en background de forma incremental —solo sobre los cubos temporales nuevos o modificados— para pre-computar resúmenes y servir consultas al instante sin recalcular todo el histórico.
- Downsampling
- Reducir la resolución temporal del dato histórico agregándolo a cubos mayores (de segundos a horas o días). Conserva la tendencia con muchos menos puntos y menos almacenamiento.
- Retención
- Política que expira o archiva el dato pasado un umbral de antigüedad. En TimescaleDB es eficiente porque elimina chunks (particiones por tiempo) completos en lugar de borrar fila a fila.
- Cardinalidad
- Número de series distintas, fruto de combinar dimensiones (p. ej. keyword × URL × país). Una cardinalidad muy alta es el principal reto de escala en rendimiento y almacenamiento de una TSDB.
Dónde lo aplicamos
Aún no mostramos casos.
No inventamos resultados. Cuando tengamos casos reales —anonimizados y medibles— donde este concepto marcó la diferencia, vivirán aquí.
Fuentes
- About continuous aggregates — TimescaleDB (Tiger Data) documentación oficial · 2026
- How to proactively manage long-term data with downsampling — Tiger Data (TimescaleDB) · 2025
- Real-Time Analytics for Time Series: Continuous Aggregates — Tiger Data (TimescaleDB) · 2025
- Teaching Postgres New Tricks: SIMD Vectorization for Faster Analytical Queries — Tiger Data · 2025
- What is a columnar database? — ClickHouse · 2025
- Columnar database vs row database — Fivetran · 2025
Una pieza del glosario.
Forma parte del glosario de SEO, analítica e IA de InnovaOrigen Tech: un mapa de conceptos definidos con criterio y fuentes. Si quieres llevarlo a tu caso, lo vemos sin compromiso.