Architektur von Datenbanksystemen - fbi.h

KAPITEL 2
VERWALTUNG DES
HINTERGRUNDSPEICHERS
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
1
Verwaltung des Hintergrundspeichers
Inhalte des Kapitels
• Speicher- und Sicherungsmedien
• Struktur des Hintergrundspeichers
• Pufferverwaltung im Detail
• Umsetzung in konkreten DBMS
Lernziele
• Verstehen der Konzepte zur physischen Speicherung der
Datenbankdaten
• Kennenlernen der wichtigsten Parameter zur Beeinflussung der
physischen Ablage der Daten und zur Pufferverwaltung
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
2
Einordnung in 5-Schichten-Architektur
Mengenorientierte Schnittstelle
Datensystem
Satzorientierte Schnittstelle
Zugriffssystem
Interne Satzschnittstelle
Speichersystem
Systempufferschnittstelle
Pufferverwaltung
Dateischnittstelle
Betriebssystem
Geräteschnittstelle
Externspeicher
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
3
Speicher- und Sicherungsmedien
• Primärspeicher
– Register, Cache, Arbeitsspeicher
– sehr schnell, teuer, flüchtig, klein
– Zugriffsgranularität: fein (i.a. jedes Byte adressierbar)
• Sekundärspeicher
– meist Plattenspeicher, nicht-flüchtig (persistent)
– langsam, preiswert, groß
– Zugriffsgranularität: Blöcke (oft 512 Bytes)
– Zugriffslücke: Faktor 105 langsamerer Zugriff
• Tertiärspeicher
– zur langfristigen Datensicherung (Backup und Archivierung)
– i.a. optische Platten und Magnetbänder (meist Wechselmedium)
– Sehr langsam, sehr preiswert, sehr groß
– Zugriffslücke: extrem groß
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
4
Magnetplattenspeicher: Aufbau
•
•
•
•
•
•
eine oder mehrere rotierende Platten
für jede Plattenoberfläche ein Schreib-/Lesekopf
jede Plattenoberfläche ist eingeteilt in Spuren
die Spuren sind formatiert als Sektoren fester Größe (Slots)
Sektoren sind die kleinste Schreib-/Leseeinheit auf einer Platte
Einteilung in Blöcke
– Block Adresse: (Zylindernummer, Spurnummer, Sektornummer)
Quelle: Wikimedia
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
5
Magnetplattenspeicher: Zugriffszeiten – 1(2)
• Wichtige Parameter für die Geschwindigkeit des Zugriffs
tseek - Positionierung des Zugriffsarms (seek time)
trotate - Umdrehungswartezeit (Latenzzeit)
ttransfer - Übertragungszeit von der Platte in den Hauptspeicher
• Vereinfachtes Modell für die mittlere Zugriffszeit
t = tseek + 1/2*trotate + ttransfer = tseek + 1/2*trotate + m/u mit
u
- Übertragungsrate von der Platte in den Hauptspeicher (MB/s)
m
- zu übertragende Datenmenge
• Typische Gerätewerte:
1970
2005
tseek
30 ms
12 ms
5 ms
trotate
18 ms
14 ms
4 ms
1 MB/s
4 MB/s
50 MB/s
u
h_da Prof. Dr. Uta Störl
1990
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
6
Magnetplattenspeicher: Zugriffszeiten – 2(2)
• Wie lange dauert der sequentielle Zugriff (chained IO) bzw. der wahlfreie
Zugriff (random IO) auf 1000 Blöcken a 4 KB (~ 4 MB)?
1970
sequentiell
wahlfrei
Verhältnis
2005
Verbesserung
4.039 ms
87 ms
~ 98%
43.000 ms
7.080 ms
~ 84%
1:10
1:80
Ergebnis:
• Sequentieller Zugriff ist bei großen Datenmengen n-mal schneller als
wahlfreier Zugriff auf die gleichen Daten.
• Da die Transferraten schneller wachsen als die Positionierungs- und
Umdrehungszeiten, wird das Verhältnis wahlfreier zu sequentieller Zugriff
immer schlechter!
 Muss bei der Implementierung (und der Administration) von
Datenbanksystemen unbedingt beachtet werden!
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
7
Solid State Disks (SSDs)
• Vorteile
– enthalten keine beweglichen Teile
 Performance! 
• Nachteile
– Preis (noch)
Quelle: Intel
– Speicherzellen können nur begrenzt oft beschrieben werden
(30.000 – 100.000) – schlecht für Datenbankanwendungen 
 SSDs sind mittelfristig der Sekundärspeicher der Zukunft!
 Verändern Paradigma nach dem DB-Algorithmen geschrieben
wurden
• Einsatz heute
– häufig benötigte bzw. für performance-kritische Operationen
benötigte Teile der Datenbank – z.B. Teradata (cold vs. hot data)
– als zusätzlicher Speicher in der Cache-Hierarchie (siehe nächster
Abschnitt) – z.B. Oracle Exadata
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
8
Einordnung in 5-Schichten-Architektur
Mengenorientierte Schnittstelle
Datensystem
Satzorientierte Schnittstelle
Zugriffssystem
Interne Satzschnittstelle
Speichersystem
Systempufferschnittstelle
Pufferverwaltung
Dateischnittstelle
Betriebssystem
Geräteschnittstelle
Externspeicher
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
9
Geräte- und Dateischnittstelle
• Geräteschnittstelle
– Vorgegeben durch die verwendete Hardware
– Durch die Abbildungsschicht der Speicherungsstrukturen wird eine
Dateischnittstelle erzeugt, auf der von Gerätecharakteristika wie
Speichertyp, Zylinder- und Spuranzahl, Spurlänge etc. abstrahiert
wird.
• Dateischnittstelle
– Strukturierung des Adressraumes in physische Blöcke (Abstraktion
vom Typ des Sicherungsmediums)
– Operationen zum Lesen und Schreiben von Blöcken
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
10
Betriebssystemdateien
• Betriebssystem fasst eine Menge von Blöcken zu einer BetriebssystemDatei zusammen
• Varianten der Nutzung von Betriebssystemdateien
– jede Relation oder jeder Zugriffspfad in genau einer BetriebssystemDatei
– ein oder mehrere Betriebssystem-Dateien, DBMS verwaltet
Relationen und Zugriffspfade selbst innerhalb dieser Dateien
– DBMS steuert selbst Magnetplatte an und arbeitet mit den Blöcken
in ihrer Ursprungsform (raw device)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
11
Blöcke und Seiten
• Zuordnung der physischen Blöcke zu Seiten
• meist mit festen Faktoren: 2n Blöcke einer Spur auf eine Seite
 (feste) Seitengröße zwischen 512 Bytes und 16 KB
– Typisch: 4KB
– Trend: größere Seiten, z.B. 1-2 MB bei Data Warehousing
• höhere Schichten des DBMS adressieren über Seitennummer
• im folgenden vereinfachend: 1 Block pro Seite (Seitengröße 512 Bytes)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
12
Abbildung der Datenstrukturen
• Abbildung der konzeptuellen Ebene auf interne Datenstrukturen
Konz. Ebene
Relationen
Tupel
Attributwerte
Interne Ebene
→ Log. Dateien
→ Datensätze
→ Felder
Dateisystem/Platte
→ Phys. Dateien
→ Seiten/Blöcke
→ Bytes
• Varianten der Abbildungen
– Beispiel 1: jede Relation in je einer logischen Datei, diese insgesamt
in einer einzigen physischen Datei
– Beispiel 2: Cluster-Speicherung – mehrere Relationen in einer
logischen Datei
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
13
Typische Form der Speicherung – 1(2)
Quelle: Saake/Heuer/Sattler:2005
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
14
Typische Form der Speicherung – 2(2)
Quelle: Saake/Heuer/Sattler:2005
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
15
Datenbankstruktur: Oracle
•
•
Jede Tabelle liegt in genau einem Segment (außer bei geclusterten oder partitionierten Tabellen).
Jeder Index liegt in genau einem Segment.
Quelle: Oracle Database Concepts 10g:2004
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
16
Oracle: Datendefinition
• Beispiel für Oracle-Datendefinition:
create table tabelle ( ...)
storage ( initial 10MB, next 2MB,
minextents 1, maxextents 20,
pctincrease 0 )
tablespace USER_TBLSPACE;
• (Optionale) Storage Parameter für eine Tabelle:
– initial, next: Größe des ersten bzw. der weiteren Extents (default für initial
und next: 5 Blöcke)
– minextents, maxextents: Anzahl der mind. bzw. max. zu allokierenden
Extents
– pctincrease: prozentuale Vergrößerung der nachfolgenden Extents (0:
gleich große Extents)
– tablespace: Zuordnung zum Tablespace
• Parameter können (teilweise) später mit alter table verändert werden
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
17
Datenbankstruktur: IBM DB2
Datenbank
Tablespace A
Tabelle 1
Tablespace B
Tabelle 2
Tabelle 3
Index 1
Ein Tablespace wird gleichmäßig
über alle Container mit Daten
gefüllt (Parameter Extentsize als
Schwellwert)
Container sind entweder vom Typ
• SMS (System Managed Space)
oder
• DMS (Database Managed Space)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Index 2
Container 1
Container 2
Container 3
Kapitel 2: Verwaltung des Hintergrundspeichers
18
IBM DB2: Tablespaces
• Jede DB2-Datenbank muss mindestens 3 Tablespaces
(Tabellenbereiche) enthalten
– einen Katalog-Tablespace
• default: SYSCATSPACE
– ein oder mehrere Tablespaces für persistente Nutzerdaten
• default: USERSPACE1
– einen oder mehrere temporäre System-Tablespaces
• default: TEMPSPACE1
• werden beim Erzeugen einer Datenbank automatisch angelegt, können
aber auch explizit spezifiziert werden
CREATE DB name
[ CATALOG TABLESPACE (…) ]
[ USER TABLESPACE (…) ]
[ TEMPORARY TABLESPACE (…) ]
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
19
Pufferverwaltung im Detail
Mengenorientierte Schnittstelle
Datensystem
Satzorientierte Schnittstelle
Zugriffssystem
Interne Satzschnittstelle
Speichersystem
Systempufferschnittstelle
Pufferverwaltung
Dateischnittstelle
Betriebssystem
Geräteschnittstelle
Externspeicher
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
20
Pufferverwaltung: Motivation
Größenordnung Zugriffszeiten
Beispiel: 100 Seiten lesen
•
•
Hauptspeicher: 100 x 100 ns =
10.000 ns = 0,01 ms
Plattenspeicher: 100 x 10 ms =
1.000 ms = 1 s
Zugriffslücke: 105
1-10 ns
Register
10-100 ns
Cache
100-1000 ns
Hauptspeicher
10 ms
Plattenspeicher
100 ms - 1 sec
Archivspeicher
Quelle: Kemper:2004
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
21
Pufferverwaltung: Prinzip
Datenbank auf dem Hintergrundspeicher
Hauptspeicher
DB-Puffer
B‘
C‘
A‘
D
D
Auslagerung
B
A‘
Einlagerung
...
E‘
F
G
E‘
F
• Puffer: ausgezeichneter Bereich des Hauptspeichers
• in Pufferrahmen gegliedert, jeder Pufferrahmen kann eine Seite der Platte
aufnehmen
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
22
Aufgaben der Pufferverwaltung
• Pufferverwaltung muss angeforderte Seiten im Puffer suchen
 effiziente Suchverfahren
• parallele Datenbanktransaktionen: geschickte Speicherzuteilung im Puffer
• Puffer gefüllt: adäquate Seitenersetzungsstrategien
– Speichersystem fordert Seite E an, die nicht im Puffer vorhanden ist
– Sämtliche Pufferrahmen sind belegt  vor dem Laden (Einlagern) von E
Pufferrahmen freimachen:
• nach den im folgenden diskutierten Strategien Seite A aussuchen, die
wieder ausgelagert wird
• ist Seite A seit Einlagerung in den Puffer verändert worden, so wird sie nun
auf Platte zurückgeschrieben
• ist Seite A seit Einlagerung in den Puffer nur gelesen worden, so kann sie
überschrieben werden (verdrängt)
– Einlagern von Seite E in den Pufferrahmen
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
23
Seitenersetzung: Verfahren
Frage: Welche Seite sollte ersetzt werden, wenn Platz im Puffer benötigt
wird?
• optimale Strategie (OPT): Welche Seite hat maximale Distanz zu ihrem
nächsten Gebrauch?
(nicht realisierbar, zukünftiges Referenzverhalten nicht vorhersehbar)
• Zufallsstrategie (RANDOM): jeder Seite gleiche
Wiederbenutzungswahrscheinlichkeit zuordnen
• Gute, realisierbare Verfahren: nutzen vergangenes Referenz-verhalten
auf Seiten, um Erwartungswerte für Wiederbenutzung schätzen zu
können
– besser als Zufallsstrategie
– Annäherung an optimale Strategie
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
24
Merkmale gängiger Strategien
• Alter der Seite im Puffer:
– Alter einer Seite nach Einlagerung (die globale Strategie (G))
– Alter einer Seite nach dem letztem Referenzzeitpunkt (die Strategie
des jüngsten Verhaltens (J))
– Alter einer Seite wird nicht berücksichtigt (–)
• Anzahl der Referenzen auf Seite im Puffer:
– Anzahl aller Referenzen auf eine Seite (die globale Strategie (G))
– Anzahl nur der letzten Referenzen auf eine Seite (die Strategie des
jüngsten Verhaltens (J))
– Anzahl der Referenzen wird nicht berücksichtigt (–)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
25
Klassifikation gängiger Strategien
Verfahren
Prinzip
Alter
Anzahl
FIFO
älteste Seite ersetzen
G
–
LFU
(least frequently used)
Seite mit geringster Häufigkeit
ersetzen
–
G
LRU
(least recently used)
Seite ersetzen, die am längsten
nicht referenziert wurde
J
J
CLOCK
• in der Literatur existieren eine Reihe von Weiterentwicklungen und
Optimierungen der obigen Verfahren (LRU-k, GCLOCK, DGCLOCK)
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
26
LRU: Least Recently Used
• Idee: Seite im Puffer ersetzen, die am längsten nicht mehr referenziert
wurde
• Implementierung: LRU-Stack
1
27
1
27
1
12
12
27
1
27
27
12
1
8
19
8
27
12
1
1 verdrängen
t
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
27
CLOCK
• LRU-Verhalten durch einfachere Implementierung
• Seite mit Benutzt-Bit; bei Referenzierung auf „1“ setzen
• bei Seitenfehler zyklische Suche:
– erste Seite mit „0“ verdrängen
– sonst Setzen auf „0“
• Verbesserung (GCLOCK): Benutzt-Bit durch Referenzzähler ersetzen;
Dekrementierung bei Suche
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
28
Pufferverwaltung in kommerziellen DBMS
• Oracle
– LRU (Liste mir LRU- bzw. MRU-Ende)
– Spezialbehandlung für full table scan: Einordnung der benutzen Seiten am
LRU-Ende
– mehrere Puffer möglich (KEEP/RECYCLE/LARGE)
• IBM DB2
– LRU-Strategie
– mehrere Puffer möglich (bufferpools)
• Microsoft SQL Server
– abgewandelte LRU-Strategie mit CLOCK-Algorithmus
• Generell: die meisten DBMS bieten die Möglichkeit, für Spezialfälle direkt in
die Pufferverwaltung einzugreifen, z.B.
– Ausschreiben aller modifizierten Seiten
– dauerhafte Fixierung einzelner Seiten im Puffer
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
29
Pufferverwaltung in kommerziellen DBMS
• weiterer wichtiger Einflussfaktor: Puffergröße
• Indikator: Trefferrate (buffer hit ratio)
buffer hit ratio = Anz. log. Zugriffe − Anz. phys. Zugriffe
Anz. log. Zugriffe
• Die buffer hit ratio kann in den meisten Systemen angezeigt bzw. aus
entsprechenden Statistiken berechnet werden.
 ggf. Anpassung der Puffergröße
• Ideal: Trefferrate > 90% (d.h. buffer hit ratio > 0.9) bei „typischen“ LastSzenarien
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
30
Anwendungsbeispiel
• SAP R/3
– unterstützte DBMS u.a. Oracle, IBM DB2, Microsoft SQL Server,
Informix, MaxDB
• Datenbankmodell SAP ERP
– 67.000 Tabellen mit 700.000 Spalten
– 10.000 Views
– 13.000 Indexe
• Initiale Größe einer SAP-Datenbank
– 100.000.000 Tupel
– 57 GB foot print
• Typische Pufferparameter
– buffer hit ratio: 98%
– 70% reads (davon 80% primary key) und 30% writes
Quelle: R. Munz (SAP AG): Datenmanagement für SAP Applikationen. Vortrag BTW 2007, März 2007
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
31
Self-tuning Database Systems
• Generelle Beobachtung in der IT i.a. und für DBS im Besonderen:
– sehr große und komplexe Systeme
– riesige Datenbestände
– Heterogenität der Systeme
 Wartung und Administration sehr aufwändig und teuer
 Vision: Autonomic Computing
[..] Computer systems that can regulate themselves much in the same way as our
autonomic nervous system regulates and protects our bodies [..]
Paul Horn (Vice President IBM Research): Autonomic Computing Manifesto, Harvard, March 2001
 self-monitoring / self-tuning / self-protecting / self-healing .. self-*
• Vision für DBS: Self-tuning Database Systems
– viele wissenschaftliche Arbeiten (auch aus den Research Labs von IBM und
Microsoft) im letzten Jahrzehnt
– inzwischen erste(!) Ansätze in einigen(!) Produkten
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
32
Self-tuning Database Systems
Aufgaben beim Betrieb eines Datenbanksystems
• Anlegen der Datenbank
– Physisches Design
– Indexe anlegen
• Aufrechterhaltung des laufenden Betriebs
– Storage Management
– Backup und Recovery
– Reaktion auf Fehler / Probleme
– …
• Performance-Optimierung
– Diagnose von Performance-Problemen
 Index Reorganisation
 Optimierung der Buffer Hit Ratio
 Optimierung von Anfragen
– …
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Ansatzpunkte für
Self-tuning?
Kapitel 2: Verwaltung des Hintergrundspeichers
33
Self-tuning Database Systems
Automatisiertes Memory Management
• Motivation: DBMS verwalten eigenen Pufferbereich (der selbst wieder
aus einer Vielzahl von Puffern besteht)
• Beispiel: Puffer-Architektur von DB2:
• Herausforderungen
– Begrenzte Ressourcen
– Dynamische Laständerungen (z.B. Batch-Verarbeitung nachts)
Quelle: http://www.ibm.com/developerworks/data/library/techarticle/dm-0709saraswatipura/
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
34
Self-tuning Database Systems
Automatisiertes Memory Management
• DB2 9: Self tuning memory management (STMM)
• Ähnliche Ansätze im
MS SQL Server
Quelle: http://www.ibm.com/developerworks/data/library/techarticle/dm-0709saraswatipura/
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
35
Zusammenfassung
• Speicherhierarchie und Zugriffslücke
• Hintergrundspeicher: Blockmodell
• Pufferverwaltung: Seitenersetzungsstrategien
• Puffergröße: wichtiger Faktor für Performance
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
36
Architektur von Datenbanksystemen
 Architektur von Datenbanksystemen
 Verwaltung des Hintergrundspeichers
• Dateiorganisation und Zugriffsstrukturen
• Basisalgorithmen für Datenbank-Operationen
• Anfrageoptimierung
• Transaktionsverwaltung und Recovery
• Verteilte Datenbankarchitekturen
h_da Prof. Dr. Uta Störl
Architektur von DBMS WS 2015/16
Kapitel 2: Verwaltung des Hintergrundspeichers
37