pg_timeseries: Open-Source-Erweiterung für Zeitreihen in PostgreSQL

Was sind Zeitreihendaten?

• Zeitreihendaten sind eine Sammlung von Datenpunkten, bei denen jeder Datenpunkt mit einem Zeitstempel versehen ist
• Beispiele: Aktienkurse, von Geräten und Sensoren zurückgegebene Temperatur- und Verfügbarkeitsdaten, Traffic-Daten von Websites
• Zeitreihen-Workloads umfassen in der Regel zeitbasierte Filterabfragen und Aggregationsabfragen zur Datenzusammenfassung

Zeitreihen mit PostgreSQL verarbeiten

• PostgreSQL kann dank seiner Erweiterbarkeit und seines Ökosystems alle Daten-Workloads bewältigen
• Tembo hat sich zum Ziel gesetzt, es Nutzern leicht zu machen, das PostgreSQL-Ökosystem zu verwenden
• Die größte Anforderung der Kunden war ein Stack zum Speichern und Verarbeiten von Zeitreihendaten

Komponenten von pg_timeseries

• Anforderungen für die effiziente Speicherung und Abfrage von Zeitreihendaten:
  • Zeitreihendaten einfach verwalten
  • Hohen Durchsatz bewältigen
  • Schnell auf Bereichsabfragen reagieren
  • Große Datenmengen effizient speichern
  • Komplexe Analysefunktionen ausführen
• Grundlegende Funktionen von PostgreSQL:
  • Native Partitionierung, verschiedene Indizes, materialisierte Views, Window-/Analysefunktionen
• Zusätzliche Erweiterungen:
  • pg_partman: Partitionsverwaltung
  • pg_cron: Job-Scheduling
  • columnar: Komprimierung
  • pg_ivm: inkrementelle materialisierte Views
  • pg_tier: langfristiges Offloading älterer Partitionen

pg_timeseries: Der einfachste Weg, Zeitreihendaten in PostgreSQL zu verwalten

• pg_timeseries kombiniert die Funktionen mehrerer Erweiterungen und bietet eine einheitliche Schnittstelle
• Für den Einstieg wird eine nach einer zeitbezogenen Spalte partitionierte Tabelle benötigt

  CREATE TABLE measurements (  
    metric_name text,  
    metric_value numeric,  
    metric_time timestamptz NOT NULL  
  ) PARTITION BY RANGE (metric_time);  
  
  SELECT enable_ts_table('measurements');  
  

• Enthält verschiedene Views, die wichtige Informationen bereitstellen:

  SELECT table_id, table_size_bytes FROM ts_table_info;  
  SELECT * FROM ts_part_info;  
  

• Es lassen sich Richtlinien für Komprimierung und Löschung von Partitionen festlegen:

  SELECT set_ts_compression_policy('measurements', '90 days');  
  SELECT set_ts_retention_policy('measurements', '365 days');  
  

• Zusätzliche Funktionen verfügbar:

  SELECT  
    locf(avg(metric_value)) OVER (ORDER BY metric_time) avg_val,  
    last(metric_name, metric_value) highest,  
    metric_time  
  FROM date_bin_table(NULL::measurements, '1 hour', '[2024-05-09,2024-06-07]');  
  

Wir stehen erst am Anfang

• Für den Aufbau einer Zeitreihen-Erweiterung für PostgreSQL werden viele Komponenten benötigt
• Es ist geplant, sie gemeinsam mit der Community offen zu entwickeln
• Aktuelle Roadmap:
  • Auslagerung älterer Partitionen in Cold Storage wie S3
  • Approximationsfunktionen für effiziente Analysen
  • Inkrementelle materialisierte Views
  • Rollup und Roll-off älterer Partitionen
  • Zusätzliche Analyse-Hilfsfunktionen
• Die vollständige Roadmap steht im GitHub-README, und die Priorisierung der Funktionen erfolgt nach Nutzernachfrage

Meinung von GN⁺

• Bedeutung von Zeitreihendaten: In verschiedenen Bereichen wie IoT, Finanzen und Webanalyse nimmt die Bedeutung von Zeitreihendaten zu. pg_timeseries bietet ein Werkzeug, um diese Daten effizient zu verwalten.
• Erweiterbarkeit von PostgreSQL: Durch die Erweiterungsfunktionen von PostgreSQL lassen sich verschiedenste Daten-Workloads verarbeiten. pg_timeseries integriert diese Erweiterungen und erhöht so den Bedienkomfort für Nutzer.
• Zusammenarbeit mit der Community: Die Entwicklung als Open Source ermöglicht es, Feedback aus der Community einfließen zu lassen. Das hilft erheblich bei Funktionsverbesserungen und Fehlerbehebungen.
• Konkurrenzprodukte: Im Vergleich zu anderen Zeitreihen-Datenbanken wie TimescaleDB bietet es den Vorteil, ohne Lizenzbeschränkungen nutzbar zu sein. Allerdings sind Vergleiche bei Performance und Funktionsumfang erforderlich.
• Aspekte bei der Einführung: Bei der Einführung von pg_timeseries sollten die Kompatibilität mit bestehenden Datenbanken, die Performance und die Wartungskosten berücksichtigt werden. Außerdem ist wegen der Natur von Zeitreihendaten ein geeignetes Storage-Management nötig, da das Datenvolumen stark ansteigen kann.

[GN⁺]

Hacker-News-Diskussion

Zusammenfassung ausgewählter Hacker-News-Kommentare

• Inkrementelle materialisierte Views

  • Inkrementelle materialisierte Views sind die Kernfunktion und können ohne Leistungseinbußen aktuell gehalten werden, wenn neue Daten eingehen.
  • Es stellt sich die Frage, ob dafür eine Implementierung wie pg_ivm genutzt wird oder ob es eigenständig umgesetzt ist.
  • Die Hoffnung besteht, dass ivm irgendwann in den PostgreSQL-Core aufgenommen wird.

• Vergleich mit TimescaleDB

  • Aufgrund der Lizenzbeschränkungen von TimescaleDB können Funktionen wie Komprimierung, inkrementelle materialisierte Views und unbegrenzter Storage nicht genutzt werden.
  • Ohne diese Funktionen, so die Einschätzung, lassen sich die Anforderungen von Kunden an Zeitreihendaten nicht erfüllen, weshalb eine Erweiterung unter PostgreSQL-Lizenz direkt selbst entwickelt wurde.
  • Es gibt Erfahrung damit, mit der kostenlosen Version von TimescaleDB eine Datenbank mit 500 Millionen Beobachtungen zu sharden. Das funktionierte ohne größere Probleme.
  • Benchmarks und Vergleichsergebnisse wären wünschenswert. Das wird weiter beobachtet.

• Append-Only-Tabellen

  • Es sei an der Zeit, dass PostgreSQL und andere Datenbanken native Append-Only-Tabellen bekommen.
  • Das sei zwar keine Zeitreihendatenbank, würde aber für Logik und Vorgehensweisen rund um Standardisierung hilfreich sein.

• Die Entwicklung von Zeitreihendatenbanken

  • Zeitreihendatenbanken entwickeln sich derzeit in folgende Richtungen:
    • Konvergenz hin zu spaltenorientiertem Storage und offenen Formaten wie Parquet und Arrow: InfluxDB 3.0, QuestDB
    • Hinzufügen von Zeitreihenfunktionen auf PostgreSQL: Timescale, pg_timeseries
    • Observability-Plattformen rund um das Prometheus-Ökosystem: Grafana, Victoria Metrics, Chronosphere

• Die Notwendigkeit von spaltenorientiertem Storage

  • Die meisten Zeitreihenabfragen sind Aggregationsabfragen.
  • Dafür ist es sinnvoll, erstklassigen spaltenorientierten Storage zu nutzen oder selbst aufzubauen.
  • Es wird hinterfragt, warum es so etwas wie ClickHouse nicht für PostgreSQL gibt.

• Nützliche Links

  • Dank dafür, auf Trunk und pgt.dev aufmerksam geworden zu sein.

• Load-Balancer-Logeinträge

  • Es stellt sich die Frage, ob diese Erweiterung nützlich wäre, um Load-Balancer-Logeinträge zu verarbeiten (Status, Response-Body, Header usw.).
  • Spaltenorientierter Datenbank-Storage dürfte dafür effizienter sein als eine klassische zeilenbasierte Datenbank.
  • Load-Balancer-Logeinträge könnten ähnlich wie Analyse-Events betrachtet werden.

• Open-Source-Innovation

  • PostgreSQL war schon immer Open Source und hat sehr freizügige Open-Source-Libraries genutzt.
  • Von Replikation bis Zeitreihen-Support gab es verschiedenste proprietäre und source-available Erweiterungen.
  • Nun werden diese proprietären Erweiterungen durch passende Open-Source-Alternativen unter Druck gesetzt.

• PostgreSQL-Lizenz

  • Die Verwendung der PostgreSQL-Lizenz wird als gute Entscheidung angesehen.

• Website-Design und App-UI

  • Das Design der Website ist gelungen und gut lesbar.
  • Auch die App-UI sieht auf den Demo-Bildern großartig aus. Es besteht Interesse, sie auszuprobieren.