pdf (1/1)
Werbung
Datenbankanwendung Wintersemester 2014/15 Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern [email protected] Indexstrukturen Skyline Anfragen Skyline Anfragen Prof. mobile.de Dr.-Ing. S. Michel Quelle: TU Kaiserslautern Datenbankanwendung, WS 14/15 2 / 58 Indexstrukturen Skyline Anfragen Skyline Anfragen (2) Quelle: mobile.de Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 3 / 58 Indexstrukturen Skyline Anfragen Skyline Anfragen (3) Quelle: mensa-kl.de Wok schmeckt besser (hat aber nur 36 Bewertungen), aber teurer. Flammkuchen hat relativ gute und viele Bewertungen. Grill hat super Bewertung (aber nur eine) und ist auch richtig teuer. Aber ist dies besser als Spaghetti Bolognese? Kostet ja mehr. Und was ist mit der Wartezeit (Schlange)? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 4 / 58 Indexstrukturen Skyline Anfragen Skyline Anfragen - Szenarien Der Klassiker: Hotel Reservierung Entscheidungsfindung (Decision making) Anwendungen Suchmaschinen für Produkte wie Autos, Grundstücke, etc. Beispiel: Überlegungen zur Hotelbuchung und zum Gebrauchtwagenkauf Welches Hotel ist besser? Das mit 100m Entfernung zum Strand für 100 Euro die Nacht, oder das Hotel mit 150m Entfernung für 80 Euro die Nacht? Unklar. Welches Auto (bzw. welcher Kauf) ist besser? Das für 10 000 Euro mit einem Kilometerstand von 150 000km oder das für 8000 Euro bei einem Kilometerstand von 130 000km? Klar. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 5 / 58 Indexstrukturen Skyline Anfragen Skyline - Konzept In vielen Anwendungen gilt es Suchanfragen zu verarbeiten, bei denen die Charakteristiken der einzelnen Objekte zwar bekannt sind, aber nicht in eine gesamte Score aufaggregiert werden können (was ist schon die Summe(?) von Entfernung zum Strand und Preis?) Es gibt dennoch Objekte die klar besser sind als andere (siehe vorheriges Beispiel mit Gebrauchtwagenkauf) Solch eine Beziehung wird als Dominanz bezeichnet In der Skyline eines Datensatzes sind all die Punkte enthalten, die von keinem anderen Punkt dominiert werden Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 6 / 58 Indexstrukturen Skyline Anfragen Skylines http://www.freefoto.com Maximum-Vektor-Problem, Pareto Optimalität, Präferenz-Anfragen,. . . H. T. Kung, F. Luccio, and F. P. Preparata. On finding the maxima of a set of vectors. Journal of the ACM, 1975. S. Börzsönyi, D. Kossmann, K. Stocker. The Skyline Operator. ICDE, 2001. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 7 / 58 Indexstrukturen Skyline Anfragen Erwartete Größe einer Skyline Allgemeines “Problem”: Anzahl der Punkte (=nicht dominierte Objekte) einer Skyline wächst recht schnell mit Anzahl der Dimensionen, d.h. der betrachteten Attribute, die verglichen werden. Für d Dimensionen und n Punkte, ist die durchschnittliche Anzahl der Punkte in der Skyline O((ln n)d−1 ) D.h. bei n = 100 Punkten: d 1 2 3 4 (ln100)d−1 1 4.6 21.2 97.6 Bentley et al. On the average number of maxima in a set of vectors and applications. J. ACM, 1978 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 8 / 58 Indexstrukturen Skyline Anfragen Formale Definition Given Datenraum D with d Dimensionen d1 , . . . , dd Datensatz S über D, Größe |S| = n Datenpunkte p ∈ S, mit p = [p1 , . . . , pd ] Präferenz in jeder Dimension: min, max, diff Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 9 / 58 Indexstrukturen Skyline Anfragen Formale Definition Given Datenraum D with d Dimensionen d1 , . . . , dd Datensatz S über D, Größe |S| = n Datenpunkte p ∈ S, mit p = [p1 , . . . , pd ] Präferenz in jeder Dimension: min, max, diff Definition Die Skyline ist eine Menge von Punkten SKY (S) ⊆ S welche von keinem anderen Punkt dominiert sind. Die Punkte in SKY (S) werden Skyline-Punkte genannt. Definition Ein Punkt p ∈ S dominiert einen anderen Punkt q ∈ S, bezeichnet mit p ≺ q, falls in jeder Dimension di ∈ D gilt pi ≥ qi und in mindestens einer Dimension dj ∈ D gilt pj > qj . Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 9 / 58 Indexstrukturen Skyline Anfragen Formale Definition Given Datenraum D with d Dimensionen d1 , . . . , dd Datensatz S über D, Größe |S| = n Datenpunkte p ∈ S, mit p = [p1 , . . . , pd ] Präferenz in jeder Dimension: min, max, diff Definition Die Skyline ist eine Menge von Punkten SKY (S) ⊆ S welche von keinem anderen Punkt dominiert sind. Die Punkte in SKY (S) werden Skyline-Punkte genannt. Definition Ein Punkt p ∈ S dominiert einen anderen Punkt q ∈ S, bezeichnet mit p ≺ q, falls in jeder Dimension di ∈ D gilt pi ≤ qi und in mindestens einer Dimension dj ∈ D gilt pj < qj . Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 9 / 58 Indexstrukturen Skyline Anfragen Dominanz . . . oder mit anderen Worten Ein Punkt p dominiert Punkt q falls er in allen Dimensionen mindestens so gut oder besser ist als q und es gibt mindestens eine Dimension in der p besser ist. In der Praxis können min, max und diff gemischt benutzt werden. Muss dementsprechend bei Check der Dominanz berücksichtigt werden. Bedeutung von min und max sollte offensichtlich sein. Darüberhinaus kann mit diff beschrieben werden, dass ein Objekt ein andere nicht dominieren kann falls der Attributwert nicht identisch ist. Also, Anwendung bei Dinge (Attributen) deren Werte nicht vergleichbar sind. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 10 / 58 Indexstrukturen Skyline Anfragen Kleiner Werte sind besser vs. grössere Werte sind besser (1,10) (6,10) (1,10) (2,9) (6,10) (2,9) (9,8) (10,8) (9,8) (10,8) (6,7) (3,6) (6,7) (5,6) (9,6) (2,5) (3,5) (3,6) (5,6) (2,5) (3,5) (7,4) (7,4) (7,3) (8,3) (3,2) (2,1) (9,6) (7,3) (8,3) (7,2) (5,1) Prof. Dr.-Ing. S. Michel (3,2) (8,1) (9,1) TU Kaiserslautern (2,1) (7,2) (5,1) Datenbankanwendung, WS 14/15 (8,1) (9,1) 11 / 58 Indexstrukturen Skyline Anfragen Veranschaulichung Dominanz Jeder Punkt der Skyline spannt Raum auf über Punkte die er dominiert. Gemeinsam decken die Punkte der Skyline alle Punkte des Datensatzes ab. (4,10) (6,10) (10,9) (7,6) (2,5) (3,4) (8,4) (6,3) (3,2) (5,1) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 12 / 58 Indexstrukturen Skyline Anfragen k-skyband Verallgemeinerung der Skyline Für Parameter k und Datensatz besteht das k-Skyband aus allen Punkten die höchstens k − 1 mal dominiert werden. Unterschied zu top-k Algorithmen: Wie schon bei der Skyline ist auch das k-Skyband unabhängig von der Aggregationsfunktion (es gibt keine!) Wie auch die Skyline hat das Skyband das Problem, dass sehr viele Objekte dazu gehören können, wenn Anzahl der Dimensionen hoch. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 13 / 58 Indexstrukturen Skyline Anfragen k-skyband - Beispiel k=1 (1,10) (6,10) (2,9) (9,8) (10,8) (6,7) (3,6) (5,6) (9,6) (2,5) (3,5) (7,4) (7,3) (8,3) (3,2) (2,1) (7,2) (5,1) Prof. Dr.-Ing. S. Michel (8,1) (9,1) TU Kaiserslautern Datenbankanwendung, WS 14/15 14 / 58 Indexstrukturen Skyline Anfragen k-skyband - Beispiel k=2 (1,10) (6,10) (2,9) (9,8) (10,8) (6,7) (3,6) (5,6) (9,6) (2,5) (3,5) (7,4) (7,3) (8,3) (3,2) (2,1) (7,2) (5,1) Prof. Dr.-Ing. S. Michel (8,1) (9,1) TU Kaiserslautern Datenbankanwendung, WS 14/15 14 / 58 Indexstrukturen Skyline Anfragen k-skyband - Beispiel k=3 (1,10) (6,10) (2,9) (9,8) (10,8) (6,7) (3,6) (5,6) (9,6) (2,5) (3,5) (7,4) (7,3) (8,3) (3,2) (2,1) (7,2) (5,1) Prof. Dr.-Ing. S. Michel (8,1) (9,1) TU Kaiserslautern Datenbankanwendung, WS 14/15 14 / 58 Indexstrukturen Skyline Anfragen k-skyband - Beispiel k=4 (1,10) (6,10) (2,9) (9,8) (10,8) (6,7) (3,6) (5,6) (9,6) (2,5) (3,5) (7,4) (7,3) (8,3) (3,2) (2,1) (7,2) (5,1) Prof. Dr.-Ing. S. Michel (8,1) (9,1) TU Kaiserslautern Datenbankanwendung, WS 14/15 14 / 58 Indexstrukturen Skyline Anfragen Skyline-Operator SELECT . . . FROM . . . WHERE . . . GROUP BY . . . HAVING SKYLINE OF [DISTINCT] d1 [MIN | MAX | DIFF], . . ., dm [MIN | MAX| DIFF] ORDER BY . . . Skyline Operator wird nach SELECT, FROM, WHERE, GROUP BY, HAVING ausgeführt, aber vor ORDER BY und LIMIT. Falls Objekte in allen Dimensionen identisch sind werden sämtliche zurückgegeben, mit DISTINCT nur eines (willkürlich) dieser. DIFF zusätzlich zu MIN und MAX. S. Börzsönyi, D. Kossmann, K. Stocker. The Skyline Operator. ICDE, 2001. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 15 / 58 Indexstrukturen Skyline Anfragen Skyline-Operator (2) Der Vollständigkeit wegen... (Quelle: Börzsönyi et al. The Skyline Operator.) Anmerkung: Leicht andere Definition von Dominanz als zuvor, relevant aber nur im Fall wo es Duplikate gibt. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 16 / 58 Indexstrukturen Skyline Anfragen Skyline-Operator - Beispiele SELECT * FROM Hotels WHERE city = Nassau SKYLINE OF price MIN, distance MIN; SELECT e.name, e.salary, sum(s.volume) as volume FROM Emp e, Sales s WHERE e.id = s.repr AND s.year = 1999 GROUP BY e.name, e.salary SKYLINE OF e.salary MIN, volume MAX; Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 17 / 58 Indexstrukturen Skyline Anfragen Übersetzung in “normales” SQL SELECT * FROM Hotels h WHERE h.city = Nassau AND NOT EXISTS( SELECT * FROM Hotels h1 WHERE h1.city = Nassau AND h1.distance <= h.distance AND h1.price <= h.price AND (h1.distance < h.distance OR h1.price < h.price)); Naive Realisierung als Nested Loops Kann sehr teuer sein, insbesondere wenn Anfragen (äußere und innere) Joins oder Group-By enthalten. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 18 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID Preis Kilometerstand Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 Preis $1.500 Kilometerstand 178.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 Preis $1.500 Kilometerstand 178.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 Preis $1.500 Kilometerstand 178.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 Preis $1.500 Kilometerstand 178.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 Preis $1.500 Kilometerstand 178.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 Preis $1.500 Kilometerstand 178.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 Preis $1.500 Kilometerstand 178.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 3 Preis $1.500 $6.000 Kilometerstand 178.000 120.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 3 Preis $1.500 $6.000 Kilometerstand 178.000 120.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 3 Preis $1.500 $6.000 Kilometerstand 178.000 120.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 5 Preis $1.500 $3.000 Kilometerstand 178.000 120.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 5 Preis $1.500 $3.000 Kilometerstand 178.000 120.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 5 Preis $1.500 $3.000 Kilometerstand 178.000 120.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 5 Preis $1.500 $3.000 Kilometerstand 178.000 120.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 5 4 Preis $1.500 $3.000 $35.000 Kilometerstand 178.000 120.000 11.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 5 4 Preis $1.500 $3.000 $35.000 Kilometerstand 178.000 120.000 11.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 5 6 Preis $1.500 $3.000 $32.000 Kilometerstand 178.000 120.000 11.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Nested Loops Algorithmus für Skyline Vergleiche jeden Punkt mit jedem anderen Punkt Eingabe ID 1 2 3 4 5 6 Preis $1.500 $2.000 $6.000 $35.000 $3.000 $32.000 Kilometerstand 178.000 188.000 120.000 11.000 120.000 11.000 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Kandidaten für Skyline ID 1 5 6 Preis $1.500 $3.000 $32.000 Kilometerstand 178.000 120.000 11.000 Datenbankanwendung, WS 14/15 19 / 58 Indexstrukturen Skyline Anfragen Algorithmen – Divide and Conquer Aufteilung der Daten in Partitionen, die dann jeweils in den Hauptspeicher passen. Endergebnis wird dann durch mergen der partiellen Skylines gewonnen. Source: Papadias et al, 2005. Beispiel in Abbildung: 4 Partitionen, s1 , s2 , s3 und s4 mit partiellen Skylines {a, c, g}, {d}, {i} und {m, k}. z.B. Ergebnisse aus s2 sind hier irrelevant. Punke aus s1 müssen nur mit Punkten aus s3 verglichen werden, etc. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 20 / 58 Indexstrukturen Skyline Anfragen Algorithmen zur Berechnung der Skyline Ausnutzen von bestehenden oder zur Laufzeit dynamisch angelegten Indexstrukturen (insbes. R-Baum) zur effizienten Bestimmung von Dominanz ohne gesamten Datensatz lesen zu müssen. Source: Papadias et al, 2005. D. Papadias, Y. T. Tao, G Fu, B. Seeger: Progressive skyline computation in database systems. ACM Trans. Database Systems, 2005. D. Kossmann, F. Ramsak, S. Rost. Shooting stars in the sky: an online algorithm for skyline queries. VLDB, 2002. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 21 / 58 Transaktionsverwaltung Übersicht Transaktionsverwaltung Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 22 / 58 Transaktionsverwaltung Übersicht Anwendungsprogrammierung: Transaktionen Nicht nur eine einzelne SQL-Anweisung, sondern ganze Folge davon, je nach Anwendung. Eine oder mehrere Anweisungen werden als Transaktion zusammengefasst bzw. betrachtet. Z.B. Abheben von Geld am Geldautomat. begin transaction operation1; operation2; operation3; operation4; operation5; end transaction Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 23 / 58 Transaktionsverwaltung Übersicht Literatur Grundlagen: Buch von Kemper und Eickler. Datenbanksysteme - Eine Einführung. Kapitel 9,10,11. Mehr Details: Buch von Härder und Rahm. Datenbanksysteme - Konzepte und Techniken der Implementierung. Kapitel 13–16. Aber hier insbesondere: Buch von Weikum und Vossen. Transactional Information Systems. Viele Details, Theorie, aber sehr gut und anschaulich geschrieben (im Allgemeinen). Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 24 / 58 Transaktionsverwaltung Übersicht Einführung Bei einer typischen Transaktion in einer Bankanwendung: 1. Lese den Kontostand von A in die Variable a: read(A, a); 2. Reduziere den Kontostand um 50 Euro: a := a − 50; 3. Schreibe den neuen Kontostand in die Datenbasis: write(A,a); 4. Lese den Kontostand von B in die Variable b: read(B, b); 5. Erhöhe den Kontostand um 50 Euro: b := b + 50; 6. Schreibe den neuen Kontostand in die Datenbasis: write(B, b); Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 25 / 58 Transaktionsverwaltung Übersicht Eigenschaften von Transaktionen: ACID Atomicity (Atomarität): Alles oder nichts Consistency: Kosistenter Zustand der DB → konsistenter Zustand Isolation: Jede Transaktion hat die DB “für sich allein” Durability (Dauerhaftigkeit): Änderungen erfolgreicher Transaktionen dürfen nie verloren gehen. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 26 / 58 Transaktionsverwaltung Übersicht Operationen auf Transaktione-Ebene begin of transaction (BOT): Mit diesem Befehl wird der Beginn einer eine Transaktion darstellende Befehlsfolge gekennzeichnet. commit: Hierdurch wird die Beendigung der Transaktion eingeleitet. Alle Änderungen der Datenbasis werden durch diesen Befehl festgeschrieben, d.h. sie werden dauerhaft in die Datenbank eingebaut. abort: Dieser Befehl führt zu einem Selbstabbruch der Transaktion. Das Datenbanksystem muss sicherstellen, dass die Datenbasis wieder in den Zustand zurückgesetzt wird, der vor Beginn der Transaktionsausführung existierte. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 27 / 58 Transaktionsverwaltung Übersicht Transaktionen bei System-Crash Absturz T1 T2 t1 t3 t2 Zeit Wie verhält sich solch ein Szenario mit ACID? Was muss beachtet werden? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 28 / 58 Transaktionsverwaltung Übersicht Abschluss einer Transaktion Für den Abschluss einer Transaktion gibt es drei Möglichkeiten: 1. Den erfolgreichen Abschluss durch commit. 2. Den erfolglosen Abschluss durch ein abort. 3. Den erfolglosen Abschluss durch einen Fehler. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 29 / 58 Transaktionsverwaltung Übersicht Transaktionsverwaltung in SQL Beispielsequenz auf Basis des Universitätsschemas: insert intoVorlesungen values (5275, ‘Kernphysik‘, 3, 2141); insert into Professoren values (2141, ‘Meitner‘, ‘C4‘, 205); commit; Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 30 / 58 Transaktionsverwaltung Übersicht Transaktionsverwaltung in SQL commit [work]: Die in der Transaktion vollzogenen Änderungen werden – falls keine Konsistenzverletzung oder andere Probleme aufgedeckt werden – festgeschrieben. Das Schlüsselwort work ist optional, d.h. das Transaktionsende kann auch einfach mit commit “befohlen” werden. rollback [work]: Alle Änderungen sollen zurückgesetzt werden. Anders als der commit-Befehl muss das DBMS die “erfolgreiche” Ausführung eines rollback-Befehls immer garantieren können. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 31 / 58 Transaktionsverwaltung Übersicht Sicherungspunkte Sicherungspunkt: Punkt innerhalb einer TA, auf den sich aktive TA zurücksetzen lässt savepoint <name>: definiert den Sicherungspunkt rollback [work] to <name>: setzt aktive TA zurück bis zum Sicherungspunkt <name> Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 32 / 58 Transaktionsverwaltung Übersicht Beispiel begin; insert into tab values ... savepoint A; insert into tab values ... savepoint B; SELECT * FROM tab; rollback to A; SELECT * FROM tab; ... Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 33 / 58 Transaktionsverwaltung Übersicht Wie unsterstützt das DMBS Transaktionen? Mehrbenutzersynchronisation (Isolation) (Ausführlich in der VL Informationssysteme behandelt) semantische Korrektheit bei Nebenläufigkeit Serialisierbarkeit Schwächere Isolationsstufen (Isolation Levels) Recovery (Atomicity and Durability) Zurücksetzen teilweise ausgeführter TA Vervollständigen der Aktionen von TA Sicherstellen der Persistenz von TA Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 34 / 58 Transaktionsverwaltung Übersicht Wiederholung: Mehrbenutzersynchronisation Das “I” in ACID. Ausführung der drei Transaktionen T1 , T2 und T3 : (a) im Einzelbetrieb (b) im (verzahnten) Mehrbenutzerbetrieb Ziel: Semantik von seriell ausgeführten Transaktionen zusammen mit Performance von verzahnter Ausführung. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 35 / 58 Transaktionsverwaltung Übersicht Wiederholung: Das lost-update Problem t1 r(x) /*update x := x + 30 */ w(x) Prof. Dr.-Ing. S. Michel Time /* x = 100 */ 1 2 3 4 5 /* x = 130 */ 6 /* x = 120*/ TU Kaiserslautern t2 r(x) /* update x := x + 20 */ w(x) Datenbankanwendung, WS 14/15 36 / 58 Transaktionsverwaltung Übersicht Wiederholung: Das lost-update Problem / Notation Die Essenz dieses Problems kann durche folgende Sequenz von Lese- und Schreiboperationen ausgedrückt werden: r1 (x)r2 (x)w1 (x)w2 (x) ri (x) beschreibt das Lesen von Datensatz x durch Transaktion i wi (x) analog das Schreiben von Datensatz x durch Transaktion i Konflikte zwischen Transaktionen können auch auftreten, wenn eine der beiden TA nur liest - wie im folgenden Beispiel klar wird. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 37 / 58 Transaktionsverwaltung Übersicht Wiederholung: Das inconsistent-read Problem Beispiel aus z.B. Anwendung in Bank. Aktueller Stand x = y = 50, also x + y = 100. Transaktion t1 berechnet die Summe von x und y, während t2 einen Wert von 10 von x nach y transferiert. t1 /* sum := 0 */ r(x) r(y) /* sum := sum + x */ /* sum := sum + y */ Prof. Dr.-Ing. S. Michel Time 1 2 3 4 5 6 7 8 9 10 11 t2 r(x) /* x := x − 10 */ w(x) r(y) /* y := y + 10 */ w(y) TU Kaiserslautern Datenbankanwendung, WS 14/15 38 / 58 Transaktionsverwaltung Übersicht Wiederholung: Das inconsistent-read Problem (2) Offensichtlich ist auch hier wieder das Problem, dass Lese- und Schreiboperationen der einzelnen Transaktionen gemischt ablaufen r2 (x)w2 (x)r1 (x)r1 (y)r2 (y)w2 (y) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 39 / 58 Transaktionsverwaltung Übersicht Wiederholung: Das dirty-read Problem t1 r(x) /* x := x + 100 */ w(x) failure & rollback Time 1 2 3 4 5 6 7 Prof. Dr.-Ing. S. Michel t2 r(x) /* x := x − 100 */ w(x) TU Kaiserslautern Datenbankanwendung, WS 14/15 40 / 58 Transaktionsverwaltung Übersicht In Infosys bereits betrachtet Transaktionen Konzept Atomare Lese- und Schreiboperationen (auf Datenobjekte) Transaktion als endliche Folge von Operationen pi T = p1 p2 p3 . . . pn mit pi ∈ {r(xi , w(xi )} TA hat als letzte Operation entweder Abbruch a oder Commit c Serialisierbarkeit Betrachtung von Historien über verschiedenen Transaktionen Ziel: Gibt es eine äquivalente serielle Historie? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 41 / 58 Transaktionsverwaltung Übersicht In Infosys bereits betrachtet (2) Sperrbasierte Synchronisation shared Lock (Lesesperre) exclusive Lock (Schreibsperre) Verträglichkeitsmatrix (auch Kompatibilitätsmatrix genannt) Zwei-Phasen Sperrprotokoll (2PL) 2PL erzeugt nur serialisierbare Historien: Weitere Protokolle wie striktes 2PL Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 42 / 58 Transaktionsverwaltung Übersicht Zusammenfassung Concurrency ;) https://www.youtube.com/watch?v=G3xH2SoMOF0 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 43 / 58 Transaktionsverwaltung Recovery Durability? – Beispiel 1a TA ändert Daten im Hauptspeicher Daten noch garnicht auf Festplatte geschrieben Transaktion schickt commit Benutzer glaubt, dass TA abgeschlossen ist ⇒ Annahme des Benutzers: alle Änderungen der TA sind dauerhaft in DB gespeichert Stromausfall Was passiert? Welche Daten befinden sich in der DB? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 44 / 58 Transaktionsverwaltung Recovery Durability? – Beispiel 1b TA ändert Daten im Hauptspeicher Daten teilweise auf Festplatte geschrieben Transaktion schickt commit Benutzer glaubt, dass TA abgeschlossen ist ⇒ Annahme des Benutzers: Änderungen der TA sind dauerhaft in DB gespeichert Stromausfall Was passiert? Welche Daten befinden sich in der DB? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 45 / 58 Transaktionsverwaltung Recovery Durability? – Beispiel 2a TA ändert Daten im Hauptspeicher Daten vollständig auf Festplatte geschrieben Transaktion schickt commit Benutzer glaubt, dass TA abgeschlossen ist ⇒ Annahme des Benutzers: alle Änderungen der TA sind dauerhaft in DB gespeichert Hardwarefehler ⇒ Totalverlust der Festplatte Was passiert? Welche Daten befinden sich in der DB? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 46 / 58 Transaktionsverwaltung Recovery Durability? – Beispiel 2b TA ändert Daten im Hauptspeicher Daten vollständig auf mehrere Festplatten geschrieben Transaktion schickt commit Benutzer glaubt, dass TA abgeschlossen ist ⇒ Annahme des Benutzers: alle Änderungen der TA sind dauerhaft in DB gespeichert Wasserschaden/Feuer/Erdbeben ... ⇒ Total verlust aller Festplatten Was passiert? Welche Daten befinden sich in der DB? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 47 / 58 Transaktionsverwaltung Recovery Durability? – Beispiel 2c TA ändert Daten im Hauptspeicher Daten vollständig auf mehrere Festplatten and mehreren geographisch verteilten Rechenzentren geschrieben Transaktion schickt commit Benutzer glaubt, dass TA abgeschlossen ist ⇒ Annahme des Benutzers: alle Änderungen der TA sind dauerhaft in DB gespeichert Wasserschaden/Feuer/Erdbeben ... an allen Rechenzentren gleichzeitig ⇒ Total verlust aller Rechenzentren und Festplatten Was passiert? Welche Daten befinden sich in der DB? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 48 / 58 Transaktionsverwaltung Recovery Quintessenz Durability immer relativ bezogen auf Anzahl Kopien/geographische Verteilung Garantie bezogen auf relative Durability kann nur gemacht werden, wenn erst die verschiedenen Kopien erzeugt werden und dann dem Benutzer mitgeteilt wird, dass die TA committed wurde ⇒ WAL-Prinzip (write-ahead logging) Varianten hiervon: log-basierte Recovery komplettes Spiegeln (mehrere Rechner/Rechenzentren machen dasselbe redundant) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 49 / 58 Transaktionsverwaltung Recovery Implikationen von ACID auf Anforderungen zu Recovery Durability Änderungen an der Datenbank, die durch erfolgreich(!) abgeschlossene (d.h. committed) Transaktionen verursacht wurden, müssen dauerhaft gespeichert sein. D.h. bei einem Crash der DB muss nach Wiederanlauf geschaut werden, ob dies tatsächlich der Fall ist. Atomicity Falls eine Transaktion noch nicht erfolgreich abgeschlossen wurde und ein DB-Crash auftritt, muss beim Wiederanlauf darauf geachtet werden, dass etwaige Änderungen in der Datenbasis rückgängig gemacht werden. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 50 / 58 Transaktionsverwaltung Recovery Fehlerklassifikation Lokaler Fehler in einer noch nicht festgeschriebenen (committed) Transaktion: Wirkung der TA muss zurückgesetzt werden Fehler mit Hauptspeicherverlust: Abgeschlossene TAs müssen erhalten bleiben Noch nicht abgeschlossene TAs müssen zurückgesetzt werden Fehler mit Hintergrundspeicherverlust: Archiv einspielen Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 51 / 58 Transaktionsverwaltung Recovery Vorsorge für den Fehlerfall Logging Sammlung redundanter Daten bei Änderungen im Normalbetrieb, als Voraussetzung für Recovery Einsatz im Fehlerfall (Undo-, Redo-Recovery) Do-Redo-Undo-Prinzip DB-Zustandalt Do DB-Zustandneu Log-Satz Prof. Dr.-Ing. S. Michel DB-Zustandalt Log-Satz Log-Satz DB-Zustandneu Redo Undo DB-Zustandneu DB-Zustandalt TU Kaiserslautern Datenbankanwendung, WS 14/15 52 / 58 CLR Transaktionsverwaltung Recovery Recovery-Oriented Computing Systemverfügbarkeit A (availability) MTTF: Mean Time To Failure MTTR: Mean Time To Repair A= MTTF MTTF + MTTR Warum Recovery-Oriented Computing? Hardwarefehler, Softwarefehler passieren (sind nicht vermeidbar) und müssen adressiert werden. Lange Systemausfälle sind sehr sichtbar (z.B. Amazon, Facebook, Ebay!) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 53 / 58 Transaktionsverwaltung Recovery Number of Nines & Entwicklungsziele Availablility wird manchmal beschrieben in Anzahl von Neunen (Nines), wie in “five nines”, oder 99.999%. 99.99% entspricht ungefähr 1 Minute Ausfall in einer Woche, bzw. circa 50 Minuten Ausfall in einem Jahr. “Build a system used by millions of people that is always available – out less than 1 second per 100 years = 8 9’s of availability” (J. Gray: 1998 Turing Award Lecture) Jim Gray: We have added three 9s in 45 years (starting with 90%), or about 15 years per order-of-magnitude improvement in availability. We should aim for five more 9s: an expectation of one second outage in a century. This is an extreme goal, but it seems achievable if hardware is very cheap and bandwidth is very high. One can replicate the services in many places, use transactions to manage the data consistency, use design diversity to avoid common mode failures, and quickly repair nodes when they fail. Again, this is not something you will be able to test: so achieving this goal will require careful analysis and proof. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 54 / 58 Transaktionsverwaltung Recovery Wie kann man annährend A = 1, 0 erreichen? MTTF → ∞? MTTR << MTTF! Es gibt Fehler die man nur sehr schwer oder gar nicht nicht durch testen in den Griff bekommen kann. Sie treten nichtdeterministisch auf, oft aufgrund von Nebenläufigkeit in Threads, unter hoher Last, oder in anderen seltenen Fällen. Solche Probleme werden auch “Heisenbugs” genannt (Jim Gray); nach Heisenbergs Unschärferelation. D.h. ein schneller Wiederanlauf (Recovery) ist essentiell für hohe Verfügbarkeit (Availability); da diese “Heisenbugs” die MTTF in der Praxis einschränken. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 55 / 58 Transaktionsverwaltung Recovery Grundlagen der DB-Recovery Aufgabe des DBMS Automatische Behandlung aller erwarteten Fehler Was sind erwartete Fehler? DB-Operation wird zurückgewiesen, Commit wird nicht akzeptiert, . . . Stromausfall, DBMS-Probleme Geräte funktionieren nicht (Spur, Zylinder, Platte defekt) Beliebiges Fehlverhalten der Gerätesteuerung ... Fehlermodelle von (zentralisierten) DBMS Transaktionsfehler Systemfehler Gerätefehler Katastrophen Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 56 / 58 Transaktionsverwaltung Recovery Recovery-Arten 1. Transaktions-Recovery Zurücksetzen einzelner (noch nicht abgeschlossener) TA im laufenden Betrieb (TA-Fehler, Deadlock, etc.) → Vollständiges Zurücksetzen auf BOT (TA-Undo) → Partielles Zurücksetzen auf Rücksetzpunkt (Savepoint) innerhalb der Transaktion 2. Crash-Recovery nach Systemfehler Wiederherstellen des jüngsten transaktionskonsistenten DB-Zustands: → (partielles) Redo für erfolgreiche TA (Wiederholung verlorengegangener Änderungen → Undo aller durch Ausfall unterbrochenen TA (Entfernung der Änderungen aus der DB) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 57 / 58 Transaktionsverwaltung Recovery Recovery-Arten (2) 3. Medien-Recovery nach Gerätefehler Spiegelplatten, bzw. vollständiges Wiederholen (Redo) aller Änderungen auf einer Archivkopie 4. Katastrophen-Recovery Nutzung einer aktuellen DB-Kopie in einem “entfernten” System oder stark verzögerte Fortsetzung der DB-Verarbeitung mit repariertem/neuem System auf Basis gesicherter Archivkopien Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbankanwendung, WS 14/15 58 / 58
