gegevensbanken 2012 t ransactieverwerking ii: technieken voor concurrentiecontrole

Gegevensbanken 2012

Transactieverwerking II:technieken voor concurrentiecontrole

Bettina Berendthttp://people.cs.kuleuven.be/~bettina.berendt/

2

Concurrentiecontrole en herstel:

Motivatie & Samenvatting

3

Waar zijn we?

Les # wie wat1 ED intro, ER2 ED EER, (E)ER naar relationeel schema2 ED relationeel model3 KV Relationele algebra & relationeel calculus4,5 KV SQL6 KV Programma's verbinden met gegevensbanken7 KV Functionele afhankelijkheden & normalisatie8 KV PHP9 BB Beveiliging van gegevensbanken10 BB Geheugen en bestandsorganisatie11 BB Hashing12 BB Indexstructuren13 BB Queryverwerking14-16 BB Transactieverwerking en concurrentiecontrole17 BB Data mining en data warehousing18 ED XML, NoSQL

Fysisch model / vragen

4

Concurrentiecontrole

t

reserveer!

5

Herhaling: Gewenste eigenschappen van transacties

– Atomicity: ondeelbaarheid• transactie wordt volledig uitgevoerd, of helemaal niet

– Consistency preservation:• consistente gegevensbank moet na transactie nog steeds consistent

zijn

– Isolation: geïsoleerdheid• effect van transactie moet zijn alsof het de enige transactie is die

uitgevoerd werd (geen interferentie met andere transacties)

– meerdere isolatieniveaus (bv. de 4 uit de ISO/ANSI standaard)

– Durability: duurzaamheid• effect van transactie moet persistent zijn, mag niet verloren gaan

concurrentie-controle

6

Herhaling: Testen of garanderen van serialiseerbarheid

• Problemen met testen van serialiseerbaarheid:• interleaving van operaties wordt bepaald door het

besturingssysteem, niet vooraf te voorspellen

• transacties worden continu aangeboden

– begin en einde van roosters moeilijk te voorspellen

• Indien rooster niet serialiseerbaar blijkt:

– herstel nodig duur

• om deze problemen te vermijden:• test niet op serialiseerbaarheid

• gebruik bij opstellen van transacties regels (protocols) om serialiseerbaarheid te verzekeren

7

Agenda

Vergrendeling (locking)

Tijdstempels

Multiversietechnieken

Optimistische concurrentiecontrole

Granulariteit van items

8

Agenda


Tijdstempels




9

Herhaling: Nog een voorbeeld (1) van les 14 OF niet-serialiseerbarheid ?↔? verloren aanpassingen

10

→ Doel

1. Met een eenvoudiger voorbeeld begrijpen waarom dit fouten kan veroorzaken (“Voorbeeld A“)

2. Zien hoe grendels en tijdstempels ermee omgaan

3. Met een licht veranderde versie van Voorbeeld A tonen Dat er gelijkaardige roosters zijn die toch “aanvaardbaar”

zijn:• Niet conflict-serialiseerbaar maar view-serialiseerbaar

En een system van regels om deze equivalentie te creëeren/vinden• „multiversie-concurrentiecontrole“

11

Voorbeeld A (1)

T1 T2r(Y)

r(X)r(Y)Y := X + Yw(Y)

r(X)X := X + Yw(X)

12

Initial values: X = 20, Y = 30

Result of serial schedule [T1,T2]:X = , Y = Result of serial schedule [T2,T1]:X =, Y =

T1 T2r(Y)


r(X)X := X + Yw(X)

Voorbeeld A (1)

13

Initial values: X = 20, Y = 30

Result of serial schedule [T1,T2]:X = 50, Y = 80Result of serial schedule [T2,T1]:X = 70, Y = 50

T1 T2r(Y)


r(X)X := X + Yw(X)

Resultaat van dit rooster?X = ; Y =

Is er een verloren aanpassing?Is dat conflict-serialiseerbar?

Voorbeeld A (1)

14

Vergrendeling

• grendel (slot, lock) • variabele horend bij een gegevenselement in de gegevensbank

• beschrijft de status van dat element t.o.v. mogelijke bewerkingen die erop kunnen worden uitgevoerd

– soorten grendels:• binaire grendels:

– twee mogelijke toestanden

• gedeelde / exclusieve grendels (of read / write locks)

– drie mogelijke toestanden

15

Binaire grendels

• twee mogelijke toestanden: lock(X) = 1 of 0– 1: X is niet toegankelijk– 0: X is toegankelijk

• twee bewerkingen– lock_item(X): een transactie vraagt toegang tot X– unlock_item(X): een transactie geeft X weer vrij

(deze bewerkingen zijn steeds atomair)

16

lock_item(X):B: als LOCK(X) = 0 dan LOCK(X) := 1

anderswacht tot LOCK(X) = 0;spring naar B

lock_item(X):B: als LOCK(X) = 0 dan LOCK(X) := 1

anderswacht tot LOCK(X) = 0;spring naar B

unlock_item(X):LOCK(X) := 0;als er transacties aan het wachten zijn op X:dan maak één van die transacties wakker

unlock_item(X):LOCK(X) := 0;als er transacties aan het wachten zijn op X:dan maak één van die transacties wakker

Binaire grendels: lock en unlock

• lock manager van DBMS houdt – status van grendels, – wachtende transacties etc. bij

17

Regels voor vergrendeling:Elke transactie T moet volgende regels volgen

1. T moet lock_item(X) uitvoeren

voor read_item(X) of write_item(X)

2. T moet unlock_item(X) uitvoeren

nadat alle read_item(X) en write_item(X) van T zijn uitgevoerd

3. T mag geen lock_item(X) uitvoeren

als het al een grendel op X heeft

4. T mag geen unlock_item(X) uitvoeren

als het geen grendel op X heeft

18

Lees- / schrijf-vergrendeling

– twee soorten grendels: lees-grendels en schrijf-grendels• ook gedeelde / exclusieve grendels genoemd

– drie toestanden voor gegevenselement:• niet vergrendeld (geen grendel)

• lees-grendel

• schrijf-grendel

– drie bewerkingen:• read_lock(X)

• write_lock(X)

• unlock_item(X)

19

read_lock(X):B: als LOCK(X)="unlocked"

dan LOCK(X):="read-locked";aantal_reads(X) := 1

anders als LOCK(X) = "read-locked"dan aantal_reads(X) := aantal_reads(X)+1anders

wacht tot LOCK(X)="unlocked";spring naar B

read_lock(X):B: als LOCK(X)="unlocked"

dan LOCK(X):="read-locked";aantal_reads(X) := 1

anders als LOCK(X) = "read-locked"dan aantal_reads(X) := aantal_reads(X)+1anders

wacht tot LOCK(X)="unlocked";spring naar B

write_lock(X):B: als LOCK(X)="unlocked"

dan LOCK(X) := "write-locked"anders

wacht tot LOCK(X)="unlocked";

spring naar B




spring naar B

20

unlock_item(X):B: als LOCK(X)="write-locked"

dan LOCK(X):="unlocked";als er transacties zijn die wachten op X:dan maak 1 ervan wakker

anders als LOCK(X) = "read-locked"dan aantal_reads(X) := aantal_reads(X)-1;

als aantal_reads(X) = 0 dan LOCK(X) := "unlocked"

als er transacties wachten op X:dan maak 1 ervan wakker

unlock_item(X):B: als LOCK(X)="write-locked"

dan LOCK(X):="unlocked";als er transacties zijn die wachten op X:dan maak 1 ervan wakker

anders als LOCK(X) = "read-locked"dan aantal_reads(X) := aantal_reads(X)-1;

als aantal_reads(X) = 0 dan LOCK(X) := "unlocked"

als er transacties wachten op X:dan maak 1 ervan wakker

21

Regels voor vergrendeling (bij lees / schrijf-vergrendeling):

Elke transactie T moet volgende regels volgen:

1. T moet read_lock(X) of write_lock(X) uitvoeren

vóór eender welke read_item(X)

2. T moet write_lock(X) uitvoeren

vóór write_item(X)

3. T moet unlock(X) uitvoeren

nadat alle read_item(X) en write_item(X) uitgevoerd zijn

4. T mag geen read_lock(X) uitvoeren

als het al een (lees- of schrijf-) grendel heeft op X (*)

5. T mag geen write_lock(X) uitvoeren

als het al een (lees- of schrijf-) grendel heeft op X (*)

6. T mag geen unlock(X) uitvoeren

als het geen grendel heeft op X

22

Afzwakken van regels

– (*) regels kunnen afgezwakt worden:• upgrade:

– als T al een leesgrendel op X heeft, en het is de enige transactie met een leesgrendel op X, dan kan dit met write_lock(X) in een schrijfgrendel veranderd worden

• downgrade:

– als T een schrijfgrendel op X heeft, kan dat met read_lock(X) verlaagd worden tot een leesgrendel

= conversie van grendels

23

Lees-/schrijf-vergrendeling --> serialiseerbarheid? Voorbeeld A (2)

Initial values: X = 20, Y = 30Result of serial schedule [T1,T2]:X = 50, Y = 80Result of serial schedule [T2,T1]:X = 70, Y = 50

24

Lees-/schrijf-vergrendeling serialiseerbarheid?

– Gebruik van bovenstaande regels vermijdt bepaalde problemen

maar garandeert geen serialiseerbaarheid– vb: fig. 21.3 (vorige slide)

• twee mogelijke seriële uitvoeringen:

– 1. tel X bij Y op, tel dan Y bij X op

– 2. tel Y bij X op, tel dan X bij Y op

– in een serieel schema zal één van de transacties de originele X/Y gebruiken en de andere de aangepaste

– in 21.3c gebruiken beide transacties de originele X/Y

• probleem: Y is te vroeg vrijgegeven

– daarom: strengere set regels (= een protocol) volgen

25

Twee-fasen-vergrendeling

– protocol van vergrendeling om bepaalde problemen te vermijden:

• alle vergrendelingen van een transactie gebeuren vóór de eerste ontgrendelbewerking

– binnen een transactie gebeurt vergrendeling steeds in twee fasen:

• "expanding phase": plaatsen van grendels

• "shrinking phase": vrijgeven van grendels

– de fasen zijn strikt gescheiden• eens een grendel vrijgegeven is, kunnen er geen nieuwe meer

geplaatst worden

– twee-fasen-vergrendeling garandeert serialiseerbaarheid• maar vermijdt geen deadlock / starvation

26

Voorbeeld A (3): Verschuiven van operaties

origineel

27

Voorbeeld A (3)

origineel Met twee-fasen-vergrendeling

28

Voorbeeld A (3): maar ...

Met twee-fasen-vergrendeling




spring naar B




spring naar B

29

Deadlock

• 2 processen wachten op elkaar– hebben elk een grendel die de ander wil– geven die grendel niet vrij voor ze de andere grendel krijgen

30

Varianten van twee-fasen-vergrendeling

– basisversie: • zoals gezien

– conservatieve 2FV:• alle grendels plaatsen voor transactie begint

• vermijdt deadlocks

• probleem:

– niet altijd bekend op voorhand welke grendels nodig zullen zijn

– strikte, resp. rigoureuze 2FV:• geen enkel schrijfgrendel, resp. grendel vrijgeven voor commit of

abort

• garandeert een strikt rooster

• is niet deadlock-vrij

31

• besluit: – twee-fasen-vergrendeling

• garandeert serialiseerbaarheid van rooster

• maar vermijdt geen deadlocks of starvation

• om dit op te lossen nog andere technieken nodig

– twee benaderingen van deadlock:• vermijden (deadlock prevention)

• opsporen (deadlock detection)

32

Deadlock-vermijdende protocollen

• alles vooraf vergrendelen (cf. conservatieve 2FV)– grote beperking op concurrentie

• items steeds in welbepaalde volgorde vergrendelen– programmeur moet deze volgorde kennen: in de praktijk niet

wenselijk

• gebruik van tijdstempels (timestamps)

33

Agenda


Tijdstempels




34

Deadlock-preventie met grendels en tijdstempels

– elke transactie T krijgt tijdstempel TS(T) toegekend• als T1 start voor T2: TS(T1) < TS(T2)

– mogelijke schema’s:• stel:

– Ti wil X vergrendelen maar kan niet omdat Tj er een grendel op heeft

• wait-die schema :

– als TS(Ti) < TS(Tj) (Ti is ouder dan Tj )

• dan mag Ti wachten tot grendel vrijkomt

• anders wordt Ti afgebroken (= de jongere transactie) en later herstart met dezelfde timestamp

• wound-wait schema :

– als TS(Ti) < TS(Tj) (Ti is ouder dan Tj )

• dan wordt Tj (de jongere transactie) afgebroken

• anders mag Ti (de jongere transactie) wachten tot grendel vrijkomt

35

Vordelen en nadelen

– in beide gevallen wordt jongste transactie afgebroken en later herstart

• gemiddeld gaat minder werk verloren

– voordeel: deadlock-vrij• oudere transactie wacht steeds op jongere (wait-die) of omgekeerd

(wound-wait)

• dus nooit lussen in wachtpatroon

– nadeel:• sommige transacties worden afgebroken zelfs al zouden ze geen

deadlock veroorzaken

• wait-die : Ti mogelijk vaak afgebroken en herstart

36

Deadlock-preventie zonder tijdstempels

• verschillende schema’s– niet wachten: "no waiting" schema

• als een transactie een grendel niet kan krijgen, wordt ze direct afgebroken en na een zekere tijd herstart

– voorzichtig wachten: "cautious waiting" schema• transactie mag alleen wachten op een grendel als de transactie die

die grendel heeft niet zelf aan het wachten is

– Stel: Ti wil X vergrendelen, Tj heeft grendel op X

– als Tj niet zelf wacht op een grendel

• dan laat Ti wachten

• anders breek Ti af

• is deadlock vrij!

– gebruik van timeouts:• als een transactie langer wacht dan een welbepaalde tijd, wordt ze

automatisch afgebroken en herstart

• detecteert niet echt deadlocks

37

Deadlock-detectie• periodieke controle of systeem in deadlock is

• enkel interessant wanneer er weinig interferentie tussen transacties is

– (korte transacties die slechts weinig items vergrendelen, of weinig transacties)

– detectie: op basis van "wacht op"-graaf• lus in graaf = deadlock

– indien deadlock: • kies slachtoffer om af te breken

– "victim selection":

• voorkeur voor jonge transacties die weinig aanpassingen gemaakt hebben

• of transacties die in meerdere cycles in de graaf betrokken zijn

38

t T1

Begin T2...Deadlock→ T2 is te jong→ afbreken!

Maar ...

39

t

T1


Maar ...


40

t

T1


Maar ...



41

t

T1


...

Maar ...



42

Starvation (“verhongeren”)

– definitie:• een transactie moet steeds maar blijven wachten, terwijl andere

transacties vooruitgaan

1. doordat andere wachtende transacties steeds de vrijkomende grendels krijgen, of

2. doordat de "victim selection" steeds deze transactie kiest

– oplossingen:• 1: te vermijden door eerlijke toekenning van grendels

– bv. first come, first serve

– verschillende prioriteiten + proces dat lang wacht krijgt steeds hogere prioriteit

• 2: te vermijden door eerlijke slachtofferselectie

– selecteer transactie met laagste prioriteit

– bij heropstarten van die transactie krijgt ze automatisch een hogere prioriteit

– opmerking: • wait-die en wound-wait voorkomen starvation

43

Concurrentiecontrole d.m.v. Tijdstempels (zonder grendels)

– serialiseerbaarheid garanderen d.m.v. tijdstempels i.p.v. grendels en deadlock-preventie/detectie

• geen grendels nodig geen deadlocks mogelijk

– er is één tijdstempel per transactie• tijdstempels zijn uniek

• en in chronologische volgorde

– T1 voor T2 aangeboden TS(T1) < TS(T2)

– tijdstempels ordenen de transacties– het transactierooster met tijdstempelordening is equivalent met

het serieel rooster met precies die volgorde van transacties

44

– met elk item X worden twee tijdstempelwaarden geassocieerd:• read_TS(X)

– grootste tiidstempel van alle transacties die met succes X gelezen hebben ( jongste transactie)

• write_TS(X)

– grootste tijdstempel van alle transacties die met succes X geschreven hebben ( jongste transactie)

– voor een transactie T die read_item(X) of write_item(X) wil uitvoeren:

• vergelijk tijdstempels

• beslis of T die actie mag uitvoeren

– vb: T mag X niet lezen als X door een transactie met latere tijdstempel geschreven is

45

– wat als tijdstempels niet kloppen?• transactie afbreken, ongedaan maken, en opnieuw aanbieden (nu

met latere TS)

• bij ongedaan maken (rollback):

– transacties die iets gelezen hebben dat door deze transactie geschreven werd ook ongedaan maken

– cascading rollback

– ordening op basis van tijdstempels• garandeert serialiseerbaarheid

– maar niet elk serialiseerbaar rooster wordt aanvaard

• vermijdt deadlock (maar geen starvation)

46

Transactie T voert write_item(X) uit:als read_TS(X) > TS(T) of write_TS(X) > TS(T):

(write_item komt te laat, jongere transacties hebben intussen al een oudere waarde van X gelezen of een jongere geschreven)

breek T af en maak T ongedaananders

write_item(X); write_TS(X) := TS(T)

Transactie T voert read_item(X) uit:als write_TS(X) > TS(T):

(te lezen waarde is intussen al overschreven door jongere transactie)breek T af en maak T ongedaan

anders read_item(X); read_TS(X) := max(TS(T), read_TS(X))

Transactie T voert write_item(X) uit:als read_TS(X) > TS(T) of write_TS(X) > TS(T):

(write_item komt te laat, jongere transacties hebben intussen al een oudere waarde van X gelezen of een jongere geschreven)

breek T af en maak T ongedaananders

write_item(X); write_TS(X) := TS(T)

Transactie T voert read_item(X) uit:als write_TS(X) > TS(T):

(te lezen waarde is intussen al overschreven door jongere transactie)breek T af en maak T ongedaan

anders read_item(X); read_TS(X) := max(TS(T), read_TS(X))

Basis tijdstempelordeningsalgoritme

47

Taak

Hoe verwerkt het tijdstempelordeningsalgoritme Voorbeeld A?

48

Voorbeeld A

1. T1 begint → TS(T1) = 1

2. T1.r(Y) gewenst → w_TS(Y0) > TS(1)? neen → r_TS(Y) = max(1,0)=1


4. T2.r(X) gewenst → w_TS(X) > TS(T2)? neen → r_TS(X) =max(3,0) = 3

5. T2.r(Y) gewenst → w_TS(Y) > TS(T2)? neen → r_TS(Y) = max(3,1) = 3

6. T2.w(Y) gewenst → r_TS(Y) of w_TS(Y) > TS(T2)? Neen → w_TS(Y) = 3

7. T1.r(X) gewenst → w_TS(X) > TS(T1)? neen → r_TS(X) = max(1,3) = 3

8. T1.w(X) gewenst → r_TS(X) of w_TS(X) > TS(T1)? ja → ABORT T1 !

T1 T2r(Y)


r(X)X := X + Yw(X)

* A niet conflict-serialiseerbar; [T2,T1] wordt afgedwongen

Voor rooster:r_TS(X) = w_TS(X) = r_TS(Y) = w_TS(Y) = 0

49

– problemen met het basis tijdstempelordeningsalgoritme:• cascading rollbacks

• niet herstelbaar

– reeds gecommitte transacties moeten soms ook ongedaan gemaakt worden

– strikte tijdstempelordening:• = een variante van het basis algoritme

• een transactie T

– die read_item(X) of write_item(X) doet met TS(T) > write_TS(X)

– wacht met deze operatie tot de transactie met timestamp write_item(X) gecommit of afgebroken is

• garandeert strikt rooster

50

Transactie T voert write_item(X) uit:als read_TS(X) > TS(T): (write_item komt te laat)

breek T af en maak T ongedaananders als write_TS(X)>TS(T): (write_item is niet meer relevant)

voer de write_item niet uit maar ga gewoon door(evt. problemen hierdoor veroorzaakt worden ontdekt door andere regels)

anders write_item(X); write_TS(X) := TS(T)

Transactie T voert write_item(X) uit:als read_TS(X) > TS(T): (write_item komt te laat)

breek T af en maak T ongedaananders als write_TS(X)>TS(T): (write_item is niet meer relevant)

voer de write_item niet uit maar ga gewoon door(evt. problemen hierdoor veroorzaakt worden ontdekt door andere regels)

anders write_item(X); write_TS(X) := TS(T)

– Thomas’ schrijfregel:licht gewijzigde versie t.o.v. basis tijdstempelordeningsalgoritme

• legt geen conflict-serialiseerbaarheid op

• verwerpt minder write_items

• wijziging aan write_item procedure:

51

Agenda


Tijdstempels




52

Multiversie-concurrentiecontrole

– er worden meerdere waarden (versies) van een item X door het systeem bewaard:

• X1, X2, ..., Xk

– voor elke versie zijn er twee tijdstempels: • read_TS( Xi ):

– grootste TS van alle T die Xi met succes gelezen hebben

• write_TS( Xi ):

– TS van de T die Xi geschreven heeft

– als T een write_item(X) mag uitvoeren:• creatie van nieuwe versie Xk+1

• met

– read_TS(Xk+1), write_TS(Xk+1) := TS(T)

– Als T de waarde van versie Xi mag lezen:

• wordt

– read_TS(Xi) := max(read_TS(Xi), TS(T))

53

Transactie T wil een write_item(X) uitvoeren:zij Xi de versie van X met de grootste write_TS(Xi) <= TS(T)als TS(T) < read_TS(Xi) (d.w.z. versie Xi zou dan moeten gelezen

zijn nadat T geschreven heeft)dan breek T af en maak T ongedaan anders

creëer nieuwe versie Xj van Xread_TS(Xj) := TS(T)write_TS(Xj) := TS(T)

Transactie T wil een read_item(X) uitvoeren:zoek de versie i van X met hoogste write_TS(Xi) <= TS(T)geef de waarde van Xi terug aan T read_TS(X

i) := max(TS(T), read_TS(X

i))

Transactie T wil een write_item(X) uitvoeren:zij Xi de versie van X met de grootste write_TS(Xi) <= TS(T)als TS(T) < read_TS(Xi) (d.w.z. versie Xi zou dan moeten gelezen

zijn nadat T geschreven heeft)dan breek T af en maak T ongedaan anders

creëer nieuwe versie Xj van Xread_TS(Xj) := TS(T)write_TS(Xj) := TS(T)

Transactie T wil een read_item(X) uitvoeren:zoek de versie i van X met hoogste write_TS(Xi) <= TS(T)geef de waarde van Xi terug aan T read_TS(X

i) := max(TS(T), read_TS(X

i))

54

T1 T2r(Y)

r(X) w(X)r(Y)Y := X + Yw(Y)

r(X)X := X + Y

w(X)

Voorbeelden A, A', A''

55

Voorbeelden A', A''

T1 T2r(Y)

r(X)w(X)r(Y)Y := X + Yw(Y)

r(X)X := X + Yw(X)

… zijnniet conflict-serialiseerbar(Voorbeeld A ook niet)

56

Taak

Hoe verwerkt het multiversie-concurrentiecontrole-algoritme Voorbeeld A?

Wat leren we eruit over de aanvaardde roosters?

57

Voorbeelden A', A''


2. T1.r(Y) gewenst → Y0 enige candidaat met w_TS(Y0) <= TS(1) → r_TS(Y0) = max(1,0)=1


4. T2.r(X) gewenst → X0 enige candidaat met w_TS(X0) <= TS(T2); w_TS(X0) <= TS(T2)? Ja → r_TS(X0) =max(3,0) = 3

5. T2.w(X) gewenst → X0 enige candidaat (zie stap 4); TS(T2) < r_TS(X0)? Neen → nieuw X1 met r_TS(X1) = w_TS(X1) = 3

6. T2.r(Y) gewenst → Y0 enige candidaat met w_TS(Y0) <= TS(T2) → r_TS(Y0) = max(3,1) = 3

7. T2.w(Y) gewenst → Y0 enige candidaat (zie stap 6); TS(T2) < r_TS(Y0)? Neen → new Y1 met r_TS(Y1) = w_TS(Y1) = 3

8. T1.r(X) gewenst → X0 enige candidaat met w_TS(X0) <= TS(T1) → read X0 ! En r_TS(X0) = max(1,3) = 3

9. T1.w(X) gewenst → X0 enige candidaat met w_TS(X0) <= TS(T1) → TS(T1) < r_TS(X0)? Ja → ABORT T1 !

T1 T2r(Y)

r(X)w(X)r(Y)Y := X + Yw(Y)

r(X)X := X + Yw(X)

* A', A'' niet conflict-serialiseerbar* A' view-serialiseerbaar equiv. met [T1,T2]* A'' niet serialiseerbaar; [T2,T1] wordt afgedwongen

Voor rooster:r_TS(X0) = w_TS(X0) = r_TS(Y0) = w_TS(Y0) = 0

58

– Er bestaan nog andere multiversie-technieken• bv. met grendels i.p.v. tijdstempels

• ...

59

Agenda


Tijdstempels




60

Optimistische concurrentiecontrole– methode:

• er gebeurt geen controle terwijl transactie wordt uitgevoerd

• alle aanpassingen gebeuren in lokale kopies van gegevens

• op het einde van de transactie: valideringsfase

– indien serialiseerbaarheid voldaan:

• pas gegevensbank aan, commit transactie

– indien niet:

• herstart transactie later

– drie fasen:• leesfase:

– T kan waarden van gegevensbank lezen

– aanpasingen gebeuren in lokale kopies

• valideringsfase

– controle op serialiseerbaarheid

• schrijffase:

– als controle positief blijkt, worden aanpassingen in de gegevensbank geschreven

61

– voordeel:• alle controles voor een transactie in één keer ( weinig last voor

en tijdens transactie zelf)

– bij kleine interferentie tussen transacties:• meeste transacties worden succesvol gevalideerd

– bij grote interferentie:• veel volledig uitgevoerde transacties moeten herstart worden

62

Implementering van optimistische concurrentiecontrole met tijdstempels

• voor elke transactie:– write_set: verzameling van alle geschreven items– read_set: verzameling van alle gelezen items– start- en eindtijd voor de 3 fasen wordt bijgehouden met

tijdstempels• valideringsfase controleert of Ti niet interfereert met een committed

transactie of met een transactie in valideringsfase:– Voor elke Tj die gecommit of in valideringsfase is, moet één

van volgende eigenschappen gelden:

1. Tj beëindigt zijn schrijffase voor Ti zijn leesfase begint

2. Ti start zijn schrijffase nadat Tj zijn schrijffase beëindigt, en read_set(Ti) write_set(Tj) =

3. Tj beëindigt leesfase voor Ti leesfase beëindigt, en

read_set(Ti) write_set(Tj) = en write_set(Ti) write_set(Tj) =

– Indien OK: • succes; • zoniet: Ti faalt ( later herstarten )

63

Agenda


Tijdstempels




64

Granulariteit van gegevensitems

• keuze van een item– read_item, write_item: wat is een "item"?

• gegevensbank (grove granulariteit)

• bestand

• blok op schijf

• record

• veld in record (fijne granulariteit)

– hoe groter het item, • hoe minder concurrentie mogelijk

– hoe kleiner het item, • hoe meer items

• meer grendels, lock/unlock bewerkingen, tijdstempels, ...

• extra ruimte en verwerkingstijd nodig

65

– ideale granulariteit hangt af van soort transactie• bv. toegang tot veel records in een bestand:

– niveau "bestand" beter

• toegang tot slechts enkele records

– niveau "record" beter

– evt. mogelijk om vergrendeling op verschillende niveaus van granulariteit uit te voeren

• keuze tussen bv. heel bestand vergrendelen, één record in bestand vergrendelen, ...

66

Vergrendeling met meervoudige granulariteitsniveaus

• een gegevensbanksysteem kan meerdere niveaus van granulariteit ondersteunen– voorbeeld:

• gegevensbanksysteem met twee bestanden, • elk bestand met verscheidene pagina’s (= blokken), • elke pagina met verscheidene records.• met grendels die op elk niveau kunnen worden geplaatst

67

Vergrendeling met meervoudige granulariteitsniveaus

• een gegevensbanksysteem kan meerdere niveaus van granulariteit ondersteunen– voorbeeld:

• gegevensbanksysteem met twee bestanden, • elk bestand met verscheidene pagina’s (= blokken), • elke pagina met verscheidene records.• met grendels die op elk niveau kunnen worden geplaatst

68

Intention locks (I)

– extra type van grendels nodig: intention locks• IS: intention shared locks:

– gedeelde grendel(s) zal (zullen) gevraagd worden op lagere niveaus

• IX: intention exclusive locks:

– een exclusieve grendel zal gevraagd worden op een lager niveau

• SIX: shared-intention-exclusive locks:

– het actuele knooppunt is in gedeelde mode vergrendeld, maar een exclusieve grendel zal op een lager niveau gevraagd worden

69

Intention locks (II)

compatibiliteitsmatrix:

Geeft aan of een transactie T een knooppunt kan locken indien daar al een lock op staat

S shared lockX exclusive lock

70

Meervoudige granulariteitsvergrendelingsprotocol

1. de vergrendeling moet rekening houden met de compatibiliteit

2. de wortel van de boom moet eerst vergrendeld worden

3. een knooppunt N kan slechts vergrendeld worden door een transactie T in S of IS modus indien het ouder knooppunt van N reeds vergrendeld is in IS of IX modus

4. een knooppunt N kan slechts vergrendeld worden door een transactie T in X, IX of SIX modus indien het ouder knooppunt van N reeds vergrendeld is in IX of SIX modus

5. een transactie T kan een knooppunt slechts vergrendelen indien het geen knooppunt ontgrendeld heeft (om aan 2-fase protocol te voldoen)

6. een transactie T kan een knooppunt N enkel ontgrendelen indien geen van de kinderen van N op dat ogenblik vergrendeld zijn door T

compatibiliteitsmatrix:

S shared lockX exclusive lock IS intention shared lockIX intention exclusive lockSIX shared-intention- exclusive lock

71

• voorbeeld:1. T1 wil record r111 en record

r211 aanpassen

2. T2 wil alle records op pagina p12 aanpassen

3. T3 wil record r11j en het volledige bestand f2 lezen

– een serialiseerbaar rooster is hiernaast gegeven

aanp. r111

aanp. r211

aanp. p12

lees f2

lees r11j

aanp. r111

2

72

Concurrentiecontrole in indexen

• index als boom-structuur (b.v. B+ ):– elke opdracht begint bij wortel

• wortel vergrendelen

• concurrentie in hele bestand wordt beperkt

– bij lees-grendel: enkel andere lees-opdrachten mogelijk

– bij schrijf-grendel: geen andere opdrachten mogelijk

– verschillende bewerkingen:• enkel lezen:

– index zal niet wijzigen

• aanpassing van velden in records:

– index zal niet wijzigen

• toevoeging of weglating van records:

– wijziging van index begint op laagste niveau, en kan zich tot in de wortel naar boven voortplanten

73

Mogelijke oplossingen (I)

1. wanneer geen toevoegingen of weglatingen gebeuren:• vergrendeling van actuele niveau is voldoende:

• daarom:

– vergrendeling van ouder opgeven zodra naar kind wordt overgegaan

74

Mogelijke oplossingen (II)

1. wanneer wel toevoegingen of weglatingen gebeuren:• eventueel een beperkt aantal niveaus vergrendelen:

– ouder ( en siblings ) van actuele knoop

– bv. vergrendeling van grootouder opgeven zodra naar kleinkind wordt overgegaan

– dit volstaat dikwijls bij aanpassingen

• indien niet voldoende niveaus vergrendeld (als aanpassing op hogere dan vergrendelde niveaus effect heeft):

– bewerking ongedaan maken en opnieuw aanbieden, ditmaal met vergrendeling op volledige pad

• zuivere “top-down” algoritmen gebruiken,

– die knooppunten die bijna vol zijn reeds splitsen tijdens afdaling

– knooppunten die erg leeg zijn reeds samenvoegen tijdens afdaling

75

Vooruitblik


Tijdstempels




Herstel

76

Discussie / Taak (gevorderd)

• De ANSI-SQL isolatieniveaus zijn– READ COMMITTED– READ UNCOMMITTED– REPEATEABLE READ– SERIALIZABLE

• De isolatieniveaus zijn gedefineerd door de problemen die ze vermijden. Welke zijn dit? (herhaling van lesinhoud)

• Welke van de in les #15 geziene methodes kunnen deze niveaus waarschijnlijk garanderen?

• Is er iets mis? (als je naar de hele inhoud van #14 en #15 kijkt)• Welke isolatieniveaus hebben, bv., Oracle of MySQL? Heb je een idee waarom?• Meer informatie:

– http://en.wikipedia.org/wiki/Isolation_(database_systems)– Hal Berenson, Phil Bernstein, Jim Gray, Jim Melton, Elizabeth O'Neil, and Patrick

O'Neil. 1995. A critique of ANSI SQL isolation levels. In Proceedings of the 1995 ACM SIGMOD international conference on Management of data (SIGMOD '95), Michael Carey and Donovan Schneider (Eds.). ACM, New York, NY, USA, 1-10. http://www.cs.umb.edu/~poneil/iso.pdf

– Atul Adya, Barbara Liskov, and Patrick O'Neil. 2000. Generalized Isolation Level Definitions. In Proceedings of the 16th International Conference on Data Engineering (ICDE '00). IEEE Computer Society, Washington, DC, USA, 67-78. http://pmg.csail.mit.edu/papers/icde00.pdf

77

Bronnen

• Deze slides zijn gebaseerd op Henk Olivié‘s slides voor Gegevensbanken 2009 en op Elmasri & Navathe, Fundamentals of Database Systems, Addison Wesley / Pearson, 5e editie 2007 (soms gecorrigeerd, zie ook 6e ed.).

• Alle kopieën zonder bronspecificatie: Elmasri & Navathe, Fundamentals of Database Systems, Addison Wesley / Pearson, 5e editie 2007.

• p. 48: Robert H. Thomas, in ACM Transactions on Database Systems, 1979

• Verdere figuren: bronnen zie “Powerpoint comments field”

• Bedankt iedereen!

gegevensbanken 2012 t ransactieverwerking ii: technieken voor concurrentiecontrole

Documents