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

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

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

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

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 Technische Entwicklung Pull vs. Push Datenverteilungsmodelle Broadcast Disks 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 2 Hauptaufgaben 1. Wie generiert der Server ein optimales Broadcast-Programm ? 2. Wie organisiert der Client seinen Speicher optimal ?

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

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

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

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

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

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

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

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

Inhaltsübersicht Technische Entwicklung Pull vs. Push Datenverteilungsmodelle Broadcast Disks Read-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 bcast    header k1 d k2 d k3 d    bucket

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

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

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

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

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

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 integriert ROT 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ültigen Daten und markiert sie automatisches Updaten der markierten 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 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)

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