Quelltext der Seite Hotspot (Datenbanken)

Bei einem '''Hotspot''' in einer [[Datenbank]] handelt es sich um die Bezeichnung für Datenelemente, die von (fast) allen Transaktionen verwendet und geändert werden.

== Anschauliches Beispiel für einen Hotspot ==
Es gibt in Datenbanken oft Datensätze, die von allen Transaktionen geändert werden möchten. Der Artikel verwendet folgendes Beispiel zu Anschauung:

* In einem Call-Center eines Homeshopping-Senders werden die vielen telefonischen Bestellungen gleichzeitig erfasst. Dabei wird nach folgender Reihenfolge vorgegangen:
** Die Kunden geben zu Beginn die Anzahl des gewünschten Artikels an, die dann vorgemerkt wird, also der verfügbare Bestand verkleinert.
** Anschließend werden die Kundendaten erfasst.
** Zum Schluss wird dem Kunden eine Zusammenfassung vorgelesen, welche er bestätigen muss, damit die Bestellung abgeschlossen wird.

Wenn der Kunde am Ende des Anrufes sich doch anders entscheidet, muss der gesamte Vorgang rückgängig gemacht werden und auch die vorgemerkten Artikel müssen wieder freigegeben werden. Üblicherweise werden solche Vorgänge in einer [[Transaktion (Informatik)|Transaktion]] abgehandelt, um so sicherzustellen, dass halb abgeschlossene Bestellungen nicht den Bestand blockieren.
Der Hotspot bildet sich hier also über dem Bestand des Produkts, das momentan beworben wird. Dabei muss sichergestellt werden, dass ''alle'' Telefonisten aktuelle Daten über den Bestand haben und gleichzeitig damit arbeiten können und dass keine Artikel mehr verkauft werden können, wenn das Kontingent aufgebraucht ist.

== Lösungsansätze und deren Probleme ==
=== Getrennte Lese- und Schreibzugriffe ===
Man könnte zuerst die Anzahl der vorhandenen Artikel auslesen, um die gewünschte Anzahl zu verringern und das Ergebnis wieder in die Datenbank schreiben.

<pre>
$bestand= sql select bestand from lager where produkt_id = $id
$bestand-=3
sql update lager set bestand = $bestand where produkt_id = $id
</pre>

''Probleme:''
Bei dieser Vorgehensweise besteht die akute Gefahr eines [[Deadlock (Informatik)|Deadlocks]]: Transaktion von Kunde A möchte, nachdem es den Bestand berechnet hat, die bestehende Lesesperre (andere können die Tabelle auch noch lesen) in eine Schreibsperre (andere können nicht auf die Tabelle zugreifen) erweitern, um den neuen Bestand in die Tabelle zu schreiben. Transaktion von Kunde B hat aber zwischenzeitlich eine Lesesperre bekommen und somit blockieren sich die beiden Transaktionen gegenseitig, da Transaktion A die Schreibsperre erst erhält, wenn alle Lesesperren aufgehoben sind, Transaktion B aber erst weitermachen kann, wenn A seine Schreibsperre aufgehoben hat. Die beiden Transaktionen blockieren sich gegenseitig. Wichtig ist dabei zu wissen, dass eine Transaktion ihre Sperren vor Ende der Transaktion ([[Commit]] oder [[Rollback|Abort]]) immer nur verschärfen, nicht aber lockern oder aufheben kann.

=== Kombinierter Lese- und Schreibzugriff ===
Der Bestand wird in einem Schritt direkt in der Datenbank verändert

<pre>
sql update lager set bestand = bestand - 3 where produkt_id = $id
</pre>

''Verbesserungen & Probleme:''
Somit können keine Deadlocks mehr entstehen. Allerdings müssen alle anderen warten, bis die Transaktion die Sperre aufhebt. Die Transaktionen können also nur hintereinander abgearbeitet werden oder anders ausgedrückt kann immer nur ein Telefonist gleichzeitig eine Bestellung bearbeiten.

=== Feldzugriffe (Field Calls) ===
[[Datei:Database hotspot field calls german.svg|mini|Beispiel mit Field Calls]]

Die Idee, die hinter Feldzugriffen steckt, ist die Zerlegung der Hotspot-Anfrage in zwei Teile, wobei in manchen Fällen einer von beiden nicht benötigt wird:

# eine Vorbedingung (Prädikat) ''(in unserem Beispiel: bestand > 3)''
# eine Umwandlung (Transformation) ''(in unserem Beispiel: bestand = bestand - 3)''
Feldzugriffe werden nach folgendem System bearbeitet:
# Sofortiger Test der Vorbedingung. Dabei wird das [[Datenelement]] mit einer Lesesperre versehen und unverändert wieder freigegeben
# Abbruch und Rollback der Transaktion, falls der Test „Falsch“ ergibt. ''(Im Beispiel wäre also der Bestand kleiner als 3 und der Telefonist würde eine Meldung erhalten, dass nicht mehr genügend Artikel vorhanden sind)''
# Es wird im Rollback-Protokoll ein Eintrag mit Vorbedingung und Umwandlung angelegt, der beim Ende der Transaktion ausgeführt wird.
# Der Abschluss der Transaktion besteht aus zwei Phasen:
## Es werden alle Rollback-Einträge für die aktuelle Transaktion bearbeitet und Sperren für die Feldzugriffe angefordert (Lesesperren für Zugriffe ohne Transformation, Schreibsperren für Zugriffe mit Transformation). Anschließend werden alle Vorbedingungen ein weiteres Mal getestet. Wenn hier ein oder mehr Tests fehlschlagen wird die Transaktion zurückgesetzt, ansonsten wird mit Phase 2 weitergemacht:
## Anwenden aller Transformationen und abschließen der Transaktion durch Freigabe aller Sperren

<pre>
sql update hotspot lager set bestand = bestand - 3 where produkt_id = $id and bestand > 3
</pre>

''Verbesserungen & Probleme:''
Bei den Feldzugriffen werden alle blockierenden Aktionen gesammelt und kurz vor Abschluss gesammelt ausgeführt. Damit wird verhindert, dass sich die Transaktionen gegenseitig lange blockieren. Dadurch entsteht aber das Problem, dass in Phase 1 im vierten Schritt eine Vorbedingung, die zum Zeitpunkt der eigentlichen Prüfung erfolgreich war immer noch fehlschlagen und somit zum Abbruch der Transaktion führen kann. Es kann dabei passieren, dass ein Anrufer, der lange für die Erfassung der Daten benötigt, trotz vorheriger Verfügbarkeit leer ausgeht, weil in der Zwischenzeit der Lagerbestand aufgebraucht wurde.
Ein weiteres Problem ist das Lesen der Daten. Sie enthalten stets den ursprünglichen Wert. Im Beispiel würde das bedeuten, dass bei einem Bestand von 6 Artikeln und drei Telefonisten, deren Kunden je zwei Artikel bestellen wollen, ein vierter Telefonist einem Kunden scheinbar immer noch 6 Artikel verkaufen kann, da die Bestände bei dieser Lösung erst bei Abschluss der Transaktion geändert werden.

=== Escrow-Sperren ===
[[Datei:Hotspot escrow locks german.svg|mini|Beispiel mit Escrow-Sperre]]

Die Escrow-Sperre protokolliert die Anfragen der Transaktionen mit und errechnet sich daraus ein Intervall, in dem der Tatsächliche Wert liegen muss. Die Obergrenze des Intervalls entspricht dabei dem Fall, dass alle Transaktionen abbrechen, die Untergrenze tritt ein, wenn alle Transaktionen beenden. Wenn also die untere Grenze kleiner als die Vorbedingung einer Transaktion, dann kann diese Transaktion zu diesem Zeitpunkt nicht beendet werden. Je nach Implementierung kann es sein, dass sie aber, sofern sie mit ihrer Vorbedingung unterhalb der oberen Grenze des Intervalls liegt, so lange wartet, bis feststeht, ob die Transaktion beendet werden kann oder sie direkt abgebrochen wird.
Logischerweise funktioniert die Escrow-Sperre nur mit Werten, die sich in eine eindeutige Reihenfolge sortieren lassen, im Normalfall also Zahlen.

''Verbesserungen & Probleme:''
Die Escrow-Sperre behebt sowohl das Problem mit den Abbrüchen in Phase 1 beim Feldzugriff als auch die „unfaire“ Reihenfolge beim Beispiel.

== Siehe auch ==
* [[Transaktionssystem]]

== Literatur ==
* [[James N. Gray|Jim Gray]], Andreas Reuter: ''Transaction Processing: Concepts and Techniques (Morgan Kaufmann Series in Data Management Systems)''. Morgan Kaufmann, ISBN 1558601902

== Quellen/Weblinks ==
* [http://pi3.informatik.uni-mannheim.de/downloads/hauptstudium/tasys/ss03/tasys.pdf Vorlesungs-Skript zur Vorlesung Transaktionssysteme], Prof. Guido Moerkotte, [[Universität Mannheim]] (''Abschnitt zu Hotspots auf den Seiten 49-52''; PDF-Datei; 397 kB)
* [http://www.dbs.ethz.ch/education/ar1/WS_99_00/folien_online/validierung/sld027.htm Vorlesungs-Folien zur Vorlesung Architektur und Realisierung von Datenbanksystemen I], Prof. Hans-Jörg Schek, [[ETH Zürich]]

[[Kategorie:Datenbanken]]