53
4-1 4. Replikation und Synchronisation

4. Replikation und Synchronisation

  • Upload
    esben

  • View
    56

  • Download
    0

Embed Size (px)

DESCRIPTION

4. Replikation und Synchronisation. 4. Replikation und Synchronisation Gliederung. 4.1 Motivation 4.2 Replikation 4.3 Synchronisation 4.4 Klassische Verfahren 4.5 Neue mobile Verfahren 4.6 SyncML (Synchronization Markup Language) 4.7 Zusammenfassung. 4.1 Motivation. - PowerPoint PPT Presentation

Citation preview

Page 1: 4. Replikation und Synchronisation

4-1

4. Replikation und Synchronisation

Page 2: 4. Replikation und Synchronisation

4-2

4. Replikation und SynchronisationGliederung

4.1 Motivation

4.2 Replikation

4.3 Synchronisation

4.4 Klassische Verfahren

4.5 Neue mobile Verfahren

4.6 SyncML (Synchronization Markup Language)

4.7 Zusammenfassung

Page 3: 4. Replikation und Synchronisation

4-3

4.1 Motivation

• Was ist Replikation?

– Ziel: Daten sollen in Offline-Phasen unabhängig auf einem Client bearbeitet werden können

– Replikation bezeichnet das Anlegen einer Kopie und damit die Einführung von Datenredundanz

– Daten werden dadurch auf mobilen Clients verfügbaroft auch nur Teile (Selektion, Projektion) der urspüngl. Relation(-> Nachforderungen, schwieriger Wiederabgleich)

Relation

Selektion

Projektion

Page 4: 4. Replikation und Synchronisation

4-4

Motivation

• Was ist Synchronisation?

– Auf den Clients geänderte Daten sollen wieder auf den Server rückübertragen werden

– Probleme entstehen, wenn auch dort die Daten zwischenzeitlich geändert wurden

– Ziel: Datenkonsistenz innerhalb einer Replikationsumgebung, da Inkonsistenzen zu schwerwiegenden Fehlern führen können

– Bei der Synchronisation werden die geänderten Daten nach bestimmten Verfahren (meistens konventionell, zeitstempelbasiert oder semantisch) abgeglichen

Replikation und Synchronisation sind wichtige Grundlagen für Offline-Szenarien

Page 5: 4. Replikation und Synchronisation

4-5

4.2 Replikation 4.2.1 Ursprung

• Ursprung der Replikation:– Ursprung in den verteilten Systemen und in den verteilten

Datenbanksystemen

– Verteilte, nichtreplizierende (DB-)Systeme sind wesentlich anfälliger für Ausfälle im Gegensatz zu zentralistisch ausgelegten Systemen

– Um Ausfall von einem Knoten zu kompensieren, werden wichtige Daten redundant auf mehreren Knoten abgespeichert

– Auch Daten mit hohen Zugriffsraten werden auf mehrere Knoten verteilt

– Alle Knoten die replizierte Daten enthalten bilden zusammen dieReplikationsumgebung

Page 6: 4. Replikation und Synchronisation

4-6

4.2.2 Vorteile von Replikation

• Vorteile:– Höhere Verfügbarkeit durch Verteilung der Daten auf mehrere Knoten

– Niedrigere Kommunikationskosten

– Bessere Performanz durch lokalen Zugriff

– Ermöglicht Lastverteilung (Zugriff auf Knoten mit geringster Last)

– Vorbeugung gegenüber Datenverlust

– Replikation ist Grundlage für das Arbeiten mit Clients, die sich im Disconnected Mode befinden

Suche nach intelligenten Verfahren zur Auswahl der zu replizierenden Daten

Page 7: 4. Replikation und Synchronisation

4-7

4.2.3 Was ist ein Replikat?

• Definition– Ein Replikat ist eine Kopie, also eine redundante Speicherung

eines bereits existierenden Datenelements

– Datenelement kann ein Tupel, eine Relation, Teile einer Relation oder eine ganze Datenpartition sein

– Per se gibt es kein Originalelement, dieses kann aber bei Bedarf festgelegt werden

– Es können beliebig viele Kopien existieren

Page 8: 4. Replikation und Synchronisation

4-8

4.2.4 Zentrale Strategien beim Einsatzder Replikation

Übersicht:

• Kopie-Update-Strategien

• Fehlerbehandlungs-Strategien

• Synchronisations-Strategien konkurrierender Zugriffe

• Konsistenz-Strategien bei Lesetransaktionen

Page 9: 4. Replikation und Synchronisation

4-9

Zentrale Strategien beim Einsatzder Replikation

• Kopie-Update-Strategien: – Datenoperationen werden auf einem einzelnen Replikat ausgeführt

– Die daraus resultierenden Änderungen werden auf 2 verschiedene Arten an die anderen Kopien weitergegeben

• Wenn alle Replikate gleichzeitig aktualisiert werden, spricht man von Eager Replication

• Wenn die Änderung asynchron an die anderen Replikate weitergegeben wird, spricht man von Lazy Replication

– Die Erlaubnis zur Änderung ist oft an spezifische Bedingungen geknüpft und hängt oft von den anderen Kopien des Replikats ab (z.B. Quorum-Verfahren)

Page 10: 4. Replikation und Synchronisation

4-10

Zentrale Strategien beim Einsatzder Replikation

• Fehlerbehandlungsstrategien:– Enthält Methoden, mit denen auf Fehlersituationen während der

Replikation reagiert wird

– Repräsentiert den Ausnahmefall gegenüber den durch die Kopie-Update-Strategien abgedeckten Normalfall

– Häufigste Fehlersituation sind typische Netzpartitionierungen, wenn also Clients dauerhaft vom Gesamtsystem getrennt werden

– In mobilen Umgebungen aber Netzpartitionierungen Normalfall, deshalb hat die „Fehlerbehandlung“ eine wichtige Rolle (Begriff „Fehlerbehandlung“ in diesem Zusammenhang fraglich)

Page 11: 4. Replikation und Synchronisation

4-11

Zentrale Strategien beim Einsatzder Replikation

• Synchronisation konkurrierender Zugriffe– Wichtig sind Methoden zur Konsistenzsicherung innerhalb einer

Replikationsumgebung

– Aufgabe: Eine geeignete Serialisierbarkeitsreihenfolge (Schedule) finden, damit bei allen Replikaten während allen Transaktionen keine Konsistenzkonflikte entstehen

– 3 Synchronisationsverfahren:• konventionell (mit Einsatz von Sperren), • optimistisch (zeitstempelbasiert, read-set, write-set)• semantisch (Einbeziehung von speziellem Anwendungswissen)

Page 12: 4. Replikation und Synchronisation

4-12

Zentrale Strategien beim Einsatzder Replikation

• Konsistenzstrategien:3 verschiedene Konsistenzgrade bei Lese-TAs:

Replikate sind • aktuell und konsistent

negativ für Gesamtdurchsatz, kein disconnected Mode

• Konsistent, aber dürfen etwas veraltet sein. Durch Versionskonzept können Lese- und Änderungstransaktionen parallel ablaufen

• innerhalb bestimmter Toleranzgrenzen inkonsistent. Die Toleranzgrenze bestimmt die maximal erlaubte Abweichung vom aktuellen, konsistenten Datenbankzustand

Page 13: 4. Replikation und Synchronisation

4-13

4.2.5 Replikationsdefinition

• Wichtigste Aufgabe der Replikation ist die Replikationsdefinition. Sie wird in 2 Subaufgaben gegliedert:

– Replikationsschemadefinition: • Definiert den Ausschnitt des Datenbankschemas auf der

Replikationsquelle, der für die Datenreplikation genutzt wird, und• die Operationen, die auf den replizierten Daten ausgeführt werden

dürfen, • sowie zusätzliche Integritätsbedingungen

– Replikatdefinition:• Wählt die zu replizierenden Daten aus (Selektionsbedingungen)• Ausgewählt werden können alle Daten, die dem Replikationsschema

genügen• Neben Daten werden auch Integritätsbedingungen auf die Senke

übertragen

Page 14: 4. Replikation und Synchronisation

4-14

4.2.6 Forderungen

• Weitere Forderungen in der Replikationsumgebung:

– Replikationstransparenz: Der Benutzer merkt von unter- schiedlichen Kopien nichts

– 1-Kopie-Serialisierbarkeit: Es gibt mind. einen Schedule, welcher mit seriellen Transaktionen auf einer Datenbank ohne Replikate den gleichen Endzustand erzeugt

– Replikationskorrektheit: Änderungen auf einer Kopie sind auf allen anderen Kopien nachziehbar: alle redundanten Kopien sind konsistent. Entweder streng korrekt (Identität) oder innerhalb bestimmter Grenzen ( Konsistenzgrade)

Page 15: 4. Replikation und Synchronisation

4-15

4.2.7 Zielkonflikt der Replikation

• 3 verschiedene Forderungen an die Replikation1. Erhöhung der Verfügbarkeit2. Konsistenz aller Kopien3. Niedrige Kosten der Replikation

• Konflikt: – Replikation wird oft eingesetzt um die Verfügbarkeit zu erhöhen– Je mehr Senken, desto mehr Daten müssen konsistent gehalten

werden– Dadurch steigen mit der Zahl der Senken die Kosten

• Konsequenz:– Alle 3 Forderung sind nie zu erreichen– Je näher man 2 Forderungen kommt, desto mehr entfernt man sich

von der 3.

Zielkonflikt derReplikation

Verfügbarkeit

KostenKonsistenz

Page 16: 4. Replikation und Synchronisation

4-16

4.3 Synchronisation

• Ziel: konsistenter Zustand aller Kopien innerhalb einer Replikationsumgebung

• Bei Synchronisation müssen Änderungen von der Replikationssenke auf die Quelle und umgekehrt übertragen werden

- Reintegration: Abgleich der geänderten Daten von Senke auf Quelle

- Rückübertragung: Quelle überträgt aktuellen + konsistenten Datenzustand auf die Senke

- Beide Phasen: Bidirektionale Synchronisation

- Eine Phase: unidirektionale Synchronisation

Page 17: 4. Replikation und Synchronisation

4-17

4.4 Klassische Replikations- und Synchronisationsverfahren

• Die wichtigsten Replikations- und Synchronisationsverfahren:

1. Konsistenzerhaltende Verfahren • Pessimistische Verfahren (ROWA, Primary-Copy-Verfahren, Quorum, ...)• Optimistische Verfahren (Log-Transformation, Data-Patch-Verfahren)

2. Verfügbarkeitserhaltende Verfahren• Epsilon-Serialisierbarkeit• Quasi-Copy-Verfahren

3. Data Caching (Replikation innerhalb der Speicherhierarchie)

4. Data Hoarding (gezieltes Nachladen vom Server)

Page 18: 4. Replikation und Synchronisation

4-18

4.4.1 Konsistenzerhaltende Verfahren

• Eigenschaften der konsistenzerhaltenden Verfahren– Hauptziel: Strikte Durchsetzung der Konsistenz

(oft auf Kosten der Verfügbarkeit)– Unterteilt in pessimistische und optimistische Verfahren– Pessimistische Verfahren:

• verwenden Sperren um von vorneherein alle möglichen Inkonsistenzen zu verhindern

• Änderungen können gleichzeitig (2-Phasen-Commit-Protokoll) (eager Repl.) oder asynchron (lazy Repl.) mit gesonderten Update-Aktionen durchgeführt werden

• Vorteil bei asynchronen Updates: keine systemübergreifende Sperren

– Optimistische Verfahren: • Gehen von seltenen Inkonsistenzen aus und verwenden deshalb keine

Sperren• Nach jeder Transaktion findet Validierung statt, ob ein inkonsistenter

Zustand vorliegt

Page 19: 4. Replikation und Synchronisation

4-19

Pessimistische Verfahren- ROWA -

• ROWA (Read One Write All):– Innerhalb einer Änderungstransaktion alle Kopien updaten

(verwendet 2-Phasen-Commit-Protokoll)

– Alle Kopien eines Replikats sind deshalb stets konsistent

– Lesetransaktionen bekommen so auch keine veralteten Daten

– Erreichbarkeit aller Kopien muss gegeben sein• deshalb in mobiler Umgebung so nicht einsetzbar, da viele mobile

Clients sich im Disconnected Mode befinden• Es exisiteren Varianten des ROWA-Verfahrens, die aber keine

sinnvolle Lösungen für den Einsatz in mobilen Umgebungen sind, z.b. Write-All-Available oder Missing-Update

Page 20: 4. Replikation und Synchronisation

4-20

Pessimistische Verfahren- Primary-Copy Verfahren -

• Primary-Copy-Verfahren:– Änderungstransaktion wird erst auf einer Masterkopie durchgeführt– Für die asynchrone Aktualisierung ist nun nicht mehr die

Änderungstransaktion selbst, sondern die Masterkopie zuständig– Stark zentralistisches Verfahren (Gleichheit aller Knoten wird aufgegeben)

– Vorteil:• In mobiler Umgebung möglich, dann darf sich aber die Masterkopie nicht auf

einem Client befinden, sondern auf stationärem Knoten

– Nachteil:• Bei Änderungstransaktionen muss eine Netzwerkverbindung bestehen

• Bei Transaktionen mit vielen Updates kann der Knoten der Masterkopie zu einem Hot-Spot werden

• Die Wahrscheinlichkeit, dass keine Netzwerkverbindung für eine Änderungstransaktion besteht, steigt mit jedem Knoten

Abhilfe: Virtual-Primary-Copy-Verfahren (siehe später)

Page 21: 4. Replikation und Synchronisation

4-21

Pessimistische Verfahren- Quorum Verfahren -

• Quorum-Verfahren:– Abstimmung entscheiden ob Aktualisierung durchgeführt wird– Jede Kopie besitzt eine Anzahl von Stimmen (meistens 1)– Um Aktualisierung durchzuführen muss die Transaktion die

Mehrheit der Stimmen gewinnen (Majority Consensus)– Transaktion gewinnt eine Stimme wenn eine Kopie durch diese

Transaktion gesperrt werden kann– Konkurrierendes Schreiben wird verhindert wenn

Schreibquorum > n/2 (Anzahl der Stimmen)– Konkurrierendes Lesen und Schreiben wird verhindert, wenn

Lese- + Schreibquorum > n

– Randfall: Schreibquorum=n und Lesequ=1 dann ROWA-Verfahren

Page 22: 4. Replikation und Synchronisation

4-22

Pessimistische Verfahren- Quorum Verfahren -

• Quorum-Verfahren Teil II:– Variante: Einführung von Stimmgewichten

– Variante: Einführung von Zeugen (Stellvertreter-Knoten)

– Wenn Mehrheiten fest vergeben, dann spricht man von statischem Quorum-Verfahren

– Wenn zur Laufzeit vergeben, spricht man von dynamischen Quorum-Verfahren (z.B. zum Zeitpunkt verfügbarer Stimmen)

– (nur bedingt) in der mobilen Umgebung einsetzbar:• Für Änderungstransaktion muss Verbindung zur Basisstation verfügbar

sein. Diese muss dann das Quorum der anderen Kopien einholen• Nur mindestens |Qw| Knoten müssen während Abstimmung online sein. • Für Commit eigentlich alle, Nachziehen auf offline Knoten? Sperren

halten? (Unwahrscheinlich, dass kein Client im Disconnected Mode)

Page 23: 4. Replikation und Synchronisation

4-23

Optimistische Verfahren

• Eigenschaften: – Keine Sperren, dafür wird am Ende jeder Transaktion validiert, ob

konsistenter Zustand vorliegt (mittels Zeitstempel)

– Propagation durchgeführter Änderungen erfolgt dann asynchron

– Späteres Wiedereinbringen von Daten kann zu Konflikte führen (z.B. Änderungen auf einen bereits alten Datensatz)

– Häufig werden diese Konflikte durch semantisches Wissen aufgelöst (z.B. summierende Verfahren, „neueste Info zählt“…)

– Die 2 wichtigsten Verfahren sind • Log-Transformation und das • Data-Patch-Verfahren

Page 24: 4. Replikation und Synchronisation

4-24

Optimistische Verfahren- Log-Transformation -

• Log-Transformation:– Änderungen einer (mobilen) Kopie werden

zuerst auf der zentralen Datenbank nachgezogen, dann an die anderen Kopien asynchron weitergegeben

– Alle Transaktionen werden in Logbuch-Einträgen protokolliert

– Bei Konflikten wird die konfliktauslösende Transaktion zurückgesetzt

– Einfaches Auflösen von Konflikten, aber umfangreiches oder kaskadierendes Zurücksetzten kompletter Transaktionen möglich

Page 25: 4. Replikation und Synchronisation

4-25

Optimistische Verfahren- Data Patch -

• Data-Patch Verfahren– Es gibt kein Zurücksetzen von TAs

denn bereits beim Datenbankentwurf werden anwendungsbezogene Regeln festgelegt

– Diese Regeln legen fest, wie aus 2 verschiedenen Versionen ein neuer konsistenter Zustand wird (z.B. neueste Info zählt, Aufaddieren, Chef hat immer recht, ...)

– Data-Patch-Verfahren kann gut in mobilen Umgebungen eingesetzt werden

– Dieses Verfahren kann sowohl den konsistenz- als auch den verfügbarkeitserhaltenden Verfahren zugeordnet werden

Page 26: 4. Replikation und Synchronisation

4-26

4.4.2 Verfügbarkeitserhaltende Verfahren

• Eigenschaften verfügbarkeitserhaltender Verfahren– Im Gegensatz zu den konsistenzerhaltenden Verfahren steht hier

die höhere (Lese-) Verfügbarkeit von Daten im Mittelpunkt

– Dies wird dadurch erreicht, dass in bestimmten Situationen inkonsistente Daten geduldet werden

– Konflikte werden oft durch semantisches Wissen aufgelöst(z.B. summierende Verfahren, Prioritätsverfahren oder „neueste-Info-zählt“-Verfahren)

– Werden keine Abweichungen toleriert, kann wieder von konsistenzerhaltenden Verfahren gesprochen werden

Page 27: 4. Replikation und Synchronisation

4-27

Verfügbarkeitserhaltende Verfahren

• Beispiele für verfügbarkeitserhaltende Verfahren:

– Epsilon-Serialisierbarkeit: • globaler Faktor Epsilon bestimmt tolerierbare Abweichung gegenüber

bestimmten Konsistenzzustand• Jedes Replikat hält selbst sein aktuelles Epsilon fest• Lesezugriff auch auf epsilon-inkonsistente Replikate möglich

höhere Verfügbarkeit

– Quasi-Copy-Verfahren:• Ähnlich zur Epsilon-Serialisierbarkeit aber jetzt

– Anzahl Änderungen auf lokaler Kopie – oder Zeitspanne ausschlaggebend,

nicht eine bestimmte Abweichung

Page 28: 4. Replikation und Synchronisation

4-28

Was bisher war

• Definition der Begriffe Replikation und Synchronisation

– Ursprung und die Vorteile der Replikation

– 4 Zentralen Strategien beim Einsatz der Replikation

– Zielkonflikt der Replikation

• Beispiele für konstistenzerhaltende Verfahren– 3 pessimistische Verfahren – 2 optimistische Verfahren

• 2 Beispiele für verfügbarkeitserhaltende Verfahren

Page 29: 4. Replikation und Synchronisation

4-29

Was kommt

• Data Caching und Data Hoarding Verfahren

• Verzicht auf Replikation

• Beispiele für neue mobile Verfahren

• Synchronization Markup Language (SyncML)

Page 30: 4. Replikation und Synchronisation

4-30

4.4.3 Data Caching

• Data Caching: (Replikation innerhalb der Speicherhierarchie)

– Zugriff auf Daten wird stark beschleunigt, wenn die Daten schon im Cache sind. Deshalb bevorzugte Speicherung im Cache

– Intelligente und vorrausschauende Verfahren gesucht, damit Daten mit hohen Zugriffsraten im Cache sind oder/und bleiben

– Da bei mobilen Clients der Cache bisher recht klein ist, sind solche intelligenten Verfahren sehr wichtig

– Eine Variante ist das semantische Cachen. Es werden zusätzlich Beschreibungen der Daten gespeichert, damit intelligente Einlagerungsstrategien implementiert werden können (Nachteil: Speicherplatzbedarf steigt)

Page 31: 4. Replikation und Synchronisation

4-31

Data Caching

– Cachen heißt zusätzliche Redundanzebene:

– Bei Synchronisation: Cache-Kohärenz sicherstellen!Damit nicht mit alten Cache-Werten weitergearbeitet wird.

– Mobile Endgeräte:Vorab-Cache-Einlagerungen (Prefetching)

• Nicht nur zugriffs- und zeitabhängig• auch ortsabhängig (bei Standortwechsel des Nutzers)

Page 32: 4. Replikation und Synchronisation

4-32

4.4.4 Data Hoarding

• Data Hoarding: (gezieltes, vorausschauendes Nachladen vom Server)

– Besondere Variante des Prefetchings bei Caches, speziell für die mobile Umgebung

– Datenaustausch zwischen Server und Client nur an speziellen Infostationen

– Die Infostationen sind mit WLANs ausgestattete Terminals, die untereinander mit Hochgeschwindigkeitsnetzwerk verbunden sind

– Gerade dort eingesetzt, wo Benutzer keine eigenen Clients, sondern nur anwendungsspezifische Clients haben (z.B. Museum)

Page 33: 4. Replikation und Synchronisation

4-33

Data Hoarding

– Spezieller Proxy-Server koordiniert sämtliche Hoarding-Prozesse:

• Schritt 1: Drahtloser Download der wahrscheinlich benötigten Informationen

• Schritt 2: Trennung der Verbindung zur Infostation• Schritt 3: Gelegentliche Übertragung des protokollierten

Nutzerverhaltens an erreichbare Infostationen bei Bedarf: Nachladen

Page 34: 4. Replikation und Synchronisation

4-34

4.4.5 Verzicht auf Replikation

• Verzicht auf Replikation:– Nur möglich, wenn eine zuverlässige und hochverfügbare

Infrastruktur drahtloser Netzwerktechnologien vorhanden ist (z.B. firmeninternes WLAN)

– Zentrale Datenhaltung und eine Schnittstelle für drahtlosen Online-Zugriff anzubieten kann einfacher sein als Offline-Szenarien mit komplizierter Replikation und Synchronisation

Page 35: 4. Replikation und Synchronisation

4-35

4.5 Neue mobile Verfahren

• Eigenschaften:

– Pessimistische Verfahren sind schlecht einsetzbar, da sie auf dem Einsatz von Sperren basieren.Sperren können aber sehr kritisch sein, falls ein Client eine Sperre setzt und in den Disconnected Mode wechselt und dort lange bleibt

– Grundlage sind die optimistischen Verfahren

– Trotzdem wurden auch pessimistische Verfahren entwickelt, Beispiel dafür ist das Virtual-Primary-Copy-Verfahren

Page 36: 4. Replikation und Synchronisation

4-36

Neue mobile Verfahren1. Virtual-Primary-Copy

• Virtual Primary Copy:

– Virtual-Primary-Copy ist eine Variante des Primary-Copy Verfahren

– Basiert auf den konsistenzerhaltenden, pessimistischen Verfahren

– Masterkopie jetzt immer auf dem mobilen Client (!), zusätzlich noch eine virtuelle Masterkopie (Position frei wählbar, meist im Festnetz)

– Falls nun Masterkopie für andere Clients nicht erreichbar ist, können die anderen Clients ihre Änderungstransaktion auf der virtuellen Masterkopie durchführen

– Sobald wieder online muss ein Abgleich beider Kopien erfolgen, damit ein konsistenter Zustand vorliegt

Page 37: 4. Replikation und Synchronisation

4-37

Neue mobile Verfahren 2. Snapshot-Verfahren

• Snapshot-Verfahren:

– Sehr gut einsetzbar in mobilen Umgebungen– Snapshots sind materialisierte Sichten nichtlokaler Datenbestände– Snapshots basiert auf einer Originaltabelle, auch Mastertabelle

genannt– Snapshots können einzelnen Tupel bis hin zu kompletten

Relationen sein– Replikationsserver werden als Master-Sites, mobile Clients als

Snapshot-Sites bezeichnet– Kommunikation kann synchron (verbindungsorientiert)

oder asynchron (dateibasiert) erfolgen– Synchronisation kann als Abgleich von Snapshots aufgefasst

werden

Page 38: 4. Replikation und Synchronisation

4-38

Neue mobile Verfahren - Snapshot-Verfahren -

• Publish & Subscribe-Modell:Der Server bietet Publikationen an, der Client subscribiert sie – Publikationen = { Publikationsartikel* }

– Publikationsartikel = Snapshot beliebiger Granularität,z.b. durch SQL-Anweisung definiert

– Zuordnung von Publikationen (Snapshots) zu mobilen Clients erfolgt anhand von Subskriptionen (auch parametrisierbar)

Subskription = Zuordnung Replikationsquelle zu Senke

Page 39: 4. Replikation und Synchronisation

4-39

Neue mobile Verfahren - Snapshot-Verfahren -

• Einfache vs. Komplexe Snapshots (vgl. View-Update Problem)

– Einfache Snapshots basieren auf einer einzelnen Tabelle. Zwischen Originaltabelle und Snapshot muss eine bijektive Abbildung existieren

– Komplexe Snapshots beziehen sich auf mehrere Tabellen oder enthalten GROUP BY oder Aggregatfkt oder weitere Snapshots

– Bei komplexen Snapshots ist keine Reintegration möglich, deshalb nur lesender Zugriff auf den mobilen Clients

• Zusammenfassung– Snapshots unterstützen den Disconnected Mode mobiler Clients– In Offline-Phasen können beliebig viele Update-Operationen ausgeführt

werden– Abgleich der Daten danach durch Synchronisation und gegebenenfalls

durch Konfliktauflösungsroutinen

Page 40: 4. Replikation und Synchronisation

4-40

Neue mobile Verfahren 3. Replikationsserver-Verfahren

• Motivation:– Beobachtung: Replikation und Synchronisation erzeugt erhebl. Last

auf stationärem DBS, besonders bei sehr vielen mobilen Clients

– Idee: Um den Datenbankserver von der Koordination der Replikation und Synchronisation zu entlasten, kann man die klassische Client/Server-Architektur erweitern um einen Replikationsserver (Replication Proxy Server)

– Dann auch anwendungsgesteuerte, dynamische Auswahl der Replikate

– SQL-ähnliche Schnittstelle, um eine solche dynamische Auswahl treffen zu können

Page 41: 4. Replikation und Synchronisation

4-41

Neue mobile Verfahren - Replikationsserver-Verfahren -

• 3-stufige Architektur:– Replikationsanforderungen des mobilen Clients werden dann über

den Replikationsserver an den Datenbankserver übertragen

– Replikationsserver hat eine Kopie der Daten vom Datenbankserver

– Aufgabe des Replikationsserver:• Pflege von Daten- und Schemaelementen• Bestimmung der zu replizierenden Daten unter der Berücksichtigung

der bereits replizierten Daten

– Der Datenaustausch zwischen mobilen Client und Datenbankserver ist nur noch indirekt möglich

– Replikationsserver auf eigenem Rechner, z.B. auf Basisstation

Page 42: 4. Replikation und Synchronisation

4-42

Neue mobile Verfahren - Replikationsserver-Verfahren -

• Architektur:

– Vorteil: Skalierbarkeit bei sehr vielen mobilen Clients(sync erzeugt erhebl. Last auf stationärem DBS)

– Ebenso können Lastspitzen vom Datenbankserver weg verteilt werden

Mobiler Client

An-wen-dung

DBMS

Replikations-server

Daten undUpdates

Dienst-aufrufe

Kommunikationzu anderen RPS

Quellserver

DBMSDBMS

Page 43: 4. Replikation und Synchronisation

4-43

• Anforderungen und Ablauf nutzerdefinierter Replikation:– Heute meist traditioneller Szenarien:

z.B. Zugriff auf einen gemeinsamen Informationspool

– Zukünftig: Location Based Services

– Dabei: Benutzer soll dann Daten nicht nur verwenden, sondern auch aktualisieren oder ergänzen

– Def.: nutzerdefinierte Replikation:Dienst, der dynamisch die zu replizierenden Daten abhängig von Position und Zeit bestimmt, damit diese Daten dann im Disconnected Mode weiterverarbeitet werden können

Neue mobile Verfahren - Replikationsserver-Verfahren -

Page 44: 4. Replikation und Synchronisation

4-44

Neue mobile Verfahren - Nutzerdefinierte Replikation -

• 5 Anforderungen an die Implementierung nutzerdefinierter Replikation:

– Replikation: Anwendung soll nach den Vorgaben des Nutzer die Daten aus einer zentralen Datenbank lokal replizieren

– Replikationseffizienz: Nur Daten replizieren, die noch nicht lokal vorhanden sind

– Speicherplatzbeschränkung: Wenn für neue Daten kein Speicherplatz auf Client ist, müssen alte, nicht mehr benötigte Daten gelöscht werden

– Zugriff: jeder Nutzer soll über die notwendigen Änderungs- und Einfügerechte verfügen

– Konsistenz: Um Konsistenz der Daten zu garantieren, müssen Routinen für Konflikterkennung und –behandlung implementiert werden

Page 45: 4. Replikation und Synchronisation

4-45

Neue mobile Verfahren - Nutzerdefinierte Replikation -

• Anforderungen und Ablauf:– Weitere Punkte:

• Schnittstelle muss implementiert werden für Anwendungen, die dynamische Replikation von Daten anfordern,

• Replikate müssen mit Zusicherungen ergänzt werden (z.B. einem garantierten Einfügerecht)

– Der Abgleich der Daten zwischen Replikations- und Quellserver erfolgt asynchron

– Primärziel der Einführung eines Replikationsservers ist die Entkopplung der mobilen Nutzer vom Quellserver

Page 46: 4. Replikation und Synchronisation

4-46

4.6 Synchronization Markup Language (SyncML)

• SyncML:– Definiert eine herstellerunabhängige Technologie für die

Synchronisation von Daten in einem mobilen Client/Server-Szenario (Open Mobile Alliance: Nokia, IBM, Panasonic, Ericson, Motorola, ...)

– Als plattenformunabhängiges Datenformat der zu übertragenden Synchronisationsnachrichten wurde XML bestimmt

– Um die Abhängigkeit von bestimmten Netzwerkprotokollen zu umgehen, wurde der physikalische Transport aus SyncML ausgeklammert

– Welches Transportprotokoll benutzt wird, hängt von der jeweiligen Implementierung ab

– Ziel: alle anfallenden Synchronisationsvorgänge sollen über einen einzelnen Mechanismus abgewickelt werden

– Beispiel: Nokia Communicator 9210

Page 47: 4. Replikation und Synchronisation

4-47

Synchronization Markup Language

• 7 Synchronisationsszenarien:– Zwei-Wege-Synchronisation (bidirektionale Synchronisation):

• Client und Server teilen sich nacheinander gegenseitig alle angefallenen Änderungen mit

– Langsame Synchronisation: • Client übermittelt seine Änderungen an den Server, dort werden die

empfangenen Änderungen feldweise mit dem Datenbestand verglichen

– Einweg-Synchronisation (Client):• Client übermittelt seine Änderungen an den Server. Eventuelle

zwischenzeitl. Änderungen auf dem Server werden ohne Nachfrage überschrieben

– Einweg-Synchronisation (Server):• Wie beim Client, nur Übertragung von Server auf Client

Page 48: 4. Replikation und Synchronisation

4-48

Synchronization Markup Language

• 7 Synchronisationsszenarien:– Erneuerungs-Synchronisation (Client):

• Der Client überträgt seinen kompletten Datenbestand an den Server. Auf dem Server werden alle entsprechenden Daten überschrieben

– Erneuerungs-Synchronisation (Server):• Wie beim Client, nur Übertragung von Server auf Client.

D.h. Server überschreibt alle Client-Daten komplett

– Serverinitiierte Synchronisation:• Server stellt die Forderung an den Client, einen Synchroni-

sationsvorgang, der einer der ersten sechs Typen sein muss, zu initialisieren

Page 49: 4. Replikation und Synchronisation

4-49

Synchronization Markup Language

• Anforderungen für die Synchronisation:– Datensätze müssen separierbar sein

– Jeder Datensatz muss eindeutig identifizierbar sein

– Identifikatoren werden serverseitig als Global Unique Identifier (GUID), clientseitig als Local Unique Identifier (LUID) bezeichnet

– Wenn auf Server und Client verschiedene Identifikatoren verwendet werden, muss der Server eine korrekte Zuordnung vornehmen können (Mapping-Tabelle)

– Datenveränderungen werden immer in Log-Dateien protokolliert (dienen als Grundlage für spätere Sync-Vorgänge)

Page 50: 4. Replikation und Synchronisation

4-50

Synchronization Markup Language

• SyncML-Framework:– Um Daten synchronisieren zu können,

müssen alle beteiligten Anwendungen das SyncML Sync Protokoll implementieren

– SyncEngine auf Clientseite nicht abgebildet, da diese nur eingeschränkte Funktionen hat

– SyncML-Interface + -Adapter transformieren Originaldaten ins XML-Format

– Kommunikation aller beteiligten Instanzen erfolgt nur über diese Adapter

– Für das globale Management aller Synchronisationsprozesse wird ein Synchronisationsserver eingesetzt

SyncEngine

SyncServer Agent

SyncClient Agent

Anwendung

Anwendung

SyncML-Adapter

Syn

cML

-In

terf

ace

SyncML-Adapter

Syn

cML

-In

terf

ace

Transport (z.B. HTTP)

SyncML XML-Objekte

Page 51: 4. Replikation und Synchronisation

4-51

Synchronization Markup Language

• Synchronisationskonflikte:– Können natürlich auch hier auftreten

– Konfliktlösung ist Aufgabe des Servers bzw. der SyncEngine

– Wenn SyncEngine Konflikt feststellt, wird dies an den konfliktauslösenden Client mitgeteilt

– SyncML legt aber nicht fest, welche Konfliktauflösungsroutinen in welchem Konfliktfall konkret angewandt werden sollen

Page 52: 4. Replikation und Synchronisation

4-52

Synchronization Markup Language

• Synchronisationskonflikte– Beispiele für Konfliktauflösungsmethoden:

• Kapitulation: Synchronisation wird nicht durchgeführt.• Duplikat: Von dem Datensatz, der einen Konflikt ausgelöst hat, wird ein

Duplikat angelegt. Beide Änderungen werden dann unabhängig voneinander auf jeweils einem der verfügbaren Datensätze ausgeführt.

• Priorität: Im Konfliktfall kann eine höhere priorisierte Operation bevorzugt werden.

• Gewinner: Dabei gewinnt immer eine der beiden Konfliktparteien. So kann z.B. immer der Client gewinnen.

Page 53: 4. Replikation und Synchronisation

4-53

4.7 Zusammenfassung

• Definition der Begriffe Replikation und Synchronisation• Ursprung und die Vorteile der Replikation• 4 Zentralen Strategien beim Einsatz der Replikation• Zielkonflikt der Replikation• Beispiele für konsistenz- und verfügbarkeitserhaltende

Verfahren• Data-Caching und Data-Hoarding-Verfahren• Beispiele für neue mobile Verfahren• Synchronization Markup Language (SyncML)