Tabellen für viele kleine Datensätze optimieren

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