Ankündigung

Einklappen
Keine Ankündigung bisher.

Alle 5 Minuten 1.345 neue Einträge managen?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Alle 5 Minuten 1.345 neue Einträge managen?

    Hi zusammen,

    ich plane aktuell eine kleine Online-Software die alle 5 Minuten exakt 1.345 Daten auswertet.
    Diese sollen natürlich in eine Datenbank gespeichert und regelmäßig ausgewertet werden.

    Sprich: Diese 1.345 Sensoren liefern verschiedene Werte (Int, Float, Boolean, ..). Das ganze soll dann in einem Diagramm ausgewertet und optisch dargestellt werden.
    Beim Diagramm mach ich mir nicht so große sorgen, da hier nicht alle Sensoren auf einmal sondern einzeln angezeigt werden.
    Allerdings mache ich mir um die Datenbank etwas sorgen.

    Wie lange wird das ganze wohl gut gehen mit dem Auswerten?
    Aktuell sieht die Datenbank so aus:

    ID, Sensor (Name), Wert (Speichert den zuletzt gelieferten Wert).
    Ich müsste das ganze nun natürlich um eine Tabelle "Statistik" erweitern:
    SensorID, Datum, Wert

    Index wäre natürlich SensorID (und einer fürs Datum?).

    Aber das sind 390.000 Einträge am Tag. Oder 140.400.000 im Jahr..das geht nicht lange gut beim auslesen.

    Habt ihr ein paar Tipps wie ihr das lösen würdet?

    Lg
    Patrick

  • #2
    Die Frage kann man so pauschal nicht beantworten.

    Am ehesten noch:
    Massendaten möglichst Typ genau nach Bedarf speichern.
    Ein Sensor, der nur an/aus liefert also Byte oder sogar Bit, usw.

    Ansonsten wäre die Frage zur Natur der Werte, Home Automation, Maschinendaten, Wetterdaten, ..

    Und die Frage, welche Genauigkeit pro Sensor erforderlich ist (s.o.)
    Also floats direkt eindampfen auf notwendige Genauigkeit, dann erst speichern. usw.

    Dann geht es darum, wie und wie lange ich anschließend mit welcher Genauigkeit die Werte betrachten möchte.
    Alles was nicht gebraucht wird, einstampfen (löschen)

    Dann geht es darum, wo ich eigentlich sparen muss/will/kann

    Performance (beim Speicher, Auslesen, Auswerten)
    Plartz (beim Speichern)

    Dann geht es um geeignete Systeme und Hardware.

    Innerhalb des Systems um verfügbare Technik je nach Anforderung (Partitionierung, etc.)

    Kommentar


    • #3
      Puhhh... okay..
      Das Problem ist, mit dem System verdient man kein Geld. deswegen ist die Hardware eher mau.
      Also schwebt dir eher so etwas vor wie:

      - nur exakte Werte speichern
      - z.b. nach 1 monat Werte löschen und nur Stündlich zur Verfügung stellen (könnte man evtl. auch täglich machen).

      Was meinst du mit Partitionierung? Innerhalb von MySQL? Hatte ich auch schon mal drüber nach gedacht.
      Nur eine Sinnvolle unterteilung fällt mir nicht ein.. Nach Sensor..Nach Datum..sind auch alles ein Haufen werte und dann Partitionierungen.

      Kommentar


      • #4
        Partitionierng hilft bei der Abfrage bzw. Unterteilung großer Datenmengen bezüglich Performance.
        By mySQL kommt es auf die Version an, bei anderen Systemen auch, zumindest bei den kostenlosen. Kaufsysteme können das schon länger.
        Ist das System schon in Betrieb, also die Datenbank "vorgegeben"? Seit Version 10 sind die Partitionierungsmöglichkeiten bei Postgres deutlich verbessert. Dort gibt es auch sehr ausgefeilte Inidizierungsmöglichkeiten.
        Wenn die Sensoren keine funktionalen oder örtlichen Gruppen bilden oder es keine Auswertungsanforderung in dieser Richtung gibt, dann bleibt wohl nur die Zeit als Partitionierungs-/Indizierungsdimension.

        "nach 1 Monat löschen" geht mir etwas zu schnell
        Welche Werte/Typen kommen überhaupt rein?
        Die Löschvarianten oder Aggregationsmöglichkeiten sollte man anhand der späteren Nutzung ausloten.
        Bspw. bei fest vorgegebenem Eingangsintervall nur Speichern von Wertänderungen im Rahmen minimal notwendiger Genauigkeitsauflösung oder bei Messwertausfällen/Sensorfehler. Achtung, das kann viel Platz sparen (Abhängig von "Natur" der Werte, das kann aber starke Auswirkung auf die Abfrageperfornance haben.

        Also was kommt rein? An/Aus? Temperaturkurven? warm/kalt? Luftdruck? Kühlschranktemperatur? Motoröldruck?
        Was muss man davon später sehen und in welcher Auflösung und wie lange?

        Stichwort Genauigkeit:
        Sensoren liefern gern einen technischen Wert, der vom Typ her schon mehr Genauigkeit liefert, als die tatsächliche Abnahmegenauigkeit hergibt. Sowas sollte man gemäß Herstellerangaben sowieso sofort abschneiden. Dann noch das weg, was man eh nicht braucht an Genauigkeit.

        Kommentar


        • #5
          Werte in Abhängigkeit vom Alter komprimieren. Beispiel:
          - Nach 1 Woche nur noch Stundenwerte
          - nach 3 Monaten nur noch 1 Wert pro Tag
          Das Beispiel ist rein willkürlich. Werte älter als z.B. 1 Jahr regelmäßig (z.B. per Cron jeden Monat) archivieren (DB-Export und zippen) oder brutal löschen, je nach Anforderung.

          Kommentar


          • #6
            Zitat von Perry Staltic Beitrag anzeigen
            Partitionierng hilft bei der Abfrage bzw. Unterteilung großer Datenmengen bezüglich Performance.
            By mySQL kommt es auf die Version an, bei anderen Systemen auch, zumindest bei den kostenlosen. Kaufsysteme können das schon länger.
            Ist das System schon in Betrieb, also die Datenbank "vorgegeben"? Seit Version 10 sind die Partitionierungsmöglichkeiten bei Postgres deutlich verbessert. Dort gibt es auch sehr ausgefeilte Inidizierungsmöglichkeiten.
            ACK. Wobei es da noch immer Möglichkeiten nach oben gibt, Robert Haas von EDB gab dazu z.B. bei der PGConf.EU in Warschau einen sehr guten Talk - und letzten Freitag wurde ein Patch von ihm für 11 commited. Auch mein Kollege Alvaro Herrera hat einen am letzten Freitag commiteten Patch für besseren Indexsupport geliefert. Aber - auch PG10 liefert hier schon sehr viel.

            Partitionierung macht insbesondere dann Sinn, wenn der Partitionierungsschlüssel später auf die Abfragen paßt, damit dann Constraint Exclusion wirken kann. Dazu müßte man mehr wissen. (über die Abfragen, über die Policy, wie lange die Daten zu speichern sind, etc.). Generell sollte man nicht über-partitionieren, je Kind-Tabelle dürfen schon gerne einige 10 bis 100 Millionen Rows sein. Ich kenne Kundentabellen mit einigen Milliarden Rows in einer Tabelle - ohne daß es da Performance-Probleme gibt. Aber das geht halt auch nur, wenn die Indexe passen. PostgreSQL hat hier z.B. auch BRIN-Indexe (diese sind selbt bei TB-großen Tabellen nur wenige hundert KB oder wenige MB groß und passen bequem in den RAM). Ein weiteres Plus von Partitionierung ist es dann, wenn alte Datensätze gelöscht werden sollen (nach z.B. N Jahren), dann DROPt man einfach die entsprechende Partition.

            Dein gezeigtes Tabellendesign paßt übrigens gar nicht zur Aufgabe. Du hast unterschiedliche Datentypen, aber nur eine Wertespalte.



            PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

            Kommentar


            • #7
              Also es handelt sich um 269 Geräte die immer 5 Werte liefern.
              - An/Aus (Boolean)
              - Temperatur 1 (Dezimal 2,2)
              - Temperatur 2 (Dezimal 2,2)
              - Drehzahl 1 (Int 4)
              - Drehzahl 2 (Int 4)

              Klar wie du schon schreibst, die Sensoren liefern viel zu genaue Werte. Die Temperatur bis auf 5 Stellen hinterm Komma und die Drehzahl auch mit 2 oder drei Dezimale. (Sagt man Dezimale? )

              Meinst du es macht also Sinn, das ganze in 269 Partitionen zu unterteilen?
              Also ich könnte die Datenbank relativ frei wählen, auch die Version. Müsste nur kostenlos sein.

              jspit genau so mein ich das, das würde auch vollkommen reichen. Wenn etwas ist und man eingreifen muss erkennt man das eh in den ersten paar Tagen. Denke spätestens nach einer Woche könnte ich auf 30 Minuten Werte und nach einem Monat auf Stündliche Werte gehen.

              Kommentar


              • #8
                Je Sensor eine Partition würde dann je Tabelle 288 Records/Tag und 105120/Jahr geben. Das ist das, was ich über-partitioniert nennen würde.

                Wenn Du nach nach einer Woche / nach einem Monat die Werte 'eindampfen' willst (wozu ich aus DB-Sicht keine Notwendigkeit sehe), dann wäre Partitionierung nach Zeit sinnvoll. Wenn Du (aus welchen Gründen auch immer, das können gesetzliche Gründe sein) die Daten aber aufheben willst und dennoch schnelle Auswertungen haben willst, böten sich evtl. materialized Views an.
                PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                Kommentar


                • #9
                  Zitat von paD Beitrag anzeigen
                  Meinst du es macht also Sinn, das ganze in 269 Partitionen zu unterteilen?
                  Also ich könnte die Datenbank relativ frei wählen, auch die Version. Müsste nur kostenlos sein.
                  Vergiß erstmal die Partitionierung. Das ist in meinen Augen eine Optimierungsmaßnahme für später.
                  Schön zu wissen, wenn man es kann, schön zu wissen, dass sowas bei der Auswahl der DB Berücksichtigung findet.

                  Konzentrier Dich auf den Bedarf:
                  Was muss gespeichert werden und was abgefragt.
                  Baue ein Modell! Hier gehört ja vielleicht eine Geräte ID rein? Oder ist beim Zugriff später irrelevant, zu welchem Gerät der Sensor gehört?

                  Mach das Modell so präzise wie möglich (u.a. Stichwort Genauigkeit, aber türlich auch fachlich)und spiel etwas damit. Du kannst Testdaten reinballern bis der Arzt kommt und Abfragen drauf legen, wie sie gebraucht werden. Alles ohne Frontend. Dabei wirst Du merken, wo Stärken und Schwächen Deiner Umsetzung liegen.

                  Dann wird das Modell optimiert.

                  Nur als HInweis: Allein das spätere "Eindampfen" von Werten kann ebenfalls deutlich Zeit kosten.
                  Berechnung eines aggregierten Ersatzwertes
                  Löschen der Aggregatbasiswerte
                  (ReIndizierung)

                  Arbeitet man also mit solchen Verfahren, so führt der Weg mglw. über verschiedene Abbildungen, sprich Tabellen, die für unterschiedliche Zeiträume / Aggregationsstufen stehen. An dieser Stelle kommt dann vielleicht Partitionierung ins Spiel oder eigene Logik, die ins Modell einfließt und nach Bedarf, also Auswertungs/-Zugriffsbedarf(!) konstruiert wird.


                  Kommentar


                  • #10
                    hm.... okay..
                    Ich bedanke mich auf jeden fall schon mal für die ganzen Ideen und Anregungen.

                    Werde dann mal damit anfangen mit dem ganzen rum zu experimentieren.
                    Wenn der Server brennt, geb ich bescheid

                    akretschmer das mit den Views schaue ich mir noch mal an, danke.

                    lg
                    Patrick

                    Kommentar


                    • #11
                      ich bin mir nicht sicher, ob MySQL das kann. Ich würde Dir aber eh zu PostgreSQL raten
                      PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                      Kommentar


                      • #12
                        darf ich fragen wieso genau?

                        Kommentar


                        • #13
                          galt das mir und PostgreSQL?

                          Falls ja: der Features wegen. Du hast in PG erheblich mehr und bessere Features als MySQL. Z.B. viel bessere Indexmöglichkeiten, Partitionierung, mat. Views. Du hast einen echt guten, kostenbasierten Optimizer. Du hast ein wesentlich besseres Explain.
                          Und Du hast Dinge wie deutlich mehr Datentypen (JSON, JSONB, Key-Value, ...), bessere Abfragemöglichkeiten (Window-Funktionen).
                          PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                          Kommentar


                          • #14
                            Ja, galt dir und danke für den Hinweis
                            Ich schau mir das ganze mal an

                            Kommentar


                            • #15
                              Ich kann da akretschmer nur beipflichten. PostgreSQL ist die definitive bessere wahl. Macht nen super Job auch im High-Performance Bereich. MySQL ist da schon lange raus aus dem Rennen. Wir haben bei uns zu Stoßzeiten um die 3 Mio schreibende Datenbankinteraktionen in der Stunde. Das wär mit MySQL schon lange in die Hose gegangen.
                              PHP-Manual ¡ mysql_* ist veraltet ¡ Debugging: Finde DEINE Fehler selbst ¡ Passwort-Hashing ¡ Prepared Statements

                              Kommentar

                              Lädt...
                              X