Data Tiering

Data Tiering verteilt Daten auf mehrere Speicher-Ebenen. Je häufiger etwas gebraucht wird, desto schneller (und teurer) liegt es. Häufig gelesene Daten liegen auf Hot (schneller Arbeitsspeicher), seltener Genutztes auf Warm und Cold (langsamerer, günstiger Speicher wie Festplatte oder Cloud-Ablage). Die Zuordnung passiert automatisch nach Regeln (etwa Alter oder Zugriffshäufigkeit) oder manuell. Ziel: Speicherkosten senken, ohne dass aktive Daten langsam werden.

Was ist Data Tiering?

Data Tiering ist ein Architektur-Konzept aus dem Datenbank- und Speicher-Umfeld. Der Ausgangspunkt ist eine einfache Beobachtung: In den meisten Systemen wird nur ein kleiner Teil der Daten regelmäßig gelesen, während der Rest oft jahrelang unangetastet herumliegt. Oft decken zehn bis zwanzig Prozent der Daten rund achtzig Prozent aller Zugriffe. Schneller Speicher (Arbeitsspeicher, SSD) kostet pro Terabyte ein Vielfaches gegenüber günstigem Objektspeicher (Cloud-Ablage für Dateien und Datensätze, z. B. Amazon S3 oder Azure Data Lake Storage). Data Tiering nutzt diesen Preisunterschied, indem selten benötigte Daten automatisch auf die günstigeren Ebenen wandern.

Die kanonischen Ebenen sind Hot (In-Memory oder Cache), Warm (Flash oder Buffer-Cache-basiert), Cold (Disk oder Objektspeicher) und optional Remote (föderierter Zugriff auf externe Systeme). Die Zuordnungs-Einheit variiert: klassische Datenbanken tieren auf Tabellen- oder Partitionsebene, Lakehouse-Architekturen und Objektspeicher arbeiten auf Datei- oder Objektebene.

Die Steuerung erfolgt über Policies oder manuelle Zuweisung. Zeit-Policies verlagern Daten nach einer Alterschwelle (etwa älter als neunzig Tage), Zugriffs-Policies reagieren auf tatsächliche Nutzung, fachliche Regeln folgen betriebswirtschaftlicher Logik (abgeschlossene Geschäftsjahre auf Cold). Manche Plattformen erlauben eine Rückverschiebung (Promote/Demote) bei erneutem Zugriff, andere schreiben die Cold-Zuordnung als Einbahn fest. Der Zugriff ist in modernen Systemen transparent und akzeptiert bei Cold-Daten höhere Latenz; ältere Systeme verlangen einen expliziten SQL-Hint für den Cold-Layer.

Der Begriff ist die Grundlage für Konzepte wie Multi-Temperature Data Management (SAP BW/4HANA, SAP Datasphere), Native Storage Extension (SAP HANA Cloud) und Lifecycle-Policies in Objektspeichern (S3 Intelligent-Tiering, Azure Blob Access Tiers). Er erlaubt eine getrennte Betrachtung von Storage- und Compute-Kosten.

Abgrenzung zu Data Aging, Archivierung und verwandten Begriffen

Data Tiering wird häufig mit spezifischen Ausprägungen oder Nachbardisziplinen verwechselt. Die Unterschiede liegen in Steuerungsebene, Persistenz und Zugriffsweg.

Beispiel: dreistufiges Tiering in einer Datenplattform

Ein Datasphere-Space verwaltet Vertriebstransaktionen über zehn Geschäftsjahre. Das laufende und die zwei zurückliegenden Jahre liegen als lokale Tabelle im spaltenorientierten Hauptspeicher von SAP HANA Cloud (Hot). Die Jahre drei bis fünf liegen als lokale Tabelle mit Native Storage Extension (Warm), seitenweise nachladbar über einen Buffer Cache. Ältere Jahre liegen als Remote Table gegen den Objektspeicher der SAP Business Data Cloud (Cold). Ein Dashboard über das laufende Geschäftsjahr trifft nur den Hot-Layer und antwortet in Millisekunden. Eine Zehn-Jahres-Analyse aktiviert alle drei Ebenen und akzeptiert längere Antwortzeiten. Die Storage-Kosten sinken deutlich, weil die überwiegende Datenmenge auf günstigem Objektspeicher liegt.

Ein analoges Muster findet sich in einem Databricks-Lakehouse: aktuelle Delta-Tabellen werden durch Photon und Disk-Cache warm gehalten, historische Partitionen wandern per Lifecycle-Policy des Objektspeichers (Amazon S3, Azure Data Lake Storage) in eine günstigere Storage-Klasse wie Infrequent Access oder Glacier. Der Query greift transparent zu und akzeptiert bei Cold-Zugriff höhere Latenz und einen Retrieval-Aufschlag der Cloud-Rechnung.