IOBroker und QuestDB

[OliverIO]

@pez3 sagte in IOBroker und QuestDB:

Ich meinte eine Verbindung mit dem sql Adapter zu questdb...

was ist den dein ziel?
das ist keine normale anforderung eine datenbank mit einer anderen datenbank zu verbinden.
eigentlich sollte eine db ausreichen.

[Homoran]

@oliverio er will influx rauswerfen, wenn ich das richtig verstanden habe

[OliverIO]

@homoran
ja verstanden, aber warum will er dann mysql mit quest db verbinden?

[Homoran]

@oliverio sagte in IOBroker und QuestDB:

aber warum will er dann mysql mit quest db verbinden?

will er?
Ich dachte nur den sql Adapter für Quest verwenden

[OliverIO]

@homoran
ich habe den abschnitt zitiert

@oliverio sagte in IOBroker und QuestDB:

@pez3 sagte in IOBroker und QuestDB:

Ich meinte eine Verbindung mit dem sql Adapter zu questdb...

[Homoran]

@oliverio sagte in IOBroker und QuestDB:

ich habe den abschnitt zitiert

da steht doch genau das drin was ich schrob!
Den SQL Adapter für Quest nutzen!

oder bin ich blöd?

[pez3]

Was ich Grund möchte ist influx kicken... da ich nicht schon wieder Lust habe, sämtliche queries umzubauen und irgendwann der Support für 2.x auslaufen wird...

auf der suche nach weiteren timeseries db bin ich auf questdb gestoßen, welche wohl Interfaces für rest, influx und postgre bieten soll...

nun habe ich gedacht, ich komme evtl mit dem influx Adapter in die questdb... geht wohl nicht...

also war die nächste idee es mit dem sql Adapter zu versuchen, welcher auch postgre unterstützt... damit bin ich allerdings zum jetzigen Zeitpunkt auch gescheitert

schöne Grüße Peter

[Codierknecht]

@pez3 sagte in IOBroker und QuestDB:

also war die nächste idee es mit dem sql Adapter zu versuchen, welcher auch postgre unterstützt

Das funktioniert prinzipiell.

Aber:

• Ohne Enterprise-Version wird nur 1 Datenbank unterstützt.
  Und die heißt "qdb". Da man die nicht neu anlegen kann, fehlen auch die nötigen Tabellen. Die werden nur beim Neu-Anlegen einer DB erzeugt.
• Man könnte Tabellen als CSV importieren oder per SQL anlegen
  Hilft aber auch nix, da nicht alle Datentypen unterstützt werden.

sql.0	2024-11-12 22:52:01.527	error	error: unsupported column type: SERIAL
sql.0	2024-11-12 22:52:01.526	error	CREATE TABLE sources (id SERIAL NOT NULL PRIMARY KEY, name TEXT);

[OliverIO]

@homoran sagte in IOBroker und QuestDB:

oder bin ich blöd?

ne stimmt, er hat ja adapter geschrieben und nicht mysql db

[Codierknecht]

@pez3

Du könntest ein Feature-Request am SQL-Adapter eröffnen, um QuestDB zu unterstützen.
https://github.com/ioBroker/ioBroker.sql/issues

Es stellt sich allerdings die Frage, ob QuestDB eine längere Halbwertszeit hat als Influx.

[Codierknecht]

@Homoran
Der Container zum Testen war in 5 Minuten aufgesetzt:

services:
  questdb:
    container_name: QuestDB
    image: questdb/questdb:latest
    ports:
      - "8812:8812"
      - "9012:9000"
    volumes:
      - questdb:/var/lib/questdb
    tty: true
    stdin_open: true
    environment:
      QDB_HTTP_ENABLED: true
      QDB_HTTP_NET_BIND: "0.0.0.0:9000"
      QDB_HTTP_USER: "admin"
      QDB_HTTP_PASSWORD: "quest"

    restart: unless-stopped

volumes:
  questdb:

Test beendet - Container weggeworfen

[pez3]

@Codierknecht
wow danke für deine hilfe! hab sxhon gesehen, dass da wohl schon eine db angelegt ist, aber weder rausgefunden, dass man nur 1 haben kann, noch wie man eine neue anlegen kann...

ja stimmt ... wenigstens das anlegen ging schnell

schade, dass das mit questdb nicht so einfach geht. las sich recht vielversprechend.

was nimmt "man" denn aktuell so als db für iobroker? influx? sql?

influx liest man ja sehr oft, allerdings ist das für mich schon ein ko Kriterium, wenn man mit jeder Version das datenmodell und die querylanguage ändert... meines Wissens ohne einfache Möglichkeit zur Migration..

timescaledb wäre evtl noch ne Alternative die ich probieren werde.

schöne Grüße Peter

[Codierknecht]

@pez3 sagte in IOBroker und QuestDB:

was nimmt "man" denn aktuell so als db für iobroker?

Ich bleibe bei MySQL/MariaDB.
Ist zwar für zeitbasierte Daten nicht optimal, aber

1. Komme ich beruflich bedingt mit SQL besser klar
2. Reicht mir die Performance
3. Habe ich die eh im Einsatz - für andere Zwecke (Zabbix, Paperless, Redmine, Wiki)