Zeitliches Problem mit LIMIT

[Fabi]

Hallo Leute,

mein Problem ist Folgendes:

Ich habe einen MySQL-Datenbankserver mit Protokolldatensätzen die pro Tag gut und gerne 200.000 DS ausmachen.

Wenn ich jetzt mit sum(Gesendete Bytes) AS summe... order by summe LIMIT 10 eine Abfrage darauf mache, kann das schon mal 5 Minuten (bei Auswertungen über Monate) dauern.

Ich möchte aber quasi nur die Top Ten, wer am meisten Traffic verursacht hat.

Hat irgendwer von euch eine Idee wie man das anderweitig lösen könnte, weil ja bei LIMIT 10 erst alle Datensätze summiert werden und dann einfach nur die ersten 10 genommen werden.

Programmiert wir übrigens in Java, falls die Info jemand braucht.

[Monty82]

Du könntest am Ende jeden Tages zeitgesteuert nur die Top-Ten in eine extra Tabelle schreiben, aus der Du dann die Statistiken für das GUI liest.

[kills]

Oder einen Trigger auf die Tabelle legen der bei jedem Insert in einer Extra Tabelle immer der Wert der hinzugefügt wird aufaddiert..

[Aiun]

die Belastung ist nicht das limit, sondern das Order.

Praktisch "muss" er jeden Datensatz bearbeiten der überhaupt in der Tabelle steht. Das dann nach üblichen Sortier-Algorythmen durchgehen. Erst danach wird limittiert.

Je nachdem wie viel du da drinstehen hast....kann ich verstehen wenn das DBMS da etwas in die knie geht. ^^

Zum Empfehlen währe eine Auslagerung der Daten, das nur die Daten in der Tabelle bleiben die du wirklich noch brauchst. Alles andere in eine Sicherrungsdatei.

Alternative: je nachdem wie weit zu zurückblicken willst, die Daten von 1-2 Monaten jeweils in eine eigene Tabelle.

[Fabi]

Das Problem ist, dass der Kunde am Fontend eine beliebige Zeitspanne auswählen kann. Also Auslagern geht schlecht.

[Aiun]

naja, du wirst doch irgendwo spezifiziert haben in welchem Rahmen die Analysen durchgeführt werden oder ?

ansonsten wird die Datenbank ganz sicher irgendwann in die knie gehen...

bzw. ab einer bestimmten Datenmenge ist es "normal" das das seine Zeit dauert. Und da ist egal wie viele Informationen du haben "willst", da geht es darum wie viele Informationen durchsucht werden müssen um dir das gewünschte zusammen zu stellen.

Evtl. solltest du auch feststellen "wann" jeweils so eine Abfrage gemacht wird.

also z.B. alle 3 Monate für jeweils diese 3 Monate und 1x im Jahr für das ganze Jahr.

Dann lagerst du nach jeder 3 Monats-Prüfung die Daten aus bzw. erstellst einen durchschnitt für die Jahresprüfung.

Hört sich für mich ein wenig so an als währe da ein Tool ohne Beschränkung gefordert...das ist unmöglich ^^ Spätestens wenn die Festplatte dicht ist kommen keine Datensätze mehr drauf.

[zirri]

Das Problem ist, dass der Kunde am Fontend eine beliebige Zeitspanne auswählen kann. Also Auslagern geht schlecht.

wenn der user im frontend die zeitspanne einschraenkt, waere ne WHERE clause vielleicht das Richtige, das quaelt die DB zwar auch, aber...

ansonsten bau dir ne view, die die daten verdichtet...

oder vielleicht mal an geschickte Indizes gedacht ?

gruss

[Fabi]

Ich habs jetzt so gelöst, dass ich versucht habe, so wenige Daten wie möglich in externe Tabellen auszulagern.

Das ist jetzt vielleicht nicht mehr super normalisiert aber ich habe eine enorme Zeitersparnis.

Meine Abfrage dauerte vorher (im phpMyAdmin wohl gemerkt, also kein Programmierfehler) 73 sek. Sie bestand aus 3 Tabellen die miteinander verjoint waren. Nach der Integration der ersten beiden Tabellen erreichte ich 34 sek und nach der Integration der letzten Tabelle dauerte die ABfrage 3 sekunden.

Also Joins sind so ziemlich der Zeitintensivste Teil der Abfrage. Wohl gemerkt, die Abfrage ging über 3 Mio. Datensätze.

[zirri]

was lernen wir daraus ?

normalieren ist schoen und gut, aber macht nicht immer sinn.......