Index setzen?

[Ghostwalker]

Vielleicht wärs hilfreich, wenn du etwas mehr über den Kontext sagst.

Aus der Abfrage heraus schließe ich mal, das du für jeden User (userid) das Datum der letzen
Buchung haben willst oder ?

Das würde u.U. ein DISTINCT oder DISTINCTROW helfen (Bin nicht wirklich firm mit Firebird).

[Gruber_Hans_12345]

Zitat von Ghostwalker:

Vielleicht wärs hilfreich, wenn du etwas mehr über den Kontext sagst.

Aus der Abfrage heraus schließe ich mal, das du für jeden User (userid) das Datum der letzen
Buchung haben willst oder ?

Das würde u.U. ein DISTINCT oder DISTINCTROW helfen (Bin nicht wirklich firm mit Firebird).

Ja korrekt ich habe eine Tabelle mit 800.000 Buchungen und will nun zu jedem User (sind 800) die letzte Buchung erfahren.

DISTINCTROW kannte ich gar nicht und weiss auch nicht wie ich das unter firebird verwende ... den eine SELECT DISTINCTROW mag er nicht, da sagt er er kenne das Feld DISTINCTROW nicht.

und beim DISTINCT Weiss ich nicht wie mir der helfen sollte
da bekomme ich gerade mal alle USer raus die irgendwann mal gebucht haben (Aber ja nicht die letze)

[tsteinmaurer]

Firebird kann keinen DESCENDING Index für ein GROUP BY verwenden:
http://tracker.firebirdsql.org/browse/CORE-4529

In einem lokalen Test hier mit 800.000 Datensätzen und unterschiedlichen Index-Kombinationen war der Full-Table Scan für deine Abfrage immer schneller, d.h. solange ein Index nicht für die Einschränkung der Ergebnismenge verwendet werden kann (fehlende WHERE Klausel), bremst er dich potentiell sogar aus, da das ein zusätzlicher "Hop" darstellt, bis er zum Datensatz (über den Indexeintrag) kommt.

D.h. ich würde eher in Richtung Firebird-Tuning/Konfiguration gehen und ihm mehr RAM geben. Z.B.:

• Größer PageCache
• Bzw. auch (wird sehr gerne auch vergessen!) dem Bereich für temporäre Sachen mehr RAM spendieren. Siehe TempCacheLimit in firebird.conf

Welche Firebird-Architektur verwendest du bzw. wie oft wird dieses Statement eigentlich ausgeführt?

LG

[Gruber_Hans_12345]

Zitat von tsteinmaurer:

Firebird kann keinen DESCENDING Index für ein GROUP BY verwenden:
http://tracker.firebirdsql.org/browse/CORE-4529

In einem lokalen Test hier mit 800.000 Datensätzen und unterschiedlichen Index-Kombinationen war der Full-Table Scan für deine Abfrage immer schneller, d.h. solange ein Index nicht für die Einschränkung der Ergebnismenge verwendet werden kann (fehlende WHERE Klausel), bremst er dich potentiell sogar aus, da das ein zusätzlicher "Hop" darstellt, bis er zum Datensatz (über den Indexeintrag) kommt.

D.h. ich würde eher in Richtung Firebird-Tuning/Konfiguration gehen und ihm mehr RAM geben. Z.B.:

• Größer PageCache
• Bzw. auch (wird sehr gerne auch vergessen!) dem Bereich für temporäre Sachen mehr RAM spendieren. Siehe TempCacheLimit in firebird.conf

Welche Firebird-Architektur verwendest du bzw. wie oft wird dieses Statement eigentlich ausgeführt?

LG

Ah okey danke

Das Problem ist, es wird teils relativ oft ausgeführt also jede Minute sowas ...
Ich werde es in diesem Fall dann zu dem jeweiligen User die letzte ID speichern, dann gehts natürlich extrem schnell.

Im Moment verwenden wir noch den 2.5 Firebird einmal als Classic und als SuperServer, aber es tut sich natürlich nicht so viel.

[tsteinmaurer]

Ja, würde mir z.b. einen Trigger (AFTER INSERT/UPDATE) auf deine Buchungstabelle geben, der dann den "LastTimestamp" in einem zusätzlichen Feld in deiner User-Tabelle wartet.

[p80286]

Zitat von Gruber_Hans_12345:

Das Problem ist, es wird teils relativ oft ausgeführt also jede Minute sowas ...
Ich werde es in diesem Fall dann zu dem jeweiligen User die letzte ID speichern, dann gehts natürlich extrem schnell.

Nichts für ungut, aber daß jede Minute sich jemand für die letzte Buchung von 800 Benutzern interessiert, halte ich für Blödsinn. Daß irgendjemand sich für die letzte Buchung eines Benutzers oder einer Benutzergruppe interessiert, das glaube ich schon schon eher.

Gruß
K-H

[jobo]

sehe ich auch so, es sei denn, wir reden von einer Börsensoftware oder sowas.

Aber
Es ist ja schon ein gangbarer Weg genannt worden, nämlich die denormalisierte Speicherung, die an solch einer Stelle (Konto/Buchaltung mit akt. Saldo, letzter Buchung, ..) nicht ungewöhnlich ist.

und was die Nutzergruppe angeht und nicht so brisante Fälle:
Eine "Gruppe" könnte bspw. die User mit Buchungen innerhalb der letzten 2 Wochen sein- nur mal so als Beispiel. Für meinetwegen Aussagefähigkeit am Telefon (Hotline) oder irgendwelche Statistiken, ergäbe sich aus solche einer -dann flotten- Abfrage Einzelwerte oder Kennwerte mit exakter Genauigkeit für die letzten 2 Wochen oder eben alles was älter ist. Für bspw. Hotline ("in den letzen 2 Wochen liegt keine Buchung vor") oder Management ("die Buchungszahlen in den letzen 14 Tagen steigen kontinuierlich") wäre das m.E. ok.

Ansonsten wäre man dann bei Datawarehouseanwendungen / Datenbanken.

[Gruber_Hans_12345]

Zitat von p80286:

Zitat von Gruber_Hans_12345:

Das Problem ist, es wird teils relativ oft ausgeführt also jede Minute sowas ...
Ich werde es in diesem Fall dann zu dem jeweiligen User die letzte ID speichern, dann gehts natürlich extrem schnell.

Nichts für ungut, aber daß jede Minute sich jemand für die letzte Buchung von 800 Benutzern interessiert, halte ich für Blödsinn. Daß irgendjemand sich für die letzte Buchung eines Benutzers oder einer Benutzergruppe interessiert, das glaube ich schon schon eher.

Gruß
K-H

das stimmt schon direkt nicht aber indirekt, es wird halt zyklisch der status der 800 user geladen, und diese dann gruppiert auf abteilungen dargestellt, wobei man mit incrementalsearch dann sehr schnell zum status des einzelnen users kommen kann.
Da ja auch paar andere infos geladen werden.
Kann man sicher auch besser machen und anders optimieren, aber eben der extremst große und bis jetzt unbekannte zeitfaktor war eben das FireBird beim GroupBy keinen Index verwenden kann.
Und die 800.000 Datensätze in ein paar Jahre dann 8.000.000 werden usw.

Aber es wurde ja schon ein WorkAround genanntm zumindest solange bis FireBird das hoffentlich irgendwann mal optimieren kann

[jobo]

Zitat von Gruber_Hans_12345:

Kann man sicher auch besser machen und anders optimieren, aber eben der extremst große und bis jetzt unbekannte zeitfaktor war eben das FireBird beim GroupBy keinen Index verwenden kann.
Und die 800.000 Datensätze in ein paar Jahre dann 8.000.000 werden usw.

Aber es wurde ja schon ein WorkAround genanntm zumindest solange bis FireBird das hoffentlich irgendwann mal optimieren kann

Also was die Optimierbarkeit angeht würde ich mir nicht allzuviel Hoffnungen machen. Das ist ein systematisches Problem was mehr oder weniger zu einem Fullscan führt. Bei Optimierung vielleicht mal eines Tages ein Rangescan oder so.
Wie Du selbst schreibst, skaliert die Lösung nicht und Du weißt schon jetzt, dass Dein Problem mit der "Lösung" Fullscan von Jahr zu Jahr größer wird (oder Tag zu Tag).
Hier muss die Last anders abgefangen werden, um zu einer dauerhaften, skalierenden Lösung zu kommen. Das ist wie bereits geschrieben die denormalisierte Ablage der benötigten Infos oder wenigstens von Hilfswerten.

Bei Denormalisierung wiederum ist dringend zu empfehlen, den Speichervorgang (insert & update) so durch geeignete Datenbankconstraint zu flankieren, dass nieniemals Differenzen in den denormalisiert abgelegten Daten entstehen können(Datenkonsistenz!). Das kann FB mit Sicherheit.

Auf diese Art (Denormalisierung) wird die Last der Abfrage verschoben auf den Zeitpunkt der "Datenentstehung". Sprich die Abfrage wird schneller, der Preis ist langsameres speichern (was aber seltener und gezielter stattfindet).

[mkinzler]

Zitat:

Sprich die Abfrage wird schneller, der Preis ist langsameres speichern (was aber seltener und gezielter stattfindet).

Und ist auch weniger aufwendig, da ja genau 1 weiterer Datensatz geändert bzw. erzeugt werden muss.