Data Warehouse Technologien

1 1 1 1 0 0 0 0 0

1002100310041005

RieslingDornfelder

Müller-ThurgauMerlot

Miniseite für

ProdNr

Präsenzbits

Miniseitenverzeichnis

1 1 1 1 0 0 0 0 0

9,9510,9511, 9 59,90

Satz-

verzeichnis

Miniseite für

Preis

Miniseite für

Bezeichnung

Abbildung 6.27: Seiten-PAX

6.4 Hauptspeicherdatenbanken

Erst seit einigen Jahren sind Hauptspeichergrößen, die für typische Data-

Warehouse-Anwendungen benötigt werden, technisch realisierbar und auch

ökonomisch sinnvoll. Daher werden Hauptspeicherdatenbanken verstärkt für

analytische Anwendungen protegiert. Da dieses Thema zurzeit noch aktuelles

Forschungsthema ist, werden wir in diesem Abschnitt im Wesentlichen einige

Forschungsfragestellungen skizzieren und nicht ins Detail gehen.

6.4.1 Was sind Hauptspeicherdatenbanken?

Hauptspeicherdatenbanken sind in den letzten Jahren stark in der Diskussion

– seit ca. 2009 steigen die Veröffentlichungszahlen zu diesem Thema stark an.

Dies ist sicher auch ein Effekt der Tatsache, dass Firmen wie SAP zusammen

mit einflussreichen Persönlichkeiten wie Hasso Plattner dies stark forcieren

[Pla09, PZ11, PZ12]. Nichtsdestotrotz ist das Konzept der Hauptspeicherdaten-

bank (engl. main memory database) schon seit längerer Zeit in der Forschung

präsent – bereits 1992 veröffentlichten Garcia-Molina und Salem einen Survey-

Artikel zu diesem Thema [GMS92].

Die klassische Datenbanktechnologie ist auf die Überwindung der soge-

nannten Zugriffslücke ausgerichtete. Die Datenbank ist persistent auf dem

Hintergrundspeicher gespeichert; nur ein Bruchteil der Daten passt in den

6.4 Hauptspeicherdatenbanken 185

Hauptspeicherpuffer. Der Hintergrundspeicher, realisiert mit Festplattentech-

nologie, ist ca. um den Faktor 10

5

langsamer als der Hauptspeicher, und aus

technischen Gründen erfolgt der Zugriff blockweise, also in Einheiten fester

Größe von mehreren Kilobyte (siehe Diskussion in [SSH11]).

Hauptspeicher statt Festplatte

Die grundlegende Idee der Hauptspeicherdatenbanken ist so einfach wie beste-

chend: Wenn der Hauptspeicher groß genug ist, passt die gesamte Datenbank

in den Hauptspeicherpuffer. Warum sollte man dann spezielle Datenorganisa-

tionsformen für die Festplatte in den Vordergrund stellen, anstatt gleich von

vornherein effiziente Hauptspeicher Datenstrukturen zu nutzen? Typisches

Beispiel ist der B-Baum: Die Seitengröße ist an die Blockgröße des Hinter-

grundspeichers angepasst – wobei die Knoten als Resultat nicht ganz gefüllt

sind. Eine Hauptspeicherdatenstruktur sollte eine bessere Speicherausnutzung

erreichen, ohne auf feste Transfereinheiten zwischen Hauptspeicher und Se-

kundärspeicher Rücksicht nehmen zu müssen.

Diese Idee hat einige Konsequenzen. Die Annahmen über den Festplatten-

zugriff treffen nicht mehr zu: die Zugriffslücke mit dem Faktor von 10

5

ist nicht

mehr die Grundlage der Anfrageoptimierung. Algorithmen können wahlfreien

Zugriff statt blockweisen Zugriff nutzen – insbesondere ist nichtlokaler Zugriff

nicht teurer als lokaler Zugriff.

Als Resultat können Algorithmen und Datenstrukturen, die wegen dieser

Charakteristika nicht in DBMS genutzt wurden, jetzt effizient eingesetzt wer-

den. Beispiele sind Bäume mit kleinen Knoten bzw. mit Knoten variierender

Größe, sowie Komprimierungsalgorithmen die nicht auf sequenziellem Durch-

lauf basieren.

Diese Bemerkungen lassen vermuten, dass Hauptspeicherdatenbanken

viel effizienter arbeiten können als Lösungen, bei denen die Daten auf dem

Hintergrundspeicher residieren. Allerdings darf man eins nicht vergessen: Der

Hauptspeicher ist flüchtig!

Weitere technische Herausforderungen

Auch wenn die große Zugriffslücke zwischen Hauptspeicher und Festplatte mit

ihrem Faktor von 10

5

nun wegfällt, ist der Zugriff auf den Speicher weiterhin

ein Engpass. In [BKM08] wird hier der Begriff des memory wall genutzt, um

den nun innerhalb des Rechners bestehenden Zugriffsengpass zwischen den

Prozessoren mit ihrem lokalen schnellen Cache-Speichern und dem normalen,

größeren, aber auch langsameren Hauptspeicher zu beschreiben. Wir haben

eine ähnliche Situation wie vorher zwischen Festplatte und Hauptspeicher: Der

schnelle Cache ist signifikant kleiner, und aus Optimierungsgründen werden

Teile des Hauptspeicherinhalts in den Cache kopiert, und dabei werden jeweils

ganze Speicherbereiche kopiert, da die lokale Optimierung davon ausgeht, dass

186 6 Speicherung