Kapitel 9 - Datenorganisation(kurz)

Kapitel 9
Dr. Brigitte Mathiak
Physische Datenorganisation
(ganz kurz)
Lernziele

• Motivation für schnellere Zugriffe
• Anlegen eines Index
Datenbanken, SS 12
Kapitel 9: Datenorganisation
2
Bottleneck Festplatte

Selbst sehr schnelle Festplatten haben typischerweise
Zugriffszeiten im ms-Bereich
Da die Prozessoren im Vergleich sehr viel schneller sind, lohnt es
sich typischerweise selbst vergleichsweise komplexe
Rechenoperationen durchzuführen um dadurch
Festplattenzugriffe zu sparen.
Weiterhin können Festplatten sehr gut Daten am Stück lesen.
Daher ist es die Standardoperation gleich einen ganzen Block
(genannt Seite) an Daten zu lesen, unabhängig, ob auch
tatsächlich alle Daten benötigt werden.
Caching und vorrausschauendes Vorladen von Daten ist dabei ein
aktives Forschungsgebiet.
Was wir hier in Vorlesung betrachten sind Datenstrukturen, die
helfen die Daten besonders schnell wieder zu finden.
Datenbanken, SS 12
Kapitel 9: Datenorganisation
3
Beispiel für einen binären Suchbaum
London, Paris, Madrid, Kopenhagen, Lissabon,
Zürich, Frankfurt, Wien, Amsterdam, Florenz
London
Kopenhagen
Frankfurt
Lissabon
Amsterdam
Paris
Madrid
Zürich
Wien
Florenz
Datenbanken, SS 12
Kapitel 9: Datenorganisation
4
Datenbanken, SS 12
Kapitel 9: Datenorganisation
5
B+-Baum
Referenzschlüssel
Suchschlüssel
Datenbanken, SS 12
Kapitel 9: Datenorganisation
6
Datenbanken, SS 12
Kapitel 9: Datenorganisation
7
Hashing
Datenbanken, SS 12
Kapitel 9: Datenorganisation
8
Hashing
Bäume: logk(n) viele Seitenzugriffe ..
Hashing:
 Fast eindeutige Zuordnung von Datum zu Bucket (Behälter)
 h: S → B
- S Schlüssel
(in diesem Kontext hier: nicht notwendigerweise Schlüssel im Sinne eines
logischen Schema)
- B: Nummerierung von n Behältern
- Zugriff innerhalb von 1-2 Schritten
- Charakteristiken der gesuchten Hash-Funktion
• Fester vs flexibler Wertebereich
• Gute Verteilung über den Wertebereich, auch bei schlechter Verteilung
der Datencharakteristiken über den Eingabebereich
Datenbanken, SS 12
Kapitel 9: Datenorganisation
9
Hashing
Abbildung h: D  [0..m-1], genannt Hash-Funktion,
von Schlüsseln x1, ..., xn aus Domain D (z.B. Strings) auf Positionen
h(x1), ..., h(xn) in Array a[0..m-1], genannt Hash-Tabelle (mit n < m)
 Speicherung von Schlüssel xi in a[h(xi)]
Anforderungen an h:
 sehr effiziente Berechenbarkeit
 zufällige „Streuung“ (Randomisierung) von x1, ..., xn auf [0..m-1]
 Urbilder von j1, j2  [0..m-1] annähernd gleich groß für alle j1, j2 und alle möglichen
x1, ..., xn
 für geordnete Schlüssel x1 < x2 < ... < xn sollte die Ordnung von h(x1), h(x2), ...,
h(xn) eine zufällige Permutation sein
Beispiele für brauchbare Hash-Funktionen




h(x) = (ax + b) mod m für Integers x mit Konstanten a, b
h(x) = (mittlere k Ziffern von x2) mod m für k-stellige Integers x
h(x) = (ord(c1)+...+ord(ck)) mod m für Strings c1c2...ck   k
mit ord: S  [1..|  |]
Datenbanken, SS 12
Kapitel 9: Datenorganisation
10
Statisches Hashing
Datenbanken, SS 12
Kapitel 9: Datenorganisation
11
Datenbanken für Mathematiker, WS 11/12
Kapitel 10: Datenorganisation
12
Datenbanken für Mathematiker, WS 11/12
Kapitel 10: Datenorganisation
13

0
0
32
Datenbanken für Mathematiker, WS 11/12
13
Bucket
18
Bucket
Bucket
1
Bucket
0
6
7
1
0
1
0
1
Bucket
1
1
0
0
4
1
48
Bucket
Kapitel 10: Datenorganisation
14

0
1
110
1
1
0
0
001
1
0
1
0
1
0
1
0
Präfix
001
4
Bucket
6
7
Bucket
32
Datenbanken für Mathematiker, WS 11/12
13
Bucket
18
Bucket
Bucket
48
Präfix
1
Bucket
Kapitel 10: Datenorganisation
15
SQL: Create Index
Grobsyntax:
CREATE [UNIQUE] INDEX Indexname
ON Tabellenname (Attribut1, Attribut2 ..)
DROP INDEX Indexname
Primary Key hat immer einen Index (muss nicht explizit indexiert werden)
.. Oracle: default-Indextyp ist ein B+ Baum
Beispiele:
CREATE INDEX Studenten_idx1 ON Studenten(Semester)
DROP INDEX Studenten_idx1
Datenbanken, SS 12
Kapitel 9: Datenorganisation
16
Standardoption sind B+-Bäume – Warum?
B+-Bäume sind stärker an die Seitenstruktur der Daten angepasst,
der Grad k ist typischerweise sehr hoch, meist hat jeder Knoten
eine Seite, also z.B. 64 MB. Logkn mit hohem k ergibt also fast
immer 1 oder 2. Da die B+-Bäume sehr dicht sind, können die
Nicht-Blattknoten oft komplett im Cache gehalten werden und
benötigen dann gar keine Festplattenzugriffe.
Ein Hash, selbst ein erweiterter Hash benötigt viel Redundanz, es
können also pro Seite weniger Daten referenziert werden. Da
aber der benötigte Speicher direkt an der Performance hängt
werden in der Praxis oft mehr Seitenzugriffe benötigt.
Überlegen ist der Hash in Situationen, wo sowieso die
kompletten Daten (mit Index) im Cache sind, etwa sehr viele
Anfragen auf eine kleine Menge von Daten kommen oder wenn
die Daten auf mehreren Rechnern verteilt sind.
Datenbanken, SS 12
Kapitel 9: Datenorganisation
17