Datenlogger mit MSSQL und Index-Fragmentierung

[Uwe Raabe]

Nur mal so ein wenig out-of-the-box gedacht:

Was wäre wenn du alle Datensätze im Voraus anlegst, diese nach aufsteigender ID per UPDATE befüllst und wenn du beim letzten angekommen bist wieder mit dem ersten weitermachst (ein Ringbuffer halt). In einer separaten Tabelle führst du ID und LogTime des ältesten und neuesten Satzes mit.

Da ja (nach 90 Tagen) für jede Sekunde ein

SQL-Code:

LogTime NOT NULL

-Datensatz vorhanden ist, kannst du unter Berücksichtigung des Überlaufs für jede Sekunde die ID bestimmen. Den Index auf LogTime brauchst du nicht mehr und der für ID ändert sich nicht, da beim UPDATE die ID gleich bleibt.

Abfragen nach Zeiträumen errechnen die WHERE Klausel für die entsprechenden ID Werte (in den ersten 90 Tagen noch mit

SQL-Code:

LogTime NOT NULL

) und die Sortierung läuft über ein

SQL-Code:

ORDER BY LogTime

.

Das müsste man sicher noch im Detail ausarbeiten, aber es wäre zumindest ein interessanter Ansatz.

[BigAl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1550284)

Nur mal so ein wenig out-of-the-box gedacht:

Was wäre wenn du alle Datensätze im Voraus anlegst, diese nach aufsteigender ID per UPDATE befüllst und wenn du beim letzten angekommen bist wieder mit dem ersten weitermachst (ein Ringbuffer halt). In einer separaten Tabelle führst du ID und LogTime des ältesten und neuesten Satzes mit.

Da ja (nach 90 Tagen) für jede Sekunde ein

SQL-Code:

LogTime NOT NULL

-Datensatz vorhanden ist, kannst du unter Berücksichtigung des Überlaufs für jede Sekunde die ID bestimmen. Den Index auf LogTime brauchst du nicht mehr und der für ID ändert sich nicht, da beim UPDATE die ID gleich bleibt.

Abfragen nach Zeiträumen errechnen die WHERE Klausel für die entsprechenden ID Werte (in den ersten 90 Tagen noch mit

SQL-Code:

LogTime NOT NULL

) und die Sortierung läuft über ein

SQL-Code:

ORDER BY LogTime

.

Das müsste man sicher noch im Detail ausarbeiten, aber es wäre zumindest ein interessanter Ansatz.

Hallo Uwe

Ich bin immer wieder begeistert von Deiner Denkweise. Genau so ein Ansatz ist mir im Kopf herumgeschwirrt. Das könnte funktionieren, wenn da auch mit einer kleinen Hürden für die ich noch keine Lösung habe:

Aktuell speichere ich einen NULL-Datensatz ab, der mir eine Unterbrechung der Aufzeichnung markiert. Wird die Anlage also mal abgeschaltet, dann kann ich damit die Lücke im Graph entsprechend visualisieren:

Anhang 57682

Wie ich diesen "Sprung" in der vordefinierten Tabell festhalten soll weiß ich momentan noch nicht. Eine Idee wäre eine Spalte wie "NextID" neben der "ID" einzuführen. Diese speichert dann den jeweils nächsten gültigen Index. Die Sprünge müsste ich dann halt mit meiner Software herausfiltern. Da ich in der Anzeige maximal zwei Stunden pro Seite ausgebe wäre das bei 7200 Datensätzen nicht die Welt...

Ich werde aber auf jeden Fall diesen Ansatz weiter verfolgen.

Danke!

[Uwe Raabe]

Die Logik aus einem sekundengenauen Datum eine ID zu berechnen erfordert allerdings genau einen Datensatz für jede Sekunde. Eine solche Unterbrechung würde dann eben auch durch mehrere Null-Sätze in der Tabelle hinterlegt werden. Ob du das dann als einen Eintrag anzeigst bleibt dir ja dann immer noch offen.

[BigAl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1550286)

Die Logik aus einem sekundengenauen Datum eine ID zu berechnen erfordert allerdings genau einen Datensatz für jede Sekunde. Eine solche Unterbrechung würde dann eben auch durch mehrere Null-Sätze in der Tabelle hinterlegt werden. Ob du das dann als einen Eintrag anzeigst bleibt dir ja dann immer noch offen.

Klar. Es gibt halt zwei Möglichkeiten:

1. Nach einer Unterbrechung die übersprungenen Datensätze mit entsprechenden Null-Werten füllen.

oder

2. Eben mit der "NextID"-Markierung entsprechend markieren wie viele Datensätze zu überspringen sind.

Bei Lösung 2 müsste halt nur ein Datensatz aktualisiert werden und man könnte die Null-Daten nach dem Einlesen schneller bearbeiten (überspringen), da nicht jeder Datensatz betrachtet werden müsste. Allerdings wäre dann das Problem, dass man im schlimmsten Fall innerhalb der Null-Werte anfängt zu lesen und nicht weiß, dass es sich um Null-Werte handelt. Da ist dann wieder Lösung 1 besser...

[TigerLilly]

Die Idee mit dem Vorausfüllen ist gut. Mich würde nur der Aufwand abschrecken und der Overhead, der dadurch entsteht.

Ein REORGANIZE müsstest du nicht nach jedem Löschen ausführen. Ich schätze mal, dass 1x am Tag genügt. REORGANIZE ist Standard-MS-SQL, das kann schon mehrfach aufrufen.

Vielleicht kann man auch Hardwareseitig optimieren: Mehr RAM + den Index auf eine eigene SSD.

[BigAl]

Zitat:

Zitat von TigerLilly (Beitrag 1550296)

Die Idee mit dem Vorausfüllen ist gut. Mich würde nur der Aufwand abschrecken und der Overhead, der dadurch entsteht.

Ein REORGANIZE müsstest du nicht nach jedem Löschen ausführen. Ich schätze mal, dass 1x am Tag genügt. REORGANIZE ist Standard-MS-SQL, das kann schon mehrfach aufrufen.

Vielleicht kann man auch Hardwareseitig optimieren: Mehr RAM + den Index auf eine eigene SSD.

Das mit dem Ausfüllen ist eigentlich nicht so schlimm: "UPDATE ... WHERE ID >= x AND ID <= x+n" oder so ähnlich. Die Null-Kennung kann man ja an einem Feld festmachen. Es muss ja nicht alles genullt werden...

Das mit dem Speicher ist halt ein Problem. Die Express-Version des SQL-Servers ist auf 10 GB Größe begrenzt. Da knallt es sehr schnell (habe es ausprobiert). Selbst meine "großen" Version des Servers (ich nutze hier den Development-Server) ist da eine Weile beschäftigt und erzeugt Unmengen an Daten...