Entscheidung: Welche Partitionierungsstrategie?

Partitionierung teilt eine große Tabelle unter einem logischen Namen in mehrere physische Teile auf, erleichtert das Entfernen alter Daten und lässt Abfragen nur die relevanten Teile lesen (Partition Pruning). Bei kleinen Tabellen fügt sie jedoch nur Komplexität hinzu. Dieser Baum hinterfragt zuerst, ob Partitionierung wirklich nötig ist, und führt dich dann je nach Zugriffs- und Verteilungsmuster zwischen Range, List, Hash und Composite.

Ist die Tabelle wirklich groß genug, um Partitionierung zu brauchen?

Partitionierung ist keine Performance-Magie, sondern ein Werkzeug für Skalierung und Wartung (Lebenszyklus). Ist die Tabelle nicht groß genug oder laufen Abfragen mit Indizes bereits gut, bringt Partitionierung nur Plankomplexität und Verwaltungsaufwand. Erreicht deine Tabelle zig Millionen+ Zeilen/Hunderte GB, oder ist sie noch klein/mittelgroß?

• Ja, sie ist sehr groß und/oder alte Daten müssen in großen Mengen gelöscht/archiviert werden
• Nein, kleine/mittlere Tabelle, oder ich bin nicht sicher

Wie greifst du auf die Daten zu und wie sollen sie aufgeteilt werden?

Der Partitionsschlüssel sollte die Spalte sein, nach der die meisten Abfragen filtern; nur dann greift Pruning. Welches Zugriffsmuster dominiert? Nach Datum/fortlaufenden Bereichen (letzte 30 Tage), nach bestimmten Kategorie-/Regionswerten, oder gibt es keinen klaren Filter und du willst die Last gleichmäßig verteilen?

• Fortlaufende Bereiche wie Datum/Sequenznummer (letzte X Tage, nach Monat)
• Diskrete Wertemengen wie Kategorie/Region/Mandant
• Kein klarer Bereich/keine Kategorie; Ziel ist gleichmäßige Lastverteilung
• Sowohl Datum als auch hohes Volumen; Aufteilung in zwei Dimensionen nötig

Empfehlung: (noch) nicht partitionieren

Bei kleinen/mittleren Tabellen bringt Partitionierung keinen Nutzen; gut gewählte Indizes und normale Wartung reichen. Verfrühte Partitionierung verkompliziert Abfragepläne, verfehlt mit dem falschen Schlüssel das Pruning und erhöht den Betriebsaufwand.

Empfehlung: Range-Partitionierung

Range-Partitionierung teilt Zeilen nach fortlaufenden Bereichen einer Spalte auf (z. B. Datumsbereiche: eine Partition pro Monat/Quartal). Sie ist die häufigste und wirkungsvollste Strategie für Zeitreihen und stetig wachsende Tabellen.

Empfehlung: List-Partitionierung

List-Partitionierung gruppiert Zeilen nach diskreten, bekannten Werten einer Spalte (z. B. region = 'TR','EU','US' oder Mandanten-ID). Gibt es natürliche, endliche Kategorien, macht sie Zugriff und Verwaltung übersichtlich.

Empfehlung: Hash-Partitionierung (gleichmäßige Verteilung)

Hash-Partitionierung verteilt Zeilen anhand des Hashs der Schlüsselspalte relativ gleichmäßig auf eine festgelegte Anzahl von Partitionen. Sie wird genutzt, um Hotspots zu vermeiden und Last auszugleichen, wenn es keinen natürlichen Bereich/keine Kategorie gibt.

Empfehlung: Composite-Partitionierung (mehrstufig)

Composite-Partitionierung kombiniert zwei Strategien: Sie teilt zuerst auf oberster Ebene auf und unterteilt dann jede Partition in Subpartitionen (z. B. Range-by-Hash oder Range-by-List). Sie wird genutzt, wenn zeitbasierter Lebenszyklus und gleichmäßige Verteilung/Kategorietrennung gleichzeitig nötig sind.