anfragen transaktionen

Kapitel 10
Updates und Transaktionen auf
XML-Dokumenten
Updates auf XML-Dokumenten
Grundlagen der Transaktionsverwaltung
Unterstützung durch DBMS
Mehrschichtenansatz für XML
Updates auf XML-Dokumenten
z
Anforderungen an eine Datenmanipulationssprache für XML
–
–
–
z
Naiver Ansatz
–
–
–
–
z
Dokumente sollen beliebig änderbar sein
Deklarative Definition der Änderungen
Zusammenspiel mit den bislang diskutierten Anfragesprachen (siehe Kap. 4)
Änderungen als eine Folge von DOM-Operationen definieren
Dokument(e) in einen DOM-Prozessor laden
Änderungen durchführen
Dokument(e) zurückschreiben
Problem des naiven Ansatzes
–
–
–
DOM ist navigierend (d.h. nicht deklarativ)
DOM-Prozessoren erfordern typischerweise eine Programmiersprache
Kein Zusammenspiel mit deklarativer Anfragesprache für XML
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-2
Erweiterung von XQuery für Updates
z
W3C XQuery ist der zukünftige Standard für XML-Anfragesprachen
z
Vorschlag für eine Erweiterung basierend auf XQuery‘s FLWR-Ausdrücken
FOR $Variablenbindung1 IN Pfadausdruck1
LET $Variablenbindung2 := Pfadausdruck2
WHERE Prädikat
UPDATE {UpdateOperation}
z
Update-Operation auf Variablenbindung $Knoten
–
–
–
–
–
z
Löschen eines Kindknoten:
DELETE $Knoten
Umbenennen eines Kindknotens:
RENAME $Knoten TO Name
Einfügen von XML-Inhalten:
INSERT Inhalt [BEFORE | AFTER $Knoten]
Ersetzen von XML-Inhalten:
REPLACE $Knoten WITH Inhalt
$Knoten kann Element oder Attribut sein
Operationen decken alle auch mit DOM möglichen Änderungen ab
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-3
Beispiel für eine Änderung
Update:
FOR $book IN //book
$bookyear IN $book/@year
WHERE $book/title = ‘Data on the Web’
UPDATE $book
DELETE $bookyear,
INSERT <author>Buneman</author>,
INSERT <author>Suciu</author>,
INSERT new_attribute("1-55860-622-X“, isbn)
Einfügen am
Ende der
Liste der
Kindknoten
Attributkonstruktor
Dokument vor der Änderung:
Dokument nach der Änderung:
<book year="1999" >
<title>Data on the Web</title>
<abstract> … </abstract>
<author>Abiteboul</author>
</book>
<book isbn="1-55860-622-X">
<title>Data on the Web</title>
<abstract> … </abstract>
<author>Abiteboul</author>
<author>Buneman</author>
<author>Suciu</author>
</book>
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-4
Motivation für Transaktionen
z
Transaktion: Verarbeitungseinheit bestehend aus einer oder mehreren
Operationen
z
Wesentliche Voraussetzung für eine zuverlässige Datenverarbeitung
–
–
z
Korrektes paralleles Verarbeiten von Updates und Retrieval
Fehlertoleranz
Viele wichtige Anwendungen erfordern Transaktionen
–
–
Datenzentrisches Beispiel: Banküberweisung
Dokumentzentrisches Beispiel: Einladen einer verlinkten Dokumentstruktur
z
Bislang keine Transaktionen bei der XML-Verarbeitung berücksichtigt
z
Viele (bspw. geschäftskritische) XML-Anwendungen erfordern dies aber
z
Zielsetzung dieses Kapitels
–
–
–
Kurze Einführung in das Transaktionskonzept
Eignung schon verfügbarer Transaktionsmanagern für die XML-Verarbeitung
Transaktionsverwaltung für XML anpassen und erweitern
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-5
Transaktionseigenschaften
z
ACID-Eigenschaften:
A Atomarität (atomicity) – Alle Operationen werden entweder erfolgreich
durchgeführt (Commit) oder die Transaktion hinterlässt keine Effekte (Abort)
C Konsistenz (consistency) – Eine Transaktion überführt eine DB von einem
konsistenten Zustand in einen nächsten. Konsistenz ist definiert über die
semantischen Integritätsbedingungen
I Isolation (isolation) – Jede Transaktion arbeitet auf der DB, als wäre sie die
einzige aktive Transaktion, d.h. sie sieht keine inkonsistenten
Zwischenzustände anderer Transaktionen
D Persistenz (durability) – Alle erfolgreich abgeschlossenen Änderungen sind
wiederherstellbar (bspw. nach einem Fehler)
z
Implementierung der Eigenschaften
–
–
Isolation: Concurrency Control / Scheduler
Atomarität: Recovery Manager
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-6
Schedules und Serialisierbarkeit
z
Ziel: korrekte Isolation bei paralleler Verarbeitung garantieren
z
Schedule (siehe auch ISK)
–
–
–
z
Konflikt (siehe auch ISK)
–
–
–
z
Modell möglicherweise verzahnter Transaktionen
Enthält Operationen der Transaktion (evtl. über mehrere Ebenen)
Gibt Auskunft über die Konflikte zwischen Transaktionen und ihren
Operationen
zwischen Operationen verschiedener Transaktionen
Beispiel für syntaktisches Konfliktverständnis: Read/Write-Operationen auf
gleichem Datenobjekt sind im Konflikt
Beispiel für semantisches Konfliktverständnis: Gutschriften auf gleichem
Konto kommutieren, stehen nicht im Konflikt zueinander
Korrektheitsbegriff der Konfliktserialisierbarkeit
–
–
Graph der Konfliktbeziehungen (Serialisierungsgraph) ist azyklisch
keine inkonsistenten Informationsflüsse zwischen Transaktionen
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-7
Beispiel für einen Schedule
T2
p2
T1
p1
q1
q2
r2(u) r2(v) r1(s) r1(t) w1(u) w1(v) w2(t) w2(s)
XML-Ebene
mit Konflikten
Seitenebene
mit Konflikten
Seitenebene: nicht serialisierbar – zyklische Konfliktrelationen
XML-Ebene: serialisierbar – da keine Konflikte
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-8
Spezielle Anforderungen von XML-Verarbeitung
an die Transaktionsverwaltung (1)
Verarbeitung
XML
klassische (in DBS)
Strukturierung der Objekte
komplex
einfach
Grösse der Objekte
eher gross
klein
Grösse der Objektmengen
variabel
gross
Art der Operationen
höhere,
semantisch reiche
read/
read/write,
write,
syntaktisch
Strukturierung der Operationen flach
geschachtelt
z
Ähnliche Anforderungen wie in objektorientierten Datenbanksystemen
z
Literatur: Saake/Türker/Schmitt: Objektdatenbanken, Kapitel 9
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-9
Spezielle Anforderungen von XML-Verarbeitung
an die Transaktionsverwaltung (2)
z
XML-Dokumente können sehr gross sein
–
Beispiel: ganze Datenbank ist ein einziges (grosses) Dokument
z
Sperren auf der Dokumentenebene würden Parallelität stark reduzieren
oder gar ausschliessen
z
Variable Sperrgranularität bei XML-Dokumenten erforderlich
z
Ausnutzung der Semantik von Operationen
z
Sperren entlang von Pfaden ermöglichen
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-10
Problematik nebenläufiger XML-Verarbeitung
z
Nebenläufige Updates und Retrieval von XML-(Teil-)Dokumenten
z
Beispiel:
T1: Retrieve “/store/auction/price[. > 1000]”
T2: Update “/store/auction[./price = 5.20]/description”
T3: Update “/store/auction[./description = ‘PC Pentium’]”
store
auction
auction
description
Floppy
disk
price
price
description
PC
Pentium
5.20
4711.00
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-11
Einsatz des Transaktionsmanagers von DBS
z
Einsatz eines DBS zur Speicherung von XML (siehe Kapitel 5)
z
Transaktionsverwaltung des DBS einsetzen
T1
T2
SQL/XML-Update
SQL/XML-Update
XML
Service
XML
Service
op1
op2
XML
Service
XML
Service
op3
op7
op8
op9
Datenbanksystem
DB-Transaktionen
r2(u)
r2(v)
r1(s)
r1(t)
w1(u)
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
w1(v)
w2(t)
w2(s)
10-12
Implementierung der Transaktionseigenschaften mit
kommerziellen Datenbanksystemen
z
Zwei-Phasen-Sperrprotokoll
–
–
–
z
Sperrgranularität
–
–
z
#Sperren
Phase mit nur Sperranforderungen
Phase mit nur Sperrenfreigaben
Trennung der Phasen
Datenbankseiten (page level locking)
Tabellenzeilen (row level locking)
rd
fo
n
A
e
as
ph
s
g
un
er
Fr
ei
ga
b
ep
ha
se
t
Sperrgranularität des Datenbanksystems reflektiert nicht die Granularität
des Zugriffs bei XML-Anfragen
–
–
–
Textbasierte Speicherung: ganzer CLOB gesperrt – keine Parallelität von Leseund Schreibzugriffen
Modellbasierte Speicherung: grosse Teile der Dokumente müssen zum Zugriff
wiederhergestellt werden – wenig Parallelität von Lese- und Schreibzugriffen
Siehe das Beispiel auf der folgenden Folien zur Illustration
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-13
Beispiel für DBS-Transaktionsmanager
mit textbasierter Abbildung
store
T1: Retrieve
/store/auction/price[. > 1000]
auction
T2: Update
/store/auction[./price = 5.20]
/description
description
Floppy
disk
T3: Update
/store/auction[./description =
‘PC Pentium’]
XML
Row: [X-Lock]
S-Lock
auction
price
5.20
description
PC
Pentium
price
4711.00
DOCID
XMLTEXT
3
<store><auction>...</
auction><auction>...</
>...</auction
auction></
></store
store>
>
store><auction>...</auction><auction
4
…
Unnötige
Blockierung
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
Berechtigte
Blockierung
10-14
Alternativer Ansatz:
Semantische Serialisierbarkeit von XML-Anfragen
z
Spezieller Transaktionsmanager nutzt das Datenmodell von XML aus und
die Semantik der XML-Verarbeitung aus
–
–
Pfadausdrücke auf Dokumentstruktur
Prädikate auf Dokument-/Elementinhalte
descendant-or-self (//)
customer
orders
//customer[id=‘4711‘]/orders
[date='2002/12/06']/lineitem
filter
opeq
('=')
id
'4711'
date
order
filter
lineitem
opeq
('=')
'2002/12/06'
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-15
Mehrschichtige Transaktionsverwaltung für XML
z
Mehrschichtiger Ansatz wie aus ISK bekannt
–
–
–
z
Datenbanksystem auf der Speicherebene
Separater Scheduler auf der darüber liegenden XML-Ebene (Middleware)
XML-Operationen werden in Datenbanktransaktionen aufgespaltet
Abbildung von der Middleware auf das DBS hängt von der Abbildung der
XML-Dokumente ab (siehe Kap. 5)
–
–
–
–
textbasierte Abbildung
modellbasierte Abbildung
strukturbasierte Abbildung
XML-Datentyp des DBS
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-16
Mehrschichtige Transaktionsverwaltung für XML
T2
T1
Scheduler für
XML
SQL/XML-Updates
XML
Service
XML
Service
XML
Service
XML
Service
XMLMiddleware
SQL/XML-Update oder SQL
op1
op2
r2(u)
r2(v)
r1(s)
op3
r1(t)
op7
w1(u)
w1(v)
op8
w2(t)
op9
Datenbanksystem
w2(s)
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-17
Vorteile einer mehrschichtigen
Transaktionsverwaltung für XML
z
Ausnutzen der Semantik der XML-Verarbeitung
–
–
z
XML-Transaktionen auf der höheren Ebene
Kurze Datenbanktransaktionen auf der Speicherebene
Höhere Parallelität
–
Frühe Sperrfreigabe auf der Datenbank
„
„
–
z
Textbasierte Abbildung: z.B. jeder CLOB eine eigene DB-Transaktion
Modelbasierte Abbildung: z.B. jeder Dokumentteilbaum bestimmter Grösse eine
DB-Transaktion
Höhere Nebenläufigkeit auf der höheren Ebene durch Ausnutzen der Semantik
Realisierung einer Transaktionsverwaltung für XML
–
–
Isolation: Wie erkennen wir Konflikte effizient?
Atomarität: Wie behandeln wir abgebrochene Transaktionen?
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-18
Isolation: Concurrency Control für mehrschichtige
Transaktionsverwaltung für XML
z
XML-Transaktionen auf der höheren Ebene
z
Grober Ablauf des Schedulings auf der höheren Ebene
–
Beginn der XML-Transaktion
„
„
„
–
z
Ende der XML-Transaktion
Problem der Konflikterkennung auf der höheren Ebene
–
–
Vergleich mit allen anderen Anfragen (bspw. in XPath-Syntax) nicht effizient
Geeignetere Repräsentation des aktuellen Workloads nötig
„
„
–
–
z
Interception der XML-Anfragen der Transaktion auf der Middleware-Ebene
Bestimme Konflikte mit anderen aktiven XML-Transaktionen
Erzeugen der Datenbanktransaktionen für die Speicherebene
Pfadausdrücke
Prädikate über Dokumentinhalte
Ausnutzen der hierarchischen Struktur von XML
Erweiterung des klassischen DAG-Sperrprotokolls für das Scheduling
DAG-Sperrprotokoll in Kombination mit striktem Zwei-PhasenSperrprotokoll auf der höheren Ebene garantiert Serialisierbarkeit
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-19
Klassisches DAG-Sperrprotokoll
z
Hierarchische Struktur von Datenobjekten
–
–
z
Wurzel -> Datenbank -> Datei -> Tabelle -> Tabellenzeile -> Tabellenspalte
Wurzel -> Datenbank -> Index -> Tabelle -> Tabellenzeile -> Tabellenspalte
Unterscheidung der Sperren
–
–
Intentionale Sperren: Transaktion beabsichtigt, auf ein Datenobjekt auf einer
tieferen Hierarchiestufe zuzugreifen
Normale Sperre: Transaktion liest oder schreibt das Datenobjekt
z
Erweiterte Kommutativitätsmatrix
im DAG-Sperrprotokoll
z
DAG-Sperrprotokoll:
–
–
z
Lesend: Ein Pfad von der
Wurzel zum Datenobjekt sperren
Schreibend: Alle (!) Pfade von der
Wurzel zum Datenobjekt sperren
Granted
Requested None IS IX S SIX
IS
+
+
+ +
+
IX
+
+
+ S
+
+
- +
SIX
+
+
X
+
-
X
-
Zusammen mit 2PL sind die entstehenden Schedules konfliktserialisierbar
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-20
Beispiel für das klassische DAG-Sperrprotokoll
T1: select * from book where bookkey = B4
T2: update book set author = ‘ Hugo‘ where price < 20.00
T1
IS
T2 IX
T1
IS
T2 IX
Root
DB: bookstore
T1
index:
book price
T2 IX
T1
S
IS
T2 IX
table: book
row: B4
T2 X
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-21
Isolation für XML-Verarbeitung:
DGLOCK – erweitertes DAG-Sperrprotokoll
z
Striktes Zwei-Phasen-Sperrprotokoll (auf der XML-Ebene)
–
–
z
Effizienter Konflikttest
–
–
z
XML-Dokumente sind Baumstrukturen
DAG-Sperrprotokoll also anwendbar
Überprüfung für alle Anfragepaare skaliert schlecht
Sperren der XML-Baumstrukturen nicht möglich, da Struktur nicht explizit
Zusammenfassung der XML-Struktur besser geeignet: bspw. DataGuide
store
auction
store
auction
auction
description
Floppy
disk
price
5.20
description
PC
Pentium
price
4711.00
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
description
price
10-22
DGLOCK-Protokoll
z
Verwendung des DataGuide zum Sperren
z
DAG-Sperrprotokoll auf dem DataGuide einsetzen
–
–
z
Problematik dieses Vorgehens:
–
–
–
–
z
DataGuide ist hierarchisch bei einem Wald von XML-Dokumentbäumen
DataGuide kann mehrere Wurzeln haben
DAG-Sperren auf dem DataGuide sperren auf der Schemaebene
Sperrgranularität ist zu gross
Es werden nur Pfadausdrücke beim Sperren berücksichtigt
Prädikate über Dokumentinhalte sollen berücksichtigt werden
Lösung:
–
–
–
Annotation der Sperren mit einfachen Prädikaten (x θ const)
Effiziente Implementierung mittels Bitstring-Signaturen
Bitoperationen auf Signaturen prüfen Überlappung der Prädikate
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-23
Beispiel zu DGLOCK
T1 Update: /store/auction/price[. < .5]
T2 Retrieve: /store/auction[./price > 42]/description
DGLOCK Kommutativitätsmatrix
T1 IX
T2 IS
T1 IX
T2 IS
auction
Requested None IS
...
IX
S
SIX
X
IS
+
+
+
+
+
P
IX
+
+
+
P
P
P
S
+
+
P
+
P
P
SIX
+
+
P
P
P
P
X
+
P
P
P
P
P
price
description
T2 IS
Granted
store
T1
X: price < .5
T2
S: price > 42
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
Höhere Parallelität
Bessere Performanz
10-24
Atomarität: Recovery Manager für mehrschichtige
Transaktionsverwaltung für XML
z
Kompensation der Effekte nicht erfolgreich abgeschlossener XMLTransaktionen
–
–
DB-Transaktionen der XML-Services sind evtl. schon committed
Lösung: Inverse Operationen dieser DB-Transaktionen durchführen
z
Zusätzliches Logging (Protokollieren) nötig
z
Ablauf der Recovery im Fehlerfall
–
–
–
–
Start am Ende des Logs
Lesen des Logs, um die nicht erfolgreich abgeschlossenen Transaktionen zu
bestimmen
Durchführen der inversen Operationen (in umgekehrter Reihenfolge der
Vorwärtsoperationen)
Ausführung der inversen Operationen durchläuft wie die Vorwärtsoperationen
die Concurrency Control, das Logging etc.
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-25
Atomarität: Recovery Manager für mehrschichtige
Transaktionsverwaltung für XML
BOT, EOT
store
XML Update
auction
TM für XML
description
Flop
py
disk
auction
price
5.20
description
PC
Pent
ium
price
4711.00
price
4711.00
transactionlog
txn
4711
4712
4711
flag
BOT
BOT
EOT
xmllog
txn
4711
4711
4712
4711
4711
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
lsn
511
512
513
514
515
docid
D13
D24
D344
D500
D500
compensate info
/a/bid[…]
//b/person
/a/bid[…]
/t/auction
/t/auction
10-26
Zusammenfassung
z
Bei XML-Datenbeständen auch Bedarf an Änderungsoperationen
–
Anfragesprache XQuery um deklarative Änderungsoperationen erweitert
z
Korrektes, paralleles, fehlertolerantes Abarbeiten von Anfragen und
Änderungen auf gemeinsamen Daten erfordert Transaktionen
z
Problematik klassischer („flacher“) Transaktionsmanager von
Datenbanksystemen bei XML-Verarbeitung
–
–
–
–
z
Sperrgranularität nicht auf XML und die Dokumentstruktur abgestimmt
Keine Ausnutzung der Semantik
Unnötige Sperrkonflikte
Schlechte Performanz der Ansätze
Neue Techniken für die Transaktionsverwaltung benötigt im
Zusammenhang mit XML
–
–
Datenmodell von XML und Semantik der Operationen im Scheduler ausnutzen
Dadurch bessere Sperrgranularität und höhere Performanz
Vorlesung "XML und Datenbanken" - WS 2004/2005 (Dr. C. Türker)
10-27