Kapitel 4: Record Stores und RDBMS -...
43
Cloud Data Management Kapitel 4: Record Stores und RDBMS 1 Dr. Andreas Thor Sommersemester 2011 Universität Leipzig Institut für Informatik http://dbs.uni-leipzig.de
Transcript of Kapitel 4: Record Stores und RDBMS -...
Cloud Data Management
Kapitel 4: Record Stores und RDBMS
1
Dr. Andreas ThorSommersemester 2011
Universität LeipzigInstitut für Informatikhttp://dbs.uni-leipzig.de
Inhaltsverzeichnis• Record Stores
– BigTable/HBase, Cassandra
– ACID-Eigenschaften: Megastore
– Replikation
• Relationale Datenbanken in der Cloud– H-Store/VoltDB
2
BigTable und HBase• Verteilte Datenspeicherung mit erweiterbarem relationalen Modell
– Spaltenorientierter Key-Value-Store
– Multi-Dimensional, Versioniert
– Hochverfügbar, High-Performance
• Ziele– Milliarden von Zeilen, Millionen von Spalten, Tausende von Versionen
– Real-time read/write random access
3
– Real-time read/write random access
– Große Datenmengen (mehrere PB)
– Lineare Skalierbarkeit mit Anzahl Nodes
• HBase ist Hadoop’s BigTable Implementation
BigTable HBase
Tablet Region
Master Server HBase Master
Tablet Server HBase Region Server
GFS HFS
SSTable File MapFile File
Einsatzfälle• Beispiel Web-Tabelle
– Tabelle mit gecrawlten Webseiten mit ihren Attributen/Inhalten
– Key: Webseiten-URL
– Millionen/Milliarden Seiten
• Szenarien– Random-Zugriff durch Crawler zum Einfügen neuer/geänderter Webseiten
– Batch-Auswertungen zum Aufbau eines Suchmaschinenindex
4
– Batch-Auswertungen zum Aufbau eines Suchmaschinenindex
– Random-Zugriff in Realzeit für Suchmaschinennutzer, um Cache-Version von Webseiten zu erhalten
Datenmodell• Verteilte, mehrdimensionale, sortierte Abbildung
(row:string, column:string, time:int64) � string
– Spalten- und Zeilenschlüssel
– Zeitstempel
– Daten bestehen aus beliebigen Zeichenketten / Bytestrings
• Zeilen– (nur) Lese- und Schreiboperationen auf eine Zeile sind atomar
5
– Speicherung der Daten in lexikographischer Reihenfolge der Zeilenschlüssel
[CDG+08]
Datenmodell (2)• Spalten
– können zur Laufzeit beliebig hinzugefügt werden
• Spaltenfamilien (column families)– Können n verwandte Spalten (ähnliche Inhalte) umfassen
– Spaltenschlüssel = Spaltenfamilie:Kennzeichen
– Benachbarte Speicherung von Spalten einer Familie
– innerhalb Familie: flexible Erweiterbarkeit um neue Spalten
6
– innerhalb Familie: flexible Erweiterbarkeit um neue Spalten
• Zeitstempel– mehrere Versionen pro Zelle
– festgelegte Versionszahl: automatisches Löschen älterer Daten
[CDG+08]
Datenmodell (3)• Konzeptionelle Sicht (alternativ)
Row Key Time Stamp Column Contents Column Family Anchor
“com.cnn.www” T9 Anchor:cnnsi.com CNN
T8 Anchor:my.look.ca CNN.COM
T6 “<html>.. “
T5 “<html>.. “
7
• Physische Speicherung Row Key Time Stamp Contents
com.cnn.www T6 “<html>..”
T5 “<html>..”
Row Key Time Stamp Anchor
com.cnn.www T9 Anchor:cnnsi.com CNN
T5 Anchor:my.look.ca CNN.COM
Architektur• Datenpartitionierung
– Zeilen in Tabelle sortiert nach Key
– Horizontale Partitionierung von Tabellen in Tablets
– Verteilung von Tablets auf mehrere Tablet Server
• Master Server– Zuordung: Tablet ↔ Tablet Server
– Hinzunahme/Entfernung von Tablet Servern
Master Server(GFS Master Server)
Tablet Server(GFS Chunk
Server)
Tablet Server(GFS Chunk
Server)
8
– Hinzunahme/Entfernung von Tablet Servern
– Lastbalancierung für Tablet Server
• Tablet Server– Verwaltung von ca. 10-1000 Tablets
– Koordiniert Lese- und Schreibzugriffe
– Tablet-Split für zu große Tablets (100-200MB)
– Replikation durch GFS
• Client– Kommunikation mit Tablet Server für Lesen und Schreiben
Server)
...
Server)
...Tablets (Chunks)
Tablet Location• Zweistufige Katalogverwaltung mit Root- und METADATA-Tabellen
• Root Tabelle– Verweis auf alle Tablets einer METADATA Tabelle
– wird niemals geteilt = genau ein Tablet
• METADATA Tabelle– Verweis auf alle Tablets (von User Tabellen)
– Identifikator: Tabellenname + letzte Zeile (Key)
9
– Identifikator: Tabellenname + letzte Zeile (Key)
– Tabellen sind sortiert nach Key
• Adressraum– Eintragsgröße: 1KB
– Tablet Größe: 128MB
– Adressierbare Tablets:
– Größe aller Tablets:
Tablet: Lese-und Schreibzugriffe• SSTable File
– Sortierte Map, unveränderbar nach Erstellung
– Bloom Filter zur Prüfung ob Daten vorhanden für row+column
• Schreiben– Schreiben in Transaction Log (for redo)
10
– Schreiben in Transaction Log (for redo)
– Schreiben in MemTable (RAM)
• Asynchron: Compaction (Verdichtung)– Minor: Kopieren von MemTable-Daten in SSTable (und entfernen aus Log)
– Merge: Zusammenführen von MemTable-Daten und SSTable zu neuer SSTable
– Major: Entfernen gelöschter Daten (=Merge in eine SSTable)
• Lesen– Zugriff auf MemTable-Daten und SSTables um Daten zu finden
Performanz• Anzahl der
1000Byte Lese-und Schreib-Opspro Sekunde
• Gute Skalierbarkeitfür bis zu 250 Tablet Server
11
250 Tablet Server
• Schreiben ist schneller als lesen– Commit-Log ist nur ein append; Lesen erfordert Zugriff auf MemTable + SSTable
• Wahlfreies Lesen (random reads) am langsamsten– Zugriff auf (alle) SSTables notwendig
• Scanning und sequentielles Lesen performanter– Ausnutzung sortierter Keys
BigTable vs. Cassandra
BigTable (CP) Cassandra (AP)
pro
Knot
en
Datenmodell (row, column, timestamp) → string
Lesen MemTable + SSTables
• Cassandra = BigTable-Modell + Dynamo-Infrastruktur
• Consistent Hashing auf Basis des Row-Key
12
pro
Knot
en
Schreiben Transaction Log + MemTable; asynchrone SSTable-Erstellung
meh
rere
Kno
ten
Partitionierung
Anfrage-Routing
Konsistenz
BigTable vs. RDBMS• BigTable-Eigenschaften
– Verteilte Punkt- und Scan-Anfragen für Reads/Writes
– Built-In-Replikation
– Skalierbarkeit
– Batch-Verarbeitung (Source/Sink für MapReduce)
– Denormalisierte Daten / breite, spärlich besetzte Tabellen
– kostengünstig
13
– keine Query-Engine / kein SQL
– Transaktionen und Sekundär-Indexe (extern) möglich, jedoch schlechte Performance
• RDBMS– deklarative Anfragen mit SQL (Joins, Group By, Order By …)
– automatische Parallelisierbarkeit auf verschiedenen PDBS-Architekturen
– Sekundär-Indexe
– Referenzielle Integrität
– ACID-Transaktionen, …
Megastore: Datenmodell• Hybrider Ansatz zwischen RDBMS und Data Store
• Ziel: Skalierbarkeit + Replikation + ACID-Transaktionen
• Relationales Schema – Tabellen und Properties (Attribute)
– Definition von Indexen
• Data Store– mehrwertige Properties (repeated)
14
– mehrwertige Properties (repeated)
– Abbildung auf BigTable-Modell
• BigTable-Modell– Row = Entity, Row key = (konkatenierter) Primary Key
– (row, column, timestamp) → value
Megastore: Partitionierung• Datenpartitionierung in RDBMS
– horizontal vs. vertikal (oder kombiniert)
– Ziel: Anfragen müssen nur von einem (oder wenigen) Knoten bearbeitet werden
– Auswahl nach Art der Anfragen (Projektion, Selektion)
– Problem: Anfragen über mehrere Relationen
• Megastore: Anwendungsspezifische Partitionierung von Entities zu Gruppen (Entity groups)
15
Gruppen (Entity groups)– Definition von Parent-Child-Beziehung zwischen Tabellen (foreign key, 1:N)
– Root-Table = Tabelle ohne Parent
– Entity group = eine Entity in Root-Table + alle seine (Kindes-)Kinder
• Beispiele– Mail-Programm: (Nutzer+Emails)
– Blogger: (NutzerProfil), (Blog+Posts)
Megastore: Beispiel CREATE TABLE User {
required int64 user_id;
required string name;
} PRIMARY KEY(user_id), ENTITY GROUP ROOT;
CREATE TABLE Photo {
required int64 user_id;
required int32 photo_id;
required int64 time;
required string full_url;
optional string thumbnail_url;
repeated string tag;
user_id name
1 Schmidt
2 Meier
user_id photo_id time tag ...
1 10 19:15 [Dinner,Paris] ...
User
Photo
16
repeated string tag;
} PRIMARY KEY(user_id, photo_id),
IN TABLE User,
ENTITY GROUP KEY(user_id) REFERENCES User;
1 11 19:18 [Dinner,Berlin] ...
2 10 15:34 [Berlin, Mauer] ...
Key user.name photo.time photo.tag photo. ...
1
1.10 ...
1.11 ...
2
2.10 ...
BigTable
EG1
EG2
MegaStore: Entity Groups• Transaktionen und konkurrierende Zugriffe
– ACID-Semantik innerhalb einer Entity Group (logischer Einbenutzerbetrieb, strong consistency)
– keine ACID-Garantie für Transaktionen über mehrere Entity Groups
• Replikation– Entity Groups werden synchron repliziert (auch über verschiedene Data Center)
– unabhängige Synchronisation verschiedener Entity Groups
17
• Indexes– lokal: nur innerhalb einer Entity Group
– global: über mehrere Entity Groups
CREATE LOCAL INDEX PhotosByTime
ON Photo(user_id, time);
CREATE GLOBAL INDEX PhotosByTag
ON Photo(tag) STORING (thumbnail_url);
Transaktionen
18[Megastore]
Transaktionen innerhalb einer Entity Group• ACID-Semantik: Änderungen zunächst in WAL (write-ahead log), erst
danach Anwendung
• Multi-Version Concurrency Control (MVCC)– Bigtable-Timestamp pro Transaktion zur Unterscheidung
– Read kann konsistente, ältere Versionen während Write lesen
– Write-Operation blockiert Lese-Operation nicht
• Transaktion
19
• Transaktion– Read: Bestimme Timestamp der letzten zugesicherten (commit) Transaktion +
Logfile Position
– Anwendungslogik: Lese Daten von Bigtable und erzeuge Logfile-Eintrag
– Commit: Einigung zwischen Knoten, dass Logfile-Eintrag geschrieben wird
– Apply: Durchführen der Operationen auf den Daten, Aktualisierung der Indexes
– Clean-up: Löschen nicht mehr benötigter Daten
Transaktionen innerhalb einer Entity Group (2)• Commit vor Apply
– Lese-Operationen müssen ggf. warten
– RDBMS: Commit (Daten sind “durable”) erst, wenn alle Daten “sichtbar”
• Reads– current: Warten, bis alle zugesicherten (comitted) writes durchgeführt, dann lesen
– snapshot: Timestamp der letzten vollständigen durchgeführten Transaktion (ggf. zugesicherte aber noch nicht durchgeführte Transaktion nicht erfasst)
20
– inconsistent: aktuelle Werte (dirty reads)
• Konkurrierende Writes– gleichzeitiger “Read-Schritt” in Transaktion liefert die gleiche Logfile-Position
– Einigungsprotokoll (Paxos) bestimmt eine Transaktion, die an die Position schreiben darf (“Winner”)
– andere (“losing”) Transaktionen werden “informiert” und abgebrochen, meist anschließendes Retry
– keine Serialisierung, aber Konsistenzsicherung
Transaktionen zwischen Entity Groups• Queue-Mechnismus
– Transaktions-Nachrichten zwischen Entity Groups
– Gesendet von einer Entity Group während Transaktion (an andere Entity Group)
– Asynchrone Ausführung, keine ACID-Transaktionssemantik
• 2-Phasen-Commit-Protokoll– Atomare Updates in Transaktionen zwischen Entity Groups möglich
– möglichst vermeiden, u.a. wegen hoher Latenz
21
– möglichst vermeiden, u.a. wegen hoher Latenz
Replikation• Unabhängige, synchrone Replikation pro Entity Group
– Anfügen von Logfile-Blöcken nach vorheriger Einigung (Paxos)
22[Megastore]
Replikation: Techniken• Backup
– Kopie des aktuellen Datenbestands
• Master/Slave– (meist asynchrone) Weiterleitung der Änderungen von Master an Slaves
– Bsp: MongoDB, Dynamo (einstellbar mit r/w-Quorum), GFS (synchron)
• Master-Master– unterschiedliche Versionen auf unterschiedlichen Knoten, Konfliktauflösung nötig
23
– unterschiedliche Versionen auf unterschiedlichen Knoten, Konfliktauflösung nötig
– Bsp: CouchDB
• 2-Phasen-Commit (2PC)– verteiltes Protokoll mit Koordinator-Knoten (Problem: Koordinatorausfall)
– synchron: “Propose, vote, commit/abort”
– Bsp: Verteilte DB
Replikation: Übersicht
Backup Master-Slave Master-
Master
2PC Paxos
Konsistenz
Transaktionen
Latenz niedrig niedrig niedrig hoch hoch
[Google I/O 2009 - Transactions Across Datacenters]
24
Latenz niedrig niedrig niedrig hoch hoch
Durchsatz hoch hoch hoch niedrig mittel
Datenverlust “viel” “etwas” (async) “etwas” nein nein
Verfügbarkeit bei Ausfall
Paxos: Verteiltes Einigungsprotokoll• Mehrere Knoten müssen sich auf auf einen Wert einigen
– Szenarien: welche Transaktion darf schreiben, Wahl eines Primary Knotens, Datenreplikation, ...
• Bedingung– Knoten funktionieren entweder ganz oder gar nicht; Recovery möglich
– Nachrichten werden korrekt (vollständig) gesendet oder gar nicht
– Knoten haben nicht-flüchtigen Speicher
25
• Vorteile– fehlertolerant, d.h. geringer Einfluss von Knotenausfällen (im Gegensatz zu 2PC)
– garantierte Korrektheit und Terminierung (im Gegensatz zu 3PC)
Paxos – Phase 1• N Prozesse
– jeder Prozess kann Werte vorschlagen (propose), akzeptieren (accept) und lernen (learn)
– jeder Prozess hat Wertebereich für eigene Nachrichten, die in aufsteigenderReihenfolge verwendet werden (i-ter Prozess: i, i+N, i+2N, ...)
– vor Senden einer Nachricht wird Nummer auf nichtflüchtigem Speicher gesichert
• Client “beauftragt” einen Prozess als Proposer
• Phase 1a: Proposer schickt Nachricht an andere Prozesse und sich selbst
26
• Phase 1a: Proposer schickt Nachricht an andere Prozesse und sich selbst– PREPARE (n) – Nachricht-Nummer n
• Phase 1b: Prozesse reagieren auf PREPARE-Nachricht– Lesen der letzten Nachrichten-Nummber n’ auf die geantwortet wurde
– Wenn n > n’ (oder es kein n’ gibt)• PROMISE (n, v’): “Ich nehme nie eine PREPARE-Nachricht mit Nummer <n an.”
• zusätzlich (wenn n’ vorhanden) Mitteilung von (n’, v’)
– andernfalls ignorieren
Paxos – Phase 2• Phase 2a: Wenn Proposer von Mehrheit der Prozesse (>N/2) ein
PROMISE erhalten hat, sendet er ACCEPT– ACCEPT(n, v’) - neue Nachrichtennummer n
– v’ = von Antwortnachricht (n’,v’) mit höchstem n’• wenn keine, dann eigenen Vorschlagwert
• Phase 2b: Prozess reagieren auf ACCEPT-Nachricht– Lesen der letzten Nachrichten-Nummber n’ auf die geantwortet wurde
27
– Wenn n > n’ (oder es kein n’ gibt)• Speichern von (n,v) und ACCEPTED (n,v)
– andernfalls ignorieren
• Wenn Proposer auf Mehrheit der Prozesse eine Antwort ACCEPT erhalten hat, ist der Vorschlag angenommen → Einigung
• Weiterleiten der Nachrichten an alle Prozesse (Learning)
Paxos: Probleme• Ausfall eines Acceptors
– kein Problem, solange Quorum (Mehrheit) erreicht wird
• Ausfall eines Learners– ggf. neu Senden
• Ausfall des Proposers– Ausfall nach PROPOSE aber vor Einigung
– Lösung durch Bestimmung eines neuen Proposers
28
– Lösung durch Bestimmung eines neuen Proposers
• Mehrere Proposer– Ausfall eines Proposers, Bestimmung eines neuen
– Recovery des ausgefallenen vor Einigung
– Wechselseitige PREPARE-Nachrichten “überstimmen” sich
– Lösung z.B. durch “zufällige Timeouts”, so dass ein Proposer sich durchsetzt
• Allgemein: Fortschritt und Korrektheit kann garantiert werden
Inhaltsverzeichnis• Record Stores
– BigTable/HBase, Cassandra
– ACID-Eigenschaften: Megastore
• Relationale Datenbanken in der Cloud– H-Store/VoltDB
29
Szenario: RDBMS und das Web• Web-Anwendung nutzt RDBMS
– irgendwann reicht ein (großer) Datenbankserver nicht mehr aus
– Skalierbarkeit durch verschiedene Techniken
• Verteiltes Caching– Problem der Aktualisierung, begrenzte Funktionalität
• Replikation der Datenbank– Lese-Workload kann verteilt werden, dafür Schreibzugriffe auch auf mehreren
30
– Lese-Workload kann verteilt werden, dafür Schreibzugriffe auch auf mehreren Knoten
• Data Sharding– Partitionierung der Daten über verschiedene Knoten
– Anwendung verwaltet Sharding: Serverausfälle, Anfragen/Transaktionen die über mehrere Knoten gehen, Re-Sharding, ...
• Ziel: Datenbank/Data Store kümmern sich um – Verteilung der Daten, Performanz, Behandlung von Ausfällen, ...
http://www.slideshare.net/VoltDB/10-rulesforscalabledatastoreperformance
Cloud Data Stores• Kein SQL (NoSQL Data Stores)
– einfacheres Datenmodell, einfache Operationen (Suche mit Schlüssel)
• Einfacheres Modell für konkurrierende Zugriffe– (meist) keine ACID-Semantik, nächste Folie
• Abgeschwächtes Konsistenzmodell– Replikation meist asynchron
– Eventual consistency: Clients können zur selben Zeit verschiedene Daten lesen
31
– Eventual consistency: Clients können zur selben Zeit verschiedene Daten lesen
– konfigurierbarer Tradeoff zwischen Konsistenz und Performanz (read-write-Quorum)
• Erhöhte Anforderung an Client-Applikation, u.a.– Auflösung von Konflikten
• Bsp: Mischen verschiedener Warenkörbe
– Umgang mit Fehlern auf Grund fehlender Transaktionen • Bsp: gleichzeitiges Kaufen des letzten Produkts
– Handling von eventual Consistency • Bsp: verzögerte Aktualisierung des Facebook-Status bei Freunden
http://www.slideshare.net/VoltDB/10-rulesforscalabledatastoreperformance
Behandlung konkurrierender Zugriffe• Einfache Sperren pro Objekt/Dokument
– Nur ein Client kann gleichzeitig auf ein Objekt/Dokument/Record zugreifen
– Bsp: Azure Storage, MongoDB, BigTable
• MVCC – Multi version concurrency control– Erstellung und Management mehrere Versionen des gleichen
Objekts/Dokuments/Records pro Knoten
– Client leistet Konfliktauflösung
32
– Bsp: Dynamo, CouchDB, Cassandra
• keine Behandlung– keine Garantien hinsichtlich resultierender Daten bei konkurrierenden Zugriffen
– Bsp: SimpleDB
• ACID– logische Serialisierung von Transaktionen (u.a. durch Sperren)
– Bsp: RDBMS, MegaStore (teilweise), VoltDB
[Sigmod Record]
RBDMS-Designprinzipien• RBDMS wurden für Shared-Memory und (später) Shared-Disk-
Architekturen entwickelt– Cloud Data Center: Shared Nothing
• RDBMS wurden primär für Speicherung und Verarbeitung von Daten auf Festplatten entwickelt; Hauptspeicher “nur” für Caching– zunehmende Größe des Hauptspeichers ermöglicht andere Nutzungsformen
• RDBMS realisieren Recovery durch Logfiles auf Festplatte
33
• RDBMS realisieren Recovery durch Logfiles auf Festplatte– Schnelle Netzwerkstruktur ermöglicht Recovery durch Kopieren von Knoten
• RDBMS realisieren eine strenge Transaktionssemantik (ACID) zur Sicherung des Datenkonsistenz durch Locking– Internet-Anwendungen können mit vereinfachten Konsistenzmodellen umgehen
• RDBMS unterstützen Multi-Threading– Gründe: T2 kann bereits ausgeführt werden, wenn T1 auf Daten (von Platte) wartet;
lange Transaktionen sollen kurze nicht blockieren (geringe Latenz)
– Szenario nicht mehr stets relevant (multi core, Hauptspeicherzugriff, OLTP workload)
Zeitaufteilung für RDBMS• 13% “sinnvoll”
– Finden relevanter Daten, Aktualisieren der Werte
• 20% Locking– Setzen, Aufheben und Verwalten von Sperren, Deadlock-Erkennung
– Ziel: Logischer Einbenutzerbetrieb
• 23% Logging– Schreiben/Lesen von Logfiles
34
– Schreiben/Lesen von Logfiles
– Ziel: Redo Recovery (Wiederherstellung bei Ausfall), Undo Recovery (Wiederherstellung des Ursprungszustands bei Transaktionsabbruch)
• 33% Buffer Management – Abbildung der Tabellen bzw. Datensätze in Seiten (Pages), die dann blockweise auf
Festplatte gepeichert werden
• 11% Latching im Mehrbenutzerbetrieb– Kurzzeitsperren für interne Datenstrukturen bei Mehrbenutzerbetrieb
Harizopoulos, S. et. al., “OLTP: Through the Looking Glass and What We Found There,” SIGMOD, June 2008.
RDBMS-Nutzung für Web-Anwendungen• Erfolg einfacher Data Stores (KV, Document) zeigt, dass
Datenunabhängigkeit nicht im Fokus steht– enge Verzahnung von Web-Anwendung und Data Store
• Viele Web-Anwendungen haben einfache(re) Nutzungsformen– OLTP mit einfachen Schreib/-Lese-Operationen
– wenige Datensätze schreiben und lesen pro Transaktion
• Transaktionen sind im Vorfeld bekannt
35
• Transaktionen sind im Vorfeld bekannt– keine ad-hoc Anfragen
• Transaktionen sind meist vergleichsweise einfach– keiner User Stalls
– Nicht: komplexe Joins, OLAP, etc.
HStore: Überblick• Verteilte Datenbank
– mehrere Knoten (Shared-Nothing), pro Knoten ein oder mehrer Sites
– ein Site pro CPU = single-threaded Datenbank → kein Latching
• Hauptspeicher-Datenbank– zeilen-orientierte Speicherung im Hauptspeicher (B-Tree) → kein Buffer Pool
• Transaktionen– keine ad-hoc SQL-Anfragen, nur Stored Procedures (SP)
36
– keine ad-hoc SQL-Anfragen, nur Stored Procedures (SP)
– direkter Zugriff und Datentransfer (kein ODBC)
– Transaktionen (SP) werden a-priori registriert und klassifiziert (z.B. “two phase”)
– Globale Reihenfolge von Transaktionen → strenge Konsistenz
– ACID-Eigenschaften
• Recovery– Recovery mittels Replikate → kein Logging
• VoltDB ≈ HStore als Open-Source-Produkt (mit Firma für Support)
HStore: Site-Architektur
37Jones, Abadi, and Madden, "Low overhead concurrency control for partitioned main memory databases,“ SIGMOD 2010
Datenpartitionierung und Transaktionen• Viele Schemas sind “Tree Schemas”
– ein (oder mehrere) Root-Tabellen (z.B. Kunde)
– andere Tabellen haben (mehrfache) 1:N-Beziehung zu Root-Tabelle
• Horizontale Partitionierung der Root-Tabelle– Horizontale Partitionierung der anderen Tabellen gemäß Root-Tabellen-
Partitionierung
– Alle Informationen zu einem “Root-Datensatz” in gleicher Partition
38
– vgl. Entity Group in Megastore
• Ziel: Ausnutzen von “Single Site”-Transaktionen– Alle Operationen einer Transaktion in selber Partition (häufiger Fall)
• Weitere Arten von Transaktionen– Two-Phase: “erst nur Reads, evtl. Abort, dann alle Writes”
– Commute: beliebige Verschränkung zweier Transkationen führt stets zum gleichen Ergebnis
HStore: Infrastruktur
39
Ausführung von Transaktionen• Transaktionen erhalten eindeutigen Timestamp
– (site_id, local_unique_timestamp)
– Alle Sites sind geordnet, Uhrzeiten zwischen Sites (nahezu) synchron
– globale Ordnung
• Replikation– 2+ Kopien jeder Tabelle
– Reads an beliebige Site, Writes werden an alle Sites gesendet
40
– Reads an beliebige Site, Writes werden an alle Sites gesendet
• Single-Site Transaktionen– Primary Site sendet an Secondary (Backup) Sites weiter
– “etwas warten”, um sicherzustellen, dass keine früheren Transaktionen kommen
– Unabhängige, parallele Ausführung• Annahme: Lokales Ergebnis (commit oder abort) = globales Ergebnis
• An Client = Primary Transaktionsergebnis, nachdem alle Secondary ein “acknowledge” geschickt haben (≠Transaktionsergebnis)
– Kein ReDo-Log, keine Concurrency Control
– Two-Phase Transaktionen: Zusätzlich kein UnDo-Log
Multi-Node-Transaktion• Multi-Node-Transaktion durch zentralen Koordinator
– Globale Reihenfolge der Transaktionen
– Einsatz mehrere Koordinator möglich mit globaler Reihenfolge
• Ausführung– Zerlegung in mehrere Fragmente, die jeweils an Site geschickt werden
– Undo-Puffer um bei evtl. Abbruch Ursprungszustand wieder herzustellen
• Abschluss
41
• Abschluss– nach Bearbeitung des letzten Fragments sendet Primary alle Fragmente an alle
Secondary und wartet auf “acknowledge”
– Prüfung auf commit/abort nicht nötig, da gleiches Ergebnis wie Primary
Zusammenfassung• Relational Data Stores und RDBMS
– Umsetzung von RDBMS-Aspekten in Shared-Nothing-Architekturen
– Erweiterung von einfachen Data Stores um Anfragemächtigkeit und Indexes
• Konsistenzsicherung– abgeschwächte ACID-Semantik
– MVCC-Prinzip um konsistente Vorversionen während Writes lesen zu können
• Performanz-Aspekte
42
• Performanz-Aspekte– Daten in Hauptspeicher
– möglichst wenige Plattenzugriffe• nur “komplette” SSTables einmal schreiben (BigTable)
• Realisierung Logfile-basierter RDBMS-Techniken ohne Plattenzugriffe
– möglichst wenige Multi-Node-Operationen durch geschickte anwendungs/schema-spezifische Datenpartitionierung
– Fokus auf spezielle OLTP-Anwendungen
Referenzen• [HBase] http://hadoop.apache.org/hbase/
• [BigTable] Fay Chang, Jeffrey Dean, Sanjay Ghemawat et al. Bigtable: A Distributed Storage System for Structured Data. OSDI’06
• [Megastore] Baker et al: Megastore: Providing Scalable, Highly Available Storage for Interactive Services . CIDR’11
• [OLTP] Harizopoulos et al: OLTP through the looking glass, and what we found there. SIGMOD, 2008
43
found there. SIGMOD, 2008
• [HStore] Stonebraker et al: The end of an architectural era: (it’s time for a complete rewrite), VLDB 2007
