Zeitreihendaten

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') );

In Oracle werden Zeitreihendaten meist mit RANGE-(INTERVAL-)Partitionierung verwaltet; neue Partitionen entstehen automatisch, alte lassen sich einfach löschen (Partition Pruning beschleunigt Abfragen). Auch Kompression (ILM/ADO) und Materialized Views zur Aggregation werden genutzt.

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 kann Zeitreihen mit nativer Partitionierung (PARTITION BY RANGE) halten; die Extension TimescaleDB ergänzt Hypertables mit automatischem zeitbasiertem Chunking, Kompression, Retention Policies und Continuous Aggregates. Sie ist eine gängige Lösung für große IoT-/Metrik-Workloads.

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 bietet keine dedizierte Zeitreihen-Engine; RANGE-Partitionierung (mit TO_DAYS/UNIX_TIMESTAMP) ermöglicht schnelles Löschen alter Daten und Partition Pruning. Für Zeitreihen mit hohem Volumen werden meist externe Lösungen (TimescaleDB, InfluxDB) oder Summentabellen bevorzugt.

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 verwaltet Zeitreihen per Partitionierung mit Partition Function/Scheme; das bietet Pruning und schnelle Archivierung für Daten über große Zeiträume. Zusätzlich halten systemversionierte temporale Tabellen (SYSTEM_VERSIONING) die Änderungshistorie der Zeilen automatisch fest und erlauben Abfragen zu einem Zeitpunkt (FOR SYSTEM_TIME).

MongoDB

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

Die in MongoDB 5.0 eingeführten Time-Series Collections speichern Daten automatisch in einem komprimierten, spaltenähnlichen (gebucketten) Format nach Zeit- und Metafeld; sie verringern Platten- und Indexnutzung und beschleunigen Bereichsabfragen. timeField ist Pflicht; metaField (Quelle/Tag) und granularity bestimmen die Performance.

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

Core Redis hat keinen Zeitreihentyp; das Modul RedisTimeSeries (Redis Stack) bietet schnelle Erfassung von Messwerten mit TS.CREATE/TS.ADD, automatische Aufbewahrung (RETENTION), Downsampling (TS.CREATERULE) und labelbasierte Bereichsabfragen mit TS.RANGE/TS.MRANGE. Ohne das Modul wird es mit einem Sorted Set nachgebildet.

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 verwaltet Zeitreihendaten mit Data Streams; neue Backing Indices entstehen im Zeitverlauf automatisch (Rollover), und ILM verschiebt alte Daten durch die Tiers hot/warm/cold und löscht sie. TSDS (index.mode: time_series) bietet Speicheroptimierungen speziell für Metrikdaten; mindestens ein Feld time_series_dimension, ein darauf zeigender index.routing_path und ein Feld @timestamp sind Pflicht (sonst wird das Template abgelehnt).

In DBAtlas öffnen →