In-Memory Datenbanken

Arno SchmidhauserLetzte Revision: Januar 2011

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.

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.

Mutationen

• ACID Regel ist immer noch ein zwingendes Prinzip!

DB-Storage

2. SQL-Befehl

2b. NeueDatenwerte

Logfile

2a. Alte und neueDatenwerte

Workspace = Gesamte Datenbank

1. Startup = Gesamte DB laden

3. Shutdown oder Checkpoint = Ganze DB speichern

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).

T-Tree Index (Oracle TimesTen)

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 !!

Trie-Index (IBM solidDB)

t

e o

r

e a

d a a

s

t

td123

4

8910

12 13

11

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

IMDB als "relationaler Cache"

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

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.

Gemischter Betrieb mit IMDB

• DB-Hersteller bieten zunehmend einen gemischten Betrieb von disk-basierten und memory-basierten Teilen an.

• Beispiel solidDBcreate 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.

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.

 MLC-NAND-Flash-

Laufwerk CompactFlash-Karte Festplatte

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 schreiben0,4 ms 10…35 ms ab 3,5 ms

Verhalten beim PC-Ausschalten problemlos problemlos problemlos

Verhalten bei Stromausfall

 

Datenverlust möglich Datenverlust möglichohne Stützkondensator Datenverlust möglich

Kennzahlen SSD

In Memory DMBS, Produkte

• Oracle Times Ten• solidDB von IBM • HSQLDB• Apache Derby• XML-Datenbank BaseX

• Weitere siehe bei Column Stores

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 einesklassischen DBMS

• Voraussetzung: AusreichendPlatz für das gesamte DBMS im physikalischen Memory, inklusive temporären Platz fürSQL-Abfragen.