Hauptseminar NoSQL ElasTraS und CloudTPS Stefan Wenz

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 25.03.2017

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 25.03.2017

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 25.03.2017

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 25.03.2017

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

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 25.03.2017

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

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 25.03.2017

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

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 25.03.2017

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 25.03.2017

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

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 25.03.2017

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 25.03.2017

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 25.03.2017

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 25.03.2017

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 25.03.2017

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 25.03.2017

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 25.03.2017

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 25.03.2017

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 25.03.2017

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 25.03.2017

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

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 25.03.2017

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 25.03.2017

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 25.03.2017

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