TimescaleDB

Allgemeines zu PostgreSQL.
Antworten
Gisman
Erfahrener Benutzer
Beiträge: 1099
Registriert: Fr 20. Jan 2006, 15:30
Wohnort: Pfalz
Kontaktdaten:

TimescaleDB

Beitrag von Gisman » Mi 26. Sep 2018, 12:59

Hallo!

Hat jemand Erfahrung damit? Lässt sich das problemlos mit einer normalen PostgreSQL-Instanz (>9.6, 10, ...) betreiben? Ab welchem Durchsatz lohnt sich das?

https://www.timescale.com/

Viele Grüße Uwe

pogomips
Benutzer
Beiträge: 61
Registriert: Fr 18. Nov 2016, 09:55

Re: TimescaleDB

Beitrag von pogomips » Sa 29. Sep 2018, 16:01

Ich fand das spannend und hab mal etwas in der Seite geblättert. Was mir aufgefallen ist:
einige (viele?) Beispiele haben m.E. nichts mit der timescale extension zu tun, sondern nutzen coole pg features kombiniert mit neuer Funktion.
Das wäre dann auf funktionaler Ebene hauptsächlich time_bucket?

Vieles scheint mir auf den ersten Blick auch per Window Functions umsetzbar (ohne dass ich es wirklich im einzelnen nachvollzogen habe)

Am Ende fehlen mir 2 Dinge. Laufzeitvergleiche und Preise.
Und Preise nicht zu veröffentlichen, finde ich irgendwie .. yesterday

Was ich auf Anhieb allerdings sehr einleuchtend fand, war die Herleitung für Query Optimierung und beschleunigten Zugriff. Ausgehend von der Annahme, dass meine zeitabhängigen Daten nur angehängt und nie geändert werden (Logs, Messdaten,..), kann man sicher viele Optimierungen vornehmen. Schon beim Speichern, aber natürlich auch bei der Indizierung.

Da es ja eine PG Extension sein soll, würde ich erwarten, dass vor allem erstmal alles wie immer funktioniert. Alles andere wäre glaub ich ein ziemlicher Krampf. Die Migrationsmethode setzt voraus, dass ich zu irgendeinem Zeitpunkt und Ort doppelt soviel Platz für meine Daten habe wie ohne die Extension.

Was wären denn Deine Anwendungsfälle? (Ich hab keinen praktischen derzeit)

Gisman
Erfahrener Benutzer
Beiträge: 1099
Registriert: Fr 20. Jan 2006, 15:30
Wohnort: Pfalz
Kontaktdaten:

Re: TimescaleDB

Beitrag von Gisman » Mo 1. Okt 2018, 08:05

Ich sehs auch so, dass das so eine Art Convenience-LAyer auf bestehendes wie Window Functions und Partitionierung ist. Was IMHO jetzt nicht ein Nachteil sein muß. Für Vergleiche ist es vielleicht einfach auch zu neu (oder man möchte sich nicht das Marketing zerschiessen ;)), die angegebenen Zahlen erschienen mir auch etwas, hm, aus der Luft gegriffen.
Zur Anwendung: Wir wollen zur Zeit ein Portal bauen, in den viele unterschiedliche, nicht zwingend einheitliche Messwerte von zahlreichen mobilen Clients geschickt werden und mit großen Mengen zeitbasierten Basisdaten (HN-Modelle, Ganglinien, W/Q-Prognosen etc) verschnitten werden. Das ganze soll natürlich auf eine mobile Karte und es sollen Prognosen für bestimmte Zeitpunkte/Positionen erstellt werden. Also in der Endstufe einiges an zeitbasierter Sucherei. Da seh ich durch aus einen Einsatzbereich, fragt sich aber, ob man hier eine Extension braucht oder ob man das mit Bordmitteln nicht besser/einfacher/transparenter hinbekommt. Wir stehen da noch am Anfang des Projekts, also ist noch Raum für Experimente.

castorp
Erfahrener Benutzer
Beiträge: 1060
Registriert: Sa 27. Jun 2009, 22:24
Wohnort: Bayern

Re: TimescaleDB

Beitrag von castorp » Mo 1. Okt 2018, 08:31

Timescale hat ein Benchmark Programm veröffentlicht, mit dem man selber testen kann: https://github.com/timescale/benchmark-postgres der scheint aber eher die Schreibgeschwindigkeit zu testen, nicht die Abfragegeschwindigkeit.

Ich habe einen Benchmark gefunden der - so wie es aussieht - nicht von Timescale kommt: https://tech.people-doc.com/pg-timescaledb.html

Zu dem Thema gibt es noch eine Diskussion auf Hacker News: https://news.ycombinator.com/item?id=14984464
A SQL query walks into a bar and sees two tables. He walks up to them and says 'Can I join you?'

Gisman
Erfahrener Benutzer
Beiträge: 1099
Registriert: Fr 20. Jan 2006, 15:30
Wohnort: Pfalz
Kontaktdaten:

Re: TimescaleDB

Beitrag von Gisman » Mo 1. Okt 2018, 11:56

@castorp: Vielen Dank!

Antworten