KAPITEL 2 VERWALTUNG DES HINTERGRUNDSPEICHERS

Transkript

1 KAPITEL 2 VERWALTUNG DES HINTERGRUNDSPEICHERS h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 1

2 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

3 Einordnung in 5-Schichten-Architektur Mengenorientierte Schnittstelle Datensystem Satzorientierte Schnittstelle Zugriffssystem Interne Satzschnittstelle Speichersystem Pufferverwaltung Systempufferschnittstelle Dateischnittstelle Betriebssystem Geräteschnittstelle Externspeicher h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 3

4 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 10 5 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

5 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

6 Magnetplattenspeicher: Zugriffszeiten 1(2) Wichtige Parameter für die Geschwindigkeit des Zugriffs t seek t rotate - Positionierung des Zugriffsarms (seek time) - Umdrehungswartezeit (Latenzzeit) t transfer - Übertragungszeit von der Platte in den Hauptspeicher Vereinfachtes Modell für die mittlere Zugriffszeit t = t seek + 1/2*t rotate + t transfer = t seek + 1/2*t rotate + m/u mit u - Übertragungsrate von der Platte in den Hauptspeicher (MB/s) m - zu übertragende Datenmenge Typische Gerätewerte: t seek 30 ms 12 ms 5 ms t rotate 18 ms 14 ms 4 ms u 1 MB/s 4 MB/s 50 MB/s h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 6

7 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)? Verbesserung sequentiell ms 87 ms ~ 98% wahlfrei ms ms ~ 84% Verhältnis 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

8 Solid State Disks (SSDs) Vorteile enthalten keine beweglichen Teile Performance! Nachteile Preis (noch) Speicherzellen können nur begrenzt oft beschrieben werden ( ) 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 Quelle: Intel h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 8

9 Einordnung in 5-Schichten-Architektur Mengenorientierte Schnittstelle Datensystem Satzorientierte Schnittstelle Zugriffssystem Interne Satzschnittstelle Speichersystem Pufferverwaltung Systempufferschnittstelle Dateischnittstelle Betriebssystem Geräteschnittstelle Externspeicher h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 9

10 Geräteschnittstelle Geräte- und Dateischnittstelle 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

11 Betriebssystemdateien Betriebssystem fasst eine Menge von Blöcken zu einer Betriebssystem- Datei zusammen Varianten der Nutzung von Betriebssystemdateien jede Relation oder jeder Zugriffspfad in genau einer Betriebssystem- Datei 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

12 Blöcke und Seiten Zuordnung der physischen Blöcke zu Seiten meist mit festen Faktoren: 2 n 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

13 Abbildung der Datenstrukturen Abbildung der konzeptuellen Ebene auf interne Datenstrukturen Konz. Ebene Interne Ebene Dateisystem/Platte Relationen Log. Dateien Phys. Dateien Tupel Datensätze Seiten/Blöcke Attributwerte Felder 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

14 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

15 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

16 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

17 Beispiel für Oracle-Datendefinition: 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

18 Datenbankstruktur: IBM DB2 Datenbank Tablespace A Tablespace B Tabelle 1 Tabelle 2 Tabelle 3 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) Index 1 Index 2 Container 1 Container 2 Container 3 h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 18

19 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

20 Pufferverwaltung im Detail Mengenorientierte Schnittstelle Datensystem Satzorientierte Schnittstelle Zugriffssystem Interne Satzschnittstelle Speichersystem Pufferverwaltung Systempufferschnittstelle Dateischnittstelle Betriebssystem Externspeicher Geräteschnittstelle h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 20

21 Pufferverwaltung: Motivation Größenordnung Zugriffszeiten Beispiel: 100 Seiten lesen Hauptspeicher: 100 x 100 ns = ns = 0,01 ms Plattenspeicher: 100 x 10 ms = ms = 1 s Zugriffslücke: ns Register ns Cache 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

22 Pufferverwaltung: Prinzip Datenbank auf dem Hintergrundspeicher Hauptspeicher DB-Puffer B A C D Einlagerung D A B E F Auslagerung 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

23 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

24 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

25 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

26 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

27 LRU: Least Recently Used Idee: Seite im Puffer ersetzen, die am längsten nicht mehr referenziert wurde Implementierung: LRU-Stack verdrängen t h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 27

28 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

29 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

30 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 Last- Szenarien h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 30

31 Anwendungsbeispiel SAP R/3 unterstützte DBMS u.a. Oracle, IBM DB2, Microsoft SQL Server, Informix, MaxDB Datenbankmodell SAP ERP Tabellen mit Spalten Views Indexe Initiale Größe einer SAP-Datenbank 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

32 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

33 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 Ansatzpunkte für Self-tuning? h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 33

34 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: h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 34

35 Self-tuning Database Systems Automatisiertes Memory Management DB2 9: Self tuning memory management (STMM) Ähnliche Ansätze im MS SQL Server Quelle: h_da Prof. Dr. Uta Störl Architektur von DBMS WS 2015/16 Kapitel 2: Verwaltung des Hintergrundspeichers 35

36 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

37 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