Tabellen für viele kleine Datensätze optimieren

[Dejan Vu]

Zitat von Sir Rufo:

Wofür benötigst du denn `id` int(10) unsigned NOT NULL auto_increment, ?

Weil es allgemein gesehen besser ist, für einen Datensatz einen eindeutigen anonymen Schlüssel zu haben. Ob es hier besser ist? Wenn man -wie vermutlich hier- die Daten nie ändert, sondern nur anfügt, braucht man das tatsächlich nicht. Da wird dann aber auch überhaupt kein PK benötigt.

Da man nur über vDate und ValueID abfragt, sollte ein Index reichen: ValueID+vDate (das meint Sir Rufo vermutlich mit 'PK über ValueID und vDate'. Hier steht jedoch nicht der Primary Key im Vordergrund, sondern ein nonunique index. Denn: Falls vDate in der Granularität nicht pikosekundengenau ist, wäre es denkbar, zwei Messwerte zum gleichen Zeitpunkt zu haben. Zumindest ausschließen kann man das nicht.

MySQL kennt vermutlich keinen Clustered Index, so wie MS SQL-Server. Gäbe es jedoch ein ähnliches Konzept, wäre ein Clustered Index über vDate+ValueID noch schneller, da bei den Abfragen nur ein Clustered Index-Seek/Scan ausgeführt wird.

Wenn man beim Auswerten über einen Zeitraum auch 'nur Morgens zwischen 8-10' abfragen will, dann Datum und Uhrzeit getrennt, sonst als Timestamp.

Grundsätzlich würde ich trotzdem das Konzept mit den redundanten Aggregationstabellen verfolgen, es macht einfach Spaß, in Echtzeit in die Daten zu zoomen und zu scrollen, ohne irgendwelche Last zu produzieren. Man sollte ja auch bedenken, das man entweder eine separate Auswerte-DB erstellt, oder -wenn man das nicht macht- den Server mit Auswertungen nicht zu sehr belastet. Das wäre dann ziemlich blöd, wenn er gerade wie ein blöder Daten fressen soll, aber nicht kann, weil eine Tabelle wegen einer Auswertung gelocked ist.

Zitat:

Mit den Partitions hat sich dann das Problem mit der Datensicherung auch erledigt,...

Top.