TimescaleDB : stocker et analyser vos métriques d'infrastructure

Vous exploitez une infrastructure cloud ou on-premise ? Vous collectez déjà des millions de métriques par jour via Prometheus, collectd ou des agents propriétaires ? Alors vous connaissez le problème : stockage massif, requêtes lentes, rétention des données coûteuse.

Les bases de données relationnelles classiques ne sont pas faites pour ça. C'est pourquoi les bases de données time-series existent. Et parmi les meilleures, TimescaleDB se démarque : c'est une extension PostgreSQL qui transforme votre DB favorite en machine de guerre pour les métriques.

Cet article explore comment déployer, configurer et optimiser TimescaleDB pour un monitoring infrastructure professionnel — que vous soyez sysadmin, DevOps ou CTO responsable de la scalabilité.

• Pourquoi une base time-series ? Limitations des DB relationnelles, débit d'écriture, compression.
• Architecture TimescaleDB : concepts clés, hypertables, chunks, compatibilité SQL.
• Installation et configuration : Debian/Ubuntu, extension, tuning.
• Hypertables et partitionnement : création, intervalles, stratégies d'optimisation.
• Compression native : algorithmes, politiques, benchmarks.
• Continuous aggregates : pré-calcul de métriques, refresh automatique.
• Rétention de données : politiques de suppression, tiered storage.
• Intégration Grafana : configuration, dashboards, alerting.
• TimescaleDB vs alternatives : comparaison avec InfluxDB, VictoriaMetrics, Prometheus.
• Perspectives complémentaires : articles connexes.

Une requête SQL classique sur PostgreSQL avec 100 millions de lignes prend des secondes. Agrémentez ça de billions de points en production, et votre infrastructure gémit.

Les limites des DB relationnelles

• Débit d'écriture : insertion de millions de rows/sec → index saturés, IO bloquée.
• Indexation : les index B-tree standard ne sont pas pensés pour du sequential time-ordered data.
• Compression : une colonne BIGINT occupe 8 bytes, même pour 1M de valeurs consécutives. Les time-series aiment les séquences compressibles.
• Rétention : supprimer 3 mois de données dans une table de 10 milliards de lignes ? Faut bloquer pendant 2 heures.

Pourquoi TimescaleDB ?

TimescaleDB résout ça en natif :

• Débit : millions de métriques/sec sur du matériel raisonnablement dimensionné.
• Compression : réduction de 90-95% de l'espace disque après compression.
• Requêtes rapides : queries optimisées pour le time-series, avec des algorithmes vectorisés.
• Rétention facile : suppression de chunks complets en microsecondes.

TimescaleDB repose sur une idée simple : partitionnement automatique par hypertables.

Hypertables

Une hypertable est une table logique distribuée virtuellement sur plusieurs chunks physiques. Chaque chunk couvre une plage de temps — par défaut, 7 jours.

CREATE TABLE metrics (
  time TIMESTAMPTZ NOT NULL,
  host TEXT NOT NULL,
  metric_name TEXT NOT NULL,
  value DOUBLE PRECISION,
  PRIMARY KEY (time, host, metric_name)
);

SELECT create_hypertable('metrics', 'time', if_not_exists => TRUE);

Derrière, TimescaleDB a créé :

• Un chunk pour 2026-03-01 à 2026-03-08
• Un chunk pour 2026-03-08 à 2026-03-15
• Etc.

Chunks

Les chunks sont des segments time-ordered où les données réelles résident. À l'insertion, TimescaleDB route automatiquement vers le bon chunk. À la suppression, il peut virer un chunk complet sans scanner la table.

Compatibilité SQL

Ici, le génie : TimescaleDB reste 100% compatible PostgreSQL. Votre requête SQL fonctionne, vos outils (DBeaver, psql, Grafana) fonctionnent. Zéro breaking change.

Debian/Ubuntu

# Ajouter le repo Timescale
apt-get install -y postgresql-common
echo "deb https://packagecloud.io/timescale/timescaledb/debian/ $(lsb_release -c -s) main" > /etc/apt/sources.list.d/timescaledb.list
wget --quiet -O - https://packagecloud.io/timescale/timescaledb/gpgkey | apt-key add -

# Installer
apt-get update
apt-get install -y timescaledb-2-postgresql-16

Activation extension

sudo -u postgres psql

CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;
\dx  -- vérifier

Tuning pour time-series

Éditez /etc/postgresql/16/main/postgresql.conf :

# Dédié au time-series
shared_buffers = 8GB                    # 25% RAM
effective_cache_size = 24GB             # 75% RAM
maintenance_work_mem = 2GB
work_mem = 256MB
random_page_cost = 1.1                  # SSD
max_wal_size = 2GB
max_parallel_workers_per_gather = 4
max_worker_processes = 8

# TimescaleDB spécifique
timescaledb.telemetry_level = 'basic'
timescaledb.max_background_workers = 4

Intervalle de chunk

Par défaut : 7 jours. Pour du high-frequency (millions/sec), réduisez à 1-2 jours :

-- À création
SELECT create_hypertable('metrics', 'time', chunk_time_interval => INTERVAL '1 day');

-- Ou modifier après
SELECT set_chunk_time_interval('metrics', INTERVAL '1 day');

Space partitioning

Vous avez 100+ hosts ? Ajoutez une dimension discrète (par ex. host) :

SELECT create_hypertable(
  'metrics',
  'time',
  'host',                           -- space dimension
  number_partitions => 16,          -- nombre de partitions
  if_not_exists => TRUE
);

Les données pour host='web-01' et host='web-02' ne se côtoient jamais, améliore la locality.

Comprimer un chunk

-- Manuellement
SELECT compress_chunk('_timescaledb_internal._hyper_1_1_chunk');

-- Ou via politique
ALTER TABLE metrics SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'host,metric_name',
  timescaledb.compress_orderby = 'time DESC'
);

Politique de compression automatique

SELECT add_compression_policy(
  'metrics',
  INTERVAL '7 days'  -- compresser les chunks > 7j
);

Résultats

En production, on voit réduction de 90-95% de l'espace disque après compression. Une semaine de métriques pour 500 hosts : 2 GB avant, 150 MB après.

Calculer la moyenne horaire de CPU pour 1000 hosts est coûteux à chaque requête. Continuous aggregates précalcule et rafraîchit continuellement :

CREATE MATERIALIZED VIEW metrics_1h
WITH (timescaledb.continuous) AS
SELECT time_bucket(INTERVAL '1 hour', time) as bucket,
       host,
       AVG(value) as avg_value,
       MAX(value) as max_value
FROM metrics
GROUP BY bucket, host;

-- Rafraîchissement automatique
SELECT add_continuous_aggregate_policy(
  'metrics_1h',
  start_offset => INTERVAL '2 hours',
  end_offset => INTERVAL '1 hour',
  schedule_interval => INTERVAL '1 hour'
);

Requête sur metrics_1h : ~100x plus rapide.

Politiques de suppression automatique

SELECT add_retention_policy(
  'metrics',
  INTERVAL '90 days'  -- supprimer les chunks > 90j
);

Derrière, TimescaleDB supprime les chunks complets sans scanner : des milliers de suppression par seconde.

Tiered storage

Pour les anciennes données moins critiques :

1. Compresser les chunks > 30j
2. Archiver les compressés vers S3 (via extension TimescaleDB Cloud)
3. Supprimer après 180j

Data source PostgreSQL

Dans Grafana > Data Sources :

1. Type : PostgreSQL
2. Host : timescaledb.internal:5432
3. Database : monitoring
4. User : grafana_ro (lecture seule)

Requête exemple

SELECT
  time,
  host,
  AVG(value) as cpu_usage
FROM metrics
WHERE metric_name = 'cpu_usage'
  AND time > now() - INTERVAL '24 hours'
GROUP BY time_bucket(INTERVAL '5 minutes', time), host
ORDER BY time

Variables Grafana

Label: Host
Query: SELECT DISTINCT host FROM metrics ORDER BY host

Alerting

Grafana alert rule :

WHEN metrics_1h.avg_value > 80 FOR 5m THEN ALERT

Conclusion : TimescaleDB brille si vous voulez PostgreSQL + compression + SQL analytique. VictoriaMetrics gagne sur la performance brute. InfluxDB sur la facilité initiale.

Pour compléter une stack monitoring :

• Prometheus et Grafana : une fondation solide — intégration TimescaleDB via Prometheus Remote Write.
• Déployer une stack monitoring moderne — architecture end-to-end.
• PostgreSQL : optimiser les performances en production — tuning approfondi.
• Grafana Tempo et le distributed tracing (2026) — traçage distribué complémentaire.

Chez SHPV (infrastructure IT depuis 2012), nous exploitons TimescaleDB pour le monitoring de notre backbone (AS41652, 150 Gbps) et de nos services. Avec un SLA > 99.9%, il n'y a pas de place pour l'approximation.

TimescaleDB nous permet de :

• Ingérer 15 millions de métriques/minute (CPU, mémoire, réseau, disque sur 500+ machines)
• Compresser à ~100 MB/jour au lieu de 10 GB
• Rejouer les métriques en moins de 500 ms même sur 90 jours
• Alerter en temps réel via Grafana + continuous aggregates

La maintenance PostgreSQL qu'on connaît déjà ? Elle s'applique. Les backups, la réplication, les outils DBA : tout ça fonctionne.

TimescaleDB n'est pas une balle magique, mais c'est une solution pragmatique et puissante pour le monitoring infrastructure. PostgreSQL sous le capot signifie :

• Compatibilité SQL totale
• Écosystème mature (backups, réplication, outils)
• Coût d'infrastructure réduit

Déployez une hypertable, laissez la compression tourner, connectez Grafana, et vous avez une base de 10 ans qui grandit sans sueur.

• TimescaleDB Official Documentation — référence complète.
• TimescaleDB vs InfluxDB : benchmark 2025 — comparaison détaillée.
• PostgreSQL Documentation — tuning et features.
• Grafana Datasource Integration — configuration.
• Prometheus Remote Write Best Practices — intégration temps réel.