Wie optimiert man langsame Aggregationen auf einer großen Tabelle?

Question

IT Interview Practice · Accepted Answer

Bei einer langsamen Aggregation klären Sie zuerst, **was das Ergebnis bedeutet und welche Operation Zeit verbraucht**. Aggregation fasst Zeilen zusammen, etwa zu Umsatz je Händler. Die Kosten hängen von der gelesenen und kombinierten Datenmenge ab.

Betrachten wir ein Dashboard für den Vormonatsumsatz. Daran entscheiden wir zwischen besserer Abfrage, gespeicherter Zusammenfassung und ausgelagertem Reporting.

## 1. Prüfen Sie die Antwort vor der Beschleunigung

Klären Sie, ob Umsatz bezahlte oder erstellte Bestellungen meint, wie Erstattungen zählen und welche Währungen enthalten sind. Bestimmen Sie außerdem die erforderliche Aktualität. Das verändert Abfrage und Optimierungsmöglichkeiten.

Ein häufiger Fehler verbindet eine Zahlung mit mehreren Bestellpositionen und summiert dann ihren Betrag:

```text
[Payment: 100] -> [Join with 3 items] -> [100, 100, 100]
                                               |
                                          [SUM = 300]
```

Die Zahlen dienen der Illustration. Die Abfrage hat die Zahlung vervielfacht; Beschleunigung liefert nur schneller ein falsches Ergebnis. Aggregieren Sie auf der vorgesehenen fachlichen Ebene oder korrigieren Sie den Join vor der Leistungsmessung.

## 2. Finden Sie den teuren Ausführungsschritt

Ein Ausführungsplan zeigt die Operationen zum Ergebnis. Untersuchen Sie teure Schritte und Eingabegrößen, statt pauschal einen weiteren Index anzunehmen.

| Beobachtung | Zu untersuchende Frage |
| --- | --- |
| Viele irrelevante Zeilen werden gelesen | Können Filter oder Partition Pruning sie ausschließen? |
| Tatsächliche Anzahlen weichen stark von Schätzungen ab | Repräsentieren die Statistiken diese Daten? |
| Ein Join wiederholt viel Arbeit | Ist die Eingabe zu groß oder der Zugriff ungeeignet? |
| Gruppierung oder Sortierung schreibt temporär auf Platte | Lässt sich die Eingabe vor höheren Speicherlimits reduzieren? |

In PostgreSQL führt EXPLAIN (ANALYZE, BUFFERS) die Abfrage tatsächlich aus und liefert Laufzeitinformationen. Untersuchen Sie teure Abfragen kontrolliert oder mit bewusst begrenztem Produktionsbudget. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Reduzieren Sie Arbeit in der vorhandenen Datenbank

Wählen Sie Monat und benötigte Spalten. Prüfen Sie, ob der Plan unbeteiligte Partitionen wirklich überspringt und Joins unnötige Daten einbringen.

Ein Index hilft, wenn er genügend Leseaufwand spart. Braucht der Bericht fast alle Zeilen, kann ein sequenzieller Scan passend sein. Bewerten Sie Plan und gemessene Kosten, nicht bloß die Verwendung eines Index.

Wenn die Sortierung auf Platte ausweicht, kann eine kleinere Eingabe helfen. Mehr Speicher pro Abfrage kann dagegen bei parallelen Berichten den RAM aufbrauchen. Testen Sie mit repräsentativer Nebenläufigkeit.

## 4. Entscheiden Sie über vorberechnete Ergebnisse

Fragen viele Nutzer dieselben Summen ab und ist Verzögerung erlaubt, verschwenden wiederholte Scans der Rohbestellungen Arbeit. Eine Übersichtstabelle kann Summen nach Tag, Händler und Währung speichern; das Dashboard kombiniert diese kleineren Ergebnisse.

```text
[Orders] -> [Scheduled / incremental calculation]
                              |
                       [Daily summaries] -> [Dashboard]
```

Die Ersparnis entsteht durch einmalige gemeinsame Berechnung statt Wiederholung bei jedem Aufruf. Eine materialisierte Sicht speichert ebenfalls Abfrageergebnisse, mit eigenem Aktualisierungsverhalten.

Daraus entstehen Pflichten:

- Legen Sie Aktualisierungsintervalle fest und zeigen Sie die relevante Aktualität an.
- Verarbeiten Sie Erstattungen, späte Bestellungen und Korrekturen ohne Doppelzählung.
- Machen Sie Wiederholungen sicher und behalten Sie eine Möglichkeit zum Neuaufbau.
- Speichern Sie Summe und Anzahl zum Zusammenführen von Durchschnitten; ein Durchschnitt der Durchschnitte kann falsch sein.

Für dieses Dashboard passen vorberechnete Werte nur, wenn Aktualität und Korrekturregeln die ursprünglichen Anforderungen erfüllen.

## 5. Trennen Sie Reporting bei gemessenem Bedarf

Wenn breite analytische Scans teuer bleiben und Käufe beeinträchtigen, prüfen Sie einen passenden analytischen Speicher. Berücksichtigen Sie Synchronisationsverzug, Wiederherstellung und zusätzlichen Betrieb.

Eine Lesereplik kann die Reportinglast isolieren, doch dieselbe Abfrage bleibt dort möglicherweise teuer. Trennung verschiebt Kosten, beseitigt sie aber nicht zwangsläufig.

Vergleichen Sie jede Änderung mit einem vertrauenswürdigen Ergebnis bei gleicher Testlast. Prüfen Sie Antwortzeit, Ressourcen, Aktualität und Schreibeinflüsse.

**Merksatz:** korrektes Ergebnis → gemessener Engpass → weniger unnötige Arbeit → geeignete Vorberechnung → bei weiterem Bedarf separate Analytik.

Beobachtung	Zu untersuchende Frage
Viele irrelevante Zeilen werden gelesen	Können Filter oder Partition Pruning sie ausschließen?
Tatsächliche Anzahlen weichen stark von Schätzungen ab	Repräsentieren die Statistiken diese Daten?
Ein Join wiederholt viel Arbeit	Ist die Eingabe zu groß oder der Zugriff ungeeignet?
Gruppierung oder Sortierung schreibt temporär auf Platte	Lässt sich die Eingabe vor höheren Speicherlimits reduzieren?

1. Prüfen Sie die Antwort vor der Beschleunigung

2. Finden Sie den teuren Ausführungsschritt

3. Reduzieren Sie Arbeit in der vorhandenen Datenbank

4. Entscheiden Sie über vorberechnete Ergebnisse

5. Trennen Sie Reporting bei gemessenem Bedarf

Ähnliche Fragen