Tabellen für viele kleine Datensätze optimieren

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

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

[Namenloser]

Zitat von Dejan Vu:

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.

Dann ist dein Code nicht vernünftig gekapselt. Mir fallen eigentlich nur zwei Stellen ein, die man ändern muss: Speichern eines Datensatzes und Laden eines Datensatzes. Das ist bei der RDBMS-Variante nicht anders.

Aber ich will das jetzt nicht weiter diskutieren, wird langsam Off Topic.

[jobo]

Zitat von 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?

Ein kombinierter Index ist naheliegend, lässt sich durch das RDBMS bzw. den Optimizer aber oftmals nicht so vielseitig nutzen.
Das Thema ist sehr DB spezifisch, vermutlich sogar (Optimizer)Version-spezifisch.

Einzeln aufgebaute Indizes werden durch die Optimizer idR besser nach Bedarf zusammengesetzt bzw. abgegriffen, also wirklich verwendet, als Kombi-Indizes. Deren Aufbau und Nutzen ist halt viel spezifischer.
Die Verwendung / Filterung nach Meßstation halte ich für sehr naheliegend. Auch wenn der Kunde was anderes behauptet.

Letztlich ist das Indexthema aber sekundär, weil man es unabhängig von der Logik mit ein paar Handgriffen variieren und testen kann, notfalls sogar auf einem Produktivsystem.

Zitat von hstreicher:

mal ne blöde Frage, wieso muessen die Daten denn in festen Zeitabständen gespeichert werden?

man könnte doch auch einfach einen Datensatz speichern wenn der Messwert einen gegeben Wert vom letzten gespeicherten Wert abweicht,
dann kann man einerseits die Daten im Sekundentakt reinholen , ohne die DB mit Abermillionen von gleichen Werten sich widerholenden aufzublasen
man haette dann die granularitaet Abnormalitaeten sekundengenau zu untersuchen

Nachteil: würde aber die Auswertungen etwas Komplizierter machen


mfg Hannes

Das ist eine prima Sache.
Wenn Anzahl der Messwerte und Toleranz gespeichert werden, kann man die Daten wenn es sein muss (>Auswertung/Export/Archiv) auch rekonstruieren (mit Toleranzverlust natürlich). Vermutlich sogar transparent on the fly per View bspw.