In Memory DataBase (IMDB) werden Performance-Vorteile bei der Analyse von großen Datenmengen mit iterativen analytischen Verfahren und interaktiven DataMining Tools gegenüber I/O basierten DataBase zugeschrieben. Auch für transaktionsorientierte Anwendungen stehen IMDB Architekturen zur Verfügung. SAP HANA Appliances liefern die Datenbasis für OLAP und OLTP Applikationen.

Warum sollen in Zukunft unterschiedliche, spezialisierte Datenbanken für transaktionsorientierte Applikationen, dispositive Applikationen und analytische Applikationen zum Einsatz kommen? Ist der Einsatz eines DataWarehouses für dispositve und analytische Applikationen noch zeitgemäß?

In Memory Datenbanken (IMDB)

IMDB Funktionalitäten werden zum weiteren Architekturprinzip neben spaltenorientieren Datenbanken, massive parallel Processing (MPP), shared nothing Architektur und für die Software optimierte Hardware (Datenbank Appliances), das genutzt wird, um große Datenmengen zu speichern und notwendige Daten-Performance für analytische Applikationen zu liefern. In IMDB befinden sich die Daten im physikalischen Arbeitsspeicher und besitzen unter Umständen eine Kopie auf Plattenspeichermedien. Die In Memory lokalisierte Datenhaltung der Datenbank benötigt ein geändertes Datenbankmanagementsystem (DBMS). Im Unterschied zu IMDB befinden sich auf I/O basierten Datenbanken die Daten auf Plattenspeichermedien mit Caching-Funktionen die Teile der Daten in den physikalischen Arbeitsspeicher auslagern. Es gibt unterschiedliche Ausführungen dieser I/O basierten Datenbanksysteme (RDBMS, HDBMS, MDBMS, ODBMS)

1. RDBMS := relationales Datenbank Management System;
2. MDBMS := multidimensionales Datenbank
   Management System;
3. HDBMS := Hierarchisches Datenbank Management System;
4. ODBMS : = objektorientiertes Datenbank Management System.
   
   Für MDBMS gibt es MDX (Multidimensional Expression) und wird als standardisierte Abfragesprache von OLE DB for OLAP (ODBO) verwendet. MDX wurde in Anlehnung an SQL für multidimensionale Anforderungen entwickelt.

die SQL und NonSQL Abfragesprachen aufweisen. Im Unterschied zum Caching bei I/O basierten Datenbanken erfolgt der Datenzugriff bei IMDB nicht über Block basierte Indices (z.B. B-Trees), die für einen Plattenzugriff ausgelegt sind; die Schnittstellen zu Anwendungen benötigen keine Buffermanager bei dem die Plattenadresse ermittelt wird, mit deren Hilfe der Zugriff auf den zugehörigen Datenblock im Arbeitsspeicher (Cache) erfolgt.

IMDB bieten die Möglichkeit des direkten Zugriffs auf Speicheradressen zur Verkürzung von Zugriffszeiten und Transaktionszeiten. Zunehmend beginnen Anbieter von RDBMS ihre Datenbanken mit Cache-Funktionen um „In Memory Techniken“ zu erweitern. Die Verfügbarkeit von Speicherchips mit mehr Kapazitäten und Datenkompressionsverfahren ermöglichen den Aufbau von IMDBs mit zunehmender Datenspeicherkapazität. Hohe Speicherkapazität kann durch Grid-Computing bei
lokaler Speicherbegrenzung erreicht werden.

In Memory Ansätze im OLAP (OLAP:=Online Analytical Processing) sind nicht neu, so wurden bereits in den 80er Jahren multidimensionale Datenbanken als arbeitsspeicherbetont konzipiert. Viele OLAP Datenbanken waren anfänglich so aufgebaut, dass „multidimensionale Arrays“ beim Start oder Laden dieser Datenbanken von einem Plattenspeicher in den Arbeitsspeicher geladen wurden und beim Schließen der Datenbanken diese „Arrays“ im Arbeitsspeicher auf Plattenspeicher zurück geschrieben wurden. Vermehrte Speicherund Persistenz-Anforderungen an OLAP Datenbanken führten in Folgejahren zu stärker I/O gestützten Speicherkonzepten und optimierten Datenkompressionsalgorithmen von MDBMS. Auch IMDB durchlaufen gegenwärtige eine ähnliche Entwicklung, indem im Rahmen von Commit
Strategien die Persistenz der Daten auf Plattenspeicher verbessert wird, so dass im Fehlerfall nur Datenänderungen nach einem Commit verloren gehen.

Ein kleine Übersicht und Aufteilung von IMDB Datenbanken und Erweiterungen etablierter DBM:

1. IMDB / Anbieter —Exasol, SAP HANA, Solid DB/IBM, TimesTen/Oracle, HyperSQL Datab, SQLlite, MySQL – Memory + Cluster / Oracle
2. Etablierte I/O Datenbanken mit IMDB Erweiterungen / Anbieter – DB2 with BLU Acceleration/IBM, Informix Warehouse Accelerator/IBM, Oracle mit IMDB Option, Paracmit IMDB Option, Teradata mit Teradata Intelligent Memory, Northscale oder Kognitio

Big Data
Das Datenvolumen hat eine weiter ansteigende Kurve: Terabytes -> Petabytes -> Exabytes -> Zettabytes -> Yottabytes -> Brontobytes -> Geopbytes.

„Big Data“ Kapazitäten verändern eine Anforderungen an Business Intelligence – die Möglichkeit, dass End-User oder auch Maschinen Ad-Hoc Analysen und Reports über eine umfangreiche und wachsende Menge strukturierter und unstrukturierter Daten (log files, Sensor Daten, Semantic Web, Emails, Streaming Daten, Forschungsdaten oder Bilder) ausführen können.

Die steigende Anzahl von Auswertungen und Transaktionen erzeugt Engpässe auf traditionellen Datenspeichern, wenn diese auf dem Quelldatenspeicher ausgeführt werden. Caching Technologien oder In Memory Technologien von analytischen Plattformen als Bindeglied zwischen Datenschicht und analytischer Anwendung sollen Zugriffszeiten reduzieren und Quelldatenspeicher entlasten. Zahlreiche analytische Plattformen unterstützen den Zugriff auf strukturierte, semi-strukturierte und unstrukturierte Daten mit SQL und NonSQL Abfragen.

Daten befinden sich bei IMDBs im Arbeitsspeicher; analytische Applikationen könnten diese Datenstrukturen direkt nutzen, wenn die IMDBs geeignete API’s zur Verfügung stellen. Änderungen in den Indexstrategien in IMDBs gegenüber RDBMS sollten Geschwindigkeitsvorteile auch bei Querys bringen, insbesondere, wenn SQL Algorithmen der jeweiligen IMDBs optimiert sind.

Aufgrund des wachsenden Datenvolumens und zunehmender Anzahl analytischer Auswertungen werden reine IMDB nicht ausreichen, die daraus resultierenden Anforderungen zu lösen. Aus ökonomischen Gesichtspunkten sollte daher geprüft werden, welche Daten im schnellen Zugriff tatsächlich benötigt werden und im Rahmen eines Data-Live-Cycle Management Daten nach Aspekten von Cold-Warm-Hot (Hot Daten, sind die Daten die für Abfragen und Analysen häufig benutzt werden und deren Bereitstellung mit minimaler Latenzzeit erfolgen muss. Cold Daten hingegen sind charakterisier durch Anwendungen, Analysen
oder Abfragen, die eine hohe Latenzzeit tolerieren bis diese Daten verfügbar sind) Daten auf Festplatte, Solide State Disk (SSD) oder im Arbeitsspeicher für Anwendungen verfügbar gemacht werden. Dieses Data-Live-Cycle Management muss die Bedeutung der Daten kontinuierlich überprüfen und Reorganisationen der Daten bezüglich der Zugriffshäufigkeit und Relevanz für near-realtime Auswertungen beinhalten. Für Big Data erscheinen Hybride Architekturen erfolgversprechend. Anbieter die mit Ihren Datenbanken die Fähigkeit der Speicherung von der wachsenden Menge an Daten unter Beweis gestellt haben und zudem über IMDB Optionen verfügen scheinen hierfür richtig aufgestellt zu sein, z.B. Teradata, IBM oder Oracle. 

DataWarehouse Architektur Prinzip
DataWarehouse Umgebungen wurden ursprünglich geschaffen, um historische Daten aus unterschiedlichen Quellen zu speichern. Bei diesen Daten handelte es ich vornehmlich um strukturierte Daten, die nach einer gewissen Zeit aus den Vorsystemen ausgelagert werden mussten, aber weiterhin für multidimensionale Abfragen benötigt wurden. Die Übernahme und Homogenisierung von Daten aus unterschiedlichen Quellen in ein DataWarehouse mit integrierten oder nachgelagerten OLAP Engines mit Daten-Summierungen und Aggregationen ist ein Architekturmerkmal heutiger DataWarehouse Landschaften. Multidimensionale High speed
Auswertungen werden so unterstützt. Für unterschiedliche (multidimensionle) Auswertungswerkzeuge werden spezialisierte (logische) Sichten auf konsolidierte Daten im DataWarehouse geschaffen – diese logischen Sichten unterstützen Aspekte wie Performance, Datenkonsistenz, Sicherheit und Wartbarkeit. DataWarehouse Architekturprinzipien werden auch dann Bestand haben, wenn in IMDB transaktionale und dispositve Inhalte integriert werden. Semi- und unstrukturierte Daten sind nicht einfach in einem Datenmodell zu erfassen und sind daher eine Herausforderung traditioneller, datenbank-basierter DataWarehouse Umgebungen. Einige
„Workloads“ werden daher ausgelagert und mit verteilen Filesystemen oder Streaming Techniken und Map-Reduce Ansätzen analysiert. Auch zu DataMining Zwecken werden Daten aus dem DataWarehouse für Analysezwecke ausgelagert oder separiert. In der Regel sind Erkenntnisse, die im Rahmen einer Analyse aus den unstrukturierten Daten ermittelt wurden, Kandidaten, die sich in Datenmodellen abbilden lassen. Auch IMDB benötigen den Einsatz von Datenmodellen. 
Zur Lösung von BigData Anforderungen und einer flexiblen/anpassungsfähigen Infrastruktur für Business Intelligence werden folgende Eigenschaften an eine DataWarehouse Architektur gestellt:

1. Eignung Transaktionsdaten, strukturierte und unstrukturierte Daten in einer Plattform zu analysieren
2. Geringe Latenzzeiten mit In Memory oder Solid State Devices (SSD) für alle „Hot-Data“ die für umfangreiche Web- und near Realtime Anwendungen benötigt werden. Integration in ein Data-Live-Cycle Datenmanagement, welches Anforderungen nach „Cold-Warm-Hot“ Daten
   berücksichtigt.
3. Skalierung mit commodity Hardware; massive paraller processing (MPP) mit Verteilung der Rechenleistung und Speicherkapazität (I/O und Arbeitsspeicher) sowie shared nothing Architekturen
4. Einsatz von Schichten, die spezifische Anforderungen von Applikationen, Sicherheit, Datenkonsistenz, Datenharmonisierung und Datenintegration, Betriebs- und
   Betreuungsaspekten kapseln
5. Integration in ein Analyseframework, das auch private und öffentliche Cloud Veröffentlichungen, Semantic-Web und Streaming Daten nutzt
6. Mit der zunehmenden Integration in die operative Steuerung (automatisierte analytische Funktionen) ist eine geeignete Verfügbarkeit der Komponenten sicherzustellen
7. Die Datenintegration und Homogenisierung sollte nachvollziehbar und geeignet für Impact Analysen (Abhängigkeitsanalysen von Daten und Datenquellen) gestaltet sein

Betrieb und Verfügbarkeit
Zur Erhöhung der Verfügbarkeit sind bei IMDBs Methoden und Technologien Kandidaten, die bei RDBMS bereits im Einsatz sind: Backupbatterie der Speicherchips, nicht flüchtige Speicherchips, redundante Netzteile, UPS der Rechner,  Fehler erkennende und korrigierende Speicherchips, Schnappschuss-Dateien über den Zustand der Datenbank, Redundanz der gespeicherten Daten in Clustern, Replikation, separaten Rechenzentren oder (Hot) Standby Rechner in Clustern in Verbindung mit Transaction Logs (nicht volatil). Diese Maßnahmen reduzieren die Wahrscheinlichkeit Daten im Fehlerfall zu verlieren, können einen Datenverlust jedoch nicht verhindern. Backup-Kopien der Daten auf nicht volatilen Medien sind für ein Desaster- und Recovery Management auch bei IMDBs notwendig. Wenn ein Memory-Board einer IMDB ausfällt, muss in der Regel der Rechner heruntergefahren werden, was zum Verlust des gesamten Speichers führt. Der Ausfall einer Platte
bei einem RDBMS hat in der Regel keinen Impact auf weitere Platten. Ein Crash eines IMDB Rechners hat einen Verlust des Speichers zur Folge, der durch redundante Speicherhaltung (Cluster) oder von Backup-Medien während der Datenbank Recovery wieder hergestellt werden muss. Recovery Maßnahmen bei IMDBs müssen als zeitaufwendiger gegenüber I/O basierten Datenbanken eingestuft werden. Dies bedeutet, der technologische und organisatorische Aufwand ist höher, die
gleiche Verfügbarkeit mit IMDBs zu erreichen. Es ist zu beachten, dass auch ein konsistentes Backup auf persistente Medien nicht die Performance der IMDB beeinträchtigen darf.

Das Tuning von IMDBs ist vereinfacht, da Index-Scans für im Arbeitsspeicher befindliche Daten weniger negative Performance Einflüsse auf Abfragegeschwindigkeiten haben wie bei I/O basierten Datenbanken. Die Notwendigkeit, Daten-Summierungen und Aggregationen für Auswertungen zu erstellen, ist deutlich reduziert.
Werden BigData Anforderungen berücksichtigt, so kann IMDB Bestandteil einer Hybriden Architektur sein, um Cold-Warm-Hot Data zu differenzieren. Das zugehörige Data Live-Cycle Management wird den Aufwand zum Betrieb erhöhen, auch wenn Tuningmaßnahmen traditioneller Databanksysteme durch den Einsatz von IMDB performanter Auswertungen reduziert werden kann. 

Datenqualität
Der Trend, eine 360° Sicht der Informationen für Entscheidungen und Analysen zu erlangen, führt dazu, immer mehr Daten aus verteilten Systemen bereitzustellen. Die automatisierte Einbindung von Erkenntnissen und analytischen Funktionen in operative Abläufe bedingt, dass Daten in immer kürzeren Zeitfenstern integriert und harmonisiert werden müssen. Das Informations-Management nimmt dabei an Komplexität zu und fehlerhafte Daten können Grund für fatale Fehlentscheidungen
sein. Die zunehmende Integration von datengetriebenen Entscheidungen erhöht das Risiko, dass Fehlentscheidungen erst erkannt werden, wenn ein wirtschaftlicher Schaden, z.B. mangelhafte Kampagne oder Kreditvergabe, bereits eingetreten sind. Programme zur kontinuierlichen Verbesserung der Datenqualität und Maßnahmen, fehlerhafte Daten an der Quelle zu korrigieren und nicht im Rahmen von Datenbewirtschaftungsprozessen, sind in einem DataWarehouse akzeptierte Maßnahmen. Auch ein zentrales Master-Data-Management liefert einen wichtigen Beitrag zu Erhöhung der Datenqualität. Der Ansatz, die Datenqualität durch Reduktion der verteilten Systeme zu erhöhen, ist von Vorteil, wenn hierdurch fehlerverursachende Schnittstellen zwischen einzelnen Daten produzierenden Systemen reduziert werden können. Der Einsatz einer IMDB für mehr als ein Quell-System reduziert nicht zwingend notwendige Schnittstellen zwischen operativen Komponenten, sondern vereinfacht die Datenintegration in ein DataWarehouse, da auf die gleiche IMDB Datenquelle mit unterschiedlichem Informationsbedarf zurückgegriffen werden kann, um relevante Daten für Analysen und Berichte zu integrieren. Eine Konsolidierung bestehender Datenbanken auf eine Datenhaltung mit IMDB Funktionalitäten bringt nicht zwingend eine Verbesserung der Datenqualität, obgleich einheitliche Datenformate in einer konsolidierten Datenbank Komplexität reduzieren.  

Fazit

1. IMDB Funktionalitäten stellen einen weiteren Schritt in der Evolution von Datenbanken dar. Die Latenzzeit für den Zugriff auf Daten reduziert und die Bedeutung von traditionellen Datenbank Tuningmaßnahmen, die Bildung von Indices oder die Erstellung von vorgerechneten Aggregaten sinkt.
2. Anbieter von (OLTP) Datenbanken haben IMDB Funktionalitäten in Ihre Datenbank zumindest als Option aufgenommen.
3. Aufgrund von BigData Entwicklungen wird im Einzelfall zu entscheiden sein, welche Daten mit IMDB Funktionalitäten verfügbar gemacht werden – nicht alle Daten sind „Hot Data“. „Cold Data“ benötigen nicht zwingend IMDB Funktionalitäten und können daher mit I/O orientierten Techniken gespeichert werden – Plattenspeicher ist weiterhin günstiger als Arbeitsspeicher.
4. Die zunehmende Integration von IMDB Funktionalitäten in die Datenbanken verlagert Aktivitäten von Teilen des Daten-Live-Cycle Managements in die Datenbanksysteme, wo die Softwareanbieter die Verwaltung in Ihre Tools integrieren können, d.h. die Applikation oder Schnittstelle muss die IMDB Option nicht berücksichtigen, sondern die Datenbank stellt transparent diese Funktionalität zu Verfügung. Datenbank Administratoren werden bezüglich I/O Tuning entlastet. Sie müssen jedoch IMDB Optionen verstehen und richtig einsetzen lernen - auch unter dem Aspekt der Verfügbarkeit.
5. Die Integration von IMDB Funktionalitäten in Datenbank Systeme der großen Anbieter bieten Chancen, Datenbanken zu konsolidieren.
6. DataWarehouse Architekturen werden weiterhin Layer Strukturen enthalten, um spezialisierte Sichten auf Daten Anwendungen und Usern zur Verfügung stellen zu können. Für die Analyse unstrukturierter Daten werden weiterhin File- oder Streaming basierte Ansätze Verwendung finden.
7. DataWarehouse Architekturen sind durch IMDB nicht überholt, aber eine bestehende DataWarehouse Plattformstrategie könnte hinterfragt werden.