1. Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm
    Information ausblenden

Vorgehensweise bei der Auswahl eines DBMS

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von christofj, 8 Februar 2018.

  1. christofj

    christofj Benutzer

    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
     
  2. akretschmer

    akretschmer Datenbank-Guru

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

    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.

    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.

    Eher peanuts, 1.5 Millionen Rows/Monat


    Ich würde keines der genannten nehmen.

    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.
     
  3. christofj

    christofj Benutzer

    Hallo akretschmer,

    danke schon mal für deine Einschätzung.

    Kannst du eine Alternative nennen? (am besten open-source)

    Was spricht aus deiner Sicht gegen MySQL?

    Gruß,
    Christof
     
  4. akretschmer

    akretschmer Datenbank-Guru

    PostgreSQL

    Es ist aus meiner Sicht einfach aufzuzählen, was dafür spricht. Hier die vollständige Liste:
     
  5. christofj

    christofj Benutzer

    :) 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ß
     
    akretschmer gefällt das.
  6. akretschmer

    akretschmer Datenbank-Guru

    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.
     
    christofj gefällt das.
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden