mirror of
https://gitlab.cs.fau.de/ik15ydit/latexandmore.git
synced 2024-12-25 09:36:06 +01:00
Saetze fortgesetzt. Hashing nur sehr kurz
This commit is contained in:
parent
8aefc54eb6
commit
e0d1b3d650
45
Saetze.tex
45
Saetze.tex
@ -5,6 +5,9 @@ Sätze abstrahieren von Blöcken. Blöcken sind Hardware spezifisch.
|
||||
Sie haben unterschiedliche Längen und die Aufgabe von Einheiten von
|
||||
Platte und HS zu transportieren. Daher hat man eine anwendungspezifische
|
||||
Einheit eingeführt, die Daten zusammenfasst.\\
|
||||
\subsection{Satzadresse}
|
||||
Eine Satzadresse ist ein Bezeichner unter der man einen einzelnen Satz wiederfinden kann. Sie wird als stabil bezeichnet, wenn sich beim
|
||||
verschieben des Satzes die Adresse nicht ändert.
|
||||
$\rightarrow$ Neue Schicht über Blöcke
|
||||
\subsection{Wechselpuffertechnik}
|
||||
Optimierungsmöglichkeit bei sequenziellen Dateien.
|
||||
@ -14,3 +17,45 @@ Anwendung beim
|
||||
\item Lesen: während Sätze in Puffer 1 gelesen werden \textbf{gleichzeitig} nächsten Block von Platte in Puffer 2 lesen
|
||||
\item Schreiben: wenn Puffer 1 voll, \textbf{asynchron} auf Platte schreiben und gleichzeitig Puffer 2 zur Aufnahme weiterer Sätze verwenden
|
||||
\end{itemize}
|
||||
\subsection{Satzzugriff über Schlüsselwerte}
|
||||
\subsection{Normales Hashing}
|
||||
Man möchte nun Sätze und deren Inhalt nicht nur über
|
||||
die Satzadresse wiederfinden, sondern auch über \textbf{inhaltliche Kriterien}.
|
||||
\textbf{Schlüssel} definieren ein oder mehrere Felder eines Satzes, über
|
||||
das man den Satz wiederfinden kann.
|
||||
|
||||
Lösung dafür ist \textbf{Hashing} der Sätze nach Schlüssel.
|
||||
|
||||
Kollisionen verhindern:
|
||||
\begin{itemize}
|
||||
\item Open Addressing (ausweichen auf Nachbar Buckets)
|
||||
\begin{itemize}
|
||||
\item $+$ kein zusätzlicher Speicherplatz erforderlich
|
||||
\item $-$ beim Suchen findet man im Bucket auch Überläufer
|
||||
\item $-$ beim löschen Überläufer zurückholen
|
||||
\item $-$ in Nachbarbuckets werden ggf weitere Überläufe erzeugt
|
||||
\end{itemize}
|
||||
\item Overflow Buckets
|
||||
\begin{itemize}
|
||||
\item Anlegen spezieller Überlauf Buckets für jeden Bucket
|
||||
\begin{itemize}
|
||||
\item $-$ zusätzlicher Speicherplatz erforderlich
|
||||
\item $+$ keine Mischung von sätzen
|
||||
\item $+$ keine Beeinträchtigung der Nachbarbuckets
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\end{itemize}
|
||||
\subsubsection{Bewertung}
|
||||
\begin{itemize}
|
||||
\item sehr schneller Zugriff über Schlüssel (1 bis 2 Blockzugriffe)
|
||||
\item gestreute Speicherung kann nur nach \textbf{einem} Schlüssel erfolgen
|
||||
\item Speicherplatz muss um voraus belegt werden
|
||||
\end{itemize}
|
||||
\subsection{Virtuelles Hashing}
|
||||
Vorteile vom virtuellen Hashing ggü. normalen Hashing:\\
|
||||
Das normale Hashing ist nicht erweiterbar, d.h. man muss den gesamten
|
||||
Speicher im voraus belegen. Dadurch kommt man in Platznot oder verschwendet zuviel.
|
||||
Beim linearen Hashing versucht man durch kontinuierliche Reorganisation
|
||||
Überlaufprobleme zu vermeiden.
|
||||
|
||||
Beschreibung von Dateizustand:
|
||||
|
Loading…
Reference in New Issue
Block a user