InfluxDB - Base de datos de series temporales

InfluxDB es una base de datos de series temporales (Time Series Database, TSDB) de código abierto desarrollada por InfluxData. Se diseñó para altas tasas de ingestión y consultas eficientes de datos con marcas de tiempo, por lo que es muy utilizada en aplicaciones de monitorización de IoT, métricas DevOps y análisis en tiempo real.

A diferencia de las bases de datos SQL tradicionales o de documentos como MongoDB, InfluxDB está optimizada específicamente para manejar datos indexados por tiempo: cada punto de datos tiene una marca temporal (timestamp) que actúa como clave primaria.

Elementos¶

https://awesome.influxdata.com/docs/part-2/influxdb-data-model/#influxdb-data-elements (min 17:11)

El modelo de datos de InfluxDB está diseñado en torno al tiempo. Los conceptos clave de los modelos de series temporales son:

Bucket (base de datos): Es el contenedor de datos más alto, combina el concepto de base de datos con las políticas de retención. Todos los datos de InfluxDB se escriben en un bucket, el cual almacena puntos de datos para tantas medidas como queramos.

Sobre los buckets conviene destacar que:
- se pueden crear tokens que controlan los permisos de lectura y escritura, con alcance a un bucket específico.
- todo bucket, al crearlo, se configura un período de retención, el cual determina cuanto tiempo se almacenarán los datos de series temporales dentro del bucket. Una buena configuración del período de retención implica una gestión óptima del sistema gestor, facilitando deshacerse de los datos inútiles y poniendo el foco en los datos recientes, que aportan mayor valor al proyecto, al mismo tiempo que se reduce los costes de almacenamiento.
Medida (measurement): Equivale a una tabla lógica que agrupa datos de la misma naturaleza. Todos los puntos en una medición comparten el mismo conjunto de etiquetas generales. Por ejemplo, una medición sensor_temp para datos de temperatura. Es análoga a una tabla SQL con la marca temporal como índice clave predefinido.
Puntos de datos (point): Es un registro único que consta de medidas, un conjunto de etiquetas, un conjunto de campos y un timestamp. Por ejemplo:
```
name: censo
time                   mariposas  abejas  zona    responsable
2025-08-18T00:00:00Z   1          30      1       amedrano
```
Este punto pertenece a la medida censo, tiene etiquetas (zona=1, responsable=amedrano), campos (butterflies=1, honeybees=30) y su timestamp. Cada punto se identifica de forma única por su serie (ver abajo) más el instante de tiempo.
Etiqueta (tag): Par clave-valor opcional indexado, usado para metadatos de filtrado. Por ejemplo, tags como host=“servidor1” o location=“oficina”. Los tags son indexados, por lo que filtrar por tags es muy eficiente. Se recomienda usar tags para información de filtrado o agrupamiento (por ejemplo, ubicación o tipo de sensor) que no cambie frecuentemente.
Campo (field): Par clave-valor que contiene el dato real (numérico, booleano, texto). Por ejemplo, temperatura=23.5. Los campos no se indexan, por lo que las consultas que filtran por campos deben escanear los datos y son más lentas. Por eso conviene guardar como campo aquello que cambia cada punto (por ejemplo, una lectura de sensor).
Timestamp (marca temporal): Tiempo exacto asociado a cada punto, en UTC o epoch. InfluxDB ordena los datos internamente por tiempo. En cada medición el campo de tiempo es obligatorio y actúa como clave primaria implícita.
Serie (series): Es el conjunto de puntos que comparten la misma medición y los mismos valores de tags. Equivale a una combinación única de measurement + tagset. Por ejemplo, para la medición weather con tags city=London y country=UK, todos los puntos con esa combinación de tags forman una serie. Cada serie contiene múltiples puntos con timestamps distintos.

En resumen, la información en InfluxDB se organiza jerárquicamente: bucket > medida > serie > punto. Por ejemplo, un registro de temperatura de un sensor puede ser: Bucket “IoTData”, medición “temperatura_sala”, tags {ubicacion=“sala1”}, fields {valor=22.5}, timestamp “2025-05-30T16:00:00Z”.

Instalación y primeros pasos¶

Para comenzar con InfluxDB se puede instalar de varias formas:

Instalación local (Linux): InfluxData provee paquetes oficiales. Por ejemplo, en Ubuntu se añade la llave de InfluxData, el repositorio APT y luego sudo apt-get install influxdb para InfluxDB v1.x o influxdb2 para la versión 2.x. Tras la instalación, se inicia el servicio (sudo systemctl start influxdb) y se puede verificar con influxd version.
Docker: Se puede descargar la imagen Docker oficial. Por ejemplo, ejecutar docker pull influxdb y luego iniciar un contenedor docker run -p 8086:8086 --name influxdb influxdb:2.7 (para InfluxDB v2). De esta forma se expone el puerto 8086 local, donde InfluxDB atiende HTTP API y la interfaz web.
Primeros pasos: Al arrancar InfluxDB por primera vez (v2), se realiza una configuración inicial: se crea un usuario administrador, una organización y un bucket de datos. En la versión 2.x esto puede hacerse vía línea de comandos (influx setup) o mediante la interfaz web integrada. En v1.x, se puede crear una base de datos con CREATE DATABASE nombreBD o configurarla en el archivo de configuración. En ambos casos ya estamos listos para enviar datos a InfluxDB.

Finalmente, se suele acceder a la interfaz web de InfluxDB (v1.8.x incluye Chronograf; v2.x incluye un UI propio) en http://localhost:8086. Por defecto la interfaz web permite explorar datos, crear consultas y dashboards.

Hidrógeno Verde

Para el PIIAFP de Hidrógeno Verde, crearemos los siguiente elementos:

Organización: s8a
Bucket: h2v
Medida: temperaturas

Influx CLI¶

Cargando datos de ejemplo¶

El primer paso es crear un bucket para guardar la información. Para ello, podemos hacerlo desde el interfaz gráfico, o bien mediante el API REST a la URL https://localhost:8086/api/v2/buckets. Por ejemplo:

INFLUX_TOKEN=hidrogenoverde
INFLUX_ORG_ID=my-org
BUCKET_NAME=ejemplo-sensores-aire

curl --request POST \
  "http://localhost:8086/api/v2/buckets" \
  --header "Authorization: Token ${INFLUX_TOKEN}" \
  --header "Content-type: application/json" \
  --data '{
    "orgID": "'"${INFLUX_ORG_ID}"'",
    "name": "'"${BUCKET_NAME}"'",
    "retentionRules": [
      {
        "type": "expire",
        "everySeconds": 0,
        "shardGroupDurationSeconds": 0
      }
    ]
  }'

````


Para cargar datos de ejemplo de [sensores de aire](https://docs.influxdata.com/influxdb/v2/reference/sample-data/#air-sensor-sample-data), vamos a crear una tarea.

<figure style="float: right;">
    <img src="images/10-task-loadsample.png" width="300">
    <figcaption>Creando una tarea</figcaption>
</figure>

Para ello, desde InfluxDB UI, accedemos a la opción de *Tasks* (el icono del calendario) y creamos una nueva, adjuntando el siguiente fragmento de código:

``` python
import "influxdata/influxdb/sample"

sample.data(set: "airSensor")
    |> to(bucket: "ejemplo-sensores-aire")

En las opciones de la tarea, le pondremos un nombre, por ejemplo, Carga de datos sensores de aire y que se ejecute cada 15m (15 minutos).

Inserción de datos¶

InfluxDB admite varios métodos para insertar datos. Lo fundamental es escribirlos en line protocol, un formato de texto específico. Ejemplos de inserción:

Por API HTTP: Es la vía más común. Se envía una petición POST al endpoint /write con el cuerpo en line protocol. Por ejemplo, usando curl:

curl -XPOST 'http://localhost:8086/write?db=miDB' \
     --data-binary 'temperatura,ubicacion=sala valor=22.5 1700000000000000000'

En este ejemplo, temperatura es la medida, ubicacion=sala es una etiqueta, valor=22.5 es el campo, y el último número es el timestamp (epoch en nanosegundos).

Mediante InfluxQL (INSERT): InfluxDB v1.x permite la sentencia SQL-like INSERT. Ejemplo en la consola InfluxQL:

> USE miDB
> INSERT temperatura,ubicacion=oficina valor=21.0 1700003600000000000

Esto escribe un punto idéntico al anterior. La sintaxis es INSERT <medición>,<tag>=<valor_tag> <field>=<valor_field> <timestamp>.

Con clientes o Telegraf: Alternativamente, se puede usar la CLI influx write, o librerías de cliente (Go, Python, etc.), o un agente Telegraf que recolecte y envíe métricas automáticamente. Pero esencialmente siempre se usa line protocol en segundo plano.

InfluxDB ordena los puntos por tiempo y los almacena de forma eficiente. No importa si llegan desordenados o con timestamps pasados; se indexan por tiempo internamente. Al escribir, hay que asegurarse de usar el formato correcto de tiempo (epoch ns o RFC3339) y, en InfluxDB 2.x, especificar el bucket de destino (por API).

Consultas básicas con InfluxQL¶

InfluxQL es un lenguaje similar a SQL adaptado a series temporales. SELECT permite recuperar datos de una medición, usar funciones de agregación (MEAN, SUM, COUNT, etc.) y agrupar por intervalos temporales. Ejemplos:

SELECT simple: Obtener todos los puntos de una medición:

SELECT * FROM "temperatura"

Esto muestra todos los registros, ordenados por tiempo. Para filtrar por tags o tiempo se usa WHERE. Por ejemplo, datos de la ubicación “oficina” después de una fecha:

SELECT * FROM "temperatura"
 WHERE "ubicacion" = 'oficina' AND time >= '2025-05-30T00:00:00Z'

. Las cadenas y nombres de campos/medición van entre comillas dobles.

Funciones agregadas: InfluxQL incluye funciones como MEAN(), MAX(), COUNT(), etc. Se aplican a un campo dentro de un intervalo temporal. Por ejemplo, para obtener la temperatura media:

SELECT MEAN("valor") FROM "temperatura"
 WHERE time >= now() - 24h
 GROUP BY time(1h)

Esto calcula la media de valor por cada hora en el último día. La cláusula GROUP BY time(intervalo) divide los datos en ventanas de tiempo. Por ejemplo, GROUP BY time(30m) agrupa cada media por bloques de 30 minutos. InfluxQL requiere una función de agregación en el SELECT si se agrupa por tiempo.

Filtrado y tags: Se puede agrupar también por tags además del tiempo. Por ejemplo, SELECT COUNT("valor") FROM "sensor" GROUP BY "ubicacion" devuelve el conteo de puntos por cada valor distinto de ubicacion. Se admiten expresiones regulares en WHERE y GROUP BY.
Otras cláusulas: InfluxQL soporta LIMIT, ORDER BY time DESC, GROUP BY fill() (para completar intervalos vacíos), etc. Un ejemplo completo:

SELECT COUNT("valor") 
  FROM "temperatura" 
  WHERE "ubicacion"='sala' AND time > '2025-05-30T00:00:00Z'
  GROUP BY time(10m) fill(previous)

Esto cuenta registros por cada 10 minutos en la sala, rellenando intervalos vacíos con el valor previo.

En general, las consultas InfluxQL siguen la forma SELECT <agregaciones> FROM <medición> [WHERE <condiciones>] [GROUP BY time(<interval>), <tags>]. A los estudiantes familiarizados con SQL les resultará intuitivo, salvo por las funciones temporales y la sintaxis de tags.

Herramientas: Chronograf y la interfaz web¶

Además de la línea de comandos y la API, existen interfaces gráficas para InfluxDB:

InfluxDB UI (2.x): En InfluxDB 2.x se incluye una interfaz web integrada accesible en http://localhost:8086. Permite explorar buckets, escribir consultas (InfluxQL y Flux), visualizar resultados en gráficas y crear dashboards personalizados. Es la herramienta de administración y análisis de InfluxDB 2.x. La documentación oficial indica que esta UI se provee con el servicio y se accede vía navegador.
Chronograf (1.x): Para InfluxDB 1.x existe Chronograf, la interfaz de usuario administrativa del TICK stack. Chronograf permite visualizar datos en tiempo real y crear dashboards de forma sencilla. Incluye plantillas prediseñadas y bibliotecas para gráficos, permitiendo construir y clonar dashboards rápidamente. También ofrece control de usuario, gestión de alertas y administración de clústeres de InfluxDB. En resumen, Chronograf es el front-end de InfluxDB 1.x para monitoreo y visualización.
Otras herramientas: Aunque no se pidió específicamente, es común integrar InfluxDB con Grafana (una plataforma de dashboards muy usada). Sin embargo, con la interfaz propia de InfluxDB o Chronograf ya es posible satisfacer la mayoría de necesidades de consulta y visualización.

InfluxDB y Python¶

El primer paso es instalar la librería influxdb_client:

pip install influxdb_client

Tanto para insertar datos, como para consultarlos, vamos a necesitar conectarnos mediante un cliente y los datos de acceso (url del host, token de acceso y organización). Para ello, crearemos un InfluxDBClient:

from influxdb_client import InfluxDBClient, Point
from influxdb_client.client.write_api import SYNCHRONOUS

# Parámetros de conexión
url = "http://localhost:8086"
token = "mi_token_aquí"
org = "mi_organización"
bucket = "mi_bucket"

# Conexión al cliente
client = InfluxDBClient(url=url, token=token, org=org)

Insertando datos¶

Para insertar un punto de datos, instanciaremos un Point indicando la medida y tantos campos como necesitemos. A continuación, mediante el método write de un WriteApi persistimos el punto y finalmente cerramos la conexión:

# Preparar el punto de datos
punto = Point("temperatura").field("valor", 23.5)

# Enviar el punto
write_api = client.write_api(write_options=SYNCHRONOUS)
write_api.write(bucket=bucket, org=org, record=punto)

# Cerrar conexión
client.close()

Al crear un punto, si queremos indicarle alguna etiqueta o de forma explícita el timestamp, podemos emplear los métodos tag o time respectivamente:

punto = (
    Point("temperatura")
    .tag("ubicacion", "sala1")
    .field("valor", 23.5)
    .time(timestamp)
)

Consultando datos¶

query_api = client.query_api()

consulta = 'from(bucket:"mi_bucket") |> range(start: -1h)'
result = query_api.query(org=org, query=query)

for table in result:
    for record in table.records:
        print(record)

Caso de Uso 1 - Monitorización de temperaturas¶

Supongamos un sistema de monitorización de temperaturas en tres habitaciones (sala, oficina, entrada).

A continuación, vamos a diseñar un medida temperatura para almacenar estos datos con los campos y etiquetas adecuados. Para la ubicación de cada sensor usaremos una etiqueta que llamaremos ubicacion, y un campo valor para almacenar la temperatura.

EL primer paso, es crear el bucket:

CREATE DATABASE iot-pruebas;
USE iot-pruebas;

Y luego insertamos datos, por ejemplo, mediante InfluxQL:

INSERT temperatura, ubicacion=sala valor=21.5 1700000000000000000
INSERT temperatura, ubicacion=oficina valor=22.0 1700000060000000000
INSERT temperatura, ubicacion=entrada valor=19.0 1700000120000000000

Sobre los datos, podríamos realizar diversas consultas:

-- Recuperamos todos los datos
SELECT * FROM "temperatura"

-- Filtramos los datos de la oficina
SELECT "valor" FROM "temperatura" WHERE "ubicacion"='oficina'

-- Calculamos la media por hora
SELECT MEAN("valor") FROM "temperatura"
    WHERE time >= now() - 1h
    GROUP BY time(30m)

Si queremos tener más datos, vamos a simular la inserción de temperaturas cada 10 minutos durante 2 horas en la sala, para luego poder calcula bien la temperatura media en esa sala cada 30 minutos.

Consulta con agregación: Continúa con el ejemplo anterior. Inserta datos de temperatura cada 10 minutos durante 2 horas en la sala, luego calcula la temperatura media en esa sala cada 30 minutos.

Solución:
- Insertar datos de ejemplo: Por brevedad, mostramos unos pocos puntos:
```
INSERT temperatura,ubicacion=sala valor=21.0 1700004000000000000
INSERT temperatura,ubicacion=sala valor=21.2 1700004600000000000
INSERT temperatura,ubicacion=sala valor=21.4 1700005200000000000
... (continuar cada 10 min)
```
* Consulta agregada: Para la media cada 30 minutos:
```
SELECT MEAN("valor") FROM "temperatura"
  WHERE "ubicacion"='sala' AND time >= '2025-05-30T14:00:00Z'
  GROUP BY time(30m)
```
Esto agrupa los datos en intervalos de 30 minutos y calcula la media de valor. El resultado mostrará, por cada intervalo de media hora, el valor medio de temperatura en la sala. (InfluxDB rellenará los intervalos sin datos según la opción fill() por defecto).

Uso de la interfaz web: Usando la interfaz gráfica (InfluxDB UI o Chronograf), crea un panel que muestre la temperatura en tiempo real.

Solución:
- Ingresar a http://localhost:8086 en el navegador e iniciar sesión.
- En InfluxDB 2.x, crear un dashboard nuevo. Añadir un Panel de gráfico. Configurar la consulta InfluxQL o Flux para graficar SELECT "valor" FROM "temperatura". Establecer el rango de tiempo deseado (p. ej. últimos 15 minutos, 1 hora, etc.).
- En Chronograf (InfluxDB 1.x), ir a la pestaña “Data Explorer”. Seleccionar la base de datos y la medición. Escribir la consulta o usar la interfaz asistida (SELECT valor FROM temperatura). Visualizar la línea de tiempo y opcionalmente guardar la consulta como parte de un dashboard.
- Así se obtiene un gráfico en tiempo real de las temperaturas, actualizándose conforme entran nuevos datos.

Comparación de etiquetas y campos: (Ejercicio conceptual) ¿Por qué no conviene usar la temperatura como tag en el ejemplo anterior? ¿Qué pasaría si lo hiciéramos?

Solución:
- En InfluxDB, los tags deben ser valores que cambian poco y que se usan para filtrar o agrupar. Si la temperatura la marcamos como tag, cada valor distinto crearía una nueva serie, lo cual aumenta la cardinalidad. Además, InfluxDB indexa los tags, lo que consumiría más memoria. Por otro lado, los fields no se indexan, por lo que filtrar por valor requiere escanear los datos, pero no impacta el almacenamiento.
- En este caso, la temperatura varía constantemente (cada punto casi siempre tiene un valor distinto), por lo que usarla como tag crearía un enorme número de series únicas y ralentizaría el sistema. Es mejor dejar valor como field.

Estos ejercicios ilustran cómo diseñar el esquema y ejecutar operaciones básicas en InfluxDB. Con práctica se adquiere destreza usando InfluxQL y las herramientas de InfluxData para proyectos de monitoreo, IoT o análisis de series temporales.

Fuentes: Documentación oficial de InfluxDB y comparativas InfluxDB vs SQL/MongoDB para conceptos de base de datos de series temporales. También se citaron guías de inserción y consulta de InfluxData.

MQTT¶

Es un protocolo de conectividad máquina máquina (M2M) / “internet de las cosas”. Fue diseñado como un transporte de mensajes de publicación / suscripción extremadamente ligero. Es útil para conexiones con ubicaciones remotas donde se requiere una pequeña huella de código y/o el ancho de banda de la red es muy importante.

¿Por qué protocolo MQTT?

MQTT (Message Queuing Telemetry Transport) es un protocolo de mensajería ligero y eficiente diseñado para situaciones donde la red puede ser inestable o los dispositivos tienen recursos limitados. Un broker MQTT es un intermediario central que facilita la comunicación entre los dispositivos que utilizan este protocolo. Funciona recibiendo mensajes de un dispositivo y entregándolos a los dispositivos de destino.

El protocolo MQTT se ha convertido en un estándar para la transmisión de datos de IoT, ya que ofrece los siguientes beneficios:

Ligero y eficiente

La implementación de MQTT en el dispositivo IoT requiere recursos mínimos, por lo que se puede usar incluso en pequeños microcontroladores. Por ejemplo, un mensaje de control MQTT mínimo puede tener tan solo dos bytes de datos. Los encabezados de los mensajes MQTT también son pequeños para poder optimizar el ancho de banda de la red.

Escalable

La implementación de MQTT requiere una cantidad mínima de código que consume muy poca energía en las operaciones. El protocolo también tiene funciones integradas para admitir la comunicación con una gran cantidad de dispositivos IoT. Por tanto, puede implementar el protocolo MQTT para conectarse con millones de estos dispositivos.

Fiable

Muchos dispositivos IoT se conectan a través de redes celulares poco fiables con bajo ancho de banda y alta latencia. MQTT tiene funciones integradas que reducen el tiempo que tarda el dispositivo IoT en volver a conectarse con la nube. También define tres niveles diferentes de calidad de servicio a fin de garantizar la fiabilidad para los casos de uso de IoT: como máximo una vez (0), al menos una vez (1) y exactamente una vez (2).

Seguro

MQTT facilita a los desarrolladores el cifrado de mensajes y la autenticación de dispositivos y usuarios mediante protocolos de autenticación modernos, como OAuth, TLS1.3, certificados administrados por el cliente, etc.

Admitido

Varios lenguajes, como Python, tienen un amplio soporte para la implementación del protocolo MQTT. Por lo tanto, los desarrolladores pueden implementar rápidamente con una codificación mínima en cualquier tipo de aplicación.

¿Cómo funciona MQTT?

A finales de los 90 IBM desarrolló el protocolo para vincular sensores de oleoductos con satélites. El propósito era enviar mensajeria de forma asíncrona entre sensores y satélites.

En el 2014 el protocolo MQTT se libera dando aportes significativos en la comunidad científica y tecnológica.

MQTT es un protocolo que necesita el STACK TCP/IP, en otras palabras necesita que el sistema ya esté conectado a internet para funciona.

En un sistema MQTT, los dispositivos pueden actuar como publicadores (enviando mensajes) o suscriptores (recibiendo mensajes). El broker es responsable de gestionar la entrega de estos mensajes, asegurando que los suscriptores reciban la información que desean.

Influx vs SQL vs Mongod¶

Comparación con SQL: En InfluxDB las mediciones (measurements) son análogas a las tablas SQL, pero el índice principal siempre es el tiempo. Los tags son pares clave-valor indexados (como columnas con índice), mientras que los fields son datos propiamente dichos sin índice (como columnas sin índice). No hay soporte para operaciones avanzadas de SQL como JOIN o HAVING. InfluxDB es “schemaless” (esquema flexible): puede agregar nuevas mediciones, tags o fields en cualquier momento sin migraciones costosas. En resumen, InfluxDB maneja grandes volúmenes de datos temporales más rápido que una base relacional, pero renuncia a funciones como relaciones complejas por tabla, priorizando la eficiencia temporal.
Comparación con MongoDB: InfluxDB está especializado en datos de series temporales, mientras que MongoDB es una base de datos de documentos genérica. InfluxDB sobresale en escenarios de alta escritura continua de datos etiquetados en el tiempo, y permite consultas rápidas tras la inserción. MongoDB, por su parte, almacena documentos JSON flexibles (sin esquema fijo) y admite índices de tiempo a través de funcionalidades como colecciones de series temporales o índices TTL, pero no está optimizado desde su núcleo para análisis de series temporales. Como resumen: InfluxDB ofrece alto rendimiento y compresión para métricas o eventos con marcas de tiempo, mientras que MongoDB ofrece flexibilidad de esquema y escalabilidad horizontal para datos generales.

InfluxDB y NodeRed¶

Para instalar InfluxDB desde Docker, ejecutaremos el siguiente comando que creará al usuario iabd, con contraseña IABDs8a. dentro de la organización s8a y un bucket inicial al que hemos llamado h2v.

docker run --name influxdb -d -p 8086:8086 -v "./data:/var/lib/influxdb2" -v "./config:/etc/influxdb2" -e DOCKER_INFLUXDB_INIT_MODE=setup -e DOCKER_INFLUXDB_INIT_USERNAME=iabd -e DOCKER_INFLUXDB_INIT_PASSWORD=IABDs8a. -e DOCKER_INFLUXDB_INIT_ORG=s8a -e DOCKER_INFLUXDB_INIT_BUCKET=h2v influxdb

Para acceder a InfluxDB desde NodeRed, desde la paleta usaremos el conector contrib

Referencias¶

Conectando NodeRed con InfluxDB