Data Warehousing - Partitionierungsstrategie
Die Partitionierung wird durchgeführt, um die Leistung zu verbessern und die einfache Verwaltung von Daten zu erleichtern. Die Partitionierung hilft auch dabei, die verschiedenen Anforderungen des Systems auszugleichen. Es optimiert die Hardwareleistung und vereinfacht die Verwaltung des Data Warehouse, indem jede Faktentabelle in mehrere separate Partitionen aufgeteilt wird. In diesem Kapitel werden verschiedene Partitionierungsstrategien erläutert.
Warum ist eine Partition notwendig?
Die Partitionierung ist aus folgenden Gründen wichtig:
- Für eine einfache Verwaltung
- Um die Sicherung / Wiederherstellung zu unterstützen,
- Um die Leistung zu verbessern.
Für eine einfache Verwaltung
Die Faktentabelle in einem Data Warehouse kann bis zu Hunderten von Gigabyte groß werden. Diese riesige Größe der Faktentabelle ist als einzelne Einheit sehr schwer zu verwalten. Daher muss es partitioniert werden.
Unterstützung bei der Sicherung / Wiederherstellung
Wenn wir die Faktentabelle nicht partitionieren, müssen wir die vollständige Faktentabelle mit allen Daten laden. Durch die Partitionierung können wir nur so viele Daten laden, wie regelmäßig benötigt werden. Es reduziert die Ladezeit und verbessert auch die Leistung des Systems.
Note- Um die Sicherungsgröße zu verringern, können alle Partitionen außer der aktuellen Partition als schreibgeschützt markiert werden. Wir können diese Partitionen dann in einen Zustand versetzen, in dem sie nicht geändert werden können. Dann können sie gesichert werden. Dies bedeutet, dass nur die aktuelle Partition gesichert werden soll.
Um die Leistung zu verbessern
Durch Partitionieren der Faktentabelle in Datensätze können die Abfrageprozeduren verbessert werden. Die Abfrageleistung wird verbessert, da die Abfrage jetzt nur die relevanten Partitionen durchsucht. Es müssen nicht die gesamten Daten gescannt werden.
Horizontale Partitionierung
Es gibt verschiedene Möglichkeiten, wie eine Faktentabelle partitioniert werden kann. Bei der horizontalen Partitionierung müssen wir die Anforderungen an die Verwaltbarkeit des Data Warehouse berücksichtigen.
Aufteilung nach Zeit in gleiche Segmente
Bei dieser Partitionierungsstrategie wird die Faktentabelle auf der Grundlage des Zeitraums partitioniert. Hier stellt jeder Zeitraum eine signifikante Aufbewahrungsfrist innerhalb des Geschäfts dar. Zum Beispiel, wenn der Benutzer nach fragtmonth to date dataDann ist es angebracht, die Daten in monatliche Segmente zu unterteilen. Wir können die partitionierten Tabellen wiederverwenden, indem wir die darin enthaltenen Daten entfernen.
Aufteilung nach Zeit in Segmente unterschiedlicher Größe
Diese Art der Partitionierung erfolgt dort, wo nur selten auf veraltete Daten zugegriffen wird. Es wird als Satz kleiner Partitionen für relativ aktuelle Daten und als größere Partition für inaktive Daten implementiert.
Zu beachtende Punkte
Die detaillierten Informationen bleiben online verfügbar.
Die Anzahl der physischen Tabellen wird relativ gering gehalten, was die Betriebskosten reduziert.
Diese Technik eignet sich, wenn eine Mischung aus Daten, die den aktuellen Verlauf eintauchen, und Data Mining über den gesamten Verlauf erforderlich ist.
Diese Technik ist nicht nützlich, wenn sich das Partitionierungsprofil regelmäßig ändert, da durch die Neupartitionierung die Betriebskosten des Data Warehouse erhöht werden.
Partition in einer anderen Dimension
Die Faktentabelle kann auch auf der Grundlage anderer Dimensionen als der Zeit wie Produktgruppe, Region, Lieferant oder einer anderen Dimension partitioniert werden. Lassen Sie uns ein Beispiel haben.
Angenommen, eine Marktfunktion wurde wie in a in verschiedene regionale Abteilungen strukturiert state by stateBasis. Wenn jede Region Informationen abfragen möchte, die in ihrer Region erfasst wurden, wäre es effektiver, die Faktentabelle in regionale Partitionen zu unterteilen. Dadurch werden die Abfragen beschleunigt, da keine relevanten Informationen gescannt werden müssen.
Zu beachtende Punkte
Die Abfrage muss keine irrelevanten Daten scannen, was den Abfrageprozess beschleunigt.
Diese Technik ist nicht geeignet, wenn sich die Abmessungen in Zukunft wahrscheinlich nicht ändern werden. Es lohnt sich also festzustellen, dass sich die Dimension in Zukunft nicht ändert.
Wenn sich die Dimension ändert, muss die gesamte Faktentabelle neu partitioniert werden.
Note - Wir empfehlen, die Partition nur auf der Grundlage der Zeitdimension durchzuführen, es sei denn, Sie sind sicher, dass sich die vorgeschlagene Dimensionsgruppierung innerhalb der Lebensdauer des Data Warehouse nicht ändert.
Partition nach Größe der Tabelle
Wenn es keine klare Grundlage für die Aufteilung der Faktentabelle in eine Dimension gibt, sollten wir dies tun partition the fact table on the basis of their size.Wir können die vorgegebene Größe als kritischen Punkt festlegen. Wenn die Tabelle die vorgegebene Größe überschreitet, wird eine neue Tabellenpartition erstellt.
Zu beachtende Punkte
Diese Partitionierung ist komplex zu verwalten.
Es sind Metadaten erforderlich, um zu identifizieren, welche Daten in jeder Partition gespeichert sind.
Abmessungen der Partitionierung
Wenn eine Dimension eine große Anzahl von Einträgen enthält, müssen die Dimensionen partitioniert werden. Hier müssen wir die Größe einer Dimension überprüfen.
Stellen Sie sich ein großes Design vor, das sich im Laufe der Zeit ändert. Wenn wir alle Variationen speichern müssen, um Vergleiche anzuwenden, kann diese Dimension sehr groß sein. Dies würde definitiv die Reaktionszeit beeinflussen.
Round Robin Partitionen
Wenn in der Round-Robin-Technik eine neue Partition benötigt wird, wird die alte archiviert. Es verwendet Metadaten, damit der Benutzerzugriffstool auf die richtige Tabellenpartition verweisen kann.
Diese Technik erleichtert die Automatisierung von Tabellenverwaltungsfunktionen im Data Warehouse.
Vertikale Partition
Vertikale Partitionierung, teilt die Daten vertikal auf. Die folgenden Bilder zeigen, wie die vertikale Partitionierung durchgeführt wird.
Die vertikale Partitionierung kann auf zwei Arten durchgeführt werden:
- Normalization
- Zeilenaufteilung
Normalisierung
Normalisierung ist die relationale Standardmethode der Datenbankorganisation. Bei dieser Methode werden die Zeilen zu einer einzigen Zeile zusammengefasst, wodurch der Platzbedarf verringert wird. Schauen Sie sich die folgenden Tabellen an, die zeigen, wie die Normalisierung durchgeführt wird.
Tabelle vor der Normalisierung
| Produkt ID | Menge | Wert | sales_date | Store_id | Geschäftsname | Ort | Region |
|---|---|---|---|---|---|---|---|
| 30 | 5 | 3.67 | 3-Aug-13 | 16 | sonnig | Bangalore | S. |
| 35 | 4 | 5.33 | 3-Sep-13 | 16 | sonnig | Bangalore | S. |
| 40 | 5 | 2,50 | 3-Sep-13 | 64 | san | Mumbai | W. |
| 45 | 7 | 5.66 | 3-Sep-13 | 16 | sonnig | Bangalore | S. |
Tabelle nach der Normalisierung
| Store_id | Geschäftsname | Ort | Region |
|---|---|---|---|
| 16 | sonnig | Bangalore | W. |
| 64 | san | Mumbai | S. |
| Produkt ID | Menge | Wert | sales_date | Store_id |
|---|---|---|---|---|
| 30 | 5 | 3.67 | 3-Aug-13 | 16 |
| 35 | 4 | 5.33 | 3-Sep-13 | 16 |
| 40 | 5 | 2,50 | 3-Sep-13 | 64 |
| 45 | 7 | 5.66 | 3-Sep-13 | 16 |
Zeilenaufteilung
Durch das Aufteilen von Zeilen bleibt in der Regel eine Eins-zu-Eins-Zuordnung zwischen Partitionen. Das Motiv der Zeilenaufteilung besteht darin, den Zugriff auf große Tabellen zu beschleunigen, indem deren Größe verringert wird.
Note - Stellen Sie bei Verwendung der vertikalen Partitionierung sicher, dass keine größere Verknüpfungsoperation zwischen zwei Partitionen ausgeführt werden muss.
Identifizieren Sie den Schlüssel zur Partition
Es ist sehr wichtig, den richtigen Partitionsschlüssel auszuwählen. Die Auswahl eines falschen Partitionsschlüssels führt zu einer Neuorganisation der Faktentabelle. Lassen Sie uns ein Beispiel haben. Angenommen, wir möchten die folgende Tabelle partitionieren.
Account_Txn_Table
transaction_id
account_id
transaction_type
value
transaction_date
region
branch_nameWir können wählen, auf jedem Schlüssel zu partitionieren. Die zwei möglichen Schlüssel könnten sein
- region
- transaction_date
Angenommen, das Unternehmen ist in 30 geografischen Regionen organisiert und jede Region hat eine andere Anzahl von Niederlassungen. Das gibt uns 30 Partitionen, was vernünftig ist. Diese Partitionierung ist gut genug, da unsere Anforderungserfassung gezeigt hat, dass die überwiegende Mehrheit der Abfragen auf die eigene Geschäftsregion des Benutzers beschränkt ist.
Wenn wir nach transaction_date anstelle von region partitionieren, befindet sich die letzte Transaktion aus jeder Region in einer Partition. Jetzt muss der Benutzer, der Daten in seiner eigenen Region anzeigen möchte, mehrere Partitionen abfragen.
Daher lohnt es sich, den richtigen Partitionierungsschlüssel zu bestimmen.