Oracle In-Memory-Option in Database 12c: Einführung und Implementierung

Die In-Memory-Option innerhalb von Database 12c soll dieses Jahr auf den Markt kommen. Wir erläutern, was Oracle-Kunden im Vorfeld beachten müssen.

Dies ist der erste Teil einer zweiteiligen Serie zu Oracles In-Memory-Option in Database 12c. Dieser Teil erläutert die Möglichkeiten für eine Implementierung. Der zweite Teil beschreibt mögliche Lizenzmodelle und Hardwarekosten, die mit der Implementierung der In-Memory-Option verbunden sein können.

Die Oracle Database 12 In-Memory-Option, die im Herbst 2013 vorgestellt und im August dieses Jahres veröffentlicht wurde, integriert In-Memory-Funktionen in Oracles Datenbanken. Der Hersteller verspricht damit, die Leistung analytischer Abfragen wesentlich zu erhöhen und die Online-Transaktionsverarbeitung (Online Transaction Processing, OLTP) zu beschleunigen.

Traditionell speichern Oracle-Datenbanken Daten im Zeilenformat auf Datenträgern. Die In-Memory-Option ermöglicht es 12c jedoch, Daten spaltenweise im Arbeitsspeicher abzulegen. Die Datenbank behält die zeilenweise gespeicherten Daten für OLPT-Prozesse bei, kopiert sie aber in den Arbeitsspeicher für analytische Abfragen. Das doppelte Format erlaubt Echtzeitanalysen von Transaktionsdaten. Unterstützt die OLTP-Datenbank zudem Business-Intelligence- (BI-)Prozesse, macht die In-Memory-Option analytische Indizes überflüssig und verbessert somit das Online Transaction Processing.

Während der Präsentation zur In-Memory-Option vorigen September kündigte Larry Ellison an, dass die datengetriebene Anwendungen nicht angepasst werden müssen. Die Administratoren sollen, so der Oracle-Chef, in der Lage sein, die neue Lösung auf Knopfdruck zu implementieren. Nachdem die Daten in den Speicher kopiert sind, werden die analytischen Abfragen automatisch zu den Analyse-Engines geleitet, die die Spaltendaten verwenden, um Scan-Raten von Milliarden Zeilen pro Sekunden zu erreichen. Da sich die Daten im Arbeitsspeicher befinden, verursachen die Abfragen nicht die typischen I/0-Kosten, die mit auf Festplatten gespeicherten Daten verbunden sind. Gleichzeitig werden OLTP-Abfragen zur OLTP-Engine geleitet; sie nutzen dort die Daten auf dem Datenträger. Die Datenbankanwendung sorgt dafür, dass die beiden Datenspeicher transaktional konsistent und gleichzeitig aktiv sind.

Die In-Memory-Option implementieren

Wann immer man ein System implementiert oder verändert, entstehen zwangsläufig Kosten für Entwicklung, Einrichtung und Qualitätssicherung – auch wenn es als Fertigprodukt angekündigt war. Denn kein Unternehmen sollte eine neue Technologie produktiv einsetzen, bevor sie nicht vollständig getestet wurde.

Angenommen, Sie planen die Implementierung eines Business-Intelligent- (BI-)Systems, das auf Daten einer OLTP-Datenbank arbeitet. Möglicherweise entscheiden Sie sich für einen bewährten Ansatz: Sie bauen ein Data Warehouse, richten die Extraktions-, Transformations- und Ladeprozesse ein und implementieren ein System, das fortwährend Wartung und Support vornimmt. Eine derartige BI-Plattform benötigt nicht nur Ressourcen für Planung, Entwicklung, Tests und Implementierung, sondern auch die Infrastruktur, auf der Software, Daten sowie Netzwerkkommunikation gehostet sind.

Mit der Oracle-In-Memory-Option überspringen Sie diesen Ansatz. Anstatt eine eigene Infrastruktur zu bauen, vergrößern Sie einfach die bestehende OLTP-Infrastruktur. Diese Plattform benötigt natürlich auch Anfangsinvestitionen für Lizenzierung und Implementierung. Gleichzeitig sparen Sie aber zum Beispiel bei Hardware und Wartung. Selbst wenn Sie proprietäre Hardware benötigen, um die In-Memory-Datenbank zu nutzen, ergeben sich Vorteile für die Gesamtbetriebskosten Total Cost of Ownership (TCO).

Wenn sie bereits ein eigenes Data Warehouse implementiert haben, lohnen sich die Investitionen in die In-Memory-Option unter Umständen nicht: Das ist vor allem dann der Fall, wenn Ihr System reibungslos funktioniert und sie bereits Geld hineingesteckt haben. Nun gilt es zu prüfen, ob die Echtzeitvorteile von In-Memory-Analytics die beschriebenen Kosten aufwiegen.

Egal ob Sie bereits ein Data Warehouse haben oder nicht, es tauchen noch weitere Kostenfragen auf. So müssen Sie entscheiden, was Sie mit Ihren historischen Daten machen. Ein Grund, warum ein Data Warehouse als separate Einheit behandelt wird, besteht darin, dass es als großes Lager für historische Daten genutzt wird, die nicht für die tägliche Arbeit erforderlich sind. Ein Data Warehouse bietet großen Spielraum für Analysen und eine weitere Perspektive. Kommt OLTP für Analytics zum Einsatz, müssen Sie die gesammelten Daten berücksichtigen und sicherstellen, dass Sie das richtige System und ausreichend Ressourcen haben, um damit zu arbeiten. Große Mengen historischer Daten können zu extrem großen In-Memory-Datensätze anschwellen und die Leistung beeinträchtigen. Nicht alle BI-Plattformen können „einfach so“ eine OLTP-Umgebung nutzen.

Werden die BI-Plattformen als separate Einheiten eingesetzt, haben Probleme, die im OLTP-System auftreten, nur minimale Auswirkungen auf das Data Warehouse – und umgekehrt. Fällt eine Plattform aus, läuft die andere weiter. Das macht die Fehlersuche und Wartung einfacher, und wenn dann doch ein Problem auftritt, betrifft es weniger Anwender. Beispielsweise wirkt sich eine verarbeitungsintensive analytische Abfrage nicht auf alle User aus, die aktuell eine Transaktionsverarbeitung nutzen. Wenn Sie sich mit dem Gedanken tragen, OLTP und BI-Prozesse in ein einzelnes System zu integrieren, müssen sie diesen Umstand – und damit auch die hierbei auftretenden Kosten – berücksichtigen.

Weitere Überlegungen müssen Sie anstellen, wenn Sie die OLTP-Datenbank bereits für Analytics verwenden. In diesem Fall haben Sie womöglich analytische Indizes implementiert, um die Leistung zu verbessern. Dies kann sich nun auf die Transaktionsverarbeitung auswirken. Unter diesen Umständen rechnet sich eventuell die Investition in die In-Memory-Option – vorausgesetzt, Sie kennen Lizenzkosten und Systemanforderungen. Dieser Ansatz könnte vor allem nützlich für explorative Formen von Analytics und operativen Analysen sein. Wenn Sie sich hierfür entscheiden, sollten Sie aber immer im Hinterkopf behalten, dass auf jeden Fall Kosten für Anschaffung, Wartung und Betrieb entstehen – allen anderslautenden Versprechungen der Hersteller zum Trotz.

Über den Autor:

Robert Sheldon ist technischer Berater und Autor mehrerer Bücher, Artikel und Schulungsmaterialien über Microsoft Windows, relationale Datenbank-Management- Systeme (DBMS) sowie Design und Implementierung von Business Intelligence.

Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im Februar 2014 aktualisiert

Erfahren Sie mehr über Oracle-Software

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close