Hauptseminar NoSQL ElasTraS und CloudTPS

Präsentation zum Thema: "Hauptseminar NoSQL ElasTraS und CloudTPS"—  Präsentation transkript:

1 Hauptseminar NoSQL ElasTraS und CloudTPS
Stefan Wenz

2 Never change a running system
Relationale Datenbanksysteme haben sich bewährt Sie wurde über Jahre hinweg verfeinert und optimiert Warum also neue Systeme? Zunahme der Datenmenge Veränderung der Umgebung Verteilte Systeme Cloud Computing Inhaltsverzeichnis Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

3 Cloud Computing Übertragung von Risiken
Kosten nur für tatsächlich genutzte Ressourcen Scheinbar unbegrenzte Ressourcen Problem: Anpassungen bestehenden Programmen Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

4 Inhalt der Präsentation
Grundlagen CAP-Theorem Datenbank Konzpte Relationale Datenbanksysteme No-SQL Systeme CloudTPS Architektur Performance & Fehlertolerance Vor- & Nachteile ElasTraS Fazit Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

5 Grundlagen – CAP Theorem
X Z Xr Y Konsistenz Alle sehen zum gleichen Zustand das gleiche Nur wenn angenommen wird, dass innerhalb eines verteilten Systems nicht mehrere Instanzen des selben Datensatzes mit unterschiedlichen Werten vorhanden sein dürfen, wäre die Verknüpfung zwischen den beiden Konsistenzvorstellungen zutreffend. Partitionstoleranz Das System kann mit dem Verlust von Nachrichten auf eine definierte Art umgehen Verfügbarkeit Der Ausfall einzelner Knoten verhindert nicht die Lauffähigkeit des Gesamtsystems Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

6 Grundlagen – CAP Theorem
Ein verteiltes System kann nur gleichzeitig zwei der drei Eigenschaften erfüllen! Beispiele? Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

7 Grundlagen – Datenbank Konzepte
Bekanntes Konzept: ACID Atomizität Konsistenz Isolation Dauerhaftigkeit Für verteiltes System neues Konzept: BASE Basic Available Soft State Eventual Consistency Strong Consistency vs Eventual Consictency (part of Weak Consictency) Zentraler Punkt: Evenutal Consistency Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

8 Relationale Datenbanksysteme - Vorteile
Vorteile SQL: standardisiert & weitverbreitet Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

9 Relationale Datenbanksysteme
Standardisierte Anfragesprache Referenzierbarkeit Strukturierbarkeit von Daten Trennung physikalischer und logischer Zugriff Definierbarkeit von Sichten Begrenzte horizontale Skalierbarkeit Fest definiertes Schema Referenzierbarkeit  Keine bzw vermeidbarkeit von Redundanten Daten Vorteile SQL: standardisiert & weitverbreitet Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

10 Übersicht NoSQL-Systeme
Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

11 Keine Verwendung von SQL als Anfragesprache
NoSQL-Systeme Keine Verwendung von SQL als Anfragesprache Keine Definition Viel verschiedene Arten Gute horizontale Skalierbarkeit Keine Unterstützung des Transaktionskonzepts Dokumentation oftmals lückenhaft Nicht realisierte Leistungsmerkmale NoSQL-System Arten: Dokumentenbasierte (bsp. CouchDB); Spaltenorientierte (bsp. Cassandra) Key-Value (bsp. MemCached)  Vor- und Nachteile stark von der Umgebung abhängig & somit gut Abstimmbar auf Aufgabe und Umgebung Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

12 CloudTPS Entwickler Zhou Wie Guillaume Pierre Chi-Hung Chi von Vrije Universiteit, Amsterdam Idee Entwurf eine Middleware mit der die Cloud Technologie genutzt werden und zugleich die ACID-Eigenschaften zugesichert werden können. Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

13 CloudTPS - Architektur
Elemente des Systems Transaction Processing System (TPS) Virtual Nodes Local Transaction Manager (LTM) Cloud Storage Service Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

14 CloudTPS – Architektur
Nutzung von vorhandener Cloud-Technologie (z.B. Hbase) Feste Zuordnung zwischen LTM und Datensatz  exklusiver Schreibzugriff Übertragung der Datensätze in bestimmten Intervallen Liste der geänderten Daten im LTM  nur diese müssen in Cloud Storage übertragen werden Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

15 CloudTPS – Architektur
Anfrageverwaltung der Web Application Load Balancing durch Hash-basierte Zuteilung von Virtual Nodes LTM hat lokale Kopie der ihm zugeordneten Datensätze im Speicher Eigenverantwortlichkeit der LTM für Replikation der Daten Nähere Erläuterung der Replikation notwendig  Sinfonia Primary-copy replication  Übertragung der Daten in das Replikat während redo-log in stable storage  Replikation in der ersten phase des 2PC + Einfacher Algorithmus + Mehrere Änderung können gebündelt übertragen werden - Keine Konsistenz im verteilten System Jeder LTM hat bestimmte Größe (Buffer)  Bufferpool notwendig aus dem die LTM sich bedienen können / erzeugt werden können Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

16 CloudTPS – ACID Atomizität Konsistenz Zwei-Phasen-Übertragung (2PC)
Ermittlung aller an einer Transaktion beteiligten LTM Anfrage an alle beteiligte LTM ob Datenmanipulation möglich Rückmeldung von allen beteiligten LTM „COMMIT“ Start Transaktion Keine Übereinkunft  Reject der Transaktion Konsistenz Grundannahme: Datenbank ist in einem konsistenten Zustand  Bindende Konsistenzregeln für alle Transaktionen Nähere Erläuterung der Replikation notwendig  Sinfonia Primary-copy replication  Übertragung der Daten in das Replikat während redo-log in stable storage  Replikation in der ersten phase des 2PC + Einfacher Algorithmus + Mehrere Änderung können gebündelt übertragen werden - Keine Konsistenz im verteilten System Jeder LTM hat bestimmte Größe (Buffer)  Bufferpool notwendig aus dem die LTM sich bedienen können / erzeugt werden können Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

17 CloudTPS – ACID Isolation Dauerhaftigkeit
Aufteilung der Transaktion in Sub-Transaktionen Aufteilungskriterium: Zugriff auf ein einzelnes Datenelement Globale Ordnung der Transaktionen notwendig  Vergabe von eindeutigen Zeitstempeln Jeder LTM hat eine chronologisch geordnete Liste mit den auszuführenden Transaktionen Jede Transaktion prüft ob einen LTM noch Transaktion mit einem kleinen Zeitstempel nicht ausgeführt hat  Notwendigkeit einer „RESTART“-Phase Dauerhaftigkeit Nach Checkpoint unproblematisch Vor Checkpoint durch Replikation der LTM gewährleistet Nähere Erläuterung der Replikation notwendig  Sinfonia Primary-copy replication  Übertragung der Daten in das Replikat während redo-log in stable storage  Replikation in der ersten phase des 2PC + Einfacher Algorithmus + Mehrere Änderung können gebündelt übertragen werden Keine Konsistenz im verteilten System Restart wird die durch einen Fehlermeldung einer Sub-Transaktion bei Zeitkonflikten ausgelöst. Kein Restart möglich wenn Transaktion in 2 Phase von 2PC. Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

18 CloudTPS – Perfromance & Fehlertoleranz
Lineare Skalierbarkeit bis 40 LTM Fehlertoleranz des Systems Nähere Erläuterung der Replikation notwendig  Sinfonia Primary-copy replication  Übertragung der Daten in das Replikat während redo-log in stable storage  Replikation in der ersten phase des 2PC + Einfacher Algorithmus + Mehrere Änderung können gebündelt übertragen werden Keine Konsistenz im verteilten System Restart wird die durch einen Fehlermeldung einer Sub-Transaktion bei Zeitkonflikten ausgelöst. Kein Restart möglich wenn Transaktion in 2 Phase von 2PC. Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

19 CloudTPS – Transaktionsverlauf
Client stellt Anfrage per Http Request Anfrage wird von der Web Application an TPS übertragen Transaktion wird von beliebigen LTM angenommen Look-Up welche anderen LTM beteiligt sind Start 2PC  Anfragen & Antwort abwarten Verteilen der Subtransaktionen und Start der Transaktion Checkpoint backup in Cloud Storage ? ! Optional: Weiterleitung von „Read-only“ Transaktionen  keine LTM weiter beteiligt Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

20 CloudTPS – Vor- & Nachteile
Gute Horizontale Skalierbarkeit Zusicherung der ACID-Eigenschaften Nutzung bereits vorhandener Cloud-Technologie Partitionstoleranz Möglichkeit der Weiterleitung von „Read-only“ Transaktionen direkt an Cloud Storage Lineare Skalierung bisher nur bis 80 Knoten getestet Keine vollständige Implementierung des System Möglicher Performanceengpass durch Zeitstempelgenerator Einschränkung der Verwendbarkeit des Systems durch Grundannahmen der Entwickler Transaktionen sind nur kurzlebig Jede Transaktion manipuliert nur kleine Datenmengen Partitionierung des Systems Zwei Möglichkeiten Einer der LTM kann sich zum Hauptverantwortlichen machen für StoragePart & Konsistenter Zustand der Daten ist herstellbar  System ist weiter verfügbar Alle anderen Fälle  Alle Transaktion werden abgelehnt bis die Konditionen wieder zutreffen Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

21 ElasTraS Kofferwort bestehende aus Entwickler Elastic Transaction
Data Store Entwickler Sudipto Das Divyakant Agrawal Amr El Abbadi vom Department of Computer Science, der UC Santa Barbara, CA, USA Department of Computer Science, UC Santa Barbara, CA, USA Entwickler sprechen hier bewusst von einem Data Store da das Wort Database System für Traditionelle Datenbanksystem reserviert ist. Das System unterstütz aber nur eine Subset von Operationen dieser Systeme Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

22 ElasTraS – Architektur
Elemente des Systems Load Balancer Higher Level Transaction Manager Metadata Manager and Master Owning Transaction Manager Distributed Storage Transaction Processing System Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

23 ElasTraS – Architektur
Distributed Storage von Amazon (S3) Nutzung vorhandener Cloud-Technologie als Raw Storage Feste Zuordnung zwischen OTM und Storage Zugriff der Web Application auf Raw Storage nur über „TPS“-System möglich Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

24 ElasTraS – Architektur
Exklusiver Schreibzugriff des OTM auf den zugeordneten Raw Storage Verwaltung der OTMs über den „Metadata Manager and Master“ (MMM) Bearbeitung von „Read-only“ Transaktionen in HTM Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

25 ElasTraS – Transaktionsverlauf
Client stellt Anfrage per Http Request Anfrage wird über einen Load Balancer an HTM übertragen HTM entscheidet ob er die Transaktion abhandeln kann Look Up der beteiligten OTM Weiterleitung der Subtransaktionen an die einzelnen OTM Checkpoint übertragen und Distributed Storage Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

26 ElasTraS – Vor- & Nachteile
Gute horizontale Skalierbarkeit Nutzung bereits vorhandener Cloud-Technologie Verschieden Anbieter des „Raw Storage“ möglich Keine vollständige Implementierung vorhanden Keine Performanceanalyse bisher möglich Performanceengpass durch Metadata Manager and Master Eventueller Zugriff von „read-only“ Transaktionen auf veraltete Daten, da lediglich auf HTM zugegriffen wird Keine Beschreibung des Load Balancer Nur eingeschränkte Zusicherung der ACID-Eigenschaften based on some load balancing policy ACID unterstützung nur bei statically partitioned setup  applications can limit transactions to single partitions Keine globale konsistenz über meherer partitionen hinweg / globale serializability Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

27 CloudTPS & ElasTraS – Fazit
ACID Eigenschafen Bedingte Unterstützung Volle Unterstützung Read-only Transaktionen Nur direkte Bearbeitung in den HTM möglich Bearbeitung in den LTM oder Direkt in Cloud Storgae Load Balancing Keine konkrete Lösung Lösung mittels Hashing Verwendung vorhandener Cloud Technologien Distributed Storage (S3) HBase Google Bigtable Amzone Simple DB Partitionstoleranz Gegeben Mögliche Problemstellen Metadata Manager and Master Zeitstempelgenerator Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS

28 Danke für die Aufmerksamkeit Fragen?
Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS