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.

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

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

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

[jobo]

Zitat von Medium:

Ist es da besser einen kombinierten Index auf vdate und valueID zu legen, oder jedes Feld seinen eigenen? Oder gar beides? Welche Art von Index eigenet sich hier? (Beide Felder sind für sich genommen non-unique, in Kombi aber unique.) Mein MySQL Tabellen-Tool bietet mir hier die Optionen:
Index Kind: Index, Primary, Unique, Fulltext, Spatial
Index Type: Default, BTree, Hash, RTree
Ich habe mich bisher schämlich wenig damit befasst, welche Index-Arten für welche Fälle geeignet sind

Ich würde es mit getrennten Indizes machen. Das ist flexibler. Ein kombinierte Index greift u.U. nicht, wenn weitere Bedingungen ins Spiel kommen.
Die uniqueness kannst Du separat per constraint definieren. NOrmalerweise tuen RDBMS einem den "Gefallen" abhängig vom Constraint direkt auch einen Index zu bauen, aber das kann man unterbinden, löschen, ändern.

Zitat von himitsu:

Aber bei vielen Daten ist ein View doch auch nicht so gut, wenn er erst stundenlang rumrechnen würde, bei jeder Abfrage.

Das kann man pauschal nicht sagen. Ein View ändert per se nichts an der Abfragegeschwindigkeit.
Ausnahme wäre bspw. wenn ein Abfrage Paramter besser "innerhalb eines Views" aufgehoben ist, weil er dort eine größere Selektivität entfaltet (stärkere Datenreduktion bringt, Folgekosten spart, ..)

Zitat von Medium:

Jetzt machst du mich aber spontan unglücklich,
..
Bei Views wüsste ich jetzt nicht so genau, wie ich die Anforderung erfüllen sollte, die in dem längeren Kommentar beschrieben ist. Und Views werden doch auch dynamisch ausgeführt oder? Die Abfrage auf die originalen "feinen" Daten würde damit ja trotzdem nötig werden. Zwar dann verdichtet über's Netzwerk gehen, aber der Server hätte dennoch die volle Arbeit zu tragen. Bin da skeptisch.

Ein Materialized View, der für kumulierte Daten verwendet werden könnte ist m.E. auch nicht unbedingt effizient. Kommt drauf an, wie das Refresh arbeitet. In Deinem Fall ist klar, es müssen immer nur Daten nachgetragen werden, nicht eine ganzer Mat.View refreshed werden.
Das kann man auch gezielt je Tag oder so manuell in eine eigene Tabelle kippen. Falls dort Indizes definiert sind, dann eben die Indizes disablen und nachher wieder aktualisieren, ist etwas schneller.

[Namenloser]

Zitat von Dejan Vu:

Meinst Du denn im Ernst, Google, Amazon & Co verwenden rollierenden Text-Dateien?

Die verwenden aber auch nicht MySQL...

Zitat von Dejan Vu:

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.

Bedenke aber, dass dir der MySQL-Index dort keine Vorteile bringt. Die Datensätze sind dann zwar schön nach Timestamp sortiert, aber was bringt dir das, wenn du von jedem Tag die Datensätze zwischen 8 und 10 Uhr brauchst. Läuft dann eh auf einen Full/Partial Table Scan hinaus. Kann dadurch schon sein, dass bestimmte Abfragen mit der Zeit langsamer werden.

Und eigentlich sind alle Abfragen, die mir einfallen, derart, dass sie vom Index nicht profitieren. Auch wenn man z.B. den Durchschnitts-/Max-/Minwert in einem Zeitabschnitt bestimmen will. Das RDBMS findet über den Index zwar recht schnell den ersten Datensatz im Zeitabschnitt, aber muss dann doch alle Datensätze in diesem Abschnitt durchscannen, was den Großteil der Zeit ausmachen wird.

Und durch den Index auf der Zeitspalte (den man natürlich trotzdem braucht) wird natürlich auch das Einfügen mit der Zeit langsamer, zwar „nur“ logarithmisch zur Anzahl der Datensätze, aber bei sekündlichem Logging über Jahre hinweg ist das vielleicht auch nicht zu unterschätzen.

Ich finde du übertreibst auch was den Aufwand von Textdateien angeht. Das ist doch wirklich die simpleste Form, Daten zu speichern und zu lesen überhaupt. Ich finde auch nicht, dass man damit das Rad neu erfindet, ganz im Gegenteil.

[Dejan Vu]

Zitat von jobo:

Ich würde es mit getrennten Indizes machen. Das ist flexibler.

Erklär mal bitte. Ist der kombinierte Index über den Zeitraum und Messstationen nicht besser, als nur über den Zeitraum? Den Index über die ValueID wird man imho nie benutzen, oder irre ich mich?

Bei SQL-Server kann man auch einzelne Felder in den Index mit aufnehmen, sozusagen Huckepack, dann spart man sich den Zugriff auf den Datensatz komplett. Geht das hier auch? Ok, der Index ist dann so groß wie die Daten, aber WTF.

Zitat von Namenloser:

Die verwenden aber auch nicht MySQL...

Bitte den Trollfaktor nicht noch weiter erhöhen.

Zitat:

Bedenke aber, dass dir der MySQL-Index dort keine Vorteile bringt. Die Datensätze sind dann zwar schön nach Timestamp sortiert, aber was bringt dir das, wenn du von jedem Tag die Datensätze zwischen 8 und 10 Uhr brauchst. Läuft dann eh auf einen Full/Partial Table Scan hinaus. Kann dadurch schon sein, dass bestimmte Abfragen mit der Zeit langsamer werden.

Bitte lies meinen vorherigen Post noch. Dessenungeachtet bringt der Index sehr wohl etwas. Denn ich will ja nicht (hab ich das nicht geschrieben) vom gesamten Betrachtungszeitraum (dann hättest Du Recht), sondern von einer Zeitspanne und innerhalb der dann mit weiteren Kriterien. Und wenn nicht, kommt mein Vorschlag zum Tragen, Datum und Uhrzeit zu trennen.

Man macht meistens von einem relativ kleinen Zeitraum eine Auswertung und da bringt der Index schon eine ganze Menge. Weiterhin gibt es noch andere Index-Arten, die eine Aggregierung drastisch beschleunigen, weil ja nicht der Record einzeln, sondern gleich der ganze Index geladen wird: So wird ein kluger Optimizer kombinierten Index vDate+ValueID+Messwert verwenden, um die Messwerte zu aggregieren.

Zitat:

Und durch den Index auf der Zeitspalte (den man natürlich trotzdem braucht) wird natürlich auch das Einfügen mit der Zeit langsamer, zwar „nur“ logarithmisch zur Anzahl der Datensätze, aber bei sekündlichem Logging über Jahre hinweg ist das vielleicht auch nicht zu unterschätzen.

Bei einem Btree vielleicht, aber die Log-Basis ist ca. 2000, sodaß das echt ne Weile braucht.

Zitat:

Ich finde du übertreibst auch was den Aufwand von Textdateien angeht. Das ist doch wirklich die simpleste Form, Daten zu speichern und zu lesen überhaupt. Ich finde auch nicht, dass man damit das Rad neu erfindet, ganz im Gegenteil.

War ein wenig übertrieben, aber ich muss Code schreiben, um die Dateien zu erstellen und zu laden, zum Auswerten auch. Kommt eine Spalte hinzu, muss ich das Programm ändern, an vielen Stellen, Ändere ich die Aggregierung, auch. Ich muss also laufend an der Software rumfummeln. Bei einem RDBMS brauch ich das alles nicht. Die Query anpassen, die Tabellenstruktur vielleicht: 1000x schneller, sicherer etc.
Zudem ist diese Text-Lösung weder skalierbar noch allgemeingültig. Das Prinzip vielleicht, aber nicht der Code.

Und auch in Messdaten werde ich mal mit SQL herumstochern wollen. Mit Textdateien lege ich mir da die Karten.

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