arbeitsgruppen-vorstellung fachgebiet electronic commerce und datenbanken prof. dr. stefan böttcher...

Arbeitsgruppen-VorstellungArbeitsgruppen-Vorstellung

Fachgebiet Electronic Commerce und DatenbankenFachgebiet Electronic Commerce und DatenbankenProf. Dr. Stefan BöttcherProf. Dr. Stefan Böttcher

Sebastian Obermeier Universität Paderborn

November 2005

AG-Vorstellung Sebastian Obermeier – University of Paderborn (Germany) Slide 2/17

Transaction Atomic Commit Caching of XML database content

Research Focus: Mobile NetworksResearch Focus: Mobile Networks

Caching in Mobile Networks

Transaction Atomic Commit for Distributed Transactions

Mobile Networks



BegriffeBegriffe

Verteilte Datenbank

Verteilte Transaktion Atomizität Serialisierbarkeit

2-Phasen-Commit

Kompensation

Mobile Ad-Hoc Netzwerk

TT1

T3

T2

nöö

ok

ok

rL(y) rL(z) wL(z) cL

DB1: r1(x) c1 r2(x) w2(x) c2

DB2: r1(y) w1(y) c1 r2(z) c2

t2 tL t1



BegriffeBegriffe

DB1 CoordinatorDBn

All votes

arrived

...canCommit?

Vote: commit

Vote: commit

doCommit!

Verteilte Datenbank

Verteilte Transaktion Atomizität Serialisierbarkeit

2-Phasen-Commit

Kompensation

Mobile Ad-Hoc Netzwerk



2-Army-Problem2-Army-Problem

A: General Alexander, B: General Bonaparte

A -> B: “Hey Bona, Angriff im Morgengrauen”

B -> A: “Gute Idee, Al, bis morgen”

A erhält Nachricht, stellt fest: “Bonaparte weiss ja gar nicht ob ich diese Nachricht erhalten habe” und traut sich nicht anzugreifen

Deshalb: Nachricht von A, dass die Bestätigung angekommen ist.

B erhält die Nachricht und denkt: ”Alexander weiss ja gar nicht, ob ich diese Nachricht erhalten habe” und traut sich nicht anzugreifen

Deshalb: Nachricht von B,…

Sogar wenn kein Nachrichtenverlust auftritt, ist das Problem unlösbar

A B



Problems for Transaction Atomic CommitProblems for Transaction Atomic Commit

- Compensation difficult due to network partitioning

- Duration of execution-phases may differ in a mobile context- Block databases after vote

long blocking times risk of infinite blocking high number of aborts

- Sub-transactions are not known in advance (web-services)

Vote Commit

Vote Commit

Vote Commit

Vote Commit

Vote Commit

Vote Commit

Vote Commit

Compen-sate!



Requirements for MaNet commit protocolsRequirements for MaNet commit protocols

Continues working correctly if single commit coordinator fails

Correctness in spite of network partitioning

Reduce blocking behavior compared to standard protocols (e.g. 2PC)

DB1 CoordinatorDBn

All votes

arrived

...canCommit?

Vote: commit

Vote: commit

doCommit!



Current Research: Transaction Atomic CommitCurrent Research: Transaction Atomic Commit

+ Suspend state reduces blocking time:+ After sub-transaction is ready to vote,

DB still controls resources Non blocking state

+ Reduce aborts due to conflicting concurrent transactions + Repeatable sub-transactions + Reusable sub-transactions

+ Identify all dynamically invoked sub-transactions ( web-services)

+ Use multiple coordinators

DB1 CoordinatorDBn...readyToVoteCommit?

ready

ready

canCommit?VoteCommit

Commit!abort

repeat

reuse

Frage: Blockierungs-Reduzierung

höherer Transaktions-durchsatz?

Frage: Blockierungs-Reduzierung

höherer Transaktions-durchsatz?



Coordinator failureCoordinator failure

Ist der Koordinator ausgefallen? Wie finden wir einen neuen Koordinator? Wie behandeln wir Netzwerkpartitionierung?

) Commit Protocol for Mobile Databases

C

D2 D3D1

ME! ME!

??

New C

D2 & D3 failedCommi

t

Abort

D3



Commit Protocol for Mobile DatabasesCommit Protocol for Mobile Databases

Initiator DB Coordinators Main-Coordinator

transaction

vote: commit

votes of DB_n...m

prepare: forward commit

acknowledgment

commit valid

doCommit

Cluster of Coordinators

result

Majority

Ist Suspend in unserem Protokoll „nützlich“? Verbessert „Suspend“

Transaktions-Durchsatz?

Abort!Suspend!

Need Vote of DB3

Abort!

Suspend!

Verringerung von aborts durch Suspend?

Simulation und Messergebnisse

2 Phases



Caching-Problem in Mobile Ad-Hoc NetworksCaching-Problem in Mobile Ad-Hoc Networks

Assumptions XML-content (blogs,

…) (Un-) popular queries Devices are egoistic Devices participate if

network becomes faster

Bottlenecks: Network bandwidth Battery power Multi-hop-distance… used for transferral of

query results



Motivation: mobile BlogosphäreMotivation: mobile Blogosphäre

B

B

B

B

B

B

<Blog> <Blogentry> <Date> 26.10.2005 </Date> <Type> newscommentary </Type> <Heading> Killer-Hurrikan </Heading> <Text> … </Text> <Picture> 94lj9jjkerl934jkwj… </Picture> <Video> 08w3ljsf9ouewrljsdf… </Video> …

</Blogentry>

<Author> <Name>Hans </Name> <Location> Paderborn </Location> …</Author>

Mobile, fehleranfällige Geräte Jeder darf Blogeinträge

anbieten Jeder ist Teil der gesamten

Blogosphäre Jeder kann bestimmte Menge

Daten cachen Strukturierte Daten, Schema

groß aber fest Art der Queries weitgehend

ähnlich Neue Blogeinträge kommen

hinzu, aber selten Veränderung von alten Einträgen

Unterschiedliche Beliebtheitsgrade Bildblog beliebt,

Vorlesungsblogs beliebt, Dekan-Blog unbeliebt

Routing teuer Keine Security-Betrachtungen



ProblemeProbleme

Probleme / Aufgaben Modelle für mobile Anwendungen (Blogosphäre)

Wie sehen (realistische?) verteilte Modelle aus?Simulation der Modelle

QueryingWie können (verteilte) Querymechanismen aussehen?

Caching Welche, auf dem Querymechanismus aufbauenden,

Cachemechanismen gibt es?Welches Einsparpotential / Geschwindigkeitssteigerungen/

Verbesserung der Qualität ergibt sich?

Vergleich von verschiedenen Query- und Cachestrategien in unterschiedlichen Modellen

B

B

B



Research: Semantic-CachingResearch: Semantic-Caching

DB

1

Key IP Segments

Job DB All

Job 1 S1; S4

Job 2 S5; S6

Lookup

Query

S1 & S4

Key-Based Routing

JobS1 S3

S4

S2

S6

S5

Segmentierung

S1S4

To: “JobLookup“

2

Segmentierungstechnik Erstellen „guter“

Segmentierung Overhead (Dynamische) Anpassung an

Queries / Anfrageprofile „versionierte“ Segmentierung

Datenverteilungsstrategien Lookup-Mechanismen

Lookup-Caching „Spinnennetz“-Caching



Research: Spinnennetz-CachingResearch: Spinnennetz-Caching

Verteilung von Daten? Information,

wo Daten sind?

Simulation Alternative Strategien Universeller Simulator

DB

1

Key IP Segments

Job 1 S1; S4

QueryS1 & S4

S1S4

2

3

Weitergehende Probleme

• DB-Updates

• Verschwinden von Caches

• Bewegung der Lookup-Nodes

Weitergehende Probleme

• DB-Updates

• Verschwinden von Caches

• Bewegung der Lookup-Nodes



Andere Ideen ???Andere Ideen ???

DB

1Query

S1 & S4

S1S4

Result



Summary: Research on Mobile NetworksSummary: Research on Mobile Networks

Caching

Mobile Networks

AuAu1 Au3

Au4

Au2

Au6

Au5

Atomic commit for distributed transactions

DB1 CoordinatorDBn...readyToVoteCommit?

ready

ready

canCommit?VoteCommit

Commit!abortrepeat

reuse

Further questions?

Thank you for your attention!Thank you for your attention!



Szenario: ad-hoc SensornetzwerkeSzenario: ad-hoc Sensornetzwerke

Sensor generiert laufend Daten Sensoren fehleranfällig

Redundanter Einsatz Senden gemessener Daten an

Interessenten Möglichkeiten zum

Routing / Aggregation der Daten etc. weitgehend erforscht

Problem: viel Routing, viel Energieverbrauch



Szenario: ad-hoc SensornetzwerkeSzenario: ad-hoc Sensornetzwerke

Idee: verteilte Datenbanken innerhalb des Netzwerkes aggregrieren und speichern Daten Kürzere Wege,

weniger Routing

Ziel: Erfassung von Ausreissern, Beantwortung von Queries



SegmentierungSegmentierung

Gegeben verschiedene „Anwendungen“ (DTD, Schemata) Zugehörige (Nonsens-) Daten Sequenz von Queries

( Beliebtheitswerte der Queries) Gesucht

Dynamischer Segmentierungsmechanismus basierend auf

DTD Queryverhalten Gewünschter Fragmentmenge

Funktion zur Erkennung benötigter Segmente Messung, dass Mechanismus gut ist

im Anwendungsszenario: Vergleich mit direktem Querying

Weitergehende Untersuchungen redundante Segmentierung

Keine disjunkten Segmente Kann DB Segmente „on-the-fly“ aus Queryantwort

mit geringem Overhead generieren?

JobS1 S3

S4

S2

S6

S5

Segmentierung



BlogbeispielBlogbeispiel

Tagebuch Aktuelle Ereignisse Bilder, Audio, Video Kommentare

arbeitsgruppen-vorstellung fachgebiet electronic commerce und datenbanken prof. dr. stefan böttcher...

Documents