Mobile Datenbanken und Informationssysteme

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. 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 Warum Push?

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 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 • 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 Erwartete Verzögerung (in Broadcast-Einheiten) A B C Flach schief multi-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

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

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. 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) Performance Betrachtung

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