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.
Table of Contents
Wesentlich hierbei ist, dass ein erheblicher Anstieg der Größe vermieden wird. Nennen wir diese Möglichkeit partitionierte Intervalltabelle. Der Algorithmus ist sehr einfach:
Die logische Tabellenstruktur bleibt die gleiche Struktur wie bei der Intervalllösung.
Die Tabelle ist durch GÜLTIG_VON in monatliche Partitionen unterteilt.
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.
Wer ist b.telligent?
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.
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.