Green-IT und Datenbanken - ODBMS

6 Energieoptimierungen
seite im Arbeitsspeicher als "dirty"markiert, kann sofort ein In-Memory-Logsektor
im Arbeitsspeicher zur Verfügung gestellt werden. Dieser Logsektor kann dann auf
den Flash-Speicher geschrieben werden, wenn der Logsektor im Arbeitsspeicher voll
ist oder die Seite aus dem Arbeitsspeicher entfernt wird. Um diese Idee umsetzen
zu können, wird ein Block des Flash-Speichers in zwei Teile unterteilt. Der eine Teil
enthält die Datenseiten und der andere die Logsektoren. Die Größe des In-Memory-
Logsektors muss genauso groß sein wie die des Flash-Speichers.
Wenn ein Block keine ausreichend freien Speichermöglichkeiten für die Log-Einträge
mehr hat, werden die Seiten und Log-Einträge in einem neuen Block zusammengeführt.
Hierbei wird aus der Vorgängerversion einer Seite und den entsprechenden
Log-Einträgen die aktuelle Version einer Seite erzeugt und in dem neuen Block gespeichert.
Dies geschieht für alle Seiten des vollen Blockes gleichzeitig. Da sich in dem
neuen Block nun bereits die aktuellen Versionen der Seiten befinden, sind die alten
Log-Einträge obsolet und müssen nicht mehr gespeichert werden. Somit ist wieder
ausreichend Platz für neue Log-Einträge. Der Inhalt des ursprünglichen Blockes wird
anschließend gelöscht.
Der IPL-Ansatz benötigt neben diesem den Schreibzugriff minimierenden Verfahren
auch einen anderen Leseansatz. Wenn eine defekte Seite neu gelesen werden muss, geschieht
dies durch das Lesen der ursprünglichen Version der Seite vom Flash-Speicher.
Gleichzeitig wird der korrekte Zustand der Seite mit Hilfe der Log-Einträge, welche
sich im selben Block befinden, wieder hergestellt. Zwar ist die Rekonstruktion der
Seite beim Lesen teuer, aber es werden dadurch viele Schreiboperationen gespart, da
das Zusammenführen nur dann ausgeführt werden muss, wenn der Logsektor voll ist.
Simulationen haben gezeigt, dass die IPL-Strategie dabei helfen kann, die Nachteile
von Flash-Speichern zu überwinden, und eine bessere Performance erzielt [Lee07].
FlashDB
FlashDB ist eine für Flash-Geräte optimierte, von Suman Nath und Aman Kansal
[Nat07] vorgestellte, Datenbank. Die Datenbank wird mit den Lese- und Schreibkosten
des verwendeten Flash-Speichers konfiguriert und passt daraufhin ihre Speicherstruktur
so an, dass der Energieverbrauch gesenkt und die Latenzzeit für den
Workload optimiert wird. FlashDB besteht aus zwei Einheiten, zum einen dem
Datenbank-Manager, der für die eigentlichen Datenbankoperationen wie Indexerstellung
und Query-Compilation verantwortlich ist, und zum anderen dem Storage-
Manager, der für die effiziente Ansteuerung des Flash-Speichers verantwortlich ist.
Der Storage-Manager kontrolliert den Puffer und die Garbage-Collection. Die Architektur
von FlashDB ist in Abbildung 6.22 dargestellt. Die zentrale Idee hinter
FlashDB ist ein selbstanpassender B + -Baum für die Indexstruktur. Für Flashspeicher
gibt es zwei verschiedenen B + -Bäume:
126
1. B + -Baum(Disk): Hierbei werden die Konten des Baumes je nach Größe über
mehrere hintereinander liegende Seiten auf dem Flash-Speicher abgelegt. Diese