In-Memory Datenbanken auf den Zahn gefühlt!

In-Memory Datenbanken auf den Zahn gefühlt!
Roland Stirnimann
Senior Consultant
Jan Ott
Senior Consultant
09. August 2011
In-Memory Datenbanken geniessen deutlich weniger Bekanntheitsgrad als
herkömmliche Datenbanken wie zum Beispiel Oracle oder Microsoft SQL Server. Glaubt
man der Werbung, so versprechen die Hersteller wie Oracle deutlich kürzere
Antwortzeiten. Doch was sollte beachtet werden beim Einsatz von In-Memory in der
Praxis? Ist In-Memory in jedem Fall schneller? Macht In-Memory die herkömmlichen
Datenbanken allenfalls überflüssig? Fragen wie diese soll der Artikel klären um bei der
Wahl der richtigen Technologie behilflich zu sein, da die wichtigsten Vor- und Nachteile
bekannt sind.
1.
Einleitung
Dieser Artikel zeigt verschiedene Aspekte zum Thema In-Memory Datenbanken auf. Einerseits
wird der Markt beleuchtet um einige Produkte beim Namen zu nennen. Andererseits findet eine
Gegenüberstellung statt um die Unterschiede in Bezug auf Funktionsumfang und Einsatzbereich
aufzuzeigen. Im letzten Teil werden Schlussfolgerungen und Entscheidungskriterien aus eigener
Erfahrung der beiden Autoren aufgelistet.
2.
In-Memory Produkte auf dem Markt
Bei der Suche in Wikipedia erscheint eine umfangreiche Liste mit In-Memory Datenbanken. Der
Artikel beschränkt sich auf 4 Produkte aus zwei unterschiedlichen Kategorien. Zwei davon
gehören klar in den High-End Bereich während sich die anderen beiden selber in kleineren bis
mittleren Umgebungen einordnen.
Obwohl einige Produkte auf dem Markt sind konnte sich die Technologie im High-End Umfeld
„noch“ nicht richtig ins Rampenlicht befördern.
2.1 Oracle TimesTen
TimesTen wurde im Juni 2005 von Oracle aufgekauft und seither weiterentwickelt in den
Versionen 6.0, 7.0 und aktuell 11.2.
TimesTen spielt aufgrund seiner umfangreichen Funktionen in der oberen Liga mit. In höheren
Sphären bewegt sich auch der Preis, was bei Oracle nicht überrascht. Fairerweise gilt zu
erwähnen, dass Oracle die Weiterentwicklung zügig voran treibt und am Input von Kunden
interessiert ist. Der Hersteller bietet das Produkt für Linux/Unix wie auch für Windows Systeme
an.
Nebst vielen Konfigurationsvarianten kann TimesTen unter anderem als Cache für Oracle Tabellen
verwendet werden. Dabei können partielle oder ganze Tabellen als so genannte Cache Groups in
TimesTen geladen werden. Eine Cache Group kann als read only wie auch read write definiert
sein. Spezielle Prozesse sorgen dafür, dass die Daten auf Wunsch synchron oder asynchron in die
Oracle Datenbank geschrieben werden. Auch das automatische Nachladen von neuen Daten aus
dem Oracle RDBMS funktioniert problemlos. Leider wird als RDBMS nur Oracle für die Cache
Groups unterstützt. Abbildung 1 zeigt wie die Tabelle customer aus dem Oracle RDBMS als
Cache Group namens target_customers in TimesTen geladen ist. Die Cache Group ist nur ein
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 21.09.2011 . Seite 2 / 10
logisches Gebilde. Für den Entwickler repräsentiert sie schlussendlich eine gleichnamige Tabelle
customer in TimesTen.
Abbildung 1: Cache Group in TimesTen (Quelle: Oracle Technology Network. URL:
http://download.oracle.com/docs/cd/E13085_01/doc/timesten.1121/e13073/img/cachegroup1table.gif [Stand:
05.08.2011])
Damit der In-Memory Datenbank nicht der Platz ausgeht bietet TimesTen zwei Typen von Aging
an: time-based oder LRU (least recently used).
Das Innenleben von TimesTen passt sich immer mehr an das Oracle RDBMS an. So findet der
DBA zum Beispiel ein Data Dictionary vor mit Tabellen wie DBA_USERS oder DBA_OBJECTS
und der Datenbankentwickler freut sich über die Unterstützung von PL/SQL. Aber aufgepasst:
Nicht alle Packages und SQL Funktionen aus dem Oracle RDBMS sind auch in TimesTen
vorhanden.
Der Zugriff aus der Applikation heraus kann via OCI oder über JDBC erfolgen. Letzteres ist sehr
gut ausgebaut.
Für High-Availability Zwecke verfügt TimesTen über diverse Replizierungsvarianten (synchron
und asynchron, uni-/bidirektional) um beim Ausfall einer TimesTen Instanz sofort einen Failover
zu initiieren.
2.2 SolidDB von IBM
Ähnlich wie TimesTen ging es zwei Jahre später auch SolidDB. Das Produkt wurde der zweiten
Hälfte 2007 von IBM aufgekauft und seither weiterentwickelt. Die aktuelle Version 6.5 von
SolidDB ist für die Power7 Prozessorgeneration optimiert. Nebst IBM AIX ist die In-Memory
Datenbank auch für andere Plattformen wie Linux, Windows oder Solaris verfügbar. Die
Verwaltung von SolidDB erfolgt über die gleiche SQL Schnittstelle wie jene von IBM DB2.
Gegenüber den Entwicklern präsentiert sich SolidDB ähnlich einer DB2 Instanz. Im Bezug auf
Funktionsumfang und Einsatzgebiete ähnelt SolidDB stark der Oracle Lösung TimesTen. So kann
„SolidDB Universal Cache“ ebenfalls als Cache von Tabellen verwendet werden, welche aus einer
IBM DB2, Microsoft SQL Server, Informix, Sybase oder Oracle Datenbank stammen können.
Betreffend Performance versprechen beide Hersteller bis zu zehn-mal schnellere Antwortzeiten.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 21.09.2011 . Seite 3 / 10
Im Bereich der Hochverfügbarkeit bietet das IBM Produkt die Replikation zu einer weiteren
Instanz an wie auch ein entsprechendes Session Failover, falls sich die aktive Instanz
„verabschiedet“. Dies könnte beispielsweise dann der Fall sein, wenn die Datenbank voll ist.
Dagegen bietet SolidDB entsprechende Aging Mechanismen an um alte oder nicht mehr
verwendete Daten aus der In-Memory Datenbank endgültig zu entfernen.
2.3 HSQLDB – HyperSQL Database
In der Kategorie, in der sich HSQLDB bewegt, gibt es am meisten Mitspieler. Die komplett in Java
geschriebene Datenbank steht unter der BSD-Lizenz und ist im OpenSource wie auch im
kommerziellen Bereich sehr verbreitet. Die In-Memory Datenbank wird für viele Applikationen als
Persistenzlayer eingesetzt wie beispielsweise bei OpenOffice, Mathematica und InstallAnywhere.
Zudem umfasst eine komplette Installation gerade nur 1.3 Megabyte in der aktuellen Version 2.2.
Der Funktionsumfang kommt bei weitem nicht an jenen von TimesTen oder SolidDB heran.
HSQLDB sieht sich selber im Bereich der klein bis mittelgrossen In-Memory Datenbanken. Die
Tabellen in HSQLDB können wahlweise als reine In-Memory Tabellen oder als diskbasierte bzw.
persistente Tabellen angelegt werden. Bei Letzteren werden zusätzlich drei weitere Typen
unterschieden:



MEMORY (default): Daten/Objekte sind in Form eines SQL Scripts auf der Disk
gespeichert.
CACHED: Binäres Dateiformat auf der Disk. Nicht alle Daten sind im Memory geladen.
TEXT: Tabellen Daten sind in CSV Dateien gespeichert.
Jede der genannten diskbasierten Typen garantiert bei einem Serverabsturz die Persistenz der
„committed“ Transaktionen.
HSQLDB lässt sich entweder im so genannten „in-process“ oder im „server mode“ betreiben.
Während „in-process“ schneller ist, bietet der „server mode“ mehr Flexibilität, da auch über das
Netzwerk auf die Datenbank zugegriffen werden kann. Beim „in-process“ Mode befindet sich die
Applikation und die Datenbank im selben Memory Bereich. Es geht keine Zeit durch die Latenz
auf dem Netzwerk verloren.
Die Verwaltung geschieht über ein einfaches Kommandozeilen-programm oder ein webbasiertes
GUI. Besonders zu erwähnen ist bei HSQLDB die sehr gute Dokumentation in vielen Büchern.
Dort geht es meist um die Verwendung der Datenbank im Zusammenhang mit Frameworks wie
Hibernate oder Spring. Die Featureliste von HSQLDB hebt besonders den guten SQL Support
hervor. Weiter bietet HSQLDB ebenfalls umfangreiche Java bzw. JDBC Unterstützung, da die
ganze Datenbank zu 100% in Java geschrieben ist.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 21.09.2011 . Seite 4 / 10
2.4 SQLite
SQLite mischt im gleichen Segment wie die HSQLDB mit und sieht sich selber nicht im High-End
Bereich sondern bei Applikationen, die ihre Daten in einem cross-plattform Format speichern
möchten. Sehr geeignet erscheint SQLite, die übrigens in ANSI C geschrieben ist, auch als
embedded Datenbank bei Gadgets wie MP3 Player oder PDA sowie für kleine Websites. Das
Produkt ist unter einer Public Domain Lizenz verfügbar und kann kostenlos heruntergeladen
werden.
Im Gegensatz zu den meisten anderen Produkten braucht SQLite keine Installation oder
Konfiguration. Die sehr kleine Datenbank von wenigen 100 Kilobytes besitzt keinen eigenen
Serverprozess (serverless). Der Applikationsprozess liest die Daten selber direkt aus der
Datendatei ins Memory. Laut Hersteller ist die Datenbank nicht besonders für hohe Parallelität
geeignet, obwohl mehrere Applikationen die gleiche Datendatei verwenden können.
SQLite wird beispielsweise als Persistenzlayer von Firefox, Skype, Apple oder Adobe verwendet.
Allein das breite Einsatzgebiet deutet darauf hin, dass die Datenbank mit sehr vielen
Programmiersprachen verwendet werden kann. Nebst der Unterstützung für alle gängigen
Plattformen kann die Datenbank relativ einfach für weitere Betriebssysteme portiert werden.
Als einzige Administrationsmöglichkeit von ausserhalb der Applikation bietet SQLite ein
Command Line Interface an.
2.5 Zusammenspiel mit In-Memory Datenbanken
Wie so oft gibt es auch für In-Memory Datenbanken keine out-of-the-box Lösung. Sofern für eine
Plattform bzw. Programmiersprache ein Treiber existiert kann eine In-Memory Datenbank wie ein
herkömmliches RDBMS angesprochen werden. Im High-End Bereich müssen
gezwungenermassen spätestens nach einem ersten enttäuschenden Versuch weitere
Überlegungen im Bezug auf die Architektur und Implementierung gemacht werden. Die Probleme
liegen im Detail. Folgende Tatsachen sprechen häufig für den Einsatz einer In-Memory
Datenbank:






Hoch frequentierter read only Daten Cache (Lookup Tabellen)
Datenbank kann/soll nahe bei der Applikation sein (gleicher Server, direct Connect)
Entlastung der physikalischen Datenbank (Anzahl Transaktionen, I/O, User Sessions)
Temporäre Daten mit vielen Zugriffen (lesend und schreibend)
Datenverlust kann in Kauf genommen werden
Kurze, einfache SQL Statements kommen zur Ausführung
Eine In-Memory Datenbank ist ein Feature für Applikationen mit dem Performance Gewinne
erzielt werden können. Um das zu erreichen, muss die Applikation an die Funktionen der InMemory Datenbank angepasst werden, nicht umgekehrt. Der Einsatz einer In-Memory Datenbank
garantiert keine Performance Gewinne.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 21.09.2011 . Seite 5 / 10
3.
Allgemeine Funktionsweise von In-Memory Datenbanken
Beim Durchlesen der Dokumentation fällt schnell auf, dass sich alle In-Memory Datenbanken
ähnlicher Prinzipien bedienen. Vor allem im Bereich der komplexeren Produkte wie TimesTen
oder SolidDB sind viele Gemeinsamkeiten festzustellen.
1. Datenhaltung
Beim Starten der Datenbank lädt das System die gesamten Daten von der Disk ins
Memory, damit zur Laufzeit keine Daten nachgeladen werden müssen.
2. Checkpoint Files/Snapshot Images:
Die geänderten Daten aus dem Memory werden in regelmässigen Abständen mit dem
persistenten Speicher (Disk) abgeglichen.
3. Transaction Logs
Zwischen den einzelnen Checkpoint Vorgängen werden die laufenden Änderungen in
Transaction Logs geschrieben, um nach einem Crash ein Rollforward machen zu können.
4. ACID Prinzip
Wie herkömmliche RDBMS unterstützen auch In-Memory Datenbanken das ACID Prinzip.
5. High-Availability
In-Memory Produkte wie IBM SolidDB oder Oracle TimesTen bieten High-Availability in
Form von Replikation an. Bei einem Crash kann ein Failover auf die verbleibende Instanz
stattfinden.
6. Direct Connect
Die Applikation hat die Möglichkeit die In-Memory Datenbank direkt in ihren eigenen
Adressbereich zu laden um jeglichen Overhead wie z.B. Netzwerk zu eliminieren.
Abbildung 2 stellt ein diskbasiertes und ein In-Memory System (TimesTen) dar. Der grösste
Unterschied besteht in der Datenhaltung. TimesTen liest beim Starten der Datenbank alle Daten
aus dem Checkpoint File in das Memory. Ein diskbasiertes RDBMS lädt erst bei Bedarf zur
Laufzeit die gewünschten „Data Pages“ von der Disk in den Buffer Pool nach. Dadurch
vereinfachen sich die Zugriffsalgorithmen bei In-Memory Sytemen massiv was wiederum zu einer
besseren Performance führt. Der „Query Optimizer“ kann bei TimesTen direkt auf alle Daten im
Memory zugreifen ohne kostspieliges I/O zu erzeugen.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 21.09.2011 . Seite 6 / 10
Abbildung 2: Diskbasierend versus In-Memory (Quelle: Oracle Technology Network. URL:
http://download.oracle.com/docs/cd/E13085_01/doc/timesten.1121/e14261/img/findingrecords.gif [Stand: 05.08.2011])
4.
„On-Disk“ oder „In-Memory“ – Entscheidungskriterien
Bei der Produktwahl spielen im In-Memory Bereich die Grösse der Datenbank (in Bytes) und die
Anzahl Transaktionen bzw. die Concurrency eine wichtige Rolle. Die folgende Grafik zeigt
schematisch, wo sich die im Artikel erwähnten Produkte etwa einordnen lassen.
Abbildung 3: Einordnung der In-Memory Produkte
Die folgende Tabelle stellt typische Eigenschaften der beiden Systeme gegenüber, die bei der
Entscheidung für oder gegen In-Memory behilflich sein können.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 21.09.2011 . Seite 7 / 10
In-Memory
Applikation und In-Memory auf gleichem
Server, verbunden mit „direct connect“
Keine blockierenden Disk I/O Operationen
beim Commit da nur im Memory
Verlust von „committed“ Daten möglich da nur
im Memory (Log Buffer).
Wenig Backup Features, Datenverlust beim
Servercrash möglich
Wenig Analysetools bei PerformanceProblemen (kein SQL elapsed time)
Kein parallel Query
Wenig Wissen vorhanden
5.
On-Disk
Verschiedene Server für Applikation und
Datenbank
Blockierende I/O Operationen beim Commit
da Log Buffer auf Disk geschrieben wird
ACID garantiert
Umfangreiche Features im Backup Bereich,
Restore/Recover ohne Datenverlust
Umfangreiche Tools und Reporting
Möglichkeiten
Parallel Query vorhanden
Viel Wissen vorhanden
Erfahrungen mit TimesTen
Die überaus interessante Projektarbeit der beiden Autoren brachte insgesamt zwei Tatsachen zu
TimesTen bzw. In-Memory Datenbanken ans Tageslicht:
1.) Die Umstellung zu In-Memory ist ein Projekt!
Eine Applikation lässt sich nicht einfach mal schnell umstellen und alles läuft 10-mal
schneller. Eine 1:1 Migration ist eine Illusion!
2.) Interessante Herausforderungen
Der Know-how Aufbau, sowie das Austesten und Anpassen der Applikation bieten ein
sehr interessantes und neues Aufgabengebiet.
Mit dem sehr guten Oracle RDBMS Know-how stellten die beiden Autoren während dem Projekt
mehrmals fest, dass Dinge aus dem Oracle RDBMS nicht implizit für TimesTen bzw. In-Memory
gelten. Deshalb zieht eine Umstellung zu In-Memory Tätigkeiten wie Code Änderungen,
Fehlersuche und kontinuierliche Performance Analyse mit sich. Das Umschreiben von Code ist
meistens wegen fehlenden Packages/Funktionen in TimesTen oder zu komplexer Queries
erforderlich. Als Beispiel mussten „connect by“ Ausdrücke in SQL geändert werden um den
gleichen Output ohne „connect by“ zu erreichen. Diese Arbeit ist betreffend Aufwand keinesfalls
zu unterschätzen, denn es stellt auch erfahrene Entwickler vor Herausforderungen eine „connect
by“ Klausel wie „zu alten Zeiten“ zu implementieren. Ein kleines Beispiel mit der Oracle EMP
Tabelle soll dies exemplarisch zeigen:
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 21.09.2011 . Seite 8 / 10
Die „Connect by“ Klausel in Oracle funktioniert in TimesTen leider nicht.
SELECT *
FROM emp
START WITH mgr IS NULL
CONNECT BY PRIOR empno = mgr;
Also könnte der Entwickler auf die Idee kommen das selbe Resultat mit der WITH Klausel zu
erzeugen. Leider ist aber auch WITH nicht unterstützt in TimesTen.
WITH
employees (empno, name, job, mgr, hierlevel)
AS
(SELECT empno, ename, job, mgr, 1
FROM emp
WHERE mgr IS NULL
UNION ALL
SELECT e.empno, e.ename, e.job
, e.mgr, m.hierlevel + 1
FROM emp e
JOIN employees m
ON(m.empno = e.mgr)
)
SELECT *
FROM employees;
Also bliebt in TimesTen nur noch die prozedurale Lösung mit PL/SQL, die hier aufgrund des
Umfangs nicht abgebildet ist.
Die Lösungssuche und Analyse der Probleme wird weiter erschwert durch die sehr rudimentären
Tools in TimesTen wie auch vom knappen Know-how Angebot, sei es via Google oder „My
Oracle Support“. Deshalb gibt es viel Bedarf an „Learning by Doing“!
Perfekt formatierte Performance Reports, wie sie vom Oracle RDBMS bekannt sind, fehlen in
TimesTen. Somit kämpft sich der DBA mit SQL Queries durch die internen Data Dictionary
Views. Zusätzlich erschwerend ist der Umstand, dass TimesTen keine „elapsed time“ für SQL
Queries aufzeichnet. Während der zeitraubenden Umstellung sank auch das Verständnis der
Applikationsentwickler, da diese der Meinung waren, eine Datenbank sei doch eine Datenbank.
Schlussendlich kämpft der DBA an zwei Fronten. Nichts desto trotz macht die Arbeit viel Spass
und bringt neue Erkenntnisse mit sich. Dies in einem noch sehr jungen und dynamischen Umfeld,
welches aktuell noch relativ überblickbar ist, im Vergleich zu einem Oracle RDBMS mit
hunderten von Features.
Zusammenfassend gesagt braucht die Projektplanung genug Zeitpuffer für Know-how Aufbau und
Testing bzw. Analyse und Anpassungen. Wird dies von Anfang an berücksichtigt bleiben auch die
rauchenden Köpfe aus, vor allem diejenigen der Projektleiter, die versuchen im Zeitplan zu sein.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 21.09.2011 . Seite 9 / 10
6.
Fazit
Schöne neue Welt, alles schneller, alles besser. Das wurde uns schon von anderen Technologien
versprochen. In-Memory ist schneller. Doch es gibt ein Aber. Es geht nicht einfach damit ein paar
Tabellen ins Memory zu stellen. Es braucht Überlegungen und da fängt die Herausforderung an.
Die Erste ist das fehlende Wissen nicht nur in der eigenen Firma sondern auch ausserhalb.
Applikationen können nicht einfach kopiert werden. Häufig fehlen dann die entsprechenden SQL
Features (connect by) oder der Datentyp ist ein bisschen anders. Doch es gibt auch Positives. InMemory ist schnell. Richtig eingesetzt sehr schnell. Legt man alles auf den gleichen Server,
arbeitet mit "direct connect" und nutzt kleine und simple SQL‘s, dann „fliegt“ die In-Memory
Datenbank und verkraftet enorme Mengen an Abfragen.
Die Frage ist also: Brauche ich In-Memory? Geht es nicht mit der "normalen" Datenbank? Würde
ein Tuning helfen oder ein grösserer Server oder mehr Memory das Problem lösen? Bin ich bereit,
die Mehrkosten für die zusätzliche Hard- und Software, Spezialisten, neue Maintenance und
Backup/Recovery Mechanismen zu zahlen?
Wenn ja, dann wird es spannend und ihre Daten lernen das Fliegen.
7.
Quellen
Wikipedia: “In-memory database“. http://en.wikipedia.org/wiki/In-memory_database [Stand
08.08.2011].
Oracle Technology Network: “TimesTen In-Memory Database Documentation”.
http://download.oracle.com/docs/cd/E13085_01/welcome.html [Stand: 08.08.2011].
IBM: “solidDB Universal Cache”. http://www-01.ibm.com/software/data/soliddb/universalcache/features.html?S_CMP=rnav [Stand: 08.08.2011].
HyperSQL DB: “HyperSQL version 2.2 documentation”.
http://hsqldb.org/web/hsqlDocsFrame.html [Stand: 08.08.2011].
SQLite DB: „SQLite Documentation“. http://sqlite.org/docs.html [Stand: 08.08.2011].
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 21.09.2011 . Seite 10 / 10