View
106
Download
1
Category
Preview:
Citation preview
IPV
S -
Un
ive
rsitä
t S
tutt
gart
Hauptseminar NoSQL
ElasTraS und CloudTPS
Stefan Wenz
IPV
S -
Uni
vers
ität S
tuttg
art
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
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 2
IPV
S -
Uni
vers
ität S
tuttg
art
Cloud Computing
Übertragung von Risiken Kosten nur für tatsächlich genutzte Ressourcen Scheinbar unbegrenzte Ressourcen
Problem: Anpassungen bestehenden Programmen
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 3
IPV
S -
Uni
vers
ität S
tuttg
art
Inhalt der Präsentation
Grundlagen CAP-Theorem Datenbank Konzpte
Relationale Datenbanksysteme No-SQL Systeme CloudTPS
Architektur Performance & Fehlertolerance Vor- & Nachteile
ElasTraS Architektur Vor- & Nachteile
Fazit
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 4
IPV
S -
Uni
vers
ität S
tuttg
art
Grundlagen – CAP Theorem
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 5
X
Xr
IPV
S -
Uni
vers
ität S
tuttg
art
Grundlagen – CAP Theorem
Ein verteiltes System kann nur gleichzeitig zwei der drei Eigenschaften erfüllen!
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 6
IPV
S -
Uni
vers
ität S
tuttg
art
Grundlagen – Datenbank Konzepte
Bekanntes Konzept: ACID Atomizität Konsistenz Isolation Dauerhaftigkeit
Für verteiltes System neues Konzept: BASE Basic Available Soft State Eventual Consistency
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 7
IPV
S -
Uni
vers
ität S
tuttg
art
Relationale Datenbanksysteme - Vorteile
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 8
PersonenID Name Verdienst 001 Peter 10.000 002 Alexander 15.000
AbteilungsID Abteilungsname 001 Buchhaltung 002 Personal
PersonenID AbteilungsID 001 002 002 001
IPV
S -
Uni
vers
ität S
tuttg
art
Relationale Datenbanksysteme
+ Standardisierte Anfragesprache
+ Referenzierbarkeit
+ Strukturierbarkeit von Daten
+ Trennung physikalischer und logischer Zugriff
+ Definierbarkeit von Sichten
- Begrenzte horizontale Skalierbarkeit
- Fest definiertes Schema
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 9
IPV
S -
Uni
vers
ität S
tuttg
art
Übersicht NoSQL-Systeme
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 10
IPV
S -
Uni
vers
ität S
tuttg
art
NoSQL-Systeme
Keine Verwendung von SQL als AnfragespracheKeine Definition
+Viel verschiedene Arten
+Gute horizontale Skalierbarkeit
-Keine Unterstützung des Transaktionskonzepts
-Dokumentation oftmals lückenhaft
-Nicht realisierte Leistungsmerkmale
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 11
IPV
S -
Uni
vers
ität S
tuttg
art
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.
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 12
IPV
S -
Uni
vers
ität S
tuttg
art
CloudTPS - Architektur
Elemente des Systems Transaction Processing System (TPS)
Virtual Nodes Local Transaction Manager (LTM)
Cloud Storage Service
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 13
IPV
S -
Uni
vers
ität S
tuttg
art
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
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 14
IPV
S -
Uni
vers
ität S
tuttg
art
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
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 15
IPV
S -
Uni
vers
ität S
tuttg
art
CloudTPS – ACID
Atomizität Zwei-Phasen-Übertragung (2PC)
1. Ermittlung aller an einer Transaktion beteiligten LTM
2. Anfrage an alle beteiligte LTM ob Datenmanipulation möglich
3. Rückmeldung von allen beteiligten LTM „COMMIT“
4. Start Transaktion
5. Keine Übereinkunft Reject der Transaktion
Konsistenz Grundannahme:
Datenbank ist in einem konsistenten Zustand
Bindende Konsistenzregeln für alle Transaktionen
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 16
IPV
S -
Uni
vers
ität S
tuttg
art
CloudTPS – ACID
Isolation1. Aufteilung der Transaktion in Sub-Transaktionen
Aufteilungskriterium: Zugriff auf ein einzelnes Datenelement
2. 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
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 17
IPV
S -
Uni
vers
ität S
tuttg
art
CloudTPS – Perfromance & Fehlertoleranz
Lineare Skalierbarkeit bis 40 LTM
Fehlertoleranz des Systems
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 18
IPV
S -
Uni
vers
ität S
tuttg
art
CloudTPS – Transaktionsverlauf
1. Client stellt Anfrage per Http Request
2. Anfrage wird von der Web Application an TPS übertragen
3. Transaktion wird von beliebigen LTM angenommen
4. Look-Up welche anderen LTM beteiligt sind
5. Start 2PC Anfragen & Antwort abwarten
6. Verteilen der Subtransaktionen und Start der Transaktion
7. Checkpoint backup in Cloud Storage
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 19
?!
IPV
S -
Uni
vers
ität S
tuttg
art
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
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 20
IPV
S -
Uni
vers
ität S
tuttg
art
ElasTraS
Kofferwort bestehende aus 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
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 21
IPV
S -
Uni
vers
ität S
tuttg
art
ElasTraS – Architektur
Elemente des Systems Load Balancer Higher Level Transaction Manager Metadata Manager and Master Owning Transaction Manager Distributed Storage
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 22
TransactionProcessingSystem
IPV
S -
Uni
vers
ität S
tuttg
art
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
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 23
IPV
S -
Uni
vers
ität S
tuttg
art
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
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 24
IPV
S -
Uni
vers
ität S
tuttg
art
ElasTraS – Transaktionsverlauf
1. Client stellt Anfrage per Http Request
2. Anfrage wird über einen Load Balancer an HTM übertragen
3. HTM entscheidet ob er die Transaktion abhandeln kann
4. Look Up der beteiligten OTM
5. Weiterleitung der Subtransaktionen an die einzelnen OTM
6. Checkpoint übertragen und Distributed Storage
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 25
IPV
S -
Uni
vers
ität S
tuttg
art
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
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 26
IPV
S -
Uni
vers
ität S
tuttg
art
CloudTPS & ElasTraS – Fazit
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 27
ElasTras CloudTPS
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) HBaseGoogle BigtableAmzone Simple DB
Partitionstoleranz Gegeben Gegeben
Mögliche Problemstellen
Metadata Manager and Master
Zeitstempelgenerator
IPV
S -
Uni
vers
ität S
tuttg
art
Danke für die Aufmerksamkeit
Fragen?
11.04.23Hauptseminar NoSQL WS10/11 – ElasTraS & CloudTPS 28
Recommended