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

Data Warehouses nehmen im Zuge der digitalen Transformation von Unternehmen eine immer zentralere Rolle ein. Denn im Zuge der Entscheidungsfindung hält ein gutes Data Warehouse für jegliche Fragestellung entscheidungsrelevante Informationen bereit. Ein DWH kann also als ein strategisches Management-Instrument gesehen werden, dessen reibungslose Funktionsweise essentiell für den zukünftigen Unternehmenserfolg ist. In diesem Blogbeitrag wird auf eines der wichtigsten Performancefeatures eingegangen, das Partition Pruning.

Physische Organisation von historischen Tabellen

In diesem Artikel schlage ich eine Möglichkeit zur physischen Organisation von historischen Tabellen vor, die es ermöglicht, Partition Pruning effektiv einzusetzen, um die Abfragegeschwindigkeit zu optimieren. Diese Möglichkeit wurde speziell für Datenbanken entwickelt, weshalb relativ komplizierte Datenmengen und dennoch ergiebige Auswahlmöglichkeiten vorausgesetzt werden.

Ich werde zwei Messgrößen verwenden, um die Effektivität jeder der beschriebenen Lösungen zu beurteilen

• Anzahl der Gesamtzeilen (TCR [Total Row Count])
• Zeilen pro einzelnem Lesevorgang (RSR [Rows per Single Read])

Bei der Anzahl der Gesamtzeilen wird die Gesamtgröße einer Tabelle ermittelt. Die Messgröße "Zeilen pro einzelnem Lesevorgang" vermittelt uns eine Vorstellung davon, wie viele Daten durchsucht werden sollten, um einer typischen Abfrage zu genügen. Bei einer typischen Abfrage einer historischen Tabelle handelt es sich meiner Ansicht nach um eine Abfrage, bei der Werte von historisierten Attributen eines bestimmten Datums zurückgegeben werden. Dies hat Auswirkungen auf einen bedeutenden Teil von Schlüsselwerten, wodurch der Indexzugriff ineffektiv wird.

Hat die Veränderung der Demographie von Daten Einfluss auf die Messgrößen?

Es ist klar, dass die Effektivität des physischen Designs von der Demographie der Daten abhängt. Für einen ersten Vergleich wird eine Tabelle herangezogen, die den Verlauf von Kontosalden bei einer Bank darstellt. Ziel ist es, darzustellen, wie Änderungen innerhalb der Demographie der Daten die Messgrößen beeinflussen können. Die Daten haben den folgenden Umfang:

• Anzahl an Konten (CA [Count of Accounts]): 1 000 000
• History Depth (HD): 5 Jahre
• Häufigkeit der Änderungen (FC [Frequency of Changes]): monatlich 5 Änderungen pro Konto

Erste Möglichkeit: die Intervalltabelle

Rufen wir uns zunächst die herkömmlichen Wege zur Aufbewahrung historischer Daten in Erinnerung. Bei der am häufigsten eingesetzten Lösung handelt es sich um eine Intervalltabelle. Jede Zeile der Tabelle enthält zwei Daten, die das Gültigkeitsintervall eines Datensatzes angeben.

Der Saldo für ein bestimmtes Datum könnte durch eine Abfrage ermittelt werden, wie sie in der nachstehenden Abbildung dargestellt ist:

Auf der Grundlage dieser Abfrage können wir den größten Nachteil von Intervalltabellen erkennen: Es besteht keine Möglichkeit, Datenpartitionierung einzusetzen, da GÜLTIG_VON/GÜLTIG_BIS von notwendigen Zeilen uneingeschränkt von dem angegebenen Datum abweichen können.

Die Leistungskennzahlen könnten anhand der folgenden Formeln berechnet werden:

TRC = CA * FC * HD * 12

RSR = TRC (da die ganze Tabelle gelesen werden sollte)

Insgesamt ergibt sich:

• Anzahl der Gesamtzeilen = 300 000 000
• Zeilen pro einzelnem Lesevorgang = 300 000 000

Zweite Möglichkeit: die Snapshot-Tabelle

Bei der zweiten Möglichkeit handelt es sich um eine Snapshot-Tabelle, was bedeutet, dass für jedes Konto für jeden Tag Salden gespeichert werden.

 Wenn man auf diese Weise vorgeht, werden viele redundante Informationen gespeichert. Es werden jedoch Abfragen mit "Equity"-Bedingung ermöglicht, um Salden eines bestimmten Datums auszuwählen:

Für diese Art von Abfragen kann Oracle leicht Partition Pruning anwenden, wenn die Basistabelle nach BALANCE_DT unterteilt ist. Aus diesem Grund können wir die Leistungskennzahlen wie folgt berechnen:

TRC = CA * HD * 365

RSR = CA (es gibt einen Datensatz je Konto je Partition)

Wird diese Vorgehensweise angewandt, so werden folgende Daten ermittelt:

Jeder einzelne Lesevorgang kostet für eine Snapshot-Tabelle wesentlich weniger als für eine Intervalltabelle. Dieser Vorteil wird jedoch durch einen Anstieg der Gesamtgröße der Tabelle zunichtegemacht. Für eine Tabelle dieser Größe bestehen weniger Chancen zur Zwischenspeicherung, und es ist mehr Zeit für Backup-, Wiederherstellungs- und Wartungsvorgänge erforderlich.

Mit welcher Lösung diese Faktoren umgangen werden können, erfahren Sie in unserem nächsten Blogbeitrag!