Download - Mobile Datenbanken und Informationssysteme
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