Speicherbanken

Server-Datenbanken setzen auf Hauptspeicher

Wissen | Know-how

Neue Datenbank-Server können auch Datenbestände von mehreren TByte im RAM bearbeiten. IBM DB2 10.5 BLU und Microsoft SQL Server 2014 schaffen Analysen im Hauptspeicher blitzschnell wie in einem Data Warehouse, wickeln aber Transaktionen gleichzeitig so sicher ab wie eine festplattengestützte Datenbank.

Bis jetzt ist im Umgang mit großen Datenmengen in Unternehmen eine zweigleisige Arbeitsweise üblich: Für Transaktionen in den Geschäftsdaten ist eine klassische OLTP-Datenbank (Online Transaction Processing) zuständig, die allerdings durch Festplattenzugriffe permanent ausgebremst wird. Um mit Datenauswertungen schneller zum Zug zu kommen, spiegelt man die sorgsam gepflegten Informationen regelmäßig in ein Data Warehouse. Das ist eine gesonderte OLAP-Datenbank (Online Analytical Processing), die als Read-Only-System alle Tricks der schnellen Datenanalytik im RAM beherrscht. Diese Strategie erfordert aber den gleichzeitigen Betrieb zweier Datenbanksysteme, und trotzdem liefern dabei auch die schnellsten Abfragen immer Ergebnisse, die schon seit Stunden überholt sein könnten.

Die 2011 erschienene Datenbank SAP HANA bricht mit dieser Tradition [1]. Sie lagert auf Biegen und Brechen die kompletten Geschäftsdaten eines Unternehmens komprimiert und großteils nach Spalten angeordnet im Hauptspeicher eines geräumigen Servers. Dort analysiert und bearbeitet sie die Daten ohne den Umweg über ein externes Speichermedium. So gehen Leseprozesse weit schneller über die Bühne als sonst. Veränderungen am spaltenorientierten Datenbestand im RAM statt auf der Festplatte verursachen dagegen so einen hohen Rechenaufwand, dass die Performance trotz geballter CPU-Leistung auf das Niveau einer konventionellen Datenbank absinkt. ...

Sie möchten wissen, wie es weitergeht?

Als c't-Plus-Abonnent gratis lesen

Anmelden als c't-Plus-Abonnent

Weitere Bilder

  • Verfolgt man in DB2 10.5 die benötigte Ausführungszeit über viele SQL-Prozeduren, zeigt sich, dass die meisten Prozeduren mit lesenden Zugriffen auf herkömmlichen (non-BLU) Tabellen viel langsamer laufen als auf BLU-Tabellen im selben Datenbank-System. Bei Prozeduren mit großteils schreibenden Zugriffen kehren sich die Verhältnisse um.

Anzeige
Anzeige