Oracle, IBM, HSQLDB, SQLite

In-Memory-Datenbanken im Vergleich

07.05.2013
Von Roland Stirnimann und Jan Ott

In-Memory-Erfahrungen

Aus Projekterfahrungen mit Oracle Times-Ten resultieren zwei grundlegende Erkenntnisse:

  1. Die Umstellung auf In Memory stellt ein eigenes IT-Projekt dar: Eine bestehende Applikation lässt sich weder schnell und spontan umstellen, noch garantiert In Memory automatisch eine beschleunigte Anwendungs-Performance. Die Migration der Applikationen erfordert von den Anwendern, diese vorher anzupassen.

  2. Die Implementierung von In Memory erfordert Know-how und Zeit: Für die Implementierung von In-Memory-Datenbanken sind fundierte Kenntnisse in Datenbanken und Anwendungsintegration erforderlich. Bestehende Business-Applikationen anzupassen und zu testen bedeutet für die Anwenderunternehmen Aufwand, der sich angesichts der neuen Technik oft nur schwer kalkulieren lässt.

Klassische RDBMS versus In-Memory-Datenbank: Während die Disk-basierte RDBMS die Data Pages erst bei Bedarf in den Buffer Pool liest, lädt TimesTen schon beim Start der DB alle Daten in den Speicher.
Klassische RDBMS versus In-Memory-Datenbank: Während die Disk-basierte RDBMS die Data Pages erst bei Bedarf in den Buffer Pool liest, lädt TimesTen schon beim Start der DB alle Daten in den Speicher.
Foto: Oracle

Auf Grundlage langjähriger Erfahrungen mit Oracle-Datenbanksystemen lässt sich feststellen, dass bestimmte Tatsachen aus dem Oracle RDBMS weder implizit für TimesTen noch grundsätzlich für In Memory gelten. Je nach Komplexität eines DB-Projekts reicht reines Oracle-RDBMS-Know-how mitunter nicht aus, da sich In-Memory-Datenbanken in bestimmten Situationen komplett anderes verhalten.

Das gilt beispielsweise für Schreibvorgänge (Commit): TimesTen speichert die Daten im flüchtigen Hauptspeicher, während Oracle RDBMS sie auf Festplatten oder SSDs ablegt. Eine Umstellung auf In-Memory-Technik erfordert daher umfangreiche Änderungen im Programmcode sowie die Implementierung von zusätzlichen Sicherheitsmechanismen gegen Datenverlust. Um die Ergebnisse einer Implementierung zu validieren, ist darüber hinaus eine regelmäßige Performance-Analyse erforderlich.

Die Hauptgründe dafür liegen darin, dass TimesTen bestimmte Programmpakete sowie Funktionen fehlen und die Anwendungen oft komplexe Datenbankabfragen enthalten. In früheren Projekten mussten beispielsweise die "Connect-by"-Ausdrücke in SQL geändert werden, um den gleichen Output auch ohne sie zu erreichen. Der dafür notwendige Arbeitsaufwand darf keinesfalls unterschätzt werden und stellt selbst erfahrene Entwickler vor Herausforderungen.

Perfekt formatierte Performance Reports, wie sie vom Oracle RDBMS bekannt sind, fehlen in TimesTen ebenfalls. Um "Data Dictionary Views" zu analysieren, müssen sich Datenbankadministratoren deshalb mit SQL-Queries behelfen. Erschwerend kommt hinzu, dass TimesTen keine "Elapsed Time" aufzeichnet.

Der Aufwand für die Umstellung bestehender Applikationen auf In Memory ist nicht zu unterschätzen, der Übergang sollte daher als eigenständiges IT-Projekt geplant werden. Entscheider müssen einen großzügigen Zeitpuffer für Softwareanpassung, Testing und Analyse einkalkulieren und entsprechende Ressourcen bereitstellen.

Zur Startseite