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.
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
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.
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:
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:
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!
Du willst den IoT Core durch eine Multi-Cloud-Lösung ersetzen und die Vorteile weiterer IoT-Services von Azure oder Amazon Web Services nutzen? Dann melde Dich bei uns und wir unterstützen Dich bei der Umsetzung mit unserer Expertise und dem b.telligent Partnernetzwerk.
Domain Lead Data Platform & Data Management
Domain Lead Data Platform & Data Management
Exasol ist ein führender Hersteller von analytischen Datenbanksystemen. Das Kernprodukt ist eine auf In-Memory-Technologie basierende Software für die professionelle, parallele und schnelle Datenanalyse. Normalerweise werden SQL-Statements in einem SQL-Skript sequenziell abgearbeitet. Wie können aber mehrere Statements gleichzeitig ausgeführt werden? Dies zeigen wir anhand eines einfachen Skripts in diesem Blogbeitrag.
Viele Unternehmen mit SAP-Quellsystemen kennen diese Herausforderung: Sie wollen ihre Daten in einen Azure Data Lake integrieren, um sie dort mit Daten aus anderen Quellsystemen und Applikationen für Reporting und Advanced Analytics weiterzuverarbeiten. Auch die neuen SAP-Informationen zur Nutzung des SAP-ODP-Frameworks führten bei b.telligent Kunden zu Fragen. In diesem Blogbeitrag stellen wir drei gute Ansätze zur Datenintegration (in die Microsoft Azure Cloud) vor, die wir bei b.telligent empfehlen und die von der SAP unterstützt werden.
In Teil 1 fassen wir die Anforderungen der Kunden zusammen.
Viele Unternehmen entscheiden sich im Rahmen ihrer aktuellen Modernisierung- und Digitalisierungsinitiativen, ihr Datawarehouse (DWH) oder auch ihre Datenplattform in die Cloud zu heben. Dieser Beitrag diskutiert aus fachlicher/organisatorischer Sicht, welche Aspekte dafür besonders wichtig sind und welche Strategien dabei helfen, etwaige Risiken zu minimieren. Eine Migration sollte nicht als rein technische Übung verstanden werden. "Weiche" Faktoren und Fachlichkeit haben einen deutlich höheren Einfluss.
Kein vorheriger Beitrag
Kein nächster Beitrag
