Tabellen für viele kleine Datensätze optimieren

[Medium]

Wow! Piano die Herren. Die Anforderungen sind recht klar, und ich bin mit dem aktuellen Stand bisher nicht unzufrieden. Um ein paar Punkte zu klären, die hier auftauchten:

Ein eigenes Dateiformat kommt nicht in die Tüte. Der Kunde wünscht explizit die Verwendung eines verbreiteten RDBMS, so dass im schlimmsten aller Fälle (für mich) auch ein anderes Softwarehaus leichtes Spiel mit der Weiterentwicklung und Wartung hat. Irgend welche obskure und ggf. proprietäre Dateiformate haben da einfach nichts verloren. Langzeitarchive, die weitere Schritte benötigen um sie auswerten zu können sind auch passé. Der Kunde will 2016 in seinem Viewer sagen können: Zeige mir die Ströme der Betriebsbereiche 1, 3 und 7 von 2014-2016, GO! Und dann will der innerhalb von einstelligen Sekunden seine Kurven sehen. Das entwickel ich NICHT selbst, das macht bitte sehr ein etabliertes DBMS. (Also zumindest das Anliefern der zum Zeichnen nötigen Daten.)
Und falls doch dann mal erweiterte Auswertungen gewünscht werden, werde ich endlos glücklich sein ein Backend zu haben, dass mir die Arbeit daran auf das Schreiben eines vergleichsweise kleinen Scriptes vereinfacht. Dass nachfolgende Wünsche dann ggf. nicht mehr in Millisekunden Ausführungszeit geschehen ist im Zweifel darstellbar, und stellt dann auch vermutlich nicht täglich genutzte Funktionalität dar.

Betrachtungen der Art "immer Donnerstags zwischen 7:00 und 12:00" wird es, laut nun mehrmonatig erstelltem Anforderungsprofil des Kunden (durch uns begleitet), nicht geben.

Ja, es ist ein großer industrieller Produktionsbetrieb. Festplattenkapazität ist nicht relevant. Der Kunde ging von sich aus schon von reichlich dimensionierten Backplanes mit zig HDDs aus, was IMHO sogar etwas hoch gegriffen ist. Ich erzeuge hochgerechnet jetzt etwa 15 MB Daten pro Tag, also pessimistisch gerechnet rund 6GB pro Jahr. Da reicht mir eine 1TB Platte für mindestens 15 Jahre, also nehme ich ein Mirror-Stripe (RAID 10) mit 4x 2TB SAS Platten und habe 30 Jahre lang Ruhe. Vorausgesetzt die technischen Standards entwickeln sich nicht zwischenzeitlich weiter, was sicherlich Umrüst-Begehrlichkeiten wecken müsste.

Abfragen werden immer die zuvor gezeigte Struktur haben: Gib Daten aus Zeitraum a bis b, der Messstellen 2, 6, 7 und 12. Der kombinierte Index aus "valueID, vdate" hat sich in meinen heutigen Tests als immense Verschnellerung erwiesen! Zusammen mit den kummulierten Tabellen, die das Zeichnen bei gröberem Zoom verschnellern sollen, dürfte ich auf akzeptable Reaktionszeiten kommen. Auch über ein handlesübliches Gigabit-Netzwerk.

Excel spielt keine Rolle. Ich schreibe ein vollumfängliches Auswertungsprogramm mit Graph und Reports, und das könnte von mir aus eine Exportfunktion bekommen. Gefordert ist dies bisher nicht, aber problemlos denkbar. Die Daten sind dann ja bereits gefiltert und aufbereitet.

"Materialized Views" erscheinen mir als ungeeignet. Beziehungsweise mache ich ja mit meinen Aggregat-Tabellen etwas sehr ähnliches, und das "Gewürgel" dies auf die verlinkte Art in reinem SQL auf MySQL abzubilden... da gefällt mir meines besser. Zumal es ziemlich einfach auch für Pflegeläufe nutzbar ist, sollte es dort wirklich mal Probleme geben.

Partitioning ist eventuell interessant. Da sich das aber durchaus auch nachträglich umsetzen lässt, würde ich gerne erstmal ohne testen. Wenn der Kunde dann doch irgendwann nicht mehr akzeptable Auswertezeiten berichtet, oder sich das noch besser in meinen noch kommenden "großen" Tests abzeichnet, wäre dies ein möglicher Ansatzpunkt.

Der wesentliche Grund für die Erstellung des gesamten Systems ist das Identifizieren der Ursachen für teilweise auftretende Verbrauchsspitzen. Verträge mit Energielieferanten definieren in diesen Größenordnungen Tarife nach aktuellem Verbrauch, heisst dass die ersten paar hundert kW normal berechnet werden, ab dann aber ein immens hoher "Straftarif" einsetzt. Die Quellen dafür sollen gefunden und bestenfalls eliminiert werden.
Der zweite Grund (nicht minder wichtig) ist die genauere Anrechenbarkeit von Energiekosten auf ein spezifisches Produkt. So, dass nachher gesagt werden kann: Für Produkt X entfallen Y kWh auf eine Produktionseinheit, verrechnet mit Tarif T sind also P% des Preises reine Energiekosten. Zusammen mit den Messungen für teils einzelne Motoren zeigen sich hier dann ggf. gute Einsparpotenziale.
Um gewissen Rankings zu entsprechen, und vereinbarte Einsparungen durch staatliche Stellen vorgegeben nachweisen zu können, sind Langzeitbetrachtungen notwendig. Auch rückwirkend über mehrere Jahre. (Manche Baugenehmigung kommt mit derartigen Anforderungen daher.)


Abschließende Bewertungen mit definitiven Werten müssen noch folgen. Hierfür muss ich zunächst ein zumindest rudimentäres Auswertetool bauen, und einen Generator für Echtwelt-ähnliche Daten, der mir flott Daten von ein paar Jahren simulieren kann. Die bisherigen Ideen und Infos bzgl. Indizes und Aggregat-Tabellen haben mich immerhin schon ein mal so weit gebracht, dass ich mir gut vorstellen kann den gewünschten Funktionsumfang mit erschwinglicher Hardware und akzeptablen Laufzeiten anbieten zu können. Sehr geil!