MV-Serialisierungsgraph

Transkript

1 MV-Serialisierungsgraph Unter der Versionenordnung eines Objektes x œ DB wird eine totale Ordnung aller in S über und DB erzeugten Versionen von x verstanden. Die Vereinigung aller Versionenordnungen der Objekte aus DB heisst Versionenordnung von S und wird mit bezeichnet. Allerdings ist diese Versionenordnung nicht unbedingt gleich der zeitlichen Reihenfolge, in der die Versionen erzeugt werden! MV-Serialisierungsgraph: Sei S ein Mehrversionen-Schedule über und DB und eine Versionenordnung zu S. Der MV-Serialisierungsgraph MVSG(S, ) zu S und ist ein Graph für den folgendes gilt: Knoten: Jede Transaktion T œ ist ein Knoten Kanten:. Falls w i (x i ) und r k (x i ) aus S mit w i (x i ) < r k (x i ), dann enthält MVSG(S, ) eine Kante T i Ø T k (liest-von-beziehung, Kante analog einem w/r-konflikt im gewöhnlichen Serialisierungsgraphen) 2. Falls w i (x i ) und r k (x m ) (i m k) aus S und x i x m, dann enthält MVSG(S) die Kante T i Ø T m ; sonst (also bei x m x i ) eine Kante T k Ø T i. (Versionenkanten) 5-76 Eigenschaften von MVSG Die Zyklenfreiheit des Serialisierungsgraphen, der nur aus den liest-von- Abhängigkeiten besteht, der also allein durch Regel gebildet wird, reicht für MVSR nicht aus! Beispiel: S = w 0 (x 0 ) w 0 (y 0 ) C 0 r (x 0 ) r (y 0 ) w (x ) w (y ) C r 2 (x 0 ) r 2 (y ) C 2 Ò S ist serieller MV-Schedule mit azyklischem SG (bezüglich der liest-von-abhängigkeiten): T T 0 T 2 Allerdings ist S nicht äquivalent zu einem seriellen Ein-Versionen-Schedule Die beiden seriellen Ein-Versionen-Schedules S bzw. S sind: S = w 0 (x) w 0 (y) C 0 r (x) r (y) w (x) w (y) C r 2 (x) r 2 (y) C 2 Ò S = w 0 (x) w 0 (y) C 0 r 2 (x) r 2 (y) C 2 r (x) r (y) w (x) w (y) C Ò beide besitzen jedoch unterschiedliche RF-Relationen! 5-77

2 MVSG und Versionenkanten Da die liest-von-abhängigkeiten alleine nicht ausreichen, müssen durch Regel 2 weitere Kanten (Versionenkanten) in den MVSG eingeführt werden, so dass auch die Reihenfolge der Versionen berücksichtigt wird. Für jedes Paar w i (x i ) und r k (x m ) gilt daher: x i x m führt zu Kante T i Ø T m und erzwingt damit w i (x i )vor w m (x m ) in S ser T k MVSG(S, ) Regel (Liest-von- Beziehung) T k T i T m r k (xm) t T i T m w i (x i ) w m (x m ) Regel 2 (Versionenkante) x m x i führt zu Kante T k Ø T i und erzwingt damit w i (x i )nach r k (x m ) in S ser Regel 2 Tk (Versionenkante) T m T k T i w m (x r k m ) (x m ) w i (xi) T t i Regel (Liest-von- Beziehung) T m 5-78 Korrektheitstest von MVSR Satz: Ein MV-Schedule S ist MVSR ñ es gibt eine Versionenordnung zu S, so dass der MV-Serialisierungsgraph zu S und azyklisch ist. Beispiel: Gegeben sei folgender Schedule über den Transaktionen T -T 4 sowie die Versionenordnung y y 3 y 2 T w (x ) w (y ) MVSG(S, ): T 4 T 2 r 2 (x ) w 2 (y 2 ) T 3 w 3 (y 3 ) T 4 r 4 (x ) r 4 (y 2 ) T i= k=4 m=2 T 2 T 3 i=3 k=4 m=2 Da MVSG(S, ) azyklisch ist, ist S MVSR. Äquivalente serielle Ein-Kopien-Schedules sind: T < T 3 < T 2 < T 4 Ò oder T 3 < T < T 2 < T 4 Ò Liest-von-Kanten (Regel ) Versionen-Kanten (Regel 2)

3 Beispiel für Mehrversionen-CC: Snapshot Isolation Bisher haben wir für jede Transaktion T k nur die Aktionen r k (x) bzw w k (x) sowie die Beendigung von T k betrachtet (entweder durch Commit C k oder Abort A k ) Für die Formalisierung der Snapshot Isolation benötigen wir jetzt zusätzlich noch folgende Informationen für jede Transaktion T k Read-Set RS(T k ): Menge der Datenobjekte, welche von T k gelesen werden Write-Set WS(T k ): Menge der Datenobjekte, welche von T k geschrieben werden Start von T k : BOT k (Begin-of-Transaction) In den folgenden Beispiel-Schedules werden wir den Beginn BOT k einer Transaktion T k nicht explizit einfügen. Die erste Aktion von T k soll gleichzeitig auch der Start der Transaktion sein Definition der Snapshot-Isolation Idee: Jede Transaktion T k erhält eine eigene Version (Snapshot) der Datenbank beim Transaktionsbeginn zugewiesen. Dieser Snapshot ist für die komplette Lebensdauer von T k gültig. Snapshot Isolation (SSI): Ein Mehrversionen-Schedule über einer Menge von Transaktionen erfüllt das Kriterium der Snapshot-Isolation (SSI), wenn die folgenden Bedingungen eingehalten werden: (SSI-V) r k (x i ) gilt: w i (x i ) < C i < BOT k < r k (x i ) und ± w m (x m ) mit: w m (x m ) < BOT k und C i < C m < BOT k (SSI-W) T i, T k mit (BOT i < BOT k < C i ) (BOT k < BOT i < C k ) gilt: WS(T i ) WS(T k ) = SSI-V: Ordnet einem Leser r k immer den jüngsten, zum Startzeitpunkt von T k committeten Wert zu (= Versionenzuordung) SSI-W: Je zwei parallele Transaktionen müssen paarweise disjunkte Write-Sets besitzen 5-8 3

4 SSI Beispiele Beispiel : S = r (x) r 2 (y) w 2(x) r 2 2(x) C 2 w 3(y) C Ò Mehrversionenschedule: S = r (x 0 ) r 2 (y 0 ) w 2(x ) r 2 2(x 0 ) C 2 w 3(y ) C Ò Sei: x 0 x und y 0 y Test auf MVSR: MVSG azyklisch fl S œ MVSR Test auf SSI: (SSI-W): WS(T ) = {x,y}, WS(T 2 ) = fl WS(T ) WS(T 2 ) = (SSI-V): ebenfalls erfüllt fl S œ SSI Beispiel 2: S 2 = r (x) r 2 (y) w 2 2(y) C 2 r 2(y) w 3(y) C Ò Mehrversionenschedule: S 2 = r (x 0 ) r 2 (y 0 ) w 2 2(y 2 ) C 2 r 2(y 2 ) w 3(y ) C Ò Sei: y 0 y 2 y Test auf MVSR: MVSG azyklisch fl S 2 œ MVSR view-äquivalenter Ein-Kopien-Schedule ist T 0 <T 2 <T Ò Test auf SSI: (SSI-W): NICHT erfüllt, da WS(T ) = WS(T 2 ) = {y} (SSI-V): ebenfalls nicht erfüllt. fl S 2 SSI Versionenzuordnung in SSI Die Wahl der Versionenzuordnung bot bei der Mehrversionen-View- Serialisierbarkeit einen zusätzlichen Freiheitsgrad und die Möglichkeit, Lesern geeignete Versionen eines Datenobjektes zuzuordnen. Bei SSI ist die freie Wahl der Versionenzuordnung jedoch nicht möglich (da Vorgabe durch SSI-V). Zusätzlich ist die Versionenordnung SSI durch SSI-V und SSI-W bereits fest vorgegeben: Versionenordnung SSI Aus SSI-V und SSI-W folgt für die Versionenordnung SSI : x i SSI x k ñ C i < C k

5 SSI Beispiele (Fortsetzung) Beispiel 3: S 3 = r (x) r 2 (y) r 2 2(x) r 2(y) w 2 3(x) w 3(y) C C 2 Ò Mehrversionenschedule (einzige mögliche Versionenordnung) : S 3 = r (x 0 ) r 2 (y 0 ) r 2 2(x 0 ) r 2(y 0 ) w 2 3(x 2 ) w 3(y ) C C 2 Ò Versionenordnung: x 0 x 2 und y 0 y Test auf SSI: (SSI-W): WS(T ) = {y}, WS(T 2 ) = {x} fl WS(T ) WS(T 2 ) = (SSI-V): ebenfalls erfüllt fl S 3 œ SSI Test auf MVSR: MVSG(S 3, ) enthält Zyklus fl S 3 MVSR!!! T 0 T T 2 fl SSI erlaubt also Schedules, die entgegen unserer ursprünglichen Annahme keine äquivalente serielle (Ein-Kopien-)Ausführung besitzen!!! 5-84 Praktisches Beispiel Relationen Konto Zins (KontoNr, Saldo, KontoInhaber), (KontoNr, Zinssatz) Transaktion T (Zinsbestimmung): Lese Kontostand Falls 5000 < Kontostand < 0000 erhöhe Zins um %, falls Kontostand > 0000 erhöhe Zins um 2% Transaktion T 2 (Zinsauszahlung): Lese kontospezifischen Zinssatz Buche Zins auf Konto Initialwert für KontoNr 47: Kontostand = 9999 Zins = 3%

6 Praktisches Beispiel Transaktion T : > Select Saldo from Konto where KontoNr = 47; > Select Zinssatz from Zins where KontoNr=47; > Update Zins Set Zinssatz = Zinssatz+ where KontoNr = 47; > commit; t Transaktion T 2 : > Select Zinssatz from Zins where KontoNr = 47; > Select Saldo from Konto where KontoNr = 47; > Update Konto set Saldo = Saldo*Zinssatz where KontoNr = 47; > commit; S 3 = r (x) r 2 (y) r 2 2 (x) r 2 (y) w 2 3 (x) w 3 (y) C C 2 Ò 5-86 Praktisches Beispiel S 3 ist nicht MVSR (es existiert nur eine mögliche Versionenzuordnung; für diese existiert Zyklus im MV-Serialisierungsgraphen) Allerdings ist S 3 korrekt bezüglich SSI da sowohl (SSI-V) als auch (SSI-W) erfüllt sind! Beide möglichen seriellen (und damit korrekten) Abläufe liefern jedoch andere Ergebnisse (entweder höheren Zinssatz oder höheren Kontostand) T Ø T 2 : Saldo = 0399 und Zinssatz = 4% T 2 Ø T : Saldo = 0299 und Zinssatz = 5% Hier jedoch: Saldo = 0299 und Zinssatz = 4% SSI wird in der Isolationsstufe serializable vom verschiedenen Datenbanksystemen (z.b. Oracle) verwendet!

7 Test auf SSI Der Test auf Mehrversionen-Sicht-Serialisierbarkeit (MVSR) lässt sich auf elegante Art und Weise mit Hilfe des MV-Serialisierungsgraphen MVSG durchführen. Ist ein ähnliches Verfahren auch für SSI möglich? Unter der Einschränkung, dass keine Blind Writes erlaubt werden (d.h. T i œ S: WS(T i ) \ RS(T i ) = Ÿ r i (x k ) < w i (x i ) ) ist dies möglich! Grundlage dieses graphisch orientierten Tests ist der SSI-Serialisierungsgraph (SSI-SG). SSI-SG entspricht dem MV-Serialisierungsgraphen mit der Ausnahme, dass alle Kanten den Bezeichner des jeweiligen Datenobjektes, das die Abhängigkeit verursacht, tragen SSI-Serialisierungsgraph SSI-Serialisierungsgraph: Sei S ein Mehrversionenschedule über und DB, der die Bedingung SSI-V erfüllt. Der SSI-Serialisierungsgraph SSI-SG(S, SSI ) zu S und SSI ist definiert durch Knoten: Jede Transaktion T œ ist ein Knoten Kanten:. Für jedes r k (x i ) in S existiert eine Kante T i Ø T k mit dem Bezeichner x (liest-von-kante) 2. Für jedes Paar r k (x m ) und w i (x i ) gibt es eine Kante T i Ø T m, mit Bezeichner x, falls x i SSI x m T k Ø T i, mit Bezeichner x, falls x m SSI x i (Versionen-Kanten)

8 Zyklenfreiheit von SSI-SG Satz (x-zyklenfreiheit des SSI-SG): Ein Mehrversionenschedule, der SSI-V erfüllt und der keine Blind Writes beinhaltet ist in SSI genau dann, wenn es kein Objekt x gibt, für das ein x-zyklus in SSI-SG existiert. Beweis siehe R. Schenkel, G. Weikum, N. Weissenberg, X. Wu Federated Transaction Management with Snapshot Isolation. In: Proceedings of the TDD 99 Workshop, Dagstuhl, Sept Das Verbot der Blind Writes ist in diesem Fall wichtig, denn es garantiert, dass durch die zusätzlichen Leseaktionen, die vor jedem Schreiben gefordert werden, durch Bedingung 2 des SSI-SG auch Kanten für w/w-abhängigkeiten eingefügt werden. Dadurch lässt sich dann SSI-W via x-zyklenfreiheit überprüfen Zyklenfreiheit von SSI-SG Beispiele Beispiel 3 (revisited): Beispiel 4: S 3 = r (x 0 ) r 2(y 0 ) r 2 (x 0 ) r 2 2(y 0 ) w 2 3(x 2 ) w 3(y ) C C 2 Ò Der zugehörige SSI-SG sieht folgendermassen aus: S 4 = r (x 0 ) r 2(y 0 ) r 2 (x 0 ) r 2 2(y 0 ) w 3(x ) w 2 3(x 2 ) C C 2 Ò Der zugehörige SSI-SG sieht folgendermassen aus: SSI-SG(S 3, 3 ): x, y T SSI-SG(S 4, 4 ): x, y T T 0 x y T 0 x x x, y T 2 x, y T 2 SSI-SG(S 3, 3 ) enthält weder x- noch y-zyklen, daher SSI. Durch Zyklus ohne Labels folgt, wie bereits festgestellt, dass S 3 MVSR. SSI-SG(S 4, 4 ) enthält jetzt einen x-zyklus. Das bedeutet, dass für x (SSI-W) verletzt ist. fl S 4 SSI

9 Vergleich: SSI vs. MVSR MVSR vs. SSI: Begründung siehe Beispiele -3 SSI MVSR Benchmarks für Data Warehouses Benchmark ( Massstab ) zum Vergleich der Leistungsfähigkeit von Systemen Für Datenbanken: Serie von Benchmarks des Transaction Processing Performance Council ( TPC-C: klassischer OLTP Benchmark TPC-E: ecommerce Benchmark (ebenfalls mit OLTP-Charakteristik) TPC-H: Ad-hoc Decision Support (Data Warehousing) Vorgegeben sind jeweils Schemata Schema-, Query- und Datengeneratoren Messungen erfolgen mit unterschiedlichen Datenbank-Grössen

10 TPC-C Benchmark System-Performanz mit OLTP-Workload Simultane Ausführung einer Mischung aus lese- und schreibintensiven Transaktionen Viele konkurrierende Benutzer On-line und asynchrone Ausführungen Normale CPU-Last, aber starke Disk-I/O ACID Eigenschaften Metrik: transactions-per-minute-c (tpmc) Anzahl der orders bearbeitet pro Minute business throughput 5-94 TPC-C-Schema Remote-W W * 0 Warehouse W District W * 0 Die Zahlen in den Entitätstypen geben die Kardinalitäten der einzelnen Tabellen (# Tupel) an Stock History W * 30k+ Customer W * 30k + bedeutet variable Grösse (Tupel werden während des TPC-C Durchlaufs neu erzeugt) W * 00k Skalierung de gesamten Datenbank erfolgt über die Anzahl Entitäten im Entitätstyp Warehouse (W) Item OrderLine W*2700k+ Order W*90k+ 00k NewOrder W*9k

11 TPC-C Transaktionen 0/23 0/23 /23 Customer-Inquiry Customer-Inquiry Customer-Inquiry New-Order Payment Order-Info. Select txn from menu:. New-Order n/a 2. Payment 43% 3. Order-Status 4 % 4. Delivery 4 % 5. Stock-Level 4 % /23 Customer-Inquiry 2 /23 Stock-Info. 3 Input screen Emulierter Benutzer wählt zufällig eine Transaktion aus Delivery-Transaktion läuft asynchron (als Batch) Vorgegebene Verteilung 80:20 read-write Output screen Go back to 5-96 TPC-C Benchmark-Resultate nach Performance Stand: 05/20, Quelle: Transaction Processing Performance Council,

12 TPC-H: Schema Der TPC-H-Benchmark bildet eine Data Warehousing-Umgebung nach Messungen in TPC-H erfolgen mit den folgenden Grössen: 00 GB 300 GB TB 3 TB 0 TB 30 TB PART REGION N NATION N SUPPLIER N N PARTSUPP N REGION N NATION N CUSTOMER N ORDERS N LINEITEM 5-98 SELECT FROM WHERE AND AND GROUP BY ORDER BY TPC-H: Beispiel einer Anfrage c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, SUM(l_quantity) customer, orders, lineitem o_orderkey IN (SELECT l_orderkey FROM lineitem GROUP BY l_orderkey HAVING SUM(l_quantity) > :) c_custkey = o_custkey o_orderkey = l_orderkey c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice o_totalprice desc, o_orderdate;

13 TPC-H: Benchmark-Resultate (3 TB) Stand: 05/20, Quelle: Transaction Processing Performance Council, TPC-H: Benchmark-Resultate (0 & 30 TB) Stand: 05/20, Quelle: Transaction Processing Performance Council,

14 5.5 Column Stores für Data Warehousing Klassische relationale Datenbanken verwenden 'Row Stores' Speicherung kompletter Tupel auf Datenbankseiten Optimiert für OLTP-Anwendungen Kurzlebige ACID-Transaktionen Schreiben / Ändern gesamter Tupel Kunden KNr Name Stadt Saldo Rabatt 0 Legrand Genf - 080, Marty Basel -8 00, Frei Basel 0,00 0,0 04 Janvier Genf 0,00 0,0 05 Rossi Lugano 0,00 0,05 06 Meier Zürich ,00 0,05 07 Hürlimann St. Gallen -00,00 0,05 08 Schmid Luzern ,00 0,0 09 Müller-Lüdenscheid Zürich -550,00 0,00 0 Schumacher Genf ,00 0,20 Datenseiten 5-02 Column Store Column Store-Datenbanksysteme Wenige Änderungen Optimiert für (langlebige) Leseanwendungen (OLAP), nur bedingt geeignet für Updates Kunden KNr Name Stadt Saldo Rabatt 0 Legrand Genf - 080, Marty Basel -8 00, Frei Basel 0,00 0,0 04 Janvier Genf 0,00 0,0 05 Rossi Lugano 0,00 0,05 06 Meier Zürich ,00 0,05 07 Hürlimann St. Gallen -00,00 0,05 08 Schmid Luzern ,00 0,0 09 Müller-Lüdenscheid Zürich -550,00 0,00 0 Schumacher Genf ,00 0,20 FS 20 Datenseiten Data Warehousing (CS242) Data Warehousing

15 C-Store C-Store: Beispiel eines Column Store-Systems Writeable Store: erlaubt beliebige Insert und Update-Operationen Read-Optimized Store: Einzige erlaubte Schreiboperation ist Batch-Update aus Writeable store (= lazy replication) Tuple Mover: führt Batch-Update durch Relationenmodell als logisches Datenmodell, SQL an der Schnittstelle Physische Speicherung: Projektionen einzelner (oder mehrerer) Attribute Writeable Store (WS) Tuple Mover Read-optimized Store (RS) 5-04 C-Store: Read-Optimized Store Einzelne Attribute können (in unterschiedlichen Projektionen) mehrfach im Readoptimized Store gespeichert werden Für jede Projektion wird ein Sort Key angegeben (das Attribut, nach dem die Projektion sortiert wird) Jede Projektion wird horizontal partitioniert in mehrere Segmente. Jedes Segment ist durch einen Segment Identifier (Sid) gekennzeichnet. Also enthält jedes Segment einer Projektion ein Intervall des Sort Keys Tabelle Name Age Dept Salary Projektion P Sort key SID Name 2 Dept Key range Segmente 3 P2 Name Sort key Salary Sort key P3 Age Salary Logische Repräsentation

16 C-Store: Read-Optimized Store Die einzelnen Attribute jedes Segments sind durch einen Storage Key (SK) gekennzeichnet Die Verknüpfung zu weiteren Attributen desselben Tupels erfolgt über spezielle Join-Indexe Annahme: P (M Segmente) und P2 (N Segmente) sind Projektionen derselben Relation Join-Index besteht aus M Tabellen (eine pro Segment von P) Eintrag im Join-Index für P-Segment S P enthält für jeden Eintrag von S P einen Verweis auf die zugehörigen Einträge in der Projektion P2 Dieser Verweis besteht aus dem Segment Identifier Sid und dem Storage Key (SK) innerhalb des Segments Join-Indexe stellen also nur eine unidirektionale Verbindung zwischen Projektionen her 5-06 C-Store Join-Index Segment S P,i : i-tes Segment von Projektion P S P,i Name SK Dept Join-Index für Segment S P,i SID SK S P2, j 3 S P2, j+2 Name Name Salary Salary S P2,j S P2,j

17 Weitere Column Store-Systeme Google s Bigtable Verwendet Projektion und Segmentierung Verteilung der Segmente auf mehrere Rechner Basiert auf GFS (Google File System) Hbase Open Source-Nachbildung von bigtable Vertica Kommerzielle Implementierung der C-Stores MonetDB Forschungsprototyp, CWI Amsterdam Sybase IQ Erstes kommerzielles Column Store-System und viele weitere mehr (Open Source & kommerziell) 5-08 Literatur [BG 09] A. Bauer, H. Günzel (Hrg.): Data Warehouse Architektur, Entwicklung, Anwendung. dpunkt.verlag, 3. Auflage, [CD 97] S. Chaudhuri, U. Dayal: An Overview of Data Warehousing and OLAP Technology. SIGMOD Record 26(), März 997. [GCB + 97] J. Gray et al.: Data Cube: A relational aggregation operator generalizing group-by, cross-tab, and sub-totals. In: Data Mining and Knowlegde Discovery, 29-53, 997. [Inm 96] W. Inmon: Building the Data Warehouse, John Wiley & Sons, 996 [Leh 03] W. Lehner: Datenbanktechnologie für Data-Warehouse-Systeme, dpunkt.verlag,