Native Storage Extension: SAP HANA Warm-Store erklärt

Native Storage Extension (NSE) ist eine Speicher-Erweiterung in der SAP-Datenbank SAP HANA und ihrer Cloud-Variante SAP HANA Cloud. NSE hält warme Daten (selten gelesene Daten wie ältere Buchungsjahre) außerhalb des teuren Arbeitsspeichers auf günstigerem Festplatten-Speicher und lädt sie erst bei Bedarf in einen Buffer Cache (Zwischenspeicher). Für Anwendungen und SQL-Abfragen bleibt das unsichtbar: NSE ist Teil der Datenbank selbst und braucht kein separates Archiv und keine zweite Plattform.

Was ist Native Storage Extension?

Native Storage Extension ist eine seit 2019 verfügbare Speicherverwaltung für warme Daten in SAP HANA (eingeführt mit dem Release SPS04). SAP hat NSE in einer Phase eingeführt, in der der HANA-Hauptspeicher als knappe und teure Ressource galt und Bestandskunden mit stark wachsenden Datenvolumina nach einer Option innerhalb der Datenbank suchten. Vor NSE mussten SAP-Landschaften selten gelesene Daten entweder in Aging-Objekte auslagern (Data Aging, gesteuert aus der ABAP-Anwendungsschicht heraus), physisch archivieren (über das SAP Archive Development Kit, SAP ADK) oder auf mittlerweile abgekündigte Zusatz-Techniken wie Dynamic Tiering und HANA IQ als angeschlossene Datenbank-Engine ausweichen. NSE liefert die Warm-Ebene stattdessen direkt in der HANA-Instanz und ist in SAP HANA Cloud der von SAP empfohlene Baustein für diesen Zweck.

Die zentrale Steuerungsgröße ist die Load Unit. Jede Tabelle, jede Partition und jede Spalte hat in SAP HANA eine Load Unit: entweder COLUMN für in-memory-residente Daten im spaltenorientierten Hauptspeicher oder PAGE für den NSE-Warm-Store. Die Zuordnung erfolgt über DDL (ALTER TABLE … LOAD UNIT PAGE) oder beim Anlegen des Objekts. NSE arbeitet auf drei Granularitäten: ganze Tabellen (LOAD UNIT PAGE für alle Spalten), einzelne Partitionen (zum Beispiel historische Partitionen auf PAGE, aktuelle auf COLUMN) oder einzelne Spalten in breiten Tabellen mit selten gelesenen Attributen.

Zugegriffen wird über einen separaten Buffer Cache im HANA-Prozess. Beim ersten Zugriff auf einen Datensatz werden die betroffenen Seiten aus dem persistenten Storage in diesen Cache geladen und dort für Folgezugriffe gehalten. Die Größe des Buffer Cache wird pro Datenbank konfiguriert und ist der zentrale Sizing-Hebel: SAP nennt als Faustregel einen Warm-zu-Hot-Ratio von bis zu 1:8, also bis zu achtmal so viel NSE-Warm-Volumen wie belegter In-Memory-Speicher, abhängig von Cache-Größe und Zugriffsmuster. Für die Anwendung bleibt der Zugriff transparent: SQL-Abfragen treffen NSE-Daten ohne expliziten Hint, akzeptieren aber höhere Latenz beim ersten Zugriff und typischerweise reduzierte Parallelität gegenüber rein in-memory-residenten Tabellen.

Der Begriff hat in SAP HANA Cloud eine feste Rolle als Warm-Baustein in Multi-Temperature-Architekturen. Er sitzt zwischen dem In-Memory Column Store als Hot-Ebene und HANA Data Lake Files als Cold-Ebene und ist in SAP Datasphere als Speicher-Option für lokale Tabellen exponiert. In der SAP Business Data Cloud übernimmt NSE dieselbe Rolle innerhalb der HANA-Cloud-Schicht der Plattform.

Abgrenzung zu Data Aging, Data Tiering und HANA Data Lake Files

Native Storage Extension wird häufig mit den anwendungsnahen und plattformübergreifenden Nachbar-Konzepten verwechselt. Die Unterschiede liegen in Steuerungsebene, Persistenz und Zugriffsweg.

Begriff	Verhältnis zu Native Storage Extension
Data Aging (SAP HANA)	anwendungsseitig auf ABAP-Ebene gesteuerte Ausprägung mit fachlichen Aging-Objekten (Finanzbelege, Materialbelege) und Residenzzeit; kalte Daten liegen in einer historischen Partition und werden nur mit Data-Temperature-Hint gelesen. NSE ist datenbankseitig über die Load Unit gesteuert, kennt keine Aging-Objekte, greift transparent auf Warm-Daten zu und ist SAPs Nachfolge-Baustein für den Cold-Data-Fall in HANA Cloud
Data Tiering	plattformübergreifender Oberbegriff für die Verteilung von Daten auf Speicher-Ebenen (Hot, Warm, Cold, Remote) anhand von Zugriffs- oder Alterskriterien. NSE ist die konkrete SAP-HANA-Umsetzung der Warm-Ebene in einem Data-Tiering-Konzept
Multi-Temperature Data Management	Architektur-Prinzip in SAP-Datenplattformen mit expliziten Temperatur-Klassen und Policy-Steuerung. NSE ist ein technischer Baustein innerhalb dieses Prinzips und liefert die Warm-Ebene für HANA-basierte Plattformen
HANA Data Lake Files / Data Lake Relational Engine	Cold-Layer auf Objektspeicher beziehungsweise auf einer relationalen IQ-Engine, angebunden über Remote Tables. NSE bleibt innerhalb der HANA-Instanz auf Buffer-Cache-Basis; HANA Data Lake Files ist eine externe Datenschicht mit anderer Latenz-Charakteristik und Kostenkurve pro Terabyte
Klassische DB-Partitionierung	rein technische Aufteilung einer Tabelle in Partitionen zur Query-Performance oder zum Bulk-Load, ohne Aussage über Speicher-Ebenen. NSE nutzt Partitionierung als Trägertechnik (Load Unit pro Partition) und ergänzt sie um den Buffer-Cache-basierten Warm-Store
Datenarchivierung (SAP ADK)	verlagert Belege physisch aus der Datenbank in ein Archivsystem, Zugriff über ADK-Reload oder Content-Repository-APIs. NSE hält die Daten in derselben Datenbank und weiterhin SQL-adressierbar

Beispiel: partitionsweise NSE-Zuordnung in einem Datasphere-Space

Ein SAP-Datasphere-Space verwaltet Vertriebstransaktionen über zehn Geschäftsjahre in einer lokalen Tabelle in SAP HANA Cloud. Das laufende und die zwei zurückliegenden Jahre liegen als Partition mit LOAD UNIT COLUMN im In-Memory Column Store. Die Jahre drei bis sieben liegen als partitionsweise NSE-Warm-Daten mit LOAD UNIT PAGE, ihre Seiten werden bei Zugriff in den Buffer Cache geladen. Ältere Jahre wandern als Remote Table gegen HANA Data Lake Files auf die Cold-Ebene.

Ein Dashboard über das laufende Geschäftsjahr trifft ausschließlich den Column Store und antwortet in Millisekunden. Eine Fünf-Jahres-Umsatzanalyse aktiviert Hot und Warm und akzeptiert bei den NSE-Partitionen eine erhöhte Latenz beim ersten Zugriff, bleibt aber innerhalb der HANA-Instanz und benötigt keinen Wechsel der Plattform. Eine Zehn-Jahres-Historie zieht zusätzlich die Remote-Partition. Die Storage-Kosten sinken deutlich, weil der überwiegende Teil des Volumens auf der Warm- und Cold-Ebene liegt und nicht im teuren Hauptspeicher.

Architektonisch sitzt Native Storage Extension als Warm-Ebene direkt in der HANA-Cloud-Datenbank und ist die Standardantwort auf die Frage, wie Daten mit reduzierter Zugriffsfrequenz in HANA gehalten werden, ohne den In-Memory-Speicher zu belegen und ohne die Anwendung auf eine externe Plattform umzustellen. In SAP-Landschaften ist NSE damit ein regelmäßig referenzierter Baustein in Sizing- und TCO-Diskussionen um SAP HANA Cloud, SAP Datasphere und die SAP Business Data Cloud.