diff --git a/Assets/DBimpl-DBL-to-arc.png b/Assets/DBimpl-DBL-to-arc.png new file mode 100644 index 0000000..be63a1f Binary files /dev/null and b/Assets/DBimpl-DBL-to-arc.png differ diff --git a/Assets/DBimpl-Seitenersetzung-2.png b/Assets/DBimpl-Seitenersetzung-2.png new file mode 100644 index 0000000..40276aa Binary files /dev/null and b/Assets/DBimpl-Seitenersetzung-2.png differ diff --git a/Assets/DBimpl-Seitenersetzung.png b/Assets/DBimpl-Seitenersetzung.png new file mode 100644 index 0000000..13773c4 Binary files /dev/null and b/Assets/DBimpl-Seitenersetzung.png differ diff --git a/Assets/DBimpl-arc-bsp-1.png b/Assets/DBimpl-arc-bsp-1.png new file mode 100644 index 0000000..b68fb34 Binary files /dev/null and b/Assets/DBimpl-arc-bsp-1.png differ diff --git a/Assets/DBimpl-arc-bsp-2.png b/Assets/DBimpl-arc-bsp-2.png new file mode 100644 index 0000000..0e94cb6 Binary files /dev/null and b/Assets/DBimpl-arc-bsp-2.png differ diff --git a/Assets/DBimpl-arc-bsp-3.png b/Assets/DBimpl-arc-bsp-3.png new file mode 100644 index 0000000..e7f4451 Binary files /dev/null and b/Assets/DBimpl-arc-bsp-3.png differ diff --git a/Assets/DBimpl-arc-bsp-4.png b/Assets/DBimpl-arc-bsp-4.png new file mode 100644 index 0000000..0339078 Binary files /dev/null and b/Assets/DBimpl-arc-bsp-4.png differ diff --git a/Assets/DBimpl-arc-bsp-5.png b/Assets/DBimpl-arc-bsp-5.png new file mode 100644 index 0000000..cab4fec Binary files /dev/null and b/Assets/DBimpl-arc-bsp-5.png differ diff --git a/Assets/DBimpl-beispiel-seitenwechsel.png b/Assets/DBimpl-beispiel-seitenwechsel.png new file mode 100644 index 0000000..df96acc Binary files /dev/null and b/Assets/DBimpl-beispiel-seitenwechsel.png differ diff --git a/Assets/DBimpl-indexsequentiell-2.png b/Assets/DBimpl-indexsequentiell-2.png new file mode 100644 index 0000000..3978824 Binary files /dev/null and b/Assets/DBimpl-indexsequentiell-2.png differ diff --git a/Assets/DBimpl-indexsequentiell-3.png b/Assets/DBimpl-indexsequentiell-3.png new file mode 100644 index 0000000..763f674 Binary files /dev/null and b/Assets/DBimpl-indexsequentiell-3.png differ diff --git a/Assets/DBimpl-indexsequentiell.png b/Assets/DBimpl-indexsequentiell.png new file mode 100644 index 0000000..2273be9 Binary files /dev/null and b/Assets/DBimpl-indexsequentiell.png differ diff --git a/Assets/DBimpl-lock-contention.png b/Assets/DBimpl-lock-contention.png new file mode 100644 index 0000000..55fc2a7 Binary files /dev/null and b/Assets/DBimpl-lock-contention.png differ diff --git a/Assets/DBimpl-seitenersetzung-clock.png b/Assets/DBimpl-seitenersetzung-clock.png new file mode 100644 index 0000000..a40fb54 Binary files /dev/null and b/Assets/DBimpl-seitenersetzung-clock.png differ diff --git a/Assets/DBimpl-seitenersetzung-lru.png b/Assets/DBimpl-seitenersetzung-lru.png new file mode 100644 index 0000000..c21839b Binary files /dev/null and b/Assets/DBimpl-seitenersetzung-lru.png differ diff --git a/Assets/DBimpl-seitenwechsel-strategie.png b/Assets/DBimpl-seitenwechsel-strategie.png new file mode 100644 index 0000000..450684d Binary files /dev/null and b/Assets/DBimpl-seitenwechsel-strategie.png differ diff --git a/Assets/DBimpl-speichertechniken-klassifikation.png b/Assets/DBimpl-speichertechniken-klassifikation.png new file mode 100644 index 0000000..d48b526 Binary files /dev/null and b/Assets/DBimpl-speichertechniken-klassifikation.png differ diff --git a/Assets/DBimpl-statische-verfahren.png b/Assets/DBimpl-statische-verfahren.png new file mode 100644 index 0000000..9358cbd Binary files /dev/null and b/Assets/DBimpl-statische-verfahren.png differ diff --git a/Assets/DBimpl-zugriff-klassifikation.png b/Assets/DBimpl-zugriff-klassifikation.png new file mode 100644 index 0000000..ff89745 Binary files /dev/null and b/Assets/DBimpl-zugriff-klassifikation.png differ diff --git a/Assets/Dbimpl-cluster-vs-nicht-cluster.png b/Assets/Dbimpl-cluster-vs-nicht-cluster.png new file mode 100644 index 0000000..54f3626 Binary files /dev/null and b/Assets/Dbimpl-cluster-vs-nicht-cluster.png differ diff --git a/Assets/Dbimpl-nichtsequentieller-index.png b/Assets/Dbimpl-nichtsequentieller-index.png new file mode 100644 index 0000000..c796444 Binary files /dev/null and b/Assets/Dbimpl-nichtsequentieller-index.png differ diff --git a/Datenbank Implementierungstechniken.md b/Datenbank Implementierungstechniken.md index e008f09..5aec83c 100644 --- a/Datenbank Implementierungstechniken.md +++ b/Datenbank Implementierungstechniken.md @@ -608,3 +608,376 @@ Suchen einer Seite - _unsortierte und sortierte Tabelle_ : alle Seiten im Puffer vermerkt - _verkettete Liste_ : schnelleres sortiertes Einfügen möglich - _Hashtabelle_ : bei geschickt gewählter Hashfunktion günstigster Such- und Änderungsaufwand + + +Speicherzuteilung im Puffer +- bei mehreren parallel anstehenden Transaktionen + - Lokale Strategien: Jeder Transaktion bestimmte disjunkte Pufferteile verfügbar machen (Größe statisch vor Ablauf der Transaktionen oder dynamisch zur Programmlaufzeit entscheiden) + - Globale Strategien: Zugriffsverhalten aller Transaktionen insgesamt bestimmt Speicherzuteilung (gemeinsam von mehreren Transaktionen referenzierte Seiten können so besser berücksichtigt werden) + - Seitentypbezogene Strategien: Partition des Puffers: Pufferrahmen für Datenseiten, Zugriffspfadseiten, Data-Dictionary-Seiten, usw. - eigene Ersetzungstrategien für die jeweiligen Teile möglich + +## Seitenersetzungsstrategien +- Speichersystem fordert Seite $E_2$ an, die nicht im Puffer vorhanden ist +- Sämtliche Pufferrahmen sind belegt +- vor dem Laden von _E_ 2 Pufferrahmen freimachen +- nach den unten beschriebenen Strategien Seite aussuchen +- Ist Seite in der Zwischenzeit im Puffer verändert worden, so wird sie nun auf Platte zurückgeschrieben +- Ist Seite seit Einlagerung in den Puffer nur gelesen worden, so kann sie überschrieben werden (verdrängt) + +![](Assets/DBimpl-Seitenersetzung.png) + +Seitenersetzung in DBMS +- Fixieren von Seiten (Pin oder Fix): + - Fixieren von Seiten im Puffer verhindert das Verdrängen + - speziell für Seiten, die in Kürze wieder benötigt werden +- Freigeben von Seiten (Unpin oder Unfix): + - Freigeben zum Verdrängen + - speziell für Seiten, die nicht mehr benötigt werden +- Zurückschreiben einer Seite: + - Auslösen des Zurückschreibens für geänderte Seiten bei Transaktionsende + +Seitenersetzung: Verfahren +- grundsätzliches Vorgehen beim Laden einer Seite: + - Demand-paging-Verfahren: genau eine Seite im Puffer durch angeforderte Seite ersetzen + - Prepaging-Verfahren: neben der angeforderten Seite auch weitere Seiten in den Puffer einlesen, die eventuell in der Zukunft benötigt werden (z.B. bei BLOBs sinnvoll) +- Ersetzen einer Seite im Puffer: + - optimale Strategie: Welche Seite hat maximale Distanz zu ihrem nächsten Gebrauch? (nicht realisierbar, zukünftiges Referenzverhalten nicht vorhersehbar) -> Realisierbare Verfahren besitzen keine Kenntnisse über das zukünftige Referenzverhalten + - Zufallsstrategie: jeder Seite gleiche Wiederbenutzungswahrscheinlichkeit zuordnen + +![](Assets/DBimpl-Seitenersetzung-2.png) + +Fehlseitenrate +$$F=1-p(\frac{1-F_{kalt}}{p_{DB}}) * 100%$$ +- $p$: Puffergröße +- $p_{DB}$: Puffergröße, die gesamte Datenbank umfasst +- $F_{kalt}$: Fehlseitenrate beim Kaltstart (d.h. leerer Puffer) -> Verhältnis von Anzahl der in den Puffer geladenen Seiten zur Anzahl der Referenzierungen + +- Gute, realisierbare Verfahren sollen vergangenes Referenzverhalten auf Seiten nutzen, um Erwartungswerte für Wiederbenutzung schätzen zu können + - besser als Zufallsstrategie + - Annäherung an optimale Strategie + + +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 (-) + + +Gängige Strategien +![](Assets/DBimpl-seitenwechsel-strategie.png) + +Klassifikation gängiger Strategien +| Verfahren | Prinzip | Alter | Anzahl | +| --- | --- | --- | +FIFO | älteste Seite ersetzt | G |- +LFU (least fre-quently used) | Seite mit geringster Häufigkeit ersetzen | - | G +LRU (least recently used) | Seite ersetzen, die am längsten nicht referenziert wurde (System R) | J | J +DGCLOCK (dyn. generalized clock) | Protokollierung der Ersetzungshäufigkeiten wichtiger Seiten | G | JG +LRD (least reference density) | Ersetzung der Seite mit geringster Referenzdichte | JG | G + +Beispiel +- Folge von Seitenanforderungen #1, #2 ... +- Puffer der Größe 6 + ![](Assets/DBimpl-beispiel-seitenwechsel.png) +- Ablauf mit + - FIFO ... + - LFU ... + +### LRU: Least Recently Used +- Idee: Seite im Puffer ersetzen, die am längsten nicht mehr referenziert wurde +- Implementierung: + - Liste oder Stack von Seiten + - Puffer-Hit bewegt Seite zur MRU-Position (Most Recently Used) + - Seite am Ende wird verdrängt + ![](Assets/DBimpl-seitenersetzung-lru.png) +- Varianten: + - durch Interpretation der Pin-Operation: Least Recently Referenced bzw. Least Recently Unfixed + - durch Berücksichtigung der letzten $k$ Referenzierungen (d.h. auch Häufigkeit): LRU-K + +LRU: Probleme +- Lock Contention in Multitasking-Umgebungen + - Zugriff auf LRU-Liste/Stack und Bewegung der Seite erfordert exklusiven Zugriff auf Datenstruktur + - aufwendige Operation +- berücksichtigt nur Alter jedoch nicht Häufigkeit + - oft gelesene Seiten mit langen Pausen zwischen den Zugriffen werden nicht adäquat berücksichtigt +- "Zerstörung" des Puffers durch Scan-Operator + - Seiten werden nur einmalig gelesen, verdrängen jedoch andere (ältere) Seiten + + +Lock Contention bei der Pufferverwaltung +![](Assets/DBimpl-lock-contention.png) +- Sperren = Latches: leichtgewichtige (wenige CPU-Instruktionen) Objekte für kurzzeitige Sperren + +Approximierende Verfahren +- Idee: + - Vereinfachung der benötigten Datenstruktur durch Approximation + - Effektivität (Trefferrate) vs. Skalierbarkeit (Anzahl der Threads) +- CLOCK: Approximation der Historie durch Bit-Schieberegister der Länge _k_ + - $k= 0$: FIFO + - $k\rightarrow\infty$: LRU + - typisch: $k = 1$ + +### CLOCK +- Seite mit Benutzt-Bit; bei Referenzierung auf "1" setzen +- bei Seitenfehler: + - zyklische Suche + - Seite mit "0" verdrängen + - sonst Setzen auf "0" + ![](Assets/DBimpl-seitenersetzung-clock.png) + +### GCLOCK +- Verbesserung: Benutzt-Bit durch Referenzzähler _RC_ ersetzen; Dekrementierung bei Suche +- weitere Verbesserungen: + - Initialisierung des Referenzzählers + - Inkrementierung des Zählers + - seitentypspezifische Maßnahmen (für Typ _i_ : Seitengewicht $E_i$ bei Erstreferenzierung, $W_i$ bei weiterer Referenzierung) + - Altern +- Varianten: Seite _j_ von Typ _i_ + - $GCLOCK(V1): RC_j := E_i ; RC_j := RC_j + W_i$ + - $GCLOCK(V2): RC_j := E_i ; RC_j := W_i$ (speziell für $W_i\geq E_i$) + +### DGCLOCK +- weitere Verbesserung: globaler Zähler $GC$ und Normierung der aktuellen Referenzzähler $RC$ + 1. Initialisierung: $RC_j := GC$ + 2. Referenzierung von Seite $j : GC := GC + 1 ; RC_j := RC_j + GC$ + 3. bei Überschreiten $GC > MIN : \forall j : RC_j := RC_j / C$ + +### ARC +- Adaptive Replacement Cache: neues Verfahren, das Nachteile von LRU vermeidet +- Prinzip: + - Puffergröße _c_ + - Pufferverzeichnis für 2 _c_ Seiten: _c_ Pufferseiten + _c_ History-Seiten + - Liste _L_ 1 : "recency" = kurzfristiger Nutzen-> Seiten, die kürzlich einmal gelesen wurden + - Liste _L_ 2 : "frequency" = langfristiger Nutzen -> Seiten, die kürzlich mehrmals gelesen wurden +- Ausgangspunkt: einfache Verdrängungsstrategie DBL(2 _c_ ) + - Ersetze die LRU-Seite in $L_1$, wenn $|L_1| = c$ , sonst ersetze LRU-Seite in $L_2$ + - Ziel: Größenausgleich zwischen $L_1$ und $L_2$ + - Zugriff Seite $p$: wenn Treffer -> $p$ wird MRU in $L_2$ , sonst in $L_1$ + +Von DBL(2c) zu ARC +![](Assets/DBimpl-DBL-to-arc.png) +- Parameter $p$ mit $0\leq p \leq c$ + - $T_1$ enthält $p$ Seiten, $T_2$ enthält $c-p$ Seiten +- Wahl von $p$? + +ARC: Algorithmus +- Seitenanforderungen: $x_1,x_2 ,..., x_t ,...$ +- $p = 0, T_1 , B_1 , T_2 ,B_2$ sind initial leer + - Fall 1: $x_t \in T_1 \cup T_2$ /* Puffer-Hit */ + - Bewege $x_t$ zu MRU von $T_2$ + - Fall 2: $x_t \in B_1$ + - Anpassung: $p = min\{ p +\delta_1,c\}$ mit $\delta_1 = \begin{cases} 1\quad\text{ wenn } |B_1|\geq |B_2| \\ \frac{|B_2|}{|B_1|} \quad\text{ sonst}\end{cases}$ + - $REPLACE(x_t,p)$ + - Bewege $x_t$ von $B_1$ zu MRU von $T_2$ + - Fall 3: $x_t \in B_2$ + - Anpassung: $p = max\{ p - \delta_2, 0 \}$ mit $\delta_2 = \begin{cases} 1\quad\text{ wenn } |B_2|\geq |B_1| \\ \frac{|B_1|}{|B_2|} \quad\text{ sonst}\end{cases}$ + - $REPLACE(x_t,p)$ + - Bewege $x_t$ von $B_2$ zu MRU von $T_2$ + - Fall 4: $x_t \not\in T_1 \cup B_1 \cup T_2 \cup B_2$ + - 4.A: $|L_1| = c$ + - Wenn $|T_1|p$ oder ($x_t\in B_2$ und $|T_1|=p$) + Lösche LRU-Seite in $T_1$ und bewege sie zu MRU in $B_1$ + else + Lösche LRU-Seite in $T_2$ und bewege sie zu MRU in $B_2$ + endif + +ARC: Beispiel +1. erstmalige Anforderung der Seiten $#1$ und $#2$: Aufnahme in + ![](Assets/DBimpl-arc-bsp-1.png) +2. nächsten Referenzierung von $#1$: Übernahme in $T_2$-Liste + ![](Assets/DBimpl-arc-bsp-2.png) +3. Seitenanforderungen $#3$, $#4$, $#1$; mit $#2$ wird diese in $T_2$ bewegt; Platz für Seite $#5$: + ![](Assets/DBimpl-arc-bsp-3.png) +4. Beantwortung der Seitenanforderungen $#1$ und $#2$ aus $T_2$ +5. neu angeforderten Seiten $#5$ und $#6$ in $T_1$ + ![](Assets/DBimpl-arc-bsp-4.png) +6. Seitenanforderung $#7$: Verdrängen von $#4$ aus $T_1$ in $B_1$ + ![](Assets/DBimpl-arc-bsp-5.png) + +ARC: Eigenschaften +- kontinuierliche Anpassung von Parameter $p$ + - Lernraten $\delta_1$ und $\delta_2$ + - "Investieren in Liste mit dem meisten Profit" +- Berücksichtigung von Alter und Häufigkeit + - durch zwei Listen $L_1$ und $L_2$ +- Scan-Resistenz + - einmalig gelesene Seiten nur in $L_1$, niemals in $L_2$ +- Vermeidung von Lock Contention durch approximierende Varianten (CAR, CART, ...) + +## Fazit +- Pufferverwaltungsstrategie mit großem Einfluss auf Performance +- in kommerziellen Systemen meist LRU mit Variationen +- besondere Behandlung von Full-Table-Scans +- weiterer Einflussfaktor: Puffergröße +- Indikator: Trefferrate (engl. _hit ratio_ ) + $$hit\_ratio = \frac{\text{Anz. log. Zugriffe} - \text{Anz. phys. Zugriffe}}{\text{Anz. log. Zugriffe}}$$ +- 5-Minuten-Regel (Gray, Putzolu 1997): + Daten, die in den nächsten 5 Min. wieder referenziert werden, sollten im Hauptspeicher gehalten werden + +# Indexierung von Daten +## Klassifikation der Speichertechniken +Einordnung in 5-Schichten-Architektur +- **Speichersystem** fordert über Systempufferschnittstelle Seiten an +- interpretiert diese als interne Datensätze +- interne Realisierung der logischen Datensätze mit Hilfe von Zeigern, speziellen Indexeinträgen und weiteren Hilfsstrukturen +- Zugriffssystem abstrahiert von der konkreten Realisierung + +Klassifikation der Speichertechniken +- Kriterien für Zugriffsstrukturen oder Zugriffsverfahren: + - organisiert interne Relation selbst (Dateiorganisationsform) oder zusätzliche Zugriffsmöglichkeit auf bestehende interne Relation (Zugriffspfad) + - Art der Zuordnung von gegebenen Attributwerten zu Datensatz-Adressen: Schlüsselvergleich = Zuordnung von Schlüsselwert zu Adresse über Hilfsstruktur; Schlüsseltransformation = Berechnung der Adresse aus Schlüsselwert (z.B. über Hashfunktion) + - Arten von Anfragen, die durch Dateiorganisationsformen und Zugriffspfade effizient unterstützt werden können +![](Assets/DBimpl-speichertechniken-klassifikation.png) + +Dünn- vs. dichtbesetzter Index +- dünnbesetzter Index: nicht für jeden Zugriffsattributwert _K_ ein Eintrag in Indexdatei sondern z.B. nur für _Seitenanführer_ einer sortierten Relation +- dichtbesetzter Index: für jeden Datensatz der internen Relation ein Eintrag in Indexdatei + +Geclusterter vs. nicht-geclusterter Index +- geclusterter Index: in der gleichen Form sortiert wie interne Relation +- nicht-geclusterter Index: anders organisiert als interne Relation +- Primärindex oft dünnbesetzt und geclustert +- jeder dünnbesetzte Index ist auch geclusterter Index, aber nicht umgekehrt +- Sekundärindex kann nur dichtbesetzter, nicht-geclusterter Index sein (auch: invertierte Datei) +![](Assets/Dbimpl-cluster-vs-nicht-cluster.png) + +Statische vs. dynamische Struktur +- statische Zugriffsstruktur: optimal nur bei bestimmter (fester) Anzahl von verwaltenden Datensätzen +- dynamische Zugriffsstruktur: unabhängig von der Anzahl der Datensätze optimal + - dynamische Adresstransformationsverfahren verändern dynamisch Bildbereich der Transformation + - dynamische Indexverfahren verändern dynamisch Anzahl der Indexstufen => in DBS üblich + +Klassifikation +![](Assets/DBimpl-zugriff-klassifikation.png) + + +## Statische Verfahren +- Heap, indexsequenziell, indiziert-nichtsequenziell +- oft grundlegende Speichertechnik in RDBS +- direkte Organisationsformen: keine Hilfsstruktur, keine Adressberechnung (Heap, sequenziell) +- statische Indexverfahren für Primärindex und Sekundärindex + + +Statische Verfahren: Überblick +![](Assets/DBimpl-statische-verfahren.png) + +### Heap +Organisation +- völlig unsortiert speichern +- physische Reihenfolge der Datensätze ist zeitliche Reihenfolge der Aufnahme von Datensätzen + | | | | | + | --- | --- | --- | --- | --- + 8832 | Max | Mustermann | ... | 9.1.2003 + 5588 | Beta | Alpha | ... | 7.3.1978 + 4711 | Gamma | Delta | ... | 2.5.1945 + +Operationen +- insert: Zugriff auf letzte Seite der Datei. Genügend freier Platz => Satz anhängen. Sonst nächste freie Seite holen +- delete: lookup, dann Löschbit auf 0 gesetzt +- lookup: sequenzielles Durchsuchen der Gesamtdatei, maximaler Aufwand (Heap-Datei meist zusammen mit Sekundärindex eingesetzt; oder für sehr kleine Relationen) +- Komplexitäten: + - Neuaufnahme von Daten $O(1)$ + - Suchen $O(n)$ + +### Sequenzielle Speicherung +- sortiertes Speichern der Datensätze + | | | | | + | --- | --- | --- | --- | --- + 4711 | Gamma | Delta | ... | 2.5.1945 + 5588 | Beta | Alpha | ... | 7.3.1978 + 8832 | Max | Mustermann | ... | 9.1.2003 + +Sequenzielle Datei: Operationen +- insert: Seite suchen, Datensatz einsortieren => beim Anlegen oder sequenziellen Füllen einer Datei jede Seite nur bis zu gewissem Grad (etwa 66%) füllen +- delete: Aufwand bleibt +- Folgende Dateiorganisationsformen: + - schnelleres lookup + - mehr Platzbedarf (durch Hilfsstrukturen wie Indexdateien) + - mehr Zeitbedarf bei insert und delete +- klassische Indexform: indexsequenzielle Dateiorganisation + +## Indexsequenzielle Dateiorganisation +- Kombination von sequenzieller Hauptdatei und Indexdatei: indexsequenzielle Dateiorganisationsform +- Indexdatei kann geclusterter, dünnbesetzter Index sein +- mindestens zweistufiger Baum + - Blattebene ist Hauptdatei (Datensätze) + - jede andere Stufe ist Indexdatei +![](Assets/DBimpl-indexsequentiell.png) + +Aufbau der Indexdatei +- Datensätze in Indexdatei: _(Primärschlüsselwert, Seitennummer)_ zu jeder Seite der Hauptdatei genau ein Index-Datensatz in Indexdatei +- Problem: "Wurzel" des Baumes bei einem einstufigen Index nicht nur eine Seite +![](Assets/DBimpl-indexsequentiell-2.png) + + +Mehrstufiger Index +- Optional: Indexdatei wieder indexsequenziell verwalten +- Idealerweise: Index höchster Stufe nur noch eine Seite +![](Assets/DBimpl-indexsequentiell-3.png) + +lookup bei indexsequenziellen Dateien +- lookup-Operation sucht Datensatz zum Zugriffsattributwert _w_ +- Indexdatei sequenziell durchlaufen, dabei $(v_1,s)$ im Index gesucht mit $v_1\leq w$: + - $(v_1,s)$ ist letzter Satz der Indexdatei, dann kann Datensatz zu _w_ höchstens auf dieser Seite gespeichert sein (wenn er existiert) + - nächster Satz $(v_2,s′)$ im Index hat $v_2 > w$ , also muss Datensatz zu _w_, wenn vorhanden, auf Seite _s_ gespeichert sein +- $(v_1,s)$ überdeckt Zugriffsattributwert _w_ + +insert bei indexsequenziellen Dateien +- insert: zunächst mit lookup Seite finden +- Falls Platz, Satz sortiert in gefundener Seite speichern; Index anpassen, falls neuer Satz der erste Satz in der Seite +- Falls kein Platz, neue Seite von Freispeicherverwaltung holen; Sätze der "zu vollen" Seite gleichmäßig auf alte und neue Seite verteilen; für neue Seite Indexeintrag anlegen +- Alternativ neuen Datensatz auf Überlaufseite zur gefundenen Seite + +delete bei indexsequenziellen Dateien +- delete: zunächst mit lookup Seite finden +- Satz auf Seite löschen (Löschbit auf 0) +- erster Satz auf Seite: Index anpassen +- Falls Seite nach Löschen leer: Index anpassen, Seite an Freispeicherverwaltung zurück + +Probleme indexsequenzieller Dateien +- stark wachsende Dateien: Zahl der linear verketteten Indexseiten wächst; automatische Anpassung der Stufenanzahl nicht vorgesehen +- stark schrumpfende Dateien: nur zögernde Verringerung der Index- und Hauptdatei-Seiten +- unausgeglichene Seiten in der Hauptdatei (unnötig hoher Speicherplatzbedarf, zu lange Zugriffszeit) + + +Indiziert-nichtsequenzieller Zugriffspfad +- zur Unterstützung von Sekundärschlüsseln +- mehrere Zugriffpfade dieser Form pro Datei möglich +- einstufig oder mehrstufig: höhere Indexstufen wieder indexsequenziell organisiert + +Aufbau der Indexdatei +- Sekundärindex, dichtbesetzter und nicht-geclusteter Index +- zu jedem Satz der Hauptdatei Satz $(w,s)$ in der Indexdatei +- _w_ Sekundärschlüsselwert, _s_ zugeordnete Seite + - entweder für ein _w_ mehrere Sätze in die Indexdatei aufnehmen + - oder für ein _w_ Liste von Adresse in der Hauptdatei angeben +![](Assets/Dbimpl-nichtsequentieller-index.png) + +Operationen +- lookup: _w_ kann mehrfach auftreten, Überdeckungstechnik nicht benötigt +- insert: Anpassen der Indexdateien +- delete: Indexeintrag entfernen + +Probleme statischer Verfahren +- unzureichende Anpassung an wachsende/schrumpfende Datenmengen +- schlechte Ausnutzung von Speicher nach Seitensplits +- Bevorzugung bestimmter Attribute (Schlüssel) +- daher in den folgenden Kapiteln: + - bessere Datenstrukturen zur Schlüsselsuche als zusätzlicher Zugriffspfad = Approximation einer Funktion Schlüssel -> Speicheradresse, z.B. über Baumverfahren + - Erweiterung von Hashverfahren um Anpassung des Bildbereichs = dynamische Hashverfahren + - Behandlung von zusammengesetzten Schlüsseln = multidimensionale Zugriffsverfahren, z.B. multidimensionale Bäume oder raumfüllende Kurven + +# Baumbasierte Indexstrukturen \ No newline at end of file