Tabellen für viele kleine Datensätze optimieren

[Dejan Vu]

Zitat von Jasocul:

... sind Indexed Views. Dort hast du dann automatisch deine aggregierten Werte und brauchst keine Trigger oder Events. Es gibt aber wohl ein paar Einschränkungen, ...

Achtung! mySQL... nicht SQL-Server

[Jasocul]

Zitat von Dejan Vu:

Achtung! mySQL... nicht SQL-Server

Ups. Sorry.

[p80286]

Da ich bisher nur gute Erfahrungen mit views gemacht habe, würde ich diese auch bevorzugen (oracle).
Jedesmal wenn ich irgendwelche kumulierten Daten in die Finger bekomme, gibt es ein paar Abweichungen, weil immer der eine oder andere Job nicht gelaufen ist oder einen Fehler hatte oder...
(Es kommt immer auf die Daten - die gespeicherten und die gefragten - an)

Gruß
K-H

[himitsu]

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

Drum auch der Vorschlag mit dem Data-Warehouse.
Die Dinger sind erstmal für viele Daten ausgelegt und sie bieten auch sowas wie Views, nur daß Diese job-/zeitgesteuert die Daten der Ansichten vorberechnen, was dann die Abfragen schneller macht.

[Medium]

Jetzt machst du mich aber spontan unglücklich, p80286. Ich habe soeben folgende Prozedur im Testlauf, die da alle 10 Sekunden* vom selben Programm ausgeführt wird, dass auch die originale Historie schreibt, und für das Pollen meiner Energiewerte sorgt:

Delphi-Quellcode:

procedure TForm1.MakeGranularValues;
  procedure ProcessGranularity(aTableName, aPriorGranularityTableName: String; aTimeDeltaInMinutes: Integer);
  var
    d1, d2: TDateTime;
  begin
    // Einen Zeitpunkt finden, zu dem der End-Zeitpunkt d2 in der Vergangenheit liegt, und
    // dessen Start-Zeitpunkt dem Raster gehorcht, dass entsteht, wenn man ab 00:00:00 des Tages an
    // in "aTimeDeltaInMinutes" Schritten hochgezählt hat. Beginne mit 0 Uhr des gestrigen Tages, da
    // 24 Stunden das größte Raster sind, und der gestrige Tag somit noch erfasst wird.
    d1 := Trunc(Now)-1;
    d2 := IncMinute(d1, aTimeDeltaInMinutes);
    while (d2 < Now) do
    begin
      d1 := d2;
      d2 := IncMinute(d1, aTimeDeltaInMinutes);
    end;
    d1 := IncMinute(d1, -aTimeDeltaInMinutes);
    d2 := IncMinute(d2, -aTimeDeltaInMinutes);

    Qry.SQL.Text := 'SELECT COUNT(valueID) FROM '+aTableName+' WHERE vdate BETWEEN :d1 AND :d2';
    Qry.ParamByName('d1').AsDateTime := d1;
    Qry.ParamByName('d2').AsDateTime := d2;
    Qry.Open;
    if Qry.Fields[0].AsInteger = 0 then
    begin
      Qry.Close;
      Qry.SQL.Text :=
        'INSERT INTO '+aTableName+' (vdate, valueID, maxValue, meanValue) '+
        '(SELECT :d1, valueID, MAX(maxValue), SUM(meanValue)/COUNT(meanValue) '+
        'FROM '+aPriorGranularityTableName+' '+
        'WHERE (vdate BETWEEN :d1 and :d2) '+
        'GROUP BY valueID)';
      Qry.ParamByName('d1').AsDateTime := d1;
      Qry.ParamByName('d2').AsDateTime := d2;
      Qry.Execute;
    end
    else
    begin
      Qry.Close;
    end;
  end;
begin
  ProcessGranularity('history_g10min', 'history',          10);
  ProcessGranularity('history_g30min', 'history_g10min',   30);
  ProcessGranularity('history_g1h',    'history_g30min',   60);
  ProcessGranularity('history_g6h',    'history_g1h',     360);
  ProcessGranularity('history_g24h',   'history_g6h',    1440);
end;

Klar ist, dass wenn diese irgendwo mal auf einen Hammer läuft, dann kummulierte Daten fehlen. Jedoch werde ich da noch diverse Schutzblöcke einarbeiten, und es spricht nichts dagegen im Bedarfsfall eine komplette Rekunstruktion der kummulierten Tabellen von der originalen Historie an zu bilden. Oder gar nur punktuelle für fehlende Zeiträume.

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.


*) Alle 10min sollte genügen, zum testen und schauen wie es sich auf die Performance auswirkt hab ich's mal schneller gemacht

[Dejan Vu]

jasocul meinte 'materialized views' oder 'indexed views', wie sie bei SQL-Server heißen. Das sind keine Views im klassischen Sinn, also einfach nur kompilierte Queries, sondern wirkliche Tabellen (weswegen sie bei Oracle eben 'materialized' heißen). Bei Oracle muss man die Aktualisierung selbst anstubsen, soweit ich mich erinnere, bei SQL-Server nicht.

Da das normale Tabellen sind, kann man eben auch einen Index draufpacken, was bezüglich der Auswertungen wirklich eine tolle Sache ist.

Ich sehe gerade, das geht auch irgendwie mit mySQL:
http://www.fromdual.com/mysql-materialized-views

PS: Kennt mySQL kein 'AVG' (als Ersatz zu SUM(**)/COUNT(**))? Wobei das eben auch in die Hose gehen kann, wenn Count(*) = 0 ist...

[Medium]

Wenn COUNT() 0 ist, werden keine Sätze selektiert, also auch die Funktion nicht ausgeführt. Gut möglich, dass es AVG() gibt - ich schaue mal. Hab nicht daran gedacht, dass es das ja schon fertig geben könnte

Die materialized Views schaue ich mir mal an, klingt "spacig".

[p80286]

Zitat von Medium:

Jetzt machst du mich aber spontan unglücklich, p80286.

War nicht meine Absicht. Ich kann Dir nur sagen, das ich mit Datawarehouse bisher nur Ärger habe, was auch daran liegt, das die DatenAnforderer sich nicht darüber im klaren sind, daß die Daten -in meinem Fall- vom Vortag sind. Sogar bei statistischen Auswertungen ist das schon aufgefallen.

Darum
1. es kommt darauf an
2. solange es läuft ist es in Ordnung
3. Ein Patentrezept gibt es nicht.

Gruß
K-H

[Namenloser]

Mal ganz ketzerisch gefragt: Braucht man da überhaupt SQL? Ich meine, bei Webservern und generell unter Unix ist es ja auch Gang und Gäbe, Zugriffslogs (das können auch gerne mal mehrere Eintrage pro Sekunde werden) einfach als Textdatei mit einem Datensatz pro Zeile abzuspeichern und in regelmäßigen Abständen, z.B. einmal am Tag, ein neues Logfile anzufangen und das alte ggf. zu komprimieren. So hat man dann eine Reihe von Logfiles, für jeden Tag eins.

Wenn man eigentlich eh nur den Verlauf plotten will und nicht wirklich komplizierte relationale Abfragen hat, dann reicht das doch im Grunde.

[Dejan Vu]

Die Frage ist gar nicht ketzerisch, denn man soll ja immer den einfachsten und kürzesten Weg gehen: jede Form der Abfrage, sogar das speichern selbst, ist per Textdatei mit einem höheren Aufwand verbunden, als ein RDBMS damit zu beauftragen.