In-Memory-Datenbanken ermöglichen es, die gesamte Datenbank im Hauptspeicher zu halten, was zu schnelleren Zugriffen und der Eliminierung von Disk-I/O führt. Durch neue Indexierungsstrukturen wie T-Tree und Trie wird die Effizienz beim Datenzugriff signifikant erhöht. Diese Technologien erfordern jedoch ausreichend physikalischen Speicher, um eine optimale Leistung zu gewährleisten.

1. In-Memory Datenbanken
Arno Schmidhauser
Letzte Revision: Januar 2011

2. Neues technologisches Umfeld
• Bisher
– Eine Datenbank konnte nur zu Bruchteilen im Memory
gehalten werden ( << 50%).
– Sparsamkeit beim Datentransfer zwischen Disk und Memory
ist daher oberstes Prinzip.
– I/O-Page als Grundeinheit der physischen Memory-
Verwaltung (durch die DB, nicht durch das OS).
• Neu
– Systemstabilität durch Hardware und Betriebssystem-
Features massiv höher als früher. Recovery aufgrund von
Systemausfällen nur noch selten notwendig.
– Standard-Memory Ausstattung > 4GB kein Problem mehr.

3. Neues Prinzip
• Datenbank bei Start des DB-Servers vollständig in das
Memory laden (z.B. Unix Memory Mapped Files).
 Das gesamte Buffer-Management entfällt, der Speicher
wird als linearer Adressraum für Datensätze angesehen,
alle Positionen gleich schnell adressierbar.
 Zugriff auf beliebiges Datenelement immer gleich schnell.
Transfer von/zu Disk muss nicht mehr berüchsichtigt
werden.

4. Mutationen
• ACID Regel ist immer noch ein zwingendes Prinzip!
2. SQL-Befehl
Workspace =
2b. Neue
Gesamte Datenbank
Datenwerte
1. Startup = 3. Shutdown oder
2a. Alte und neue Checkpoint =
Gesamte DB laden
Datenwerte Ganze DB speichern
Logfile DB-Storage

5. Neue Optimierungsmöglichkeiten
• Indexe werden bei Systemstart im Memory aufgebaut.
Keine materialisierten Indexe mehr.
• Keine komplizierte Datensatz-Adressierung auf die Disk
notwendig, da die Daten selber ja bereits im Memory sind.
• Indexe brauchen die Schlüsselwerte nicht noch einmal zu
enthalten, da die Daten selber ja bereits im Memory sind.
 Zusätzliche Ersparnis von Memory gegenüber
klassischen Datenbank.
 Neue Index-Strukturen: zum Beispiel T-Tree (Oracle)
und Trie (IBM).

6. T-Tree Index (Oracle TimesTen)

7. T-Tree Index
• Über alles gesehen wesentlich weniger Code abzuarbeiten,
da keine Diskzugriffe zu berücksichtigen sind.
• Wenig Platzbedarf für Index, da nur Pointer auf Daten
nötig sind, und nicht die Datenwerte selbst.
• Binäre Verzweigung und kleine Anzahl Werte (Pointer) pro
Knoten garantiert hohe CPU-Effizienz. Keine lineare Suche
durch grosse IO/Pages hindurch.
• Anwendbar wie B-Tree: für Suche mit exakten Vergleiche
und Range-Suche geeignet.
• Achtung: Peformance-Desaster bei zuwenig Memory !!

8. Trie-Index (IBM solidDB)
t r
e o
e a
8
9
d a 10 a
d t
1 4
2 12
3 s 13
t
11

9. Trie-Index
• Das Auffinden von Schlüsselwerten ist sehr schnell,
Zeitbedarf nur proportional zur Länge des Schlüsselwertes!
• Alle Werte mit demselben Präfix teilen sich die Knoten für
dieses Präfix, z.B. "to" und "toast". Suche nach Werten mit
demselben Präfix via Trie möglich, z.B. like – Prädikat.
• Auch Zahlen können mit einem Trie indexiert werden.
• Tries können sortiert aufgebaut werden, so dass dann eine
preorder-Ausgabe ebenfalls sortiert ist.
• Demo unter http://blog.ivank.net/trie-in-as3.html

10. IMDB als "relationaler Cache"
• Oracle TimesTen und IBM solidDB können als schneller
relationaler Cache verwendet werden:

11. Latenzzeit für Queries
• Aufgrund der einfacheren Optimizer (meist nur ein bis
zwei Indextypen und sequentieller Table Scan zur
Auswahl), sowie massiv kleinerem Code, liegt die
Latenzzeit für Queries und Änderungsoperationen
typischerweise bei Mikrosekunden. Bei klassischen
Datenbanken sind es meist Millisekunden.

12. Gemischter Betrieb mit IMDB
• DB-Hersteller bieten zunehmend einen gemischten Betrieb
von disk-basierten und memory-basierten Teilen an.
• Beispiel solidDB
create table T (…) store memory | store disk
• Aus dem Speichertyp der Tabelle werden alle übrigen
Verhaltensweisen abgeleitet: Indextyp,
Zugriffsoptimierung, Verhalten bei Startup, Checkpoint
und Shutdown des DB-Servers.

13. Solid State Disk
• Datenbanken können aus den schnelleren Solid State
Disks Gewinn ziehen, insbesondere auch für das Führen
von Log-Files. Die Grundsatztechnologie geht aber von
klassischen Datenbanksystemen aus:
– mehrstufiger Zugriff Disk-Memory
– IO/Pageing
– Komplexe, zeitintensive Optimierungsstrategien
• Eine noch höhere Performance wird erreicht, wenn wenig-
selektive Indexe gelöscht oder vermieden werden, damit
vermehrt Full Table Scans vom DBMS ausgeführt werden.

14. Kennzahlen SSD
MLC-NAND-Flash-
CompactFlash-Karte Festplatte
Laufwerk
1,0″ bis 3,5″ per ATA-Adapter 1,0″ bis 3,5″
Größe bis 600 GB bis 128 GB bis 3 TB
Preis pro GB (Stand Dez.
2011) ab ca. 0,96 € ab ca. 1,02 € ab ca. 0,05 €
Anschluss S-ATA, P-
ATA, mSATA, PCIe S-ATA, P-ATA S-ATA, P-ATA, SCSI, SAS
Lesen (kein RAID) bis 509 MB/s bis 100 MB/s bis 150 MB/s
Schreiben (kein RAID) bis 446 MB/s bis 100 MB/s bis 150 MB/s
Mittlere Zugriffszeit lesen 0,2 ms 0,8 ms ab 3,5 ms
Mittlere Zugriffszeit schreiben 0,4 ms 10…35 ms ab 3,5 ms
Verhalten beim PC-
Ausschalten problemlos problemlos problemlos
Verhalten bei Stromausfall
ohne Stützkondensator
Datenverlust möglich Datenverlust möglich Datenverlust möglich

15. In Memory DMBS, Produkte
• Oracle Times Ten
• solidDB von IBM
• HSQLDB
• Apache Derby
• XML-Datenbank BaseX
• Weitere siehe bei Column Stores

16. Zusammenfassung Ziele eines
In-Memory-DBMS
• Eliminierung von Disk-IO für den laufenden Betrieb des DBMS
• Ausnutzung der virtuellen Memory-Verwaltung des Betriebs-
systems
• Minimierung aller roten
Bereiche in nebenstehendem
Profilingdiagramm eines
klassischen DBMS
• Voraussetzung: Ausreichend
Platz für das gesamte DBMS
im physikalischen Memory,
inklusive temporären Platz für
SQL-Abfragen.