Der effektive Einsatz von Partition Pruning zur Optimierung der Abfragegeschwindigkeit (Teil 2)

Nachdem im ersten Beitrag dieser Blogreihe die herkömmlichen Wege zur Aufbewahrung historischer Daten dargestellt wurden, möchte ich in diesem zweiten Teil eine weitere, effektivere Möglichkeit zur Partitionierung einer historischen Tabelle vorstellen. Wesentlich hierbei ist, dass ein erheblicher Anstieg der Größe vermieden wird. Nennen wir diese Möglichkeit partitionierte Intervalltabelle. Der Algorithmus ist sehr einfach:

1. Die logische Tabellenstruktur bleibt die gleiche Struktur wie bei der Intervalllösung.
2. Die Tabelle ist durch GÜLTIG_VON in monatliche Partitionen unterteilt.
3. Die Werte vom letzten Tag des Monats werden zu Beginn des nächsten Monats immer kopiert, wobei GÜLTIG_VON dem ersten Tag des neuen Monats entspricht.

Sehen wir anhand eines Beispiels, wie dies funktioniert. Für den ersten Monat ergibt sich kein Unterschied gegenüber einer Intervalltabelle:

Sobald jedoch der nächste Monat beginnt, sollten wir einen neuen Datensatz erstellen und den vorherigen Datensatz für jedes Konto "schließen", unabhängig davon, ob die Attribute aktualisiert wurden (33333333333) oder nicht (11111111111 und 22222222222):

Bis zur Erstellung der nächsten Partition werden in der Partition II weitere Aktualisierungen vorgenommen, was ebenfalls wie in einer normalen Intervalltabelle erfolgt.

Selbstverständlich sind bei dieser Lösung redundante Zeilen erforderlich, was unüblich ist, wenn Sie die Leistung optimieren möchten. Es gibt jedoch einen weiteren riesigen Vorteil: Wir können sicher sein, dass für alle Zeilen, die für die Auswahl der Salden an dem bestimmten Datum erforderlich sind, das Datum GÜLTIG_VON in dem gleichen Monat liegt wie das angegebene Datum. Dementsprechend können wir beispielsweise die folgende Abfrage verwenden, um die Salden auszuwählen: 

Die Regel der Transitivität ermöglicht es Oracle, festzustellen, dass das Datum GÜLTIG_VON zwischen dem 01.06.2016 und dem 15.06.2016 liegen sollte, was bedeutet, dass nur die Partition II gelesen werden sollte, um die Abfrage durchzuführen. Grundsätzlich sollte nur eine Partition anstelle der ganzen Tabelle durchsucht werden. Aus diesem Grund könnten unsere Kennzahlen anhand der folgenden Formeln berechnet werden:

TRC = CA * (FC + 1 - FC/30) * HD * 12

RSR = CA * (FC + 1 - FC/30)

Und in Zahlen:

Abschließend ist festzuhalten, dass die partitionierte Intervalltabelle die Vorteile der zuvor genannten beiden Methoden kombiniert: Zwar ist eine minimal größere Tabelle als eine normale Intervalltabelle erforderlich, die Leistung der Auswahlmöglichkeiten ist jedoch mit derjenigen einer Snapshot-Tabelle vergleichbar. Zudem ist es verhältnismäßig einfach, Filter in Berichten anzupassen, um die Vorteile der Partitionierung zu nutzen.

Die Effektivität hängt in der Tat von der Häufigkeit der Änderungen von historisierten Attributen ab. In der folgenden Tabelle werden die oben genannten Maßnahmen auf der Grundlage der Häufigkeit der Änderungen verglichen:

Wie Sie sehen, sind die partitionierten Intervalltabellen für die Häufigkeit der Änderungen von einmal alle zwei Monate bis zu fünfmal pro Monat am effektivsten. Bei weniger häufigen Änderungen können Sie versuchen, größere Partitionen zu verwenden (die gleiche Logik funktioniert für vierteljährliche oder jährliche Partitionen zusätzlich zu monatlichen Partitionen). Wenn die Anzahl an Änderungen 5 übersteigt, können Sie wöchentliche Partitionen ausprobieren; wenn die Anzahl um die 20 liegt, ist die Snapshot-Tabelle die effektivste Lösung.

Es geht tatsächlich immer darum, wie partitionierte Intervalltabellen allgemein funktionieren könnten, aber "der Teufel steckt im Detail". Deshalb sind wichtige Kleinigkeiten zu beachten, die im nächsten Blogbeitrag dieser dreiteiligen Serie dargestellt werden.