Nachdem herkömmliche Datenbanksysteme an Grenzen stoßen, kommen mehr und mehr In-Memory-Lösungen auf den Markt. Lesen Sie, worauf Unternehmen bei der Implementierung achten sollten.
von Roland Stirnimann und Jan Ott, Senior Consultants bei der Trivadis AG
Foto: Shawn Hempel - Fotolia.com
Noch stehen In-Memory-Datenbanken (IMDB) vielfach im Schatten der großen klassischen Datenbanklösungen wie der "Oracle Database", IBMs "DB2" oder Microsofts "SQL Server", die sich in den zurückliegenden Jahrzehnten fest in den Unternehmen etabliert haben. Doch im Zuge steigender Anforderungen auf Seiten der Anwender kommt Bewegung in den Markt. Die Anbieter arbeiten mit Hochdruck an neuen Datenbankmodellen und -architekturen wie beispielsweise In-Memory-Lösungen. Glaubt man den Werbeslogans der Softwarehersteller, bietet In Memory eine Reihe von Vorteilen wie beispielsweise eine beschleunigte Datenverarbeitung und damit stark verkürzte Antwortzeiten.
Allerdings haben Anwender, die überwiegend in der Welt relationaler Datenbanksysteme verhaftet sind, noch viele Fragen. Was ist beim Praxiseinsatz von In Memory zu beachten? Ist die neue Technologie in jedem Fall schneller, macht sie andere Datenbanken sogar überflüssig? Diese Fragen gilt es für die Unternehmen zu klären, um die richtige Technik für die eigenen Anforderungen zu finden.
Mittlerweile gibt es zahlreiche In-Memory-Datenbanken auf dem Markt. Vier Produkte sollen nachfolgend näher beschrieben werden. Je zwei davon bieten umfangreiche Features für den Einsatz im Enterprise-Segment ("Oracle TimesTen" und "SolidDB" von IBM) beziehungsweise eignen sich eher für den Betrieb in klein oder mittelgroß dimensionierten IT-Umgebungen ("HyperSQL Database" und "SQLite").
Oracle TimesTen
Oracle hat TimesTen im Jahr 2005 gekauft und die gleichnamige In-Memory-DB seitdem kontinuierlich weiterentwickelt. Hinsichtlich Funktionsumfang und Lizenzierung bewegt sich die Datenbanklösung auf Enterprise-Niveau und ist sowohl für Linux und Unix als auch für Windows-Plattformen erhältlich. Neben dem Betrieb als eigenständige Datenbank lässt sich TimesTen vor allem auch als Cache für bestehende Oracle-Tabellen verwenden. Diese werden dabei vollständig oder partiell als sogenannte Cache Groups in TimesTen geladen. Spezielle Prozesse sorgen anschließend dafür, dass die Daten - je nach Anwendungsfall - synchron oder asynchron in die Oracle-Datenbank geschrieben werden. Das beschleunigt den Zugriff auf Business-relevante Geschäftsdaten und sorgt auch bei hoher Systemlast für einen unterbrechungsfreien Betrieb der zugehörigen Datenbank-Server. Auch das automatische Nachladen neuer Daten aus dem relationalen Datenbank-Management-System (RDBMS) funktioniert problemlos, leider wird jedoch für die Cache Groups bisher nur die Oracle-Plattform unterstützt.
Damit der In-Memory-Datenbank nicht der Platz ausgeht, muss der Cache regelmäßig bereinigt werden (Aging). TimesTen bietet dazu zwei Vorgehensweisen - "time-based" oder "least recently used" (LRU). Dabei passt sich die Lösung immer mehr an das Oracle RDBMS an. So findet der Datenbankadministrator zum Beispiel ein Data Dictionary mit Tabellen wie DBA_USERS oder DBA_OBJECTS vor. Datenbankentwickler können sich zudem über die Unterstützung von PL/SQL freuen.
Dennoch finden sich bei Weitem noch nicht alle Pakete und SQL-Funktionen aus dem Oracle RDBMS auch in TimesTen. Beim Portieren einer Applikation vom Oracle RDBMS auf TimesTen sind viele Anpassungen am Code erforderlich. Den damit verbundenen Zeitaufwand sollten Anwender nicht unterschätzen und in ihrer Budget- und Projektplanung berücksichtigen.
TimesTen verfügt zudem über diverse Replizierungsvarianten (synchron/asynchron, uni-/bidirektional). So lässt sich beim Ausfall einer TimesTen-Instanz sofort ein Failover initiieren und somit ein unterbrechungsfreier Betrieb sicherstellen.