TimescaleDB compresse 98% de tes données temps réel

Pourquoi PostgreSQL échoue sur la compression temps réel

PostgreSQL a TOAST : tu stockes une longue chaîne, elle dépasse 2 Ko, PostgreSQL la compresse avec pglz. Pratique pour les textes longs — zéro efficacité sur les floats de température ou les horodatages réguliers. TimescaleDB résout un problème différent : compresser des motifs inter-lignes (d'une ligne à l'autre), pas des valeurs individuelles.

Comparaison concrète :

• ▸Colonne float (capteur temp) : PostgreSQL = 1.0× (aucune compression), TimescaleDB = 10-20× grâce au XOR
• ▸Colonne horodatage : PostgreSQL = 1.0× (type fixe), TimescaleDB = 50-100× grâce au delta-of-delta
• ▸Colonne texte statique (type capteur) : PostgreSQL = 2-3×, TimescaleDB = 5-10× avec dictionnaire + RLE

Comment l'hypercore transforme tes données

TimescaleDB fonctionne en deux phases :

1. ▸Données récentes : insérées en format ligne (écritures rapides) dans des chunks PostgreSQL standard
2. ▸Données anciennes : converties automatiquement en format colonnaire comprimé (dès qu'elles dépassent l'âge configuré)

Une fois en colonnaire, tes 1000 lignes deviennent 1 seule ligne où chaque colonne est un tableau comprimé. Les requêtes lisent uniquement les colonnes utiles au lieu de parcourir tous les champs.

Maths réelles : delta encoding en action

Ton capteur envoie toutes les 5 secondes :

time        value
12:00:00    72.5
12:00:05    72.7  (+0.2)
12:00:10    72.4  (-0.3)
12:00:15    72.6  (+0.2)

Au lieu de stocker 72.5, 72.7, 72.4, 72.6, tu stockes 72.5, +0.2, -0.3, +0.2 : des petits nombres négatifs/positifs. Avec le delta-of-delta (différence de la différence), si l'intervalle est régulier, tu obtiens souvent 0 — codé en 2-3 bits au lieu de 32 bits.

Run-length encoding : le secret des colonnes répétitives

Ton machine_id c'est MACHINE_001 sur 5000 lignes consécutives ?

Avant : 55 Ko (5000 × 11 caractères) Après : 15 octets (MACHINE_001 × 5000)

TimescaleDB détecte automatiquement ces répétitions par colonne — pas besoin de configuration.

XOR pour les floats sans delta

Deux capteurs de vibration : 2.0487 et 2.0491. Représentation binaire en IEEE 754 :

2.0487 = 0100000000000001010001...
2.0491 = 0100000000000001010010...
XOR    = 0000000000000000000011...

Beaucoup de zéros au début et à la fin : tu ne stockes que les bits « significatifs » du milieu. Gorilla (l'algorithme de Facebook pour leurs séries) fonctionne exactement comme ça.

Configuration : activer la compression

TimescaleDB choisit automatiquement l'algorithme selon le type de colonne. Mais tu configures quand compresser :

ALTER TABLE ma_table SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'machine_id',
  timescaledb.compress_orderby = 'time DESC'
);

SELECT compress_chunk(chunk) FROM show_chunks('ma_table')
WHERE chunk_time < now() - INTERVAL '7 days';

Résultat : les données de plus de 7 jours se compressent. Les requêtes récentes restent rapides (format ligne). Les requêtes analytiques sur l'historique lisent moins de données.

À retenir

TimescaleDB ne rivalise pas avec PostgreSQL TOAST — il résout un problème différent. Ses gains (10-100×) viennent de l'exploitation de la structure propre aux séries temporelles : deltas réguliers, colonnes répétitives, floats proches les uns des autres. Si tu enregistres des millions de lignes capteur, le retour sur investissement est massif : stockage divisé par 10, performances analytiques améliorées, facture cloud réduite d'autant.