Datenbanken: Verwaltung großer Datenmengen in Hauptspeicherdatenbanken - Stefan Halfpap, Ralf Teusner, Werner Sinzig, Michael Perscheid 17. Juli 2020

Datenbanken: Verwaltung großer Datenmengen in
Hauptspeicherdatenbanken

                  Stefan Halfpap, Ralf Teusner, Werner Sinzig, Michael Perscheid
                                                                   17. Juli 2020

Vorlesungsinhalte/-aufbau

■ Einführung zu Unternehmensanwendungen

■ Grundlagen des IT-gestützten Rechnungswesens und der Planung

■ Einführung zu relationalen Datenbanken und Anfrageverarbeitung

■ Grundlagen von (spaltenorientierten) Hauptspeicherdatenbanken

■ Trends in Hauptspeicherdatenbanken

■ Klausur

                                                                   2

Überblick

■ Motivation

■ Problem

■ Moderne Buffermanager

■ Implementierungen

■ Zusammenfassung

                          3

Literatur und Empfehlung

■ Andy Pavlo „Advanced Database Systems“
 □ Larger-than-Memory Databases
         https://15721.courses.cs.cmu.edu/spring2020/slides/23-largerthanmemory.pdf

■ Leis et al. „LeanStore: In-Memory Data Management beyond Main Memory” (2018)
         https://db.in.tum.de/~leis/papers/leanstore.pdf

                                                                                      4

Zusammenfassung
Festplattenbasierte DB vs. HauptspeicherDB

■ Festplattenbasierte Datenbanksysteme verwenden Buffermanager um große (größer
  als Hauptspeicher) Datenmengen zu verwalten
 □ Effektiv um Festplattenzugriffe zu minimieren
 □ Aber: Hauptquelle des Overheads
   im Vergleich zu Hauptspeicherdatenbanken

                                                                                                                             5

                                          Harizopoulos et al. „OLTP Through the Looking Glass, and What We Found There” (2008)

Zusammenfassung
Festplattenbasierte DB vs. HauptspeicherDB

■ Hauptspeicherdatenbanken verzichten auf einen Buffermanager
■ Möglich durch größere und günstigere Hauptspeicher und Datenkompression
■ Relationen und Indizes sind direkt im Hauptspeicher gespeichert
  und virtuelle Memory-Pointer werden statt Page-Identifier verwendet
  (siehe 05_DB_Tabellenrepraesentation_im_Speicher)

                                                                            6

Motivation

■ Relationen und Indizes sind direkt im Hauptspeicher gespeichert
■ Aber:
 □ Hauptspeicher ist im Vergleich zu SSDs/Festplatten eine relativ teure und knappe
   Ressource
 □ Workloads habe schiefe Zugriffsmuster: Hot vs. Cold Data
   (siehe 07_DB_Weitere_Optimierungen)
 □ Kosten/Performanz in Praxis wichtig
      David Lomet „Cost/Performance in Modern Data Stores: How Data Caching Systems Succeed “ (2019)

■ Es wäre schön, wenn Hauptspeicherdatenbanken günstigeren Speicher nutzen könnten
  ohne den Ballast von Festplattenbasierten Systemen zu benötigen

                                                                                                       7

Problem

■ Hauptspeicherdatenbanken verzichten auf einen Buffermanager,
  was die Verwaltung von großer (größer als der Hauptspeicher) Datenmengen schwierig macht
 □ Wenn Daten nicht in Hauptspeicher passen, lagert das Betriebssystem virtuelle Seiten aus
 □ Hauptspeicherzugriffe erzeugen dann Seitenfehler
 □ Die Ausführung einen Datenbankoperation wird dann
   unterbrochen, während die Seite in den Hauptspeicher
   geladen wird
 à unvorhersagbare Performanzverschlechterung

 □ Besonders für OLTP-Workloads ein Problem                 Graefe et al. „In-Memory Performance for Big Data” (2014)

 □ Zugriffsmuster von OLAP-Workloads werden in der Regel besser unterstützt                                      8

Idee

■ Klassifiziere und partitioniere Daten in „hot“ (häufig zugegriffen)
  und „cold“ (selten zugegriffen)
■ Speichere kalte Daten auf günstigeren Speicher (SSD, HDD);
  lade kalte Daten, wenn sie benötigt werden
■ „Anti-Caching“: Primärer Speicherort ist Hauptspeicher und Daten werden ausgelagert
  (als Gegensatz zu festplattenbasierten Systemen: primärer Speicherort ist die Festplatte und
  Daten werden im Hauptspeicher (Buffermanager) gecacht)

Ist es möglich einen effizienten „Buffermanager“ für moderne Hardware zu entwerfen?

                                                                                             9

Moderner „Buffermanager“: Designentscheidungen

■ Identifikation von kalten Daten (Welche Daten lagere ich auf die Festplatte aus?)

■ Auslagerungsstrategie (Wie lagere ich Daten auf die Festplatte aus?)

■ Rückholstrategie (Wie hole ich Daten von der Festplatte zurück?)

■ Beachte: Hardware-Zugriffsmethoden sind unterschiedlich
  □ RAM: „think of cachelines“
  □ Disk: Seiten-orientiert

                                                                                      10

Moderner Buffermanager: Designentscheidungen
Identifikation von kalten Daten

Identifikation von kalten Daten (Welche Daten lagere ich auf die Festplatte aus?)
■ Online
  □ Datenbanksystem überwacht/verfolgt Zugriffe (während der Anfrageverarbeitung)
  □ Umgesetzt durch Meta-Daten direkt am Element (z.B. Seite, Tupel oder Spalte)

■ Offline
  □ Speichere eine ein Zugriffslog während der Anfragebearbeitung
  □ Separater Hintergrundprozess zur Berechnung der Zugriffsstatistik

                                                                                    11

Moderner Buffermanager: Designentscheidungen
Auslagerungsstrategie

Auslagerungsstrategie (Wie lagere ich Daten auf die Festplatte aus?)
■ Bestimmung des Zeitpunktes und Menge der ausgelagerten Daten

■ Meta-Daten für ausgelagerte Daten
 □ Speicherort für ausgelagerten Eintrag (Tupel)
 □ Meta-Informationen (Pruning-Filter) für ausgelagerte Einträge
   (siehe 07_DB_Weitere_Optimierungen)
 □ Seitenverwaltung durch Datenbanksystem
 □ Seitenverwaltung (bestimmter Bereiche) durch Betriebssystem

                                                                       12

Moderner Buffermanager: Designentscheidungen
Rückholstrategie

Rückholstrategie (Wie hole ich Daten von der Festplatte zurück?)
■ Granularität
  □ Alle Tupel der Speicherseite
  □ Nur benötigte Tupel
  □ Nur veränderte Tupel
  □ Nur häufig zugegriffene Blöcke

                                                                   13

Moderner Buffermanager
Implementierungen
                        Andy Pavlo „Advanced Database Systems“: Larger-than-Memory Databases

■ (2013) H-Store: Anticaching - Tupel-Level

■ (2014) Hekaton: Siberia - Tupel-Level

■ (2013) EPFL‘s VoltDB Prototype – OS Seitenverwaltung

■ (2018) LeanStore: Hierarchischer Bufferpool (mit Pointer Swizzeling)

■ (2019) Umbra: Bufferpool mit Seiten variabler Größe (mit Pointer Swizzeling)

                                                                                               14

Zusammenfassung

■ Hohe Performanz von Hauptspeicherdatenbanken ist unstrittig
■ Aber: Kosten/Performanz in Praxis wichtig
■ Moderne effiziente „Buffermanager“ ermöglichen (fast) In-Memory Performanz, für
  Datenbanken, die größer als der Hauptspeicher sind

                                                                                    15