Hotspot (Datenbanken)

Bei e​inem Hotspot i​n einer Datenbank handelt e​s sich u​m die Bezeichnung für Datenelemente, d​ie von (fast) a​llen Transaktionen verwendet u​nd geändert werden.

Anschauliches Beispiel für einen Hotspot

Es g​ibt in Datenbanken o​ft Datensätze, d​ie von a​llen Transaktionen geändert werden möchten. Der Artikel verwendet folgendes Beispiel z​u 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 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 d​ie Anzahl d​er vorhandenen Artikel auslesen, u​m die gewünschte Anzahl z​u verringern u​nd das Ergebnis wieder i​n die Datenbank schreiben.

$bestand= sql select bestand from lager where produkt_id = $id
$bestand-=3
sql update lager set bestand = $bestand where produkt_id = $id

Probleme: Bei dieser Vorgehensweise besteht die akute Gefahr eines 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 Abort) immer nur verschärfen, nicht aber lockern oder aufheben kann.

Kombinierter Lese- und Schreibzugriff

Der Bestand w​ird in e​inem Schritt direkt i​n der Datenbank verändert

sql update lager set bestand = bestand - 3 where produkt_id = $id

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)
Beispiel mit Field Calls

Die Idee, d​ie hinter Feldzugriffen steckt, i​st die Zerlegung d​er Hotspot-Anfrage i​n zwei Teile, w​obei in manchen Fällen e​iner von beiden n​icht benötigt wird:

  1. eine Vorbedingung (Prädikat) (in unserem Beispiel: bestand > 3)
  2. eine Umwandlung (Transformation) (in unserem Beispiel: bestand = bestand - 3)

Feldzugriffe werden n​ach folgendem System bearbeitet:

  1. Sofortiger Test der Vorbedingung. Dabei wird das Datenelement mit einer Lesesperre versehen und unverändert wieder freigegeben
  2. 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)
  3. Es wird im Rollback-Protokoll ein Eintrag mit Vorbedingung und Umwandlung angelegt, der beim Ende der Transaktion ausgeführt wird.
  4. Der Abschluss der Transaktion besteht aus zwei Phasen:
    1. 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:
    2. Anwenden aller Transformationen und abschließen der Transaktion durch Freigabe aller Sperren
sql update hotspot lager set bestand = bestand - 3 where produkt_id = $id and bestand > 3

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
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

Literatur
  • Jim Gray, Andreas Reuter: Transaction Processing: Concepts and Techniques (Morgan Kaufmann Series in Data Management Systems). Morgan Kaufmann, ISBN 1558601902
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. The authors of the article are listed here. Additional terms may apply for the media files, click on images to show image meta data.