Mobile Datenbanken und Informationssysteme

Präsentation zum Thema: "Mobile Datenbanken und Informationssysteme"—  Präsentation transkript:

1 Mobile Datenbanken und Informationssysteme
Thema: Strategien zur Datenverteilung Push und Broadcast

2 Inhaltsübersicht Technische Entwicklung Pull vs. Push
Datenverteilungsmodelle Broadcast Disks Read-Only-Transaktions & Updatehandling

3 Inhaltsübersicht Technische Entwicklung Pull vs. Push
Datenverteilungsmodelle Broadcast Disks Read-Only-Transaktions

4 Asymmetrische Kommunikation
Kommunikationskapazitäten in klassischen Netzwerken gleich (downstream = upstream)  asymmetrisch verteilte Ressourcen (downstream > upstream)

5 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

6 Asymmetrische Kommunikation
Einseitige Kommunikation als Extremform der asymmetrischen Kommunikation  Schlafmodus wegen Batteriegrenzen (mobile, drahtlose Netzwerke)  Nicht technische Gründe (militärische Anwendungen)

7 Information Feed Application
kleine Anzahl von Produzenten liefern Informationen an viele Konsumenten Verkehrsinformationssysteme Börsenkurse anzeigen TV ... Unterhaltungsmedien Mircocell-Anwendungen militärsche Anwendungen

8 Inhaltsübersicht Technische Entwicklung Pull vs. Push
Datenverteilungsmodelle Broadcast Disks Read-Only-Transaktions

9 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

10 Inhaltsübersicht Technische Entwicklung Pull vs. Push
Datenverteilungsmodelle Broadcast Disks Read-Only-Transaktions

11 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.

12 periodisch  nicht periodisch
periodisch: wiederholtes senden eines Programms Pull  wiederholte Clientanfragen Push  wiederholtes Push-Programm nicht periodisch: einmaliges senden

13 Point-to-Point  One-to-Many
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)

14 periodisch nicht periodisch
Data Dissemination auf Push-Strategie und One-To-Many-Konzept basierende Datenverteilung   periodisch nicht periodisch Vorteile: - Broadcastprogramm für unbegrenzte Clientanzahl - keine Performanceverluste

15 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

16 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

17 Inhaltsübersicht Technische Entwicklung Pull vs. Push
Datenverteilungsmodelle Broadcast Disks Read-Only-Transaktions

18 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

19 Modellannahmen Restriktionen: - die Profile der Clients sind bekannt und konstant - Anzahl der Clients ändert sich nicht - keine Update‘s - keine Upstream-Kommunikation 2 Hauptaufgaben 1. Wie generiert der Server ein optimales Broadcast-Programm ? 2. Wie organisiert der Client seinen Speicher optimal ?

20 Broadcast-Programm Einfachster Fall: Server fasst alle Profile zusammen und sendet kontinuierlich alle benötigten Daten.  flaches Broadcast-Programm C D B E A A E B D C

21 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

22 Broadcast-Programm Schiefes Broadcast-Programm A A B C
Clustering  verschiedene inter-arrival times regelmäßiges Broadcast-Programm  Multi-Disk Broadcast A B A C Konstante Abstände zwischen zwei gleichen Elementen

23 Zugriffswahrscheinlichkeit (in Broadcast-Einheiten)
Broadcast-Programm Zugriffswahrscheinlichkeit Erwartete Verzögerung (in Broadcast-Einheiten) A B C Flach schief multi-disk 0,333 1,50 1,75 1,67 0,5 0,25 1,63 0,75 0,125 1,44 1,25 0,9 0,05 1,33 1,10 1,0 0,0 1,00

24 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 for j := 1 to anz_disks do sende Block Bj(i mod anz_blocks(j)) end 5. end

25 Broadcast-Programm Datenbank wichtig/heiß 1 2 3 4 5 6 7 8 9 10 11
unwichtig/kalt Disk‘s 1 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 8 9 10 11 Blöcke Subzyklus Broadcast-Programm 1 2 4 5 1 3 6 7 1 2 8 9 1 3 10 11 Hauptschleife/-zyklus

26 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 ?

27 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

28 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 10 11 Von vielen Clients benötigt  nicht lokal speichern Von wenigen Client‘s benötigt  lokal speichern

29 Speicherverwaltung neue Speicherstrategie
Speicherung von Daten, deren lokale Zugriffszeit signifikant kleiner ist als die Zugriffszeit beim Lesen von Broadcast. Kurze Wartezeit 1 3 10 11 1 2 4 5 1 3 6 7 1 2 8 9 1 3 10 11 1 2 4 5 lange Wartezeit

30 Speicherverwaltung Neue Ersetzungsstrategie
Ersetzen der Daten mit dem kleinsten Verhältnis zwischen Zugriffswahrscheinlichkeit P und relativer Frequenz der Übermittlung  PIX (P Inverse X) zuerst im Speicher ersetzen, obwohl wichtiger P = 1% X = 1% A PIX = 1 P = 0,5% X = 0,1% PIX = 5 später ersetzen B

31 Speicherverwaltung Voraussetzungen für PIX
1) perfektes Wissen über Zugriffswahrscheinlichkeiten 2) Vergleichen alle gespeicherten Daten zur Ersetzungszeit  wird kaum implementiert Alternative ist LIX beruht auf erweitertem LRU-Ansatz

32 Inhaltsübersicht Technische Entwicklung Pull vs. Push
Datenverteilungsmodelle Broadcast Disks Read-Only-Transaktions

33 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 bcast    header k1 d k2 d k3 d    bucket

34 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

35 Konsistenz Lesen von einem Zyklus  keine Konsistenzprobleme
Lesen von mehren Zyklen  Inkonsistenzen möglich If a>0 then read b else read c bcast begin ... b ... c ... a ... end 1 bcast begin ... b ... c ... 5 ... end Update auf Server 2 bcast begin ... b ... c ... -5 ... end  Client liest b, obwohl a<0

36 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

37 Invalidation-Only Methode
invrep bcast Ungültigkeitsbericht 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

38 Invalidation-Only Methode
Nachteile:  nur Abbruch von inkonsistenten ROT  Client muss jeden Bericht lesen  Performancebeeinflussung durch vergrößerten Broadcast

39 Multiversion Broadcast
Abbruch von ROT verhindern durch mehrere Versionen der Daten. Erste Leseoperation der ROT liefert Daten mit Versionsnummer C0 Zyklus C0 Zyklus Ci Client Kein Abbruch  gelesene Daten haben VNr.<C0 Abbruch  gelesene Daten haben VNr.>C0

40 Multiversion Broadcast
V-Multiversion-Server ... sendet die letzten V älteren Versionen der Daten  garantiert Konsistenz aller Transaktionen mit max(span(T)) < V

41 Multiversion Broadcast
header k1 d P k2 d P k3 d P    k1 d v k3 d v    bucket overflow bucket Schlüsselfelder k Version v Pointer P Datenfelder d 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

42 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)

43 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 integriert ROT des Client‘s werden nur akzeptiert, wenn in der lokalen Kopie kein Kreis entsteht

44 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

45 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

46 Caching/Lokales Speichern
Möglichkeit: Invalidation-only & Autoprefetching Ungültigkeitsbericht am Anfang eines jeden bcast Client sperrt die ungültigen Daten und markiert sie automatisches Updaten der markierten Daten Daten bleiben im Speicher

47 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

48 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 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 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)

49 Abschießende Bemerkungen
Push- und Broadcast-Konzepte werden kaum in der Wirtschaft eingesetzt  Sicherheitsaspekte  Wirtschaftlichkeit  Zu spezifische Anwendungen  Zu viele Vorabinformationen notwenig