DBAtlas · Atlas d'exploitation des bases de données

Données de séries temporelles

Oracle

-- Range partitioning by date:
CREATE TABLE measurements (
  ts TIMESTAMP, sensor_id NUMBER, value NUMBER)
PARTITION BY RANGE (ts)
INTERVAL (NUMTODSINTERVAL(1,'DAY'))
( PARTITION p0 VALUES LESS THAN (TIMESTAMP '2026-01-01 00:00:00') );

Dans Oracle, les séries temporelles sont généralement gérées avec un partitionnement RANGE (INTERVAL) ; les nouvelles partitions sont créées automatiquement et les anciennes facilement supprimées (le partition pruning accélère les requêtes). La compression (ILM/ADO) et les vues matérialisées pour l'agrégation sont aussi utilisées.

PostgreSQL

-- Hypertable with the TimescaleDB extension:
CREATE EXTENSION IF NOT EXISTS timescaledb;
CREATE TABLE measurements (ts TIMESTAMPTZ, sensor_id INT, value DOUBLE PRECISION);
SELECT create_hypertable('measurements', 'ts');
-- Summarize with a continuous aggregate.

PostgreSQL peut héberger des séries temporelles avec le partitionnement natif (PARTITION BY RANGE) ; l'extension TimescaleDB ajoute les hypertables avec découpage automatique par temps (chunks), compression, politiques de rétention et continuous aggregates. C'est une solution courante pour les grosses charges IoT/métriques.

MySQL

-- RANGE partitioning by date:
CREATE TABLE measurements (
  ts DATETIME, sensor_id INT, value DOUBLE,
  PRIMARY KEY (ts, sensor_id))
PARTITION BY RANGE (TO_DAYS(ts)) (
  PARTITION p2026_01 VALUES LESS THAN (TO_DAYS('2026-02-01')),
  PARTITION pmax VALUES LESS THAN MAXVALUE);

MySQL n'offre pas de moteur dédié aux séries temporelles ; le partitionnement RANGE (avec TO_DAYS/UNIX_TIMESTAMP) permet de supprimer rapidement les anciennes données et le partition pruning. Pour les séries temporelles à fort volume, on préfère généralement des solutions externes (TimescaleDB, InfluxDB) ou des tables de synthèse.

SQL Server

-- Partitioned table (partition function + scheme) or
-- system-versioned temporal table (history kept automatically):
CREATE TABLE dbo.measurements (
  id INT PRIMARY KEY, value DECIMAL(10,2),
  valid_from DATETIME2 GENERATED ALWAYS AS ROW START,
  valid_to DATETIME2 GENERATED ALWAYS AS ROW END,
  PERIOD FOR SYSTEM_TIME (valid_from, valid_to))
WITH (SYSTEM_VERSIONING = ON);

SQL Server gère les séries temporelles par partitionnement avec une partition function/scheme ; cela apporte le pruning et un archivage rapide pour les données couvrant de larges plages de dates. En outre, les tables temporelles system-versioned (SYSTEM_VERSIONING) conservent automatiquement l'historique des modifications de lignes et permettent l'interrogation à un instant donné (FOR SYSTEM_TIME).

MongoDB

// Time-series collection (MongoDB 5.0+):
db.createCollection("measurements", {
  timeseries: {
    timeField: "ts",
    metaField: "sensor_id",
    granularity: "seconds"
  }
})

Les collections time-series, introduites dans MongoDB 5.0, stockent automatiquement les données dans un format compressé de type colonne (par buckets) selon le temps et le champ meta ; elles réduisent l'utilisation du disque et des index et accélèrent les requêtes par plage. timeField est obligatoire ; metaField (source/tag) et granularity déterminent les performances.

Redis

# Requires the RedisTimeSeries module (Redis Stack).
# Create a series with a retention period:
TS.CREATE sensor:1 RETENTION 86400000 LABELS type temperature
# Add a sample (with an automatic timestamp):
TS.ADD sensor:1 * 23.5

Redis de base n'a pas de type série temporelle ; le module RedisTimeSeries (Redis Stack) fournit l'ingestion rapide d'échantillons avec TS.CREATE/TS.ADD, la rétention automatique (RETENTION), le sous-échantillonnage (TS.CREATERULE) et les requêtes par plage basées sur des labels avec TS.RANGE/TS.MRANGE. Sans le module, on l'émule avec un Sorted Set.

Elasticsearch

# Data stream: automatically rolling indexes for time series
PUT _index_template/measurements-tpl
{ "index_patterns": ["measurements*"], "data_stream": {},
  "template": {
    "settings": { "index.mode": "time_series", "index.routing_path": ["sensor_id"] },
    "mappings": { "properties": {
      "@timestamp": { "type": "date" },
      "sensor_id": { "type": "keyword", "time_series_dimension": true },
      "temperature": { "type": "double", "time_series_metric": "gauge" } } } } }
PUT _data_stream/measurements

Elasticsearch gère les séries temporelles avec les data streams ; de nouveaux backing indexes sont créés automatiquement au fil du temps (rollover), et ILM fait passer les anciennes données par les tiers hot/warm/cold puis les supprime. TSDS (index.mode: time_series) fournit des optimisations de stockage propres aux métriques ; au moins un champ time_series_dimension, un index.routing_path pointant vers lui et un champ @timestamp sont obligatoires (sinon le template est rejeté).

Ouvrir dans DBAtlas →