Tabellen für viele kleine Datensätze optimieren

[DSP]

Weil das Progy sonst nach n paar Monaten verdamt wird und nach einen Jahr nicht mehr läuft ...

Grüssle
DSP

[himitsu]

Gerade wenn man sich auf bestehende/bekannte Strukturen bezieht, wird es nicht schnell Probleme geben.

Es ist ja nicht so, daß man unbedingt jedes mögliche Bit einsparen muß.
Lieber ein paar Byte mehr und dafür sind die Daten wenigstens gut verarbeitbar.

Natürlich kann man im Spezialfall auch mal alles extrem auf größe optimiert in binären Rinspeichern ablegen, aber wozu alles neu erfinden,
wenn man sich auch eine der vielen vorhandenen und voallem leicht anpassbaren und erweiterbaren Lösungen auswählen kann.

[DSP]

Wüsste nicht was da unbekannte Strukturen sind? Es ist einfach ein Compound Key, das wars. Alle Daten liegen in der Datenbank und können Problemlos gelesen werden. Und dass man die Zeit normalisieren muss, liegt auf der Hand, warum dann nicht die 650 Stationen auf einen Zeitstempel vereinheitlichen? Wenn details nötig sind, muss sowieso nachgelesen werden.

Auch hier mit dem rollierenden und wartungsarmen verfahren, dürften mehrere Gigs im Jahr überschritten werden und es ist nur eine Frage der Zeit, mis da noch weitere Stationen dazu kommen und ehrlich, wenn schon dieser Detailgrad gefordert wirs, wenn interessierts in n paar Jahren noch welche Station n paar Jahre zuvor einen höheren value hatte als die andere Station n paar millisekunden davor?

Grüssle
DSP

[Dejan Vu]

Zitat von DSP:

Weil das Progy sonst nach n paar Monaten verdamt wird und nach einen Jahr nicht mehr läuft ...

Äh, eigentlich nicht. Das 'Progy' wird auch in 20 Jahren noch genauso schnell laufen, wie am ersten Tag. Du solltest Dich mal eingehend mit RDBMS beschäftigen. Meinst Du denn im Ernst, Google, Amazon & Co verwenden rollierenden Text-Dateien? Was ist denn mit deinem Ansatz, wenn Du doch noch in den Summentabellen das Windsormittel oder den harmonischen Median haben willst? Wie lange sitzt Du denn daran? Wie regelst Du das mit graphischen Auswertungen in, sagen wir, EXCEL? Schreibst Du dir dann eine Schnittstelle, oder einen Ole-DB Provider, um an deine Summentabellen zu kommen? Ach nein, Du öffnest die Summentabelle und c&p'st das Zeugs in Excel. Aber -blöd- nun wollten wir doch die Werte der letzten drei Monate jeweils zwischen 8 und 10 Uhr, immer Dienstags, weil der Kunde meint, wenn der Bäcker die Brötchen bringt (immer Dienstags zwischen 8-10 Uhr), spinnen die Messpunkte.

[DSP]

Zitat von Dejan Vu:

Zitat von DSP:

Weil das Progy sonst nach n paar Monaten verdamt wird und nach einen Jahr nicht mehr läuft ...

Äh, eigentlich nicht. Das 'Progy' wird auch in 20 Jahren noch genauso schnell laufen, wie am ersten Tag. Du solltest Dich mal eingehend mit RDBMS beschäftigen. Meinst Du denn im Ernst, Google, Amazon & Co verwenden rollierenden Text-Dateien? Was ist denn mit deinem Ansatz, wenn Du doch noch in den Summentabellen das Windsormittel oder den harmonischen Median haben willst? Wie lange sitzt Du denn daran? Wie regelst Du das mit graphischen Auswertungen in, sagen wir, EXCEL? Schreibst Du dir dann eine Schnittstelle, oder einen Ole-DB Provider, um an deine Summentabellen zu kommen? Ach nein, Du öffnest die Summentabelle und c&p'st das Zeugs in Excel. Aber -blöd- nun wollten wir doch die Werte der letzten drei Monate jeweils zwischen 8 und 10 Uhr, immer Dienstags, weil der Kunde meint, wenn der Bäcker die Brötchen bringt (immer Dienstags zwischen 8-10 Uhr), spinnen die Messpunkte.

Sorry Dejan Vu, das ist schlichtweg blödsinn. Einmal kann Excel keine Terra an Zeilen halten und zweitens intessiert dies kein Schwein. Auch bei weiteren statistischen daten, min fehlt mir bspw im Datenformatt, muss man irgendwann sagen ab wann man berechen will. Es interessier auch niemanden, welchen Wert hier bspw Station Null vor dreihundert Jahren hatte, der war schöicht und einfach Null! Es interessiert also immer ein bestimmter Zeitraum, wenn man will, kann man die Historischen Werte auch getrennt aufzeichnen, wie gesagt, Min ist schon mal Null

Grüssle
DSP

[Dejan Vu]

Zitat von DSP:

Sorry Dejan Vu, das ist schlichtweg blödsinn.

Ist es nicht. Ich will aus EXCEL heraus die 3 Stunden vom Januar 1980 in meiner Auswertung darstellen, wegen der Anomalie. Wie geht das mit deinen rollierenden Tabellen? Das sind übrigens auch keine Terra(?) an Daten, sondern z.B. ähm, warte 3x60=180 Datenpunkte pro Station, soweit ich das richtig verstanden habe.

Dessenungeachtet könnte es ja sein, das z.B. die Messdaten in einem Atomkraftwerk(darum geht es hier nicht, aber egal) oder in einer Fabrik über mehrere Jahre aufbewahrt werden müssen und ich möchte bitte nicht erst Stundenlang im Archiv irgendwelche Zipdateien entpacken, um mir die Aufzeichnungen anzuschauen. Muss ich auch nicht, ich habe ja mein RDBMS mit meinen Archivdaten: Kurz gemounted, Auswertung gestartet, fertig.

Zitat:

und zweitens intessiert dies kein Schwein.

Das stimmt. Die meisten Schweine interessieren sich nicht dafür, aber Kontrolleure und Ingenieure z.B. Das nennt sich Tracing und ist im ISO-Prozess zwingend. Bei bestimmten Produkten beträgt die Aufbewahrungsfrist für Messprotokolle 10 Jahre und mehr und wenn Reklamationsmanagement ernstgenommen wird oder -wie Medium das angedeutet hat- Qualitätsmanagement gelebt wird, sollte man sich schon auch mal die Daten von vor ein paar Jahren anschauen können. Sogar einzelne Werte.

Zitat:

Min ist schon mal Null

Den Rest deiner Argumentation habe ich nicht verstanden (wie das z.B.), das war zu konfus.
So, nun komm wieder runter.

[DSP]

Ach Du argumentierst wie n Programmierer aus Indien, der nichts von dem Business versteht, daher stife ich dich jetzt auch mal so ein, als jemanden dem man alles in jeden Schritt erklären muss. Dazu habe ich keine Lust und zweitens hängst vom spezifischen Kunden B, und da ist Medium gefordert mit ihm zusammen zu sitzen und erst mal ein requirements Engeniering durchzuführen. Damit erledigen sich die meisten Punkte, natürlich, wenn der Kunde bereit ist, die nächsten Jahre für diese minifunktionalität mit äußerst beschränkten Nutzen n paar Millionen, mit steigender tendenz, loszumachen, dann ist das auch in Ordnung, nur ich bezweifle dies. Aber wenn, dann sollt er HANA zulegen und jährlich n paar Gig draufsatteln, sonst wird das nix mehr

Wusste nicht, dass hier mittlerweile Systemanalyse, DB Design und Best Practice, zwischenzeitlich verpönt sind ...

... Aber ist mir auch egal ...

[DSP]

Zitat von Dejan Vu:

[Das nennt sich Tracing und ist im ISO-Prozess zwingend.

Sorry, merkst du nicht, wie du dich her disqualifizierst? Ich sagte nicht, dass man die Daten löschen soll, sondern archivieren. Und für manche gibts da auch längere aufbewarungsfristen, zehn Jahre sind da eher die untere Grenze. Dann sag mir mal, wie willst du das mit eine wirtschaftlich vertretbaren aufwand realisieren? Dein aktueller Ansatz ist wirtschaftlich komplett inakzeptabel .. Daneben sollte die Zuverlässigkeit des System über die nächsten zehn Jahre gewährleistet sein mit geringen Wartungsaufwand und Folgekosten. Das sehe ich bei deinen Ansatz nicht. Eher die Tendenz, die Softwarequalität immer miserabler zu gestalten ...

[DSP]

Zitat von Dejan Vu:

ich will aus EXCEL heraus die 3 Stunden vom Januar 1980 in meiner Auswertung darstellen, wegen der Anomalie.

exakt, das ist Blödsinn, welcher troll will schon 50 Terra vorhalten um dann festzustellen, dass in Excel, in der neusten Version, nur zwei Gig passen?

Sorry, das kannst komplett vergessen.

[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!