Influx-DB - Daten wie lang im Ram?

[ptr]

Hallo zusammen,

ich bin gerade in der erweiterten Konzeptphase zu einer Anwesenheitserkennungslogik mit JS/Blockly & mehreren Raumsensoren.
Dabei ergibt sich eine einigermaßen aufwändige Zustandsabfrage von Sensorwerten aus der nahen Vergangenheit. Also suche Wert zu einem bestimmten Zeitpunkt von Variable X. Zeiträume: "in den letzten 10 Sekunden", "in der letzten Minute", "in den letzten 3 Minuten".
Es erfolgen bei einem Raumdurchgang ca um die 12 Abfragen eines solchen Historienwertes.
Bisher habe ich ein Skript extra dafür laufen, der die Historie jedes Sensorwertes in einen DP schreibt. Das lesen geht dann sehr schnell, weil ich ja einfach den DP-Wert in eine variable schreibe (und die DP-Werte ja eh im Ram liegen).
Hier würde ich mir aber eine Optimierung wünschen, da ich ja eigentlich damit nur eine Datenbank nachbaue. Was eine unnötige Dopplung/Verkomplizierung wäre die ich nur warten muss.

Es gäbe jedoch eine (vermutlich) stabilere, unaufwendigere Lösung um solche gerade vergangenen Datenwerte zu erhalten.

• Die Sensor-DPs einfach per influx-DB mitloggen. Dann per Datenbankabfrage nach dem gewünschten Wert suchen!

-> Hier die Frage danach jedoch ob das performant genug läuft? 12 Werte abzufragen innerhalb 10ms. Oder ob so eine Datenbankabfrage grundsätzlich nicht in einem Prozess laufen sollte, der insgesamt nicht länger als 10ms dauern sollte... Falls das zu langsam oder unkalkulierbar in der Geschwindigkeit wäre, müsste ich von vornherein das Konzept anpassen....

-> Wie lange werden geloggt DP-Werte vom influx-db-Adapter im Ram oder woanders gehalten? Im Ram wäre das ja superschnell schätze ich. Die eigentliche Influx-DB liegt in einem parallel-LXC unter Proxmox, (also denke 10gbit-Ethernet Emulation)

Vielen Dank für diese Einschätzung.

[BananaJoe]

@ptr also ...

12 Werte in "kurzer Zeit" sind kein Problem für eine Datenbank. Wenn diese es nicht in der Zeit schafft dann dauert es eben länger, wenn diese Schneller ist ... geht es schneller.
Meine Webseite basiert auf einem Framework welches die Webseite anhand der Daten aus einer MySQL-Datenbank "on the fly" zusammenbaut. Das sind hunderte von SQL-Abfragen bis die Seite steht und trotzdem ist die quasi sofort da.

Da mach dir mal - in diesem Maßstab - keine Gedanken drüber. Wenn es zu langsam wird kannst du damit anfangen.

Wie lange die Daten im RAM gehalten werden? Das Entscheidet die Datenbank anhand von internen Parametern selbst. In der Regel bis der Platz gebraucht wird. Der Datenbank würde RAM zur verfügung gestellt, den nutzt diese in der Regel auch aus. Hat die Datenbank zur verfügung 2GB werden diese genutzt, sind es 8 dann werden 8 genutzt.
Aus meiner Praxis: in 7 von 10 Fällen wollen die Applikationen die Daten die eben geschrieben wurde sofort wieder auslesen. Weshalb fast alle Datenbanken die zuletzt geschriebenen Werte erst einmal im RAM behalten.
Wenn er merkt das du bestimmte Sachen linear abfragt wird die Datenbank ggf, anfangen die schon mal ins RAm zu holen.

Und wenn es passt nimmt er sowieso fast alles ins RAM.

Ich schreibe mal auch hier zu: Mach dir da nicht zu viele Gedanken, das ist Aufgabe der Datenbank das selbst zu regeln.

Bisher habe ich ein Skript extra dafür laufen, der die Historie jedes Sensorwertes in einen DP schreibt. Das lesen geht dann sehr schnell, weil ich ja einfach den DP-Wert in eine variable schreibe (und die DP-Werte ja eh im Ram liegen).

Wenn das schnell geht - dann lass doch dem Umweg weg und frag immer direkt die Datenbank. Hast du Performance- oder Zeit-Probleme?
Die Datenbank wird immer schneller werden, die lernt von den Abfragen und versucht das zu optimieren (sollte diese jedenfalls).

[ptr]

@bananajoe Vielen Dank, das reicht mir um am Datenbankkonzept festzuhalten!

Performance-Probleme hätte ich nur an der Stelle gesehen, dass die eigentliche influx-dB „entfernt“ auf einem anderen LXC liegt. Ich vertraue mal auf den influxdb-Adapter also, dass er die Daten im ioBroker vorhält. Bzw, dass die glaube 10gbit-Anbindung (zwischen LXCs) für das alles keine Latenzen >ca. 1ms erzeugt.
Mein Anwendungsfall ist letztendlich: „welchen Wert hatte BewegungssensorX vor 10/30/60 Sekunden“