Ich habe nur Erfahrung mit PostgreSQL:
Timeout für queries lässt sich proprietär mit statement_timeout setzen. statement_timeout wird ab V9.6 benutzt, aber ich selbst habe das noch nie eingesetzt.
Ab V10 unterstützt PostgreSQL Declarative Table Partitioning, da gibt man für eine Tabelle an, in welchem Bereich sich ein Wert bewegt. Die einzelnen Partitionen mit ihren Constraints muss man allerdings selbst pflegen, d.h. man muss ggf. neue Tabellen für neue Intervalle erzeugen. Da scheint aber noch Optimierungspotenzial drinzustecken, denn bis V13 wird da immer noch dran gearbeitet um bessere Performance zu erzielen.
Wir haben mit Postgres V9 ein Tool, das Messdaten in einem 15 Sekunden Intervall aufzeichnet und daraus Diagramme bastelt. Jedes Diagramm besteht so aus 5-12 Kurven und es werden gleichzeitig bis zu vier Diagramme angezeigt. Das war mit Postgres bis V9 nur mit viel Trickserei hinzukriegen (keine vollen Updates der Diagramme, sondern nur inkrementell für den Anzeigebereich, der aktualisiert werden muss. Wenn sich der Anzeigebereich von 8:35:00 - 9:35:00 auf 8:35:15 - 9:35:15 ändert werden z.B. nur die Daten für 9:35:00 bis 9:35:15 angefordert und die bestehenden Daten aktualisiert. Außerdem sind in der db in den Messwert noch Statusinformationen reinkodiert worden, damit alle Daten in einer Tabellenspalte zur Verfügung stehen. Das Auslesen aus der Software ist kein Problem, aber per SQL in die Datenbank zu gucken, um sich die Messwerte anzusehen geht halt nicht. Damals hätte ich schon gerne Table Partitioning gehabt, aber das ging nur umständlich über Vererbung und da war auch nicht klar, ob das besser performt.
Wie du deine Tabellen partitionierst hängt von deiner Anforderung ab, aber wenn es Zeitverläufe sind scheint mit einer Partitionierung nach Zeitstempel schon sinnvoll. Wichtig (zumindest bei PostgreSQL) ist auch, dass man nicht zu viele Partitionen erzeugt, weil das Bestimmen der relevanten Partitionen auch Zeit kostet. Auf Stackoverflow habe ich mal gelesen, dass Partitionierung bei PostgreSQL erst bei Tabellen Sinn macht, die mehrere Millionen Einträge haben (ausm Gedächtnis, ohne Referenz). Zur Not musst du das halt mal selbst mit synthetischen Daten prüfen.
Wie gesagt, über Timescale DB bin ich iwann mal gestolpert, bin aber nie dazu gekommen, das mal auszuprobieren. Wenn du dazu iwann mal Ergebnisse hast würde ich mich sehr über Infos freuen.
