Vorgehensweise bei der Auswahl eines DBMS

christofj

Fleissiger Benutzer
Beiträge
55
Hallo Zusammen,

ich bin auf der suche nach einem Datenbankmanagementsystem.

Ich möchte Messwerte in eine DB schreiben und diese danach mit Referenzmesswerten vergleichen.
Ergibt der Vergleich das die gemessenen Werte überein stimmen wird nur ein "Messwerte ok" abgespeichert und Messwerte werden verworfen.
Falls die Messwerte von den Referenzmesswerten abweichen, sollen die abweichenden Werte, mit einem Zeitstempel versehen, für einen Monat gespeichert werden.
Danach können sie überschrieben werden.

Durchschnittlich rechne ich mit 35 Schreibvorgängen pro sek. dies hängt allerdings von der Tageszeit ab.
Tags über sind es durchaus mehr nachts sind es weniger. Wie viele Messwerte kommen kann ich nicht beeinflussen.

Für das DB-System wollte ich SQlite oder MySQL (MariaDB) verwenden.

Bezüglich DBMS habe ich leider kaum Erfahrung.

Ich frage mich ob das die richtige Richtung ist in die ich da gehe oder ob eine relationale DB eher ungeeignet ist, Stichwort ODB oder noSQL wie MongoDB.

Habt ihr Tipps für mich, wie ich herausfinden kann, was für meine Anwendung am geeignetsten ist?

Danke schon mal im Voraus,

Christof
 
Werbung:
Hallo Zusammen,

ich bin auf der suche nach einem Datenbankmanagementsystem.

Ich möchte Messwerte in eine DB schreiben und diese danach mit Referenzmesswerten vergleichen.

Du kommst aus Performance-Sicht vermutlich besser, wenn Du diese Reihenfolge umdrehst bzw. diese Dinge gleichzeitig machst. Das könnte via TRIGGER erfolgen.

Ergibt der Vergleich das die gemessenen Werte überein stimmen wird nur ein "Messwerte ok" abgespeichert und Messwerte werden verworfen.

Dann müßtest Du 2 Tabellen führen. Eine mit Timestamp und den Werten, eine andere mit Timestamp und ob ok. Eine Auswertung wird komplexer. Ich würde eher die Werte speichern UND in einer Spalte mitführen, ob okay oder nicht.

Falls die Messwerte von den Referenzmesswerten abweichen, sollen die abweichenden Werte, mit einem Zeitstempel versehen, für einen Monat gespeichert werden.
Danach können sie überschrieben werden.

Dazu böte sich eine Partitionierung an, je Monat. In die aktuelle Tabelle (Februar) schreibst Du, die vom Januar beläßt Du noch, Dezember kann weg.

Durchschnittlich rechne ich mit 35 Schreibvorgängen pro sek. dies hängt allerdings von der Tageszeit ab.
Tags über sind es durchaus mehr nachts sind es weniger. Wie viele Messwerte kommen kann ich nicht beeinflussen.

Eher peanuts, 1.5 Millionen Rows/Monat


Für das DB-System wollte ich SQlite oder MySQL (MariaDB) verwenden.

Bezüglich DBMS habe ich leider kaum Erfahrung.
Ich würde keines der genannten nehmen.

Ich frage mich ob das die richtige Richtung ist in die ich da gehe oder ob eine relationale DB eher ungeeignet ist, Stichwort ODB oder noSQL wie MongoDB.

Habt ihr Tipps für mich, wie ich herausfinden kann, was für meine Anwendung am geeignetsten ist?

Danke schon mal im Voraus,

Christof

Das ist eine typische Anwendung für eine relationale Datenbank. Vermutlich hast Du weitere Daten zum Verknüpfen wie z.B. Sensor-ID oder Kunde oder sonstwas. Und die genannten Zahlen sind wirklich peanuts.
 
:) Ok, schaue ich mir an.

Ich frage mich jetzt warum MySQL in meiner der Technikerschule immer so als Wunderwaffe angepriesen wurde???

Danke für deine Hilfe!

Gruß
 
Werbung:
Mal ein ganz kleines Beispiel, wie Partitioning in PG10 funktioniert (es wird noch besser in 11):

Code:
test=*# create table messwerte (ts timestamp, value numeric, ok bool) partition by range(ts);
CREATE TABLE
test=*# create table messwerte_2017_12 partition of messwerte for values from ('2017-12-01') to ('2018-01-01');
CREATE TABLE
test=*# create table messwerte_2018_01 partition of messwerte for values from ('2018-01-01') to ('2018-02-01');
CREATE TABLE
test=*# create table messwerte_2018_02 partition of messwerte for values from ('2018-02-01') to ('2018-03-01');
CREATE TABLE

Damit hast Du eine 'virtuelle' Tabelle "messung" mit 3 Partitionen. Abfragen tust Du immer die 'virtuelle' Tabelle, und auch dort einfügen:

Code:
test=*# insert into messwerte values ('2017-12-24 16:00:00',123,true);
INSERT 0 1
test=*# insert into messwerte values (now(),66,false);
INSERT 0 1


Scheinbar sind alle Werte in der Haupttabelle:
Code:
test=*# select * from messwerte;
  ts  | value | ok
----------------------------+-------+----
2017-12-24 16:00:00  |  123 | t
2018-02-08 11:29:17.021009 |  66 | f
(2 Zeilen)

Dem ist aber nicht so:

Code:
test=*# select * from only messwerte;
ts | value | ok
----+-------+----
(0 Zeilen)

test=*# select * from only messwerte_2017_12;
  ts  | value | ok
---------------------+-------+----
2017-12-24 16:00:00 |  123 | t
(1 Zeile)

test=*# select * from only messwerte_2018_01;
ts | value | ok
----+-------+----
(0 Zeilen)

test=*# select * from only messwerte_2018_02;
  ts  | value | ok
----------------------------+-------+----
2018-02-08 11:29:17.021009 |  66 | f
(1 Zeile)

test=*#

Eine Abfrage aller Messwerte für Februar wird nur die betreffende Partition abfragen:

Code:
test=*# explain select * from messwerte where ts = '2018-02-08';
  QUERY PLAN  
---------------------------------------------------------------------------
Append  (cost=0.00..24.75 rows=6 width=41)
  ->  Seq Scan on messwerte_2018_02  (cost=0.00..24.75 rows=6 width=41)
  Filter: (ts = '2018-02-08 00:00:00'::timestamp without time zone)
(3 Zeilen)


Wenn Du alte Werte nach N Monaten nicht mehr benötigst, DROP'st Du einfach die Partition mit diesen alten Daten. Das und die Erstellung neuer Partitionen kannst Du via CRON machen.
Partitionen sollten nicht zu klein sein, bzw. nicht unnötig klein partitionieren. Einzelne Partitionen können durchaus im 3-stelligen Millionenbereich sein, tausend Partitionen sind kein Problem.

Ich hab jetzt mal Indexe weggelassen. PG kann z.B. auch partielle Indexe, damit könntest Du Indexe nur auf die Werte setzen, die nicht ok sind, und damit eine Suche aller falsche Werte massiv beschleunigen.
 
Zurück
Oben