Mobile Datenbanken und Informationssysteme

Thema:

Strategien zur Datenverteilung

Push und Broadcast

Inhaltsübersicht

1. Technische Entwicklung

2. Pull vs. Push

3. Datenverteilungsmodelle

4. Broadcast Disks

5. Read-Only-Transaktions &

Updatehandling

Inhaltsübersicht

1.1. Technische EntwicklungTechnische Entwicklung

2. Pull vs. Push

3. Datenverteilungsmodelle

4. Broadcast Disks

5. Read-Only-Transaktions

Asymmetrische Kommunikation

Kommunikationskapazitäten in klassischen Netzwerken gleich

(downstream = upstream)

asymmetrisch verteilte Ressourcen

(downstream > upstream)

Asymmetrische Kommunikation

- Asymmetrie kann verschiedene Gründe haben, man unterscheidet

3 Arten:

Netzwerk (Bandbreiten) Asymmetrie

verschiedene Bandbreiten hat technische Gründe

Service Load Asymmetrie

Server sendet mehr Nachrichten als Client

mehr Clients als Server viele Anfragen Server überlasten

Gründe: Verhältnis Server-/Clientanzahl

neue, aktuelle Informationen

Datenmengen Asymmetrie

kleine Anfragen haben große Auswirkungen

Asymmetrische Kommunikation

Einseitige Kommunikation als Extremform der asymmetrischen Kommunikation

Schlafmodus wegen Batteriegrenzen (mobile, drahtlose Netzwerke)

Nicht technische Gründe (militärische Anwendungen)

Information Feed Application

kleine Anzahl von Produzenten liefern Informationen an viele

Konsumenten

Verkehrsinformationssysteme Börsenkurse anzeigen TV ... Unterhaltungsmedien Mircocell-Anwendungen militärsche Anwendungen

Inhaltsübersicht

1. Technische Entwicklung

2.2. Pull vs. PushPull vs. Push

3. Datenverteilungsmodelle

4. Broadcast Disks

5. Read-Only-Transaktions

Warum Push?

Pull

• Uplink nicht immer bzw. nur eingeschränkt möglich

technische Gründe

beabsichtigt

• Serverüberlastung bei unbekannte Client-Anzahl möglich

Push

• Keine Clientanfragen

• Zentralisiertes System,

Updates nur auf Server

Effizienz

mehr Clients durch weniger Aktionen pro Client

bessere Kapazitätenauslastung

Inhaltsübersicht

1. Technische Entwicklung

2. Pull vs. Push

3.3. DatenverteilungsmodelleDatenverteilungsmodelle

4. Broadcast Disks

5. Read-Only-Transaktions

Definitionen

• Push-Programm

In einem Push-basierten System sendet der Server Daten um die Bedürfnisse der Clients zu befriedigen. Die vom Server übermittelte Datensequenz wird als Push-Programm bezeichnet.

• Broadcast-Programm

Wird bei der Übermittlung ein Broadcast-Kanal verwendet, so spricht man von einem Broadcast-Programm.

periodisch nicht periodisch

periodisch: wiederholtes senden eines Programms

Pull wiederholte Clientanfragen

Push wiederholtes Push-Programm

nicht periodisch: einmaliges senden

Point-to-Point One-to-Many

Point-to-Point

jedes gesendete Datenobjekt hat genau einen Empfänger

Unicast

One-to-Many

Daten gehen an große Anzahl von Empfängern

Multicast (an ausgewählte Client-Gruppe)

Broadcast (an alle Clients)

Data Dissemination

auf Push-Strategie und One-To-Many-Konzept basierende Datenverteilung

periodisch nicht periodisch

Vorteile: - Broadcastprogramm für unbegrenzte

Clientanzahl

- keine Performanceverluste

Data Dissemination

Nachteile: - Verschwendung von Netzwerk- und Client- Ressourcen, da alle Daten an alle Clients

- lange Broadcastprogramme bei viele disjunkten Interessen

- Server muss Interessen der Clients kennen und sie mit Prioritäten versehen können

Profile der Clients

Data Dissemination

Server kennt die zusendenden Daten und die Prioritäten

Client erstellt sein Profil selbst eigene Aktionen überwachen Anfragen an Server sammeln

Client-Profil

globales Profil

Probleme: Fairness des globalen Profils Aktualisierung der Profile

Inhaltsübersicht

1. Technische Entwicklung

2. Pull vs. Push

3. Datenverteilungsmodelle

4.4. Broadcast DisksBroadcast Disks

5. Read-Only-Transaktions

Modellannahmen basiert auf Broadcast Disk: - Modell für Übertragungskanal

- verschiedene Größen und Geschwindigkeiten multiple Disk‘s

- schnelle Disk‘s senden enthaltenen Daten öfters als langsame

Ziel: Daten entsprechend ihrer Priorität auf Disk‘s verteilen wichtige Daten (hot spots) auf schnelle Disk‘s unwichtige Daten auf langsame Disk‘s

fein strukturierte Datenhierarchie

strukturiertes Broadcast-Programm

Modellannahmen

Restriktionen: - die Profile der Clients sind bekannt und konstant

- Anzahl der Clients ändert sich nicht

- keine Update‘s

- keine Upstream-Kommunikation

1. Wie generiert der Server ein optimales Broadcast-Programm ?

2. Wie organisiert der Client seinen Speicher optimal ?

2 Hauptaufgaben

Broadcast-Programm

Einfachster Fall: Server fasst alle Profile zusammen und sendet kontinuierlich alle benötigten Daten.

flaches Broadcast-Programm

E AD BC

A B EDC

Broadcast-Programm

Besser: Übermitteln der Daten mit verschieden Frequenzen

wichtige Daten werden im gleichen Zeitintervall öfters gesendet als unwichtige

Verfahrensweise:

1. Server berechnet für jedes Datenelement den prozentualen Anteil der Broadcast-Bandbreite

2. Zusammensetzen des Broadcast‘s, so dass „inter-arrival time“ zwischen zwei Vorkommen

eines Elementes, den Client-Bedürfnissen entsprechen

Broadcast-Programm

Schiefes Broadcast-Programm

regelmäßiges Broadcast-Programm Multi-Disk Broadcast

A A B C

A B A C

Clustering verschiedene inter-arrival times

Konstante Abstände zwischen zwei gleichen Elementen

Broadcast-Programm

ZugriffswahrscheinlichkeitErwartete Verzögerung(in Broadcast-Einheiten)

A B C Flach schiefmulti-disk

0,333 0,333 0,333 1,50 1,75 1,67

0,5 0,25 0,25 1,50 1,63 1,50

0,75 0,125 0,125 1,50 1,44 1,25

0,9 0,05 0,05 1,50 1,33 1,10

1,0 0,0 0,0 1,50 1,25 1,00

Broadcast-Programm

Algorithmus für Multi-Disk Broadcast Ordnen der Daten nach ihren Zugriffswahrscheinlichkeiten (heiß kalt)② Daten mit der selben Priorität werden zusammengefasst und einer Disk

zugeordnet③ Wahl der relativen Frequenz der Übertragung für jede Disk (rel_freq(disk)

Integer)④ Unterteilen der Disk‘s in Blöcke Bij (j-ter Block auf i-ter Disk) indem man

zuerst das kleinste gemeinsame Vielfache der relativen Frequenzen berechnet und in max_blocks speichert. Danach teilt man jede Disk i in anz_blocks(i) = max_blocks/rel_freq(i) viele Blöcke.

⑤ Der Broadcast wird wie folgt erzeugt: 1. for i := 0 to max_blocks do

2. for j := 1 to anz_disks do3. sende Block Bj(i mod anz_blocks(j))4. end5. end

Broadcast-Programm

1 2 3 4 5 6 7 8 9 1011wichtig/heiß unwichtig/kalt

1 2 3 4 5 6 7 8 9 1011

1 2 3 4 5 6 7 8 9 1011

1 2 4 5 1 3 6 7 1 2 8 9 1 3 1011

Datenbank

Blöcke

Disk‘s

Broadcast-Programm

Subzyklus

Hauptschleife/-zyklus

Speicherverwaltung

Problem: viele Client‘s mit verschiedenen Profilen

Performance-Nachteile für einige Client‘s,

aufgrund von abweichenden Profilen

Lösung: Speichern von Daten auf Client

Was ist optimale Strategie ?

Speicherverwaltung

Probleme bei herkömmlichen Strategien:

Pull-System: wichtigste Daten lokal gespeichert unsinnig für Push, da am meisten gesendet

Speicherersetzung: LRU suboptimal

Broadcast-Programm nicht optimal

Speicherverwaltung

neue Speicherstrategie

Speicherung von Daten, deren lokale Zugriffszeit signifikant kleiner ist als die Zugriffszeit beim Lesen von Broadcast.

1 2 3 4 5 6 7 8 9 1011

Von vielen Clients benötigt nicht lokal speichern

Von wenigen Client‘s benötigt lokal speichern

Speicherverwaltung

neue Speicherstrategie

Speicherung von Daten, deren lokale Zugriffszeit signifikant kleiner ist als die Zugriffszeit beim Lesen von Broadcast.

1 2 4 5 1 3 6 7 1 2 8 9 1 3 10111 3 1011 1 2 4 5

Kurze Wartezeit

lange Wartezeit

Speicherverwaltung

Neue Ersetzungsstrategie

Ersetzen der Daten mit dem kleinsten Verhältnis zwischen Zugriffswahrscheinlichkeit P und relativer Frequenz der Übermittlung

PIX (P Inverse X)

B

A P = 1%X = 1%

P = 0,5%X = 0,1%

PIX = 1

PIX = 5

zuerst im Speicher ersetzen,obwohl wichtiger

später ersetzen

Speicherverwaltung

Voraussetzungen für PIX

1) perfektes Wissen über Zugriffswahrscheinlichkeiten2) Vergleichen alle gespeicherten Daten zur Ersetzungszeit

wird kaum implementiert

Alternative ist LIX

beruht auf erweitertem LRU-Ansatz

Inhaltsübersicht

1. Technische Entwicklung

2. Pull vs. Push

3. Datenverteilungsmodelle

4. Broadcast Disks

5.5. Read-Only-TransaktionsRead-Only-Transaktions

Konzept der ROT

Client kann nur Downstream mittels ROT lesen

Schlafmodus zeitweise inaktiv

Energie- und Arbeitsersparnis

„Inhaltsverzeichnis“ des Broadcast nötig

Bucket kleinste logische Einheit des Broadcast

header k1 d k2 k3d d

bucket

bcast

Konsistenz

Konsistenter Datenbankzustand

Werte der Daten erfüllen bestimmte Integritätsbedingungen

Konsistenter Broadcast

Übertragung von konsistenten Datenbankzustände

Problem: Updates auf Server können zu inkonsistenten Übertragungen führen

Konsistenz

Lesen von einem Zyklus keine Konsistenzprobleme

Lesen von mehren Zyklen Inkonsistenzen möglich

If a>0 then read b else read c

b end... c a... ...beginbcast ...

b end... c 5... ...begin ...

b end... c -5... ...begin ...2 bcast

1 bcast

Update auf Server

Client liest b, obwohl a<0

Konsistenz

span(T)

... die Dauer/Spanne einer Transaktion T ist die maximale Anzahl der verschieden Broadcast-Zyklen von denen T liest.

Read_Set(T)

... Menge geordneter Paare von Daten und ihren Werten, welche von T gelesen wurden.

T liest konsistente Daten, wenn Read_Set(T) eine Teilmenge eines

konsistenten Datenbankzustandes ist

Invalidation-Only Methode

Ungültigkeitsbericht (invalidation-report):

Liste von Datenelementen, deren Wert sich während des letzten Broadcast-Zyklus geändert hat

ROT wird abgebrochen, wenn vorher gelesene Daten im Ungültigkeitsbericht enthalten sind

x Read_Set(T) x invrep Abbruch

invrep bcast

Ungültigkeitsbericht

Invalidation-Only Methode

Nachteile:

nur Abbruch von inkonsistenten ROT

Client muss jeden Bericht lesen

Performancebeeinflussung durch vergrößertenBroadcast

Multiversion Broadcast

Abbruch von ROT verhindern durch mehrere Versionen der Daten.

Zyklus C0

Client

Erste Leseoperation der ROT liefert Daten mit Versionsnummer C0

Zyklus Ci

Kein Abbruch gelesene Daten haben VNr.<C0Abbruch gelesene Daten haben VNr.>C0

Multiversion Broadcast

V-Multiversion-Server

... sendet die letzten V älteren Versionen der Daten

garantiert Konsistenz aller Transaktionen mit

max(span(T)) < V

Multiversion Broadcast

header k1 d k2 k3d dP P P k1 d v k3 d v

bucket overflow bucket

Schlüsselfelder k

Datenfelder d

Version vPointer P

Vorteil: mittels Inhaltsverzeichnis auf Client sind alle Daten problemlos auffindbar (ältere Versionen über Pointer)

Nachteil: lange laufende ROT (viele Zyklen) müssen immer auf Ende des bcast warten stark vergrößertes Broadcast-Volumen

Serialisation-Graph Testing

History H(Menge von Transaktionen)

Serialisierbarkeitsgraph SG(H)

(gerichteter Graph, mit TA als Knoten und Paare von TA als Kanten)

Test auf Kreisfreiheit

(Serialisierbarkeitstheorem: H mit kreisfreien SG(H) sind serialisierbar)

Serialisation-Graph Testing

SG des Servers(bezogen auf TA auf Server)

lokale SG-Kopie des Clients(enthält zusätzlich alle aktiven ROT des Clients)

Veränderungen des Server-SG‘s werden mit dem bcast mitübertragen und vom Client in seine lokale Kopie integriertROT des Client‘s werden nur akzeptiert, wenn in der lokalen Kopie kein Kreis entsteht

Serialisation-Graph Testing

Verbesserungen:

• nur relevante SG-Teilgraphen des Servers auf Client speichern

• Update-Informationen am Ende des Broadcast-Zyklus

lokales Inhaltsverzeichnis zum Finden der Daten

Nachteile:

• keine inaktiven Phasen möglich

• aufwendige Aktualisierung der lokalen SG-Kopie

Caching/Lokales Speichern

meist werden die wichtigsten Daten lokal gespeichert

Laufzeitverbesserung span(T) kleiner, d.h. aus weniger Zyklen lesen

Konsistenz auch für gespeicherte Daten garantieren Anwendung der genannten Methoden geeignete Ersetzungsstrategie nötig

Zusätzliche Informationen nötig

Caching/Lokales Speichern

Möglichkeit: Invalidation-only & Autoprefetching

Ungültigkeitsbericht am Anfang eines jeden bcast

Client sperrt die ungültigenDaten und markiert sie

automatisches Updaten dermarkierten Daten

Daten bleiben im Speicher

Caching/Lokales Speichern

Erweiterung: „invalidation-only with version cache“

- neben Daten auch den Broadcast-Zyklus speichern in dem sie zuletzt geändert wurden

- ROT nicht abbrechen als abgebrochen markieren

kann so lange weiterlaufen, wie alte

konsistente Daten vorhanden sind

Performance Betrachtung

  Invalidation-only Multiversion Broadcast

SGT Methode Caching

Anzahl von akzeptierten ROT

gering groß (abh. von der Anzahl der

Versionen)

mittel (abh. von den TA auf dem Server)

(abh. von der Speichergröße des

Clients)

Laufzeit (Anzahl von Zyklen)

keine Auswirkung wächst bei lang lesenden TA

keine Auswirkung sinkt

Broadcastgröße (Vergrößerung des

BC-Volumens)

abh. von Update-Rate (1% bei 50 updates

und span = 3)

abh. von Update-Rate und span (12% bei 50

updates und V = 3)

abh. von TA auf dem Server (2,5% bei 10

STA und 50 updates)

relativ gering, z.B. für invalidation-

Report

Gelesener Datenbankzustand

Zustand bei der letzten Leseoperation

Zustand bei der ersten Leseoperation

Ein Zustand zwischen erster und letzter LO

verschieden

Rechenaufwand gering mittel Beträchtlich (SG auf Server und Client

erhalten)

Gering

Toleranz bzgl. Ausklinken

Keine (lesen des Inv. Reports zu jedem

Zyklus)

Vorhanden (abh. von span und Update-

Rate)

Keine (SG muss immer aktualisiert

sein)

Vorhanden (abh. von Update-Rate und Speichergröße)

Abschießende Bemerkungen

• Push- und Broadcast-Konzepte werden kaum in der Wirtschaft eingesetzt

Sicherheitsaspekte

Zu spezifischeAnwendungen

Wirtschaftlichkeit

Zu viele Vorabinformationen notwenig