Hotspot (Datenbanken)

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten (Unterschied zur vorletzten Version).

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.

Inhaltsverzeichnis

1 Anschauliches Beispiel für einen Hotspot
2 Lösungsansätze und deren Probleme
3 Literatur
4 Quellen/Weblinks
5 Siehe auch

[Bearbeiten] Anschauliches Beispiel für einen Hotspot

Es gibt in Datenbanken oft Datensätze, auf 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 viele 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 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 wieder freigegeben werden. Üblicherweise werden solche Vorgänge in einer Transaktion abgehandelt, um so sicherzustellen, dass halb abgeschlossenen Bestellungen nicht den Bestand blockieren. Der Hotspot bildet sich hier also über dem Bestand des Produkt, 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.

[Bearbeiten] Lösungsansätze und deren Probleme

[Bearbeiten] getrennte Lese- und Schreibzugriffe

Man könnte zuerst die Anzahl der vorhandenen Artikel auslesen, um die gewünschte Anzahl verringern und das Ergebnis wieder in 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.

[Bearbeiten] kombinierter Lese- und Schreibzugriff

Der Bestand wird in einem Schritt direkt in 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.

[Bearbeiten] Feldzugriffe (Field Calls)

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)

Bei Feldzugriffen 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 Telefonisten 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:
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 wird die alle blockierende 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 kann 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 immer noch scheinbar 6 Artikel verkaufen kann, da die Bestände bei dieser Lösung erst bei Abschluss der Transaktion geändert werden.

[Bearbeiten] 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.

[Bearbeiten] Literatur

Jim Gray, Andreas Reuter: Transaction Processing: Concepts and Techniques (Morgan Kaufmann Series in Data Management Systems). Morgan Kaufmann, ISBN 1558601902