Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Mobile Datenbanken und Informationssysteme Thema: Strategien zur Datenverteilung Push und Broadcast."—  Präsentation transkript:

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

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

3 Inhaltsübersicht 1. Technische Entwicklung 2. Pull vs. Push 3. Datenverteilungsmodelle 4. Broadcast Disks 5. 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 1. Technische Entwicklung 2. Pull vs. Push 3. Datenverteilungsmodelle 4. Broadcast Disks 5. 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 1. Technische Entwicklung 2. Pull vs. Push 3. Datenverteilungsmodelle 4. Broadcast Disks 5. 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 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)

14 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 1. Technische Entwicklung 2. Pull vs. Push 3. Datenverteilungsmodelle 4. Broadcast Disks 5. Read-Only-Transaktions

18 Modellannahmen basiert auf Broadcast Disk: - Modell für Übertragungskanal - verschiedene Größen und Geschwindigkeiten multiple Disks - schnelle Disks senden enthaltenen Daten öfters als langsame Ziel: Daten entsprechend ihrer Priorität auf Disks verteilen wichtige Daten (hot spots) auf schnelle Disks unwichtige Daten auf langsame Disks fein strukturierte Datenhierarchie strukturiertes Broadcast-Programm

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

20 Broadcast-Programm Einfachster Fall: Server fasst alle Profile zusammen und sendet kontinuierlich alle benötigten Daten. flaches Broadcast-Programm EA DB C A B E 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 Broadcasts, so dass inter-arrival time zwischen zwei Vorkommen eines Elementes, den Client-Bedürfnissen entsprechen

22 Broadcast-Programm Schiefes Broadcast-Programm regelmäßiges Broadcast-Programm Multi-Disk Broadcast AABC ABAC Clustering verschiedene inter-arrival times Konstante Abstände zwischen zwei gleichen Elementen

23 Broadcast-Programm Zugriffswahrscheinlichkeit Erwartete Verzögerung (in Broadcast-Einheiten) ABCFlachschief multi- disk 0,333 1,501,751,67 0,50,25 1,501,631,50 0,750,125 1,501,441,25 0,90,05 1,501,331,10 1,00,0 1,501,251,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 Disks 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 do 3. sende Block Bj(i mod anz_blocks(j)) 4. end 5. end

25 Broadcast-Programm wichtig/heißunwichtig/kalt Datenbank Blöcke Disks Broadcast-Programm Subzyklus Hauptschleife/-zyklus

26 Speicherverwaltung Problem: viele Clients mit verschiedenen Profilen Performance-Nachteile für einige Clients, 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 Von vielen Clients benötigt nicht lokal speichern Von wenigen Clients 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 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) 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

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 1. Technische Entwicklung 2. Pull vs. Push 3. Datenverteilungsmodelle 4. Broadcast Disks 5. 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 headerk1 dk2k3dd bucket bcast

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 bend...ca begin bcast... bend...c5 begin... bend...c-5... begin... 2 bcast 1 bcast Update auf Server 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 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 invrepbcast Ungültigkeitsbericht

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. Zyklus C0 Client Erste Leseoperation der ROT liefert Daten mit Versionsnummer C0 Zyklus Ci Kein 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 headerk1 dk2k3ddPPPk1dvk3dv bucketoverflow bucket Schlüsselfelder k Datenfelder d Version v Pointer 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

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-SGs werden mit dem bcast mitübertragen und vom Client in seine lokale Kopie integriert ROT des Clients 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-onlyMultiversion Broadcast SGT MethodeCaching Anzahl von akzeptierten ROT geringgroß (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 Auswirkungwächst bei lang lesenden TA keine Auswirkungsinkt 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 RechenaufwandgeringmittelBeträ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 Zu spezifische Anwendungen Wirtschaftlichkeit Zu viele Vorabinformationen notwenig


Herunterladen ppt "Mobile Datenbanken und Informationssysteme Thema: Strategien zur Datenverteilung Push und Broadcast."

Ähnliche Präsentationen


Google-Anzeigen