WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #2 Physische Datenorganisation.

WS 2004/2005Datenbanken II - 5W

Mi 17:00 – 18:30G 3.18

Vorlesung #2

Physische Datenorganisation

© Bojan Milijaš, 20.10.2004 Vorlesung #2 - Physische Datenorganization 2


Mi 17:00 – 18:30G 3.18

„Fahrplan“

Einführung und Motivation Trennung der logischen und der physischen Ebene einer

Datenbank Speichermedien (Platten, RAID usw.), Speicherhierarchien

(Cache, Hauptspeicher, Hintergrundsspeicher usw.) Abbildung von Relationen auf den Hintergrundsspeicher Indexstrukturen (Algorithmen und Datenstrukturen!)

ISAM B-Bäume

Hashing Clustering (Ballung) Unterstützung eines Anwendungsverhaltens Physische Datenorganisation in SQL Fazit und Ausblick Vorlesung #3



Mi 17:00 – 18:30G 3.18

Einführung und Motivation

Die Benutzung und somit die Akzeptanz einer Datenbank wird maßgeblich durch die Antwortzeiten des Systems bestimmt.

Selbst eine sehr gut modellierte Datenbank(anwendung) wird von Benutzern nicht akzeptiert, wenn sie langsam ist.

Eine effiziente physische Organisation der Daten und der Zugriffe ist die Voraussetzung für akzeptable Datenbanken.

Physische Organisation der Daten muss unabhängig von logischen Schema-Veränderungen bleiben, um System-Änderungen und vor allem System-Wachstum effizient unterstützen können. Man hat die Wahl zwischen mehreren physischen Entwürfen und kann das Optimale wählen.

Die heute marktbeherrschenden (objekt)relationalen Datenbanken haben sich auch dank effizienter physischen Implementierung und der strikten Trennung zwischen der logischen und der physischen Ebene durchgesetzt.



Mi 17:00 – 18:30G 3.18

Wiederholung: DBMS 3 -Abstraktionsebenen

...Externes Schema - Sicht 1

Externes Schema - Sicht 2

Externes Schema - Sicht n

Konzeptionelles Schema

Physische Speicherung – internes Schema

Logi

sche

Ebe

neP

hysi

sche

E

bene



Mi 17:00 – 18:30G 3.18

3 Abstraktionsebenen

Ebene 1: Sichten – Datenbank VIEWs Ebene 2: Relationen – Datenbank Tabellen

mit ihren logischen Attributen Ebene 3: Datenstrukturen bzw.

Speicherstrukturen – Datenbank Tabellen mit ihren physischen Attributen



Mi 17:00 – 18:30G 3.18

Beispiel: logische und physische Datenunabhängigkeit

Internet-BesucherStudenten

ProfVerlesung

Dozentenlesen Kurse

CREATE VIEW ProfVorlesungCREATE VIEW ProfVorlesung AS SELECT Name, TitelAS SELECT Name, Titel FROM DozentenFROM Dozenten NATURAL JOIN lesenNATURAL JOIN lesen NATURAL JOIN Kurse;NATURAL JOIN Kurse;

CREATE VIEW ProfVorlesungCREATE VIEW ProfVorlesung

ASAS

SELECT Name, TitelSELECT Name, Titel

FROM Professoren, VorlesungenFROM Professoren, Vorlesungen

WHERE PersNr = gelesenVon;WHERE PersNr = gelesenVon;

Professoren Vorlesungen

IOT lesenPT lesen CT lesen,Kurse



Mi 17:00 – 18:30G 3.18

Erläuterung zum Beispiel

Man hat mehrere Möglichkeiten, eine Relation („logische“ Tabelle mit ihren Attributen) als eine „physische“ oder DBMS-Tabelle zu implementieren. Die Abkürzungen bedeuten (keine Standard-Abkürzungen) IOT – Index Organized Table HT – Heap Table CT – Clustered Tables PT – Partitioned Tables

SQL Code Beispiele am Ende der Vorlesung!



Mi 17:00 – 18:30G 3.18

Speichermedien und Speicherhierarchien

Es gibt eine Zugriffslücke 105 zwischen dem Haupt- und dem Hintergrundsspeicher, die vor allem an mechanische Vorgänge innerhalb eines Plattenstapels zurückzuführen ist

RAID Systeme sind fehlertoleranter und performanter als einzelne Platten

... weiter Folien Kemper 7.2 – 7.22



Mi 17:00 – 18:30G 3.18

Puffer-Verwaltung

Hauptspeicher ist nicht nur viel schneller sondern auch viel kleiner als Hintergrundsspeicher nicht genug Platz für alle Seiten

Ständiges Ein-/ und Auslagern der Seiten mit dem Ziel möglichst viele aktuelle oder in der nächsten Zukunft gebrauchte Seiten im Hauptspeicher bereit zu halten

... Kemper 7.24 – 7.25



Mi 17:00 – 18:30G 3.18

Abbildung von Relationen auf den Sekundarspeicher Die Tupel einer Relation (Zeilen, Rows)

werden so abgespeichert, dass sie nicht über die Grenzen einer Seite hinausgehen.

Jeder Tupel enthält eine Tupel-ID, jede Seite eine interne Datensatztabelle

Beim Wachstum der Tupel muss reorganisiert d.h auf andere Seiten umgezogen werden

... Kemper 7.26 – 7.29



Mi 17:00 – 18:30G 3.18

Indexstrukturen

ISAM – Index Sequential Access Method Vom Prinzip her wie ein Daumenindex eines

Wörterbuchs mit Indexseiten und Datenseiten Schlechtes Verhalten bei UPDATE Operationen Hinzufügen einer weiteren Indirektion (eines

weiteren Zeigers) B-Bäume



Mi 17:00 – 18:30G 3.18

B-Bäume

Binärbäume wurden als Suchstruktur für den Hauptspeicher konzipiert

Für den Hintergrundspeicher nimmt man balancierte Mehrwegbäume, deren Knotengrößen auf die Seitenkapazitäten angepasst sind

Balancierung bedeutet, dass jedes Blatt von der Wurzel gleich entfernt ist, d.h. die Suche logk(n) dauert k ist der Verzweigungsgrad n – Anzahl der Datensätze

... Kemper 7.30 – 7.113



Mi 17:00 – 18:30G 3.18

B+-Bäume Die Höhe des B-Baums ist direkt abhängig von der

Satzgröße Je höher der Verzweigungsgrad des Baumes ist,

umso „flacher“ ist der Baum, umso effizienter ist der Zugriff

B+- Baum = die Daten werden nur in den Blättern abgespeichert, der Rest des Baumes ist „hohl“ und stellt lediglich eine sehr effiziente Road Map zum Auffinden der gewünschten Datensätze

Die Reorganisation ist durch die Verwendung der Referenzschlüssel im Baum viel effizienter, da sich die Datensätze nur in Blättern verändern

... Kemper 113 - 114



Mi 17:00 – 18:30G 3.18

Präfix B+-Bäume Verbesserungsmöglichkeit: statt gesamten

Schlüsseln nur Teile von Schlüsseln, d.h. Präfixe zu speichern

Gut bei Nachnamen, z.B. nur erste Buchstabe statt dem gesamten Namen

Schlecht bei Werten mit gleichen Präfixen wie „Systemprogramm“, „Systemprogrammierung“, „Systemprogrammierer“ usw.

... Kemper 115



Mi 17:00 – 18:30G 3.18

Hashing

Das Ziel: ein Datum mit einem bis zwei Datenzugriffen zu finden (Bäume logk(n) )

Hashing ist die Technik die in Compilerbau, Betriebsystemen etc. oft angewendet wird

Zugriff zwischen O(1) und O(n), in der Praxis aber meistens sehr gute Ergebnisse

Beschreibung: mit Hilfe einer Hashfunktion wird eine Schlüsselmenge S wird auf eine Hashtabelle B (Buckets) abgebildet h: S B wobei |S| >> |B|



Mi 17:00 – 18:30G 3.18

Hashing (2)

Wegen |S| >> |B| ist h nicht injektiv, d.h. es ist in der Hashtabelle nicht genug Platz für alle Schlüssel aus S

Als Hashfunktion wählt man meistens das Divisonsrestverfahren (Modulo-Funktion) h(x) := x mod p p soll wegen der besseren Streuung eine Primzahl sein

Es kann auftreten h(s1) = h(s2) = b1

Man braucht dann eine Kollisionsroutine Statisches Hashing – Chaining der Sätze gleichem h(s) Erweiterbares Hashing – dynamisches Wachsen der Hash-

Tabelle ... Kemper 125 - 139



Mi 17:00 – 18:30G 3.18

Mehrdimensionale Indexstrukturen

für häufige Anfragen mit Selektionsprädikaten über mehrere gleiche Attribute, z.B. wenn sehr oft Alter und Gehalt gemeinsam abgefragt werden

kann sehr schön mit algorithmischer Geometrie und Bildverarbeitung verknüpft werden

... Kemper 150 - 162



Mi 17:00 – 18:30G 3.18

Clustering

Ballung von Datensätzen Oft selektierte Datensätze sollten idealerweise

physikalisch auf einer Seite abgespeichert werden Die Tupeln einer Relation werden sortiert nach den

Werten eines Attributs physikalisch abgelegt Problem: es wird oft über mehrere Attribute abgefragt Lösung: Zusammenspiel zwischen mehreren Indexstrukturen und Clustering

Weitere Möglichkeit für Clustering: Materialisierung von Beziehung (Join Clusters)

Bsp: Professoren werden verzahnt mit Vorlesungen abgespeichert (verzahnte Objektballung)

... Kemper 163 - 166



Mi 17:00 – 18:30G 3.18

Clustering und Index-Pflege

Bei Verwendung mehrer Indexstrukturen auf einer Tabelle muss eine zusätzliche Indirektion pro Index eingeführt und zusätzlich gepflegt werden

Die INSERTs und UPDATEs führen in der Regel zur aufwändigen Index-Reorganisationen (zusätzliche Zeiger bei Indirektion, B-Baum Änderungsoperationen wie Spalten und Zusammenfassen der Knoten)

In der Praxis werden Indizies aus Effizienzgründen oft vor der Durchführung der Massen-UPDATEs und INSERTS gelöscht und danach neu erstellt. Es bestehen aber auch die Möglichkeiten der Online-Reorganisation und Aktualisierung



Mi 17:00 – 18:30G 3.18

Unterstützung des Anwenderverhaltens Für unterschiedliche Arten von Abfragen und/oder

Veränderungsoperationen eignen sich unterschiedliche Zugriffstechniken unterschiedlich gut

Beispiel: Exact Match Query vs. Range Query--exactSELECT Name FROM ProfessorenWHERE PersNr = 4711;-- rangeSELECT NameFROM ProfessorenWHERE Gehalt BETWEEN 40000 AND 50000;

Besser mit Hashing!

Besser mit B+Baum!



Mi 17:00 – 18:30G 3.18

Unterstützung des Anwenderverhaltens (2) Es gibt noch weitere Möglichkeiten, die

Zugriffe bzw. Speicherung der Daten effizienter zu gestalten

BITMAP und BITMAP JOIN Index nur für lesende Zugriffe wird bei Data Warehousing vorgestellt

Partitionierung Tabelle wird in unterschiedliche Partionen

aufgeteilt, die unterschiedlich voneinander physikalisch verwaltet werden können

wird bei verteilten Datenbanken vorgestellt



Mi 17:00 – 18:30G 3.18

Physische Dateiorganisation in SQL So gut wie keine Standardisierung

CREATE INDEX SemesterInd ON Studenten(Semester);

DROP IINDEX SemesterInd;

Zu beachten sind die Eigenschaften des jeweiligen DBMS, so legt z.B. Oracle für jedes Primärschlüsselattribut automatische einen Index an



Mi 17:00 – 18:30G 3.18

Physische Dateiorganisation in ORACLE(2 von ca. 60 Klauseln)

CREATE TABLE { segment_attributes_clause [ data_segment_compression ]

| ORGANIZATION { HEAP [ segment_attributes_clause ]

[ data_segment_compression ] | INDEX [ segment_attributes_clause ]

index_org_table_clause | EXTERNAL external_table_clause } | CLUSTER cluster ( column[,

column ]... ) } physical attributes clause:[{ PCTFREE integer | PCTUSED integer | INITRANS integer | MAXTRANS integer | storage_clause } [ PCTFREE integer | PCTUSED integer | INITRANS integer | MAXTRANS integer | storage_clause ]... ]



Mi 17:00 – 18:30G 3.18

Fazit Vorlesung #2

Bedeutung der strikten Trennung der logischen und physischen Ebene einer Datenbank und deren positive Auswirkung auf die Performance und Flexibilität der Datenbank

Speichermedien (RAM, Platte, RAID, Bänder) Speicherhierarchien, Zugriffslücke, Notwendigkeit der

Pufferverwaltung Zugriffstechniken: B+Bäume, Hashing, Clustering Unterstützung des Anwenderverhaltens (so gut wie keine) SQL Standards



Mi 17:00 – 18:30G 3.18

Ausblick Vorlesung #3

Anfragebearbeitung Logische Optimierung

Äquivalenzen und „Rechenregeln“ in der relationalen Algebra

Anwendung der Transformationsregeln für Optimierungszwecke

Physische Optimierung Selektion, Join-Operatoren Gruppierung, Duplikateliminierung, Projektion,

Vereinigung, Sortierung Kostenmodelle Tuning


Mi 17:00 – 18:30G 3.18

Vorlesung #2

Ende

WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #2 Physische Datenorganisation.

Documents

Transcript of WS 2004/2005 Datenbanken II - 5W Mi 17:00 – 18:30 G 3.18 Vorlesung #2 Physische Datenorganisation.