Creative Commons License Deed - Salle-URL · Creative Commons License Deed Reconeixement-No...

Creative Commons License Deed Reconeixement-No comercial-Sense obres derivades 2.5 Espanya

Vostè és lliure de: Copiar, distribuir i comunicar públicament l’obra.

Sota els següents condicionants:

Reconeixement. S’ha de referenciar aquesta obra a August Climent - Enginyeria La Salle (Estudis Semipresencials).

No comercial. No es pot utilitzar aquesta obra per a finalitats comercials. Sense obres derivades. No es pot alterar, transformar o generar una obra derivada a partir d’aquesta.

• Quan reutilitzeu o distribuïu l'obra, heu de deixar ben clar els termes de la llicència de l'obra. • Alguna d'aquestes condicions pot no aplicar-se si obteniu el permís del titular dels drets d'autor.

• No hi ha res en aquesta llicència que menyscabi o restringeixi els drets morals de l'autor.

Els drets derivats d'usos legítims o altres limitacions reconegudes per llei no queden afectats per l'anterior

Això és un resum fàcilment llegible del text legal (la llicència completa) disponible en els idiomes següents:

Català Castellà Basc Gallec

Crèdits

Autor: August Climent

Editor: Lluís Vicent

Coordinació lingüística: Sara Laso

Revisió lingüística: Cristóbal Cabeza

Maquetació: Sara Laso

Disseny de portada: Marc Segarra

Aquesta edició ha comptat amb el suport de l’Agència de Gestió d’Ajuts Universitaris i de Recerca (AGAUR) de la Generalitat de Catalunya en la Convocatòria d’ajuts a l’edició i la difusió de llibres de text o manuals universitaris i llibres cientificotècnics, en suport paper o en suport electrònic, escrits en llengua catalana (DILL 2008).

ISBN: 978-84-935665-5-5

1

ÍNDEX

SESSIÓ 1 ..................................................................................................................... 5

1. Bases de dades relacionals ..................................................................................... 5

1.1. El model relacional i arquitectura ................................................................................ 5

SESSIÓ 2 ..................................................................................................................... 9

1.2. La normalització .......................................................................................................... 9

SESSIÓ 3 ................................................................................................................... 15

1.3. Càlcul i àlgebra relacional .......................................................................................... 15

SESSIÓ 4 ................................................................................................................... 19

SESSIÓ 5 ................................................................................................................... 35

1.4. Integritat i seguretat ................................................................................................. 35

SESSIÓ 6 ................................................................................................................... 41

1.5. Model bàsic d’un gestor relacional ............................................................................ 41

SESSIÓ 7 ................................................................................................................... 45

2. Bases de dades distribuïdes .................................................................................. 45

2.1. Introducció ............................................................................................................... 45

2.2. Definició i arquitectura ............................................................................................. 47

SESSIÓ 8 ................................................................................................................... 51

2.3. Serveis i problemes dels gestors distribuïts ............................................................... 51

SESSIÓ 9 ................................................................................................................... 63

2.4. Transparència i models distribuïts ............................................................................. 64

SESSIÓ 10 ................................................................................................................. 69

SESSIÓ 11 ................................................................................................................. 73

2.5. Diccionari de dades ................................................................................................... 73

SESSIÓ 12 ................................................................................................................. 75

2.6. Model bàsic d’un gestor distribuït ............................................................................. 75

SESSIÓ 13 ................................................................................................................. 79

3. Disseny de gestors distribuïts ................................................................................ 79

3.1. Introducció ............................................................................................................... 79

3.2. Disseny i distribució .................................................................................................. 81

SESSIÓ 14 ................................................................................................................. 85

SESSIÓ 15 ................................................................................................................. 91

2

3.3. Fragmentació horitzontal .......................................................................................... 91

SESSIÓ 16 ................................................................................................................. 99

3.4. Models de cost i ubicació .......................................................................................... 99

SESSIÓ 17 ............................................................................................................... 105

3.5. Exercicis .................................................................................................................. 105

SESSIÓ 18 ............................................................................................................... 109

4. Processament de peticions .................................................................................. 109

4.1. Introducció ............................................................................................................. 109

SESSIÓ 19 ............................................................................................................... 117

4.2. Nivells en el processament de peticions .................................................................. 117

SESSIÓ 20 ............................................................................................................... 123

SESSIÓ 21 ............................................................................................................... 127

4.3. Algorismes d’execució de joins ................................................................................ 127

SESSIÓ 22 ............................................................................................................... 141

4.4. Modelització del sistema ......................................................................................... 141

SESSIÓ 23 ............................................................................................................... 147

4.5. Optimització en els gestors centralitzats ................................................................. 147

SESSIÓ 24 ............................................................................................................... 155

SESSIÓ 25 ............................................................................................................... 161

SESSIÓ 26 ............................................................................................................... 169

4.6 Optimització en els gestors distribuïts. ..................................................................... 169

SESSIÓ 27 ............................................................................................................... 175

SESSIÓ 28 ............................................................................................................... 181

4.7. Exercicis .................................................................................................................. 181

SESSIÓ 29 ............................................................................................................... 191

5. Control de concurrència ...................................................................................... 191

5.1. Introducció ............................................................................................................. 191

SESSIÓ 30 ............................................................................................................... 197

5.2. Arquitectura ........................................................................................................... 197

SESSIÓ 31 ............................................................................................................... 203

5.3. Teoria de la serialització .......................................................................................... 208

SESSIÓ 32 ............................................................................................................... 213

5.4. Algorismes pessimistes basats en adquisicions ........................................................ 213

SESSIÓ 33 ............................................................................................................... 221

3

5.5. Detecció i resolució del bloqueig ............................................................................. 221

SESSIÓ 34 ............................................................................................................... 227

5.6. Algorismes s2pl i ww2pl .......................................................................................... 227

SESSIÓ 35 ............................................................................................................... 249

5.7. Exercicis .................................................................................................................. 249

BIBLIOGRAFIA ......................................................................................................... 253

GLOSSARI ............................................................................................................... 255

5

SESSIÓ 1 Nom: El model relacional Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:

o Bibliografia bàsica: [Tamer1999]

PRECEDENTS Aquesta és la primera sessió del capítol de bases de dades relacionals i la primera sessió de l’assignatura.

OBJECTIUS En aquesta sessió s’estudia el model relacional i s’introdueixen els principis del seu funcionament.

CONTINGUTS En aquesta sessió s’estudia el model relacional. Inicialment es justifica la seva utilització i es veuen els motius que han facilitat la seva implantació. Seguidament s’explica la notació emprada en la seva utilització i finalment s’analitzen les seves principals característiques a partir de les dotze regles d’en Codd.

1. Bases de dades relacionals En aquest tema s’explica el model relacional així com les seves principals característiques.

1.1. El model relacional i arquitectura El model relacional és el model que utilitzen els sistemes gestors de bases de dades relacionals per a representar i guardar la informació que gestionen. És el model emprat per la majoria de sistemes gestors comercials que s’utilitzen en els sistemes d’informació actuals. La seva gran implantació es deu principalment a tres factors: 1.- Utilització d’estructures de dades senzilles. Tota la informació està estructurada a partir de taules formades per tuples i atributs i de forma independent a la seva memorització física.

6

2.- Facilitat per garantir la consistència de la informació. El model relacional facilita el disseny de les bases de dades a partir de processos de normalització que eliminen inconsistències en el model de dades. La consistència de la informació es pot mantenir fàcilment a partir de la definició de regles d’integritat. 3.- Definició i gestió de la informació a partir d’àlgebra i càlcul relacional. La definició i tractament de la informació es fa a partir d’SQL (càlcul relacional) el qual treballa directament amb conjunts de dades, tal com defineix el model relacional. Aquest llenguatge és força clar i senzill d’utilitzar, cosa que l’ha convertit en un estàndard. Segons el model relacional, una taula o relació és un conjunt de files o tuples que formen una llista de valors. Totes les tuples de la relació estan formades pel mateix nombre de camps o atributs. Llavors, la representació d’una relació es fa en forma de taula, tal com es pot veure a continuació en la taula Productes. Productes

A partir del nom de la relació i el nom dels atributs que la formen, es defineix l’esquema de la relació. Llavors, l’esquema de la relació Productes és: Productes(Codi Producte, Descripció, Preu) El nombre d’atributs que formen la relació es defineix com a grau de la relació i el nombre de tuples d’una relació és la cardinalitat de la relació, que es dóna a partir de card(NomRelació). Per tant, la relació Productes és de grau 3 i amb una cardinalitat 4, ja que card(Productes)=4. El domini d’un atribut és el conjunt de valors diferents que pot adoptar l’atribut, que es dóna a partir de dom(NomAtribut). Llavors, la cardinalitat del domini d’un atribut és el nombre diferent de valors que adopta un atribut de la relació. En referència a la relació Productes sabem que: Card(dom(Descripció))=4 La longitud d’un atribut és el nombre de bytes que aquest utilitza per guardar un valor de l’atribut. En canvi, la longitud d’una relació és el nombre de bytes que utilitza per guardar una tupla, que és igual a la suma de les longituds de tots els atributs de la relació. A partir d’aquests valors es pot definir el grandària d’una relació com: Size(NomRelació)=card(NomRelació) * long(NomRelació) Una característica que han de complir totes les relacions d’una base de dades és que han de tenir una clau primària, que és l’atribut que permet identificar de forma única la informació. En l’exemple de la taula anterior la clau primària és l’atribut CodiProducte,

7

ja que a partir del seu valor es pot accedir al valor de la resta dels atributs, que són Descripció i Preu. Llavors, el conjunt dels esquemes de totes les relacions que formen una base de dades s’anomena esquema de la base de dades. A partir de l’esquema de la base de dades, es facilita l’accés a la informació a partir del llenguatge SQL. En aquesta assignatura se suposa que l’estudiant té un bon coneixement del llenguatge SQL així com uns coneixements bàsics d’arxius i bases de dades. A [Ullman1997] hi ha els conceptes bàsics relatius als sistemes gestors, a [Garcia2000] p15-17 hi ha un breu resum d’SQL i a [Groff1990] hi ha una descripció més detallada d’SQL. Les característiques principals del model relacional es poden estudiar a partir de les 12 regles que va proposar en Codd que han de complir aquest tipus de sistemes. Aquestes són: 1.- Informació. Tota la informació de la base de dades està organitzada en taules. 2.- Garantia d’accés. S’ha de garantir l’accés a qualsevol dada de la base de dades a partir del nom de la taula, l’atribut que es vol consultar i el valor de la clau primària associada a la informació. 3.- Nulls. El sistema ha de suportar dades de tipus null així com el seu tractament. 4.- Diccionari basat en el model relacional. El diccionari de dades del sistema també ha de seguir el model relacional. 5.- Subllenguatge d’accés. Ha d’existir un subllenguatge d’accés que permeti: Definir l’estructura de la base de dades (taules, atributs i vistes), manipular les dades, definir regles d’integritat, garantir la seguretat mitjançant la gestió dels privilegis i suportar transaccions. 6.- Modificació amb vistes. S’ha de permetre la modificació de les dades de les taules a partir de les vistes que s’han definit sobre aquestes. 7.- Gestió de les dades per conjunts. Les operacions de consulta i modificació de la informació han de permetre fer les operacions per grups de tuples. 8.- Independència de la ubicació de les dades. Els programes d’accés a la informació són independents als mètodes d’accés utilitzats pel sistema per accedir-hi. 9.- Independència de les dades lògiques. Els canvis en el model de dades no han de provocar canvis en els programes que tracten la informació. 10.- Integritat independent. La integritat de la informació s’ha de definir des del subllenguatge d’accés. 11.- Independència de distribució. El llenguatge d’accés ha de permetre accedir a les dades de forma independent a la seva ubicació.

8

12.- No subversió. Si existeix un llenguatge addicional que permet tractar la informació a nivell de tupla, aquest no ha de permetre violar les regles d’integritat definides.

[Groff1990]p49-p69

RESUM En aquesta sessió s’ha estudiat el model relacional. S’ha justificat la seva utilització i s’han vist els motius que han facilitat la seva implantació. També s’ha estudiat la notació emprada en la seva utilització i finalment s’han vist les seves principals característiques a partir de les dotze regles d’en Codd.

9

SESSIÓ 2 Nom: La normalització Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la segona sessió del capítol de bases de dades relacionals. A la primera sessió s’ha estudiat el model relacional.

OBJECTIUS En aquesta sessió s’estudia la teoria de la normalització.

CONTINGUTS En aquesta s’estudia la teoria de la normalització. Aquest és un procés que aplicat a l’esquema de la base de dades, permet obtenir un model de dades correcte. Per fer-ho, es comença amb la justificació de la seva utilització, després s’analitzen els conceptes de dependències funcionals i finalment les formes normals.

1.2. La normalització En aquest tema s’explica la normalització. Mitjançant la seva utilització es garanteix que els models de dades del sistema siguin correctes.

La normalització

La normalització és un procés reversible que es va aplicant a l’esquema de la base de dades i que permet obtindre un esquema nou equivalent al de partida però més simple i regular. Mitjançant la seva utilització s’eliminen tres problemes que es poden presentar en l’esquema original de la base de dades. Aquests són: 1.- Repetició de dades. Si hi ha informació repetida es dificulta el manteniment de la seva consistència entre les diferents còpies. Per tant, és una situació que s’ha d’evitar. 2.- Afegir dades incompletes. S’ha de poder afegir informació al sistema amb valors desconeguts d’alguns atributs.

10

3.- Esborrat incorrecte de dades. Si s’esborra informació, només s’ha d’esborrar la informació estrictament necessària i sense cap tipus de restricció relativa a altres dades. Per tal d’evitar les tres problemàtiques anteriors, es dissenya l’esquema de la base de dades a partir d’una sola relació, anomenada relació universal, i llavors es va transformant mitjançant el compliment de les formes normals fins obtenir l’esquema correcte de la base de dades. Per cada iteració del procés de normalització es descompon una relació amb dues o més relacions. Per fer-ho, les noves relacions han d’estar en una forma normal de nivell superior, ja que hi ha un total de cinc formes normals (de l’1FN a la 5FN). Per tant, quan l’esquema de la base de dades està en cinquena forma normal 5FN, podem afirmar que aquest és correcte. Per definir les formes normals, primer cal descriure les funcions de dependència dels atributs, ja que aquestes s’utilitzen en aplicar el procés de normalització.

Dependència funcional

R és una relació i està formada pels atributs

. Llavors, si per cada valor d’X en R, només hi ha un sol valor associat d’Y, llavors es pot afirmar que X determina funcionalment Y, o el que és el mateix, que Y és funcionalment depenent d’X. Això s’expressa amb . Normalment, la clau primària d’una relació determina funcionalment el valor de la resta d’atributs de la relació i també en un relació pot haver-hi més d’una dependència funcional. A continuació en tenim un exemple: Productes

Models

11

En aquest cas s’observen les dependències funcionals següents:

Dependència funcional total o parcial

La definició de dependència funcional es pot detallar més a partir de la definició de les dependències funcionals totals i parcials. Si tenim dues dependències funcionals, Xj→Yj, Xi→Yi i Xj⊆Xi llavors: Els atributs Yi ⊆ Yj són parcialment dependents i els atributs Yi ⊄ Yj són totalment dependents. Llavors, segons les dues dependències funcionals que hi ha a l’esquema de les relacions anteriors podem afirmar que els atributs Descripció i Preu són parcialment dependents i l’atribut Unitats és totalment depenent.

Dependència de múltiples valors

Si per cada valor de Z en R, hi ha un únic valor de la parella (X,Y), y el valor de Z només depèn del valor d’X, podem afirmar que X multidetermina Z, i s’expressa de forma Aquesta multidependència és on el valor d’un atribut o conjunt d’atributs X determinen un conjunt de valors d’un altre atribut o conjunt d’atributs Z. Un exemple el tenim a l’esquema següent:

Distribuïdors (CodiComercial, CodiProducte, Lloc) Si els comercials poden vendre en diferents llocs independentment del producte que venen, llavors es pot afirmar que:

A partir de les dependències funcionals totals, parcials i de múltiples valors, a continuació es descriuen les formes normals que s’han d’utilitzar per tal d’obtenir un esquema correcte de la base de dades.

Formes Normals

Primera forma normal 1FN Una relació està en 1FN si només conté valors atòmics dels atributs.

12

L’esquema anterior no està en 1FN, ja que l’atribut autor no és atòmic. Si es normalitza queda de forma:

Segona forma normal 2FN Una relació està en 2FN si està en 1FN i si tots els atributs que no pertanyen a la clau primària depenen funcionalment de tots els atributs de la clau primària.

La clau primària de Preus és . Per tant, si el Preu depèn del CodiProducte i CodiDepartament, l’esquema està en 2FN. Ara bé, si el Preu només depèn del CodiProducte, llavors no està en 2FN i per normalitzar-ho caldria dividir la relació Preus en dues relacions de forma:

Tercera forma normal 3FN Una relació està en 3FN si està en 2FN i no hi ha dependència funcional transitiva dels atributs que no pertanyen a la clau primària amb els atributs de la clau primària.

La clau primària de la relació Productes és CodiProducte. Si el Descompte només depèn del Preu sí que està en 3FN ja que

Ara bé, si el Descompte també depèn del CodiProducte, llavors hi ha dependència funcional transitiva i no està en 3FN. Llavors, per normalitzar-ho cal dividir la relació de forma:

Forma normal de Boyce-Codd Una relació està en la forma normal de Boyce-Codd si està en 3FN i no existeix cap dependència funcional d’un atribut que no pertany a la clau primària amb algun dels atributs de la clau primària.

13

Sous(SouBase, Carrec, Plus) La clau primària de la relació Sous és (SouBase, Carrec). Sabem que

amb la qual cosa la relació Sous no està en forma normal de Boyce-Codd. Per arreglar-ho es divideix la relació Sous en dues relacions que són:

Quarta forma normal 4FN Una relació està en 4FN si està en forma normal de Boyce-Codd i no existeixen dependències funcionals de múltiple valor. Si existeixen dependències funcionals de múltiple valor, cal dividir la relació original en tantes relacions com dependències de múltiple valor hi hagi. Per exemple:

Si sabem que

la relació original Projectes no està en 4FN. Per arreglar-ho, aquesta es divideix en dues relacions de forma:

Cinquena forma normal 5FN. Una relació està en 5FN si està en 4FN i si tots els seus atributs són clau primària i existeixen dependències de múltiple valor entre ells.

En aquest cas com que no hi ha dependències de múltiple valor entre tots els atributs, i tots els atributs formen part de la clau primària de la relació, aquesta no està en 5FN. Per arreglar-ho es divideix la relació original en tantes relacions com combinacions d’atributs existeixen agafant-los de dos en dos. Per tant, el model que compleix la 5FN seria:

14

[Tamer1999] p27-p34

RESUM En aquesta sessió s’ha estudiat la teoria de la normalització que és un procés que aplicat a l’esquema de la base de dades permet obtenir un model de dades correcte. Per fer-ho s’ha començat amb la justificació de la seva utilització, després s’han analitzat els conceptes de dependències funcionals i finalment les formes normals.

15

SESSIÓ 3 Nom: Càlcul relacional Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la tercera sessió del capítol de bases de dades relacionals. A les sessions anteriors s’ha estudiat el model relacional i la normalització.

OBJECTIUS En aquesta sessió s’estudia el càlcul relacional.

CONTINGUTS En aquesta sessió s’estudia el càlcul relacional, ja que aquest s’utilitza per especificar les peticions que rep del sistema.

1.3. Càlcul i àlgebra relacional En aquest tema s’introdueix el càlcul relacional. Aquest s’utilitza per especificar les peticions que es donen al sistema gestor.

Càlcul relacional

Hi ha dos tipus diferents de llenguatges per a la gestió de la informació del model relacional que són el Càlcul Relacional i l’Àlgebra Relacional. La principal diferència d’aquests llenguatges rau en la forma en què es dóna la petició. L’Àlgebra Relacional és un llenguatge processual, ja que en donar la petició s’indica el procediment que cal seguir per a la seva execució. En canvi, el Càlcul Relacional és un llenguatge no processual, ja que només s’indica la informació que es vol obtenir sense indicar cap tipus de procediment a seguir per la seva obtenció. El llenguatge més utilitzat en l’actualitat per accedir a la informació del model relacional és el llenguatge SQL (Structured Query Language). Aquest llenguatge és un bon exemple de Càlcul Relacional. Hi ha dos tipus de llenguatges basats en Càlcul Relacional, que són els basats en Tuples i els basats en el Domini.

16

Càlcul Relacional basat en Tuples

Les variables emprades sempre són les tuples de les relacions on les peticions s’acostumen a donar de forma En aquest cas t és la variable o tupla i F és una fórmula complerta. Les fórmules que s’utilitzen són: Per especificar el conjunt de tuples d’una relació i s’indica amb . Per especificar una condició de forma . En aquest cas s és la variable de la tupla, A és un atribut de la variable, θ és un operador de comparació aritmètica i c és una constant. Per exemple:

També es poden donar condicions que afecten dues relacions de forma s[A] θ t[B] on s i t són les variables de les tuples, A i B són els atributs de les variables i θ és l’operador de comparació aritmètica. Per exemple:

. Segons tot això es poden definir tot un conjunt d’operacions bàsiques que permeten accedir al contingut de les relacions contingudes en el model relacional. Seguint aquesta notació, a continuació es defineixen les operacions bàsiques d’un llenguatge d’accés de càlcul relacional basat en tuples a partir de vuit operacions que són: a) Projecció. Retorna el contingut dels atributs A de tota la relació R. b) Selecció. Retorna el contingut de totes les tuples d’R que compleixen la condició c) Unió. Retorna la unió de les tuples de la relació R i les tuples de la relació S. d) Diferència. Retorna les tuples que estan a la relació R i que no estan a la relació S. e) Intersecció. Retorna les tuples que estan a la relació R i que també estan a la relació S. f) Producte cartesià Retorna un conjunt de tuples formades per la concatenació dels atributs d’R i els atributs d’S com a resultat d’agafar per cada tupla d’R totes les tuples d’S. g) Join.

17

És el resultat d’aplicar l’operació de selecció sobre el producte cartesià de les relacions R i S. h) Divisió. Å són els atributs de la relació R menys els atributs de la relació S. s[B] són els atributs d’S que estan per cada tupla d’R. Per tant, les tuples resultants de l’operació de divisió són aquelles formades pels atributs Å que estan per tots els valors dels atributs de la relació S. Els llenguatges SQL i QUEL són llenguatges de càlcul relacional basat en tuples. El llenguatge SQL és el més popular i s’ha convertit en l’estàndard internacional que permet la definició, consulta i modificació de la informació continguda en una base de dades relacional. En [Groff1990] hi ha una descripció detallada del llenguatge SQL així com força exemples que faciliten la seva comprensió.

Càlcul Relacional basat en el Domini

En aquest tipus de càlcul relacional l’accés a la informació es fa a partir de la definició del domini de les variables de les relacions. O sigui, que s’ha d’especificar el domini dels atributs a què es vol accedir. Aquest tipus de llenguatge es va fer popular amb la utilització de llenguatges del tipus QBE (Query By Example), ja que aquests proporcionen una interfície visual que a partir d’un exemple es defineix la petició d’accés a la informació. A continuació n’hi ha un exemple. Si tenim les relacions: Productes(CodiProducte, Descripció, Preu) Models(CodiModel, CodiProducte, Unitats) Es pot donar una petició de consulta de forma: Productes

Models

En aquest exemple, s’especifica el domini de l’atribut Unitats de la relació Models (>1), que indica l’operació de selecció que es vol fer. Els atributs que contenen la clau P. són els atributs que es volen visualitzar, o sigui, que amb la P. s’especifiquen els atributs associats a l’operació de projecció. Per indicar els atributs que relacionen les relacions per tal de fer una operació de join es posa una constant, que en aquest cas és CP. Per tant, amb l’exemple anterior es mostra el CodiModel i Descripció del resultat de join de les relacions Productes i Models per l’atribut CodiProducte de tots aquelles tuples de Models amb un valor de l’atribut Unitats superior a la unitat. Si no s’indica el contrari totes les peticions QBE són de consulta. Per donar una petició de modificació cal posar a l’atribut que es desitja modificar la clau U. seguida del valor.

18

A continuació hi ha un exemple on es modifica el preu del producte amb CodiProducte 4486. Productes

[Tamer1999] p43-46

RESUM En aquesta sessió s’ha estudiat el càlcul relacional, que és el que s’utilitza per especificar les peticions que rep del sistema.

19

SESSIÓ 4 Nom: Àlgebra relacional Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la quarta sessió del capítol de bases de dades relacionals. A les darreres sessions d’aquest capítol s’ha vist el funcionament d’un sistema gestor relacional, la teoria de la normalització i el càlcul relacional.

OBJECTIUS En aquesta sessió s’estudia l’àlgebra relacional a partir de les seves operacions bàsiques.

CONTINGUTS En aquesta sessió s’introdueix l’àlgebra relacional a partir de la definició de les seves operacions bàsiques i es complementa amb exemples per tal de facilitar la seva comprensió.

Àlgebra relacional

L’àlgebra relacional s’utilitza pels sistemes gestors per donar les peticions que aquest rep, ja que d’aquesta forma es facilita la seva transformació i optimització. Tal com s’ha vist a l’apartat anterior, amb les expressions d’àlgebra relacional s’especifica la informació que es vol obtenir com a resultat de l’execució d’una petició i l’estratègia d’execució de la petició, ja que es tracta d’un llenguatge processual. L’àlgebra relacional està formada per un conjunt d’operadors que tracten la informació que hi ha en les relacions. Aquests operadors s’apliquen sobre una o dues relacions i sempre retornen el resultat en forma de relació. Encara que inicialment l’àlgebra relacional es va definir per treballar amb conjunts, com que en el model relacional una tupla pot aparèixer més d’un cop com a resultat de l’execució d’una petició, aquesta es defineix com un àlgebra que treballa amb conjunts múltiples amb una extensió per treballar amb conjunts. Els operadors bàsics de l’àlgebra relacional són selecció, projecció, unió, diferència i producte cartesià.

20

L’operació de selecció retorna les tuples de la relació R que compleixen la condició C sense cap tipus d’eliminació de duplicats. La condició C pot incloure: Operadors aritmètics o de cadenes de caràcters, termes , comparacions entre termes i connectors booleans (and, or o not),. A continuació hi ha alguns exemples amb l’operador de selecció sobre la relació Models.

L’operació de projecció retorna el contingut de la llista d’atributs L de la relació R. Igual que succeeix amb l’operació de selecció el resultat és un conjunt múltiple i per tant, pot haver-hi tuples repetides. A continuació hi ha uns exemples de projecció sobre la relació Models.

21

L’operació d’unió retorna un conjunt múltiple de tuples format per totes les tuples d’R i totes les tuples d’S. Perquè l’operació d’unió es pugui fer, l’esquema de la relació R ha de ser el mateix que el de la relació S i és l’esquema de la relació resultant. En aquest resultat hi poden haver tuples repetides. Cal anar amb compte amb l’operador d’unió i l’operador SQL UNION, ja que aquest darrer no retorna duplicats per defecte. Si es vol que l’operador UNION també retorni les tuples repetides cal especificar-ho amb UNION ALL. A continuació hi ha un exemple d’utilització de l’operació amb les relacions ProductesStock i ProductesNoStock.

22

L’operació de diferència entre dues relacions R i S retorna les tuples d’R que no estan en S. Si les relacions R i S contenen tuples repetides, llavors una tupla t està en el resultat el nombre de cops que està en R menys el nombre de cops que està en S, però mai menys de zero cops. Cal aclarir que a partir de la definició de l’operació de diferència es pot afirmar que

El producte cartesià de dues relacions R i S és una relació amb un esquema que conté els atributs d’R i els atributs d’S. Les tuples del producte cartesià són aquelles que s’obtenen agafant per cada tupla d’R totes les tuples d’S. Llavors podem afirmar que

Com es possible que en el resultat hi hagi atributs de les dues relacions amb el mateix nom, per tal d’identificar-los s’afegeix el nom de la relació seguit per un punt separador abans del nom de l’atribut.

23

A partir dels cinc operadors bàsics es poden definir els operadors d’intersecció i join.

L’operació d’intersecció entre dues relacions R i S retorna les tuples que estan en R i també estan en S. Si les relacions R i S contenen tuples repetides, llavors una tupla t està en el resultat el nombre mínim de cops que està en R i S. L’operació d’intersecció també s’obté de forma . A partir d’aquesta definició es pot afirmar que A continuació hi ha un exemple amb l’operació d’intersecció amb les relacions ProductesStock i ProductesNoStock.

24

L’operació de Join es construeix a partir del producte cartesià de dues relacions i una operació de selecció. Hi ha diferents operadors de Join que són: Theta-Join, Equi-Join, Natural-Join, SemiJoin i Anti-SemiJoin.

25

. L’Equi-Join és un cas especial del Theta-Join. En aquest Join la condició C que s’aplica a l’operació de selecció és un terme simple del tipus a=b, on a és un atribut de la relació R i b un atribut de la relació S. A continuació hi ha un exemple amb les relacions Clients i Factures.

26

. El Natural-Join és un cas especial de l’Equi-Join on a és el nom d’un atribut de la relació R i de la relació S. En aquest cas el resultat del Natural-Join és el d’un Equi-Join amb el terme simple R.a = S.a. Una altra diferència del Natural-Join respecte de l’Equi-Join, és que en el resultat del Natural-Join no hi ha atributs repetits. Això es pot observar a l’exemple següent on s’executa la petició El resultat de l’execució és:

El Natural-Join es pot donar com: on L és una llista de tots els atributs d’R i d’S, excepte l’atribut S.a. Hi ha un cas especial de Natural-Join que es dóna de forma on la condició

En aquest cas, la llista L d’atributs que hi ha en el resultat són tots els atributs d’R i d’S, excepte l’atribut S.b.

27

. L’operació d’outer-join és un cas especial de join. Aquest retorna les tuples del join les tuples d’R que no estan en el join I les tuples d’S que no estan en el join. En el cas de les tuples d’R I d’S que no estan en el join, els atributs de l’altra relació es donen amb valor null, ja que aquest és desconegut. A continuació hi ha un exemple amb les relacions Clients i Factures.

En aquest cas s’observa que el client amb codi 6539 també apareix en el resultat, però amb valors null dels atributs de la relació Factures, ja que no està en el join. El mateix pot succeir amb les tuples de Factures que no estiguessin en el join, però en aquest cas no té sentit, ja que això voldria dir que no es compleixen les condicions d’integritat referencial, ja que l’atribut CodiClient de la relació Factures és una clau forània respecte la clau primària CodiClient de la relació Clients. Hi ha dos casos especials de Outer-Join, que són el

. En el Left-Outer-Join es retornen les tuples del join i les tuples d’R que no estan en el join. En el

es retornen les tuples del join i les tuples d’S que no estan en el join.

. El semijoin de dues relacions R i S es defineix com les tuples de la relació R que estan en el join . Aquest es defineix com . Un conveni força utilitzat és definir com A el conjunt d’atributs de la relació R i B com els atributs de la relació S. A continuació hi ha un exemple de SemiJoin amb les relacions Clients i Factures.

28

. El Anti-SemiJoin de dues relacions R i S es defineix com les tuples de la relació R que no estan en el join . Aquest es defineix com

. A continuació hi ha un exemple de Anti-SemiJoin a partir de les relacions Clients i Factures.

29

De forma addicional, a continuació hi ha un conjunt d’operadors que estenen l’àlgebra relacional amb les operacions d’eliminació de duplicats, divisió, agrupació de tuples i ordenació de les tuples. h) Eliminació de duplicats. Un operador força útil és el que elimina les tuples repetides que hi ha en un conjunt múltiple i el converteix en un conjunt. Aquest és l’operador δ i dóna un conjunt format per una còpia de cada tupla que apareix un o més cops. Aquest operador equival a la utilització del DISTINCT o UNIQUE de SQL. A continuació hi ha un exemple amb la seva utilització amb les relacions ProductesStock I ProductesNoStock.

En aquest cas es pot observar com la tupla amb CodiProducte=9283 només apareix un cop.

30

Si s’executa l’operació s’obtenen les tuples de Models amb A-B atributs que per totes les tuples de CodiProductes estan per cada tupla de Models. O sigui, que si s’aplica a l’exemple, el resultat conté tots els valors de l’atribut CodiModel que fan servir tots els productes que hi ha a la taula CodiProductes. Si seguim l’execució de l’operació de divisió pas a pas seguint l’expressió donada en la seva definició es veu que:

31

I en executar l’operació de projecció sobre aquest resultat, la projecció sobre Models i la resta final s’obté el resultat final de l’operació de divisió que és: A partir del resultat de l’operació de divisió de l’exemple anterior s’observa que el resultat és un CodiModel que conté tots els productes que hi ha a la relació CodiProductes.

33

En aquest cas, el contingut de la relació ProductesStock s’ha ordenat pel contingut de l’atribut Preu. Això s’observa en el resultat anterior, ja que les tuples estan ordenades pels productes amb preu més petit fins els productes amb el preu més gran. Programes d’Àlgebra Relacional Fins ara s’ha vist que totes les operacions tenen com a paràmetre d’entrada una relació i retornen com a paràmetre de sortida un altra relació que és el resultat de l’execució de l’operació. Llavors, el resultat de l’execució d’una operació pot ser la relació d’entrada d’un altra operació. Aquest procés s’indica amb la utilització de parèntesis que indiquen l’ordre d’execució de les operacions. Un exemple és el programa que s’ha utilitzat per definir l’operació de divisió que és: D’aquesta forma es poden especificar amb programes d’àlgebra relacional peticions més complexes.

[Tamer1999] p35-p43

34

RESUM En aquesta sessió s’ha estudiat l’àlgebra relacional. Això s’ha fet a partir de la definició de les seves operacions bàsiques i s’ha completat amb exemples de la seva utilització.

35

SESSIÓ 5 Nom: Integritat i seguretat Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la cinquena sessió del capítol de bases de dades relacionals. A les darreres sessions s’ha vist el funcionament d’un sistema gestor relacional, la teoria de la normalització, el càlcul i l’àlgebra relacional.

OBJECTIUS En aquesta sessió s’estudien els mecanismes utilitzats pels sistemes gestors per tal de garantir la integritat de la informació com els conceptes bàsics de seguretat.

CONTINGUTS En aquesta sessió s’estudien els conceptes d’integritat i seguretat de la informació i els mecanismes que s’utilitzen per tal de garantir-la.

1.4. Integritat i seguretat En aquest tema s’estudien els mecanismes utilitzats pels sistemes gestors que faciliten el manteniment de la integritat de la base de dades.

Integritat

Un dels principals problemes dels sistemes gestors es que al haver-hi aplicacions que modifiquen la informació, aquesta pot deixar de ser correcta o consistent. En modificar la informació d’una base de dades, aquesta passa de l’estat anterior a la modificació a l’estat posterior de la modificació, on sempre s’ha de complir que en qualsevol estat que estigui la base de dades ha de ser un estat amb tota la informació correcta i consistent. Per garantir aquesta consistència hi ha un conjunt de mecanismes que ajuden a fer-ho anomenats regles d’integritat i que es poden classificar en dos tipus diferents; de comportament o estructurals. Les regles d’integritat de comportament depenen de la semàntica de l’aplicació, tal com s’ha vist a l’apartat de normalització. En canvi, les regles d’integritat estructurals

36

són inherents al model de dades. Segons Codd, les regles d’integritat mínimes del model relacional són la regla de l’entitat, la regla de la integritat referencial i les regles del negoci.

Regla de l’Entitat

Els atributs que pertanyen a la clau primària sempre han de tenir un valor únic i diferent de null.

Regla de la integritat referencial

A partir de la relació de dues relacions del model, es defineix el conjunt d’atributs d’una relació, que s’anomenen clau forània, que es corresponen a la clau primària de l’altra relació on el valor dels atributs de la clau forània sempre ha d’existir en la corresponent clau primària. A l’exemple següent, la relació Pais té com a clau primària l’atribut CodiPais, i la relació Clients té com a clau primària l’atribut CodiClient. En aquest cas, es veu que l’atribut CodiPais de la relació Clients és una clau forània que està relacionada amb la clau primària de la relació Pais, ja que per garantir la consistència del model, el valor de l’atribut CodiPais de la relació Clients sempre ha d’existir a la relació Pais. De la mateixa forma, l’atribut CodiContinent és una clau forània i l’atribut CodiIdioma també ho és.

També es pot donar el cas que alguns atributs de la clau primària d’una relació també siguin una clau forània. A continuació n’hi ha un exemple:

En aquest cas, la clau primària de la relació Models és (CodiModel, CodiProducte) i l’atribut CodiProducte de la relació Models és la clau forània que està relacionada amb la clau primària de la relació Productes que és l’atribut CodiProducte.

Regles del negoci

Són les regles que sempre s’han de complir en funció del tipus d’aplicació i segons les restriccions pròpies del negoci. Si s’analitzen les relacions Productes i Models, es poden intuir algunes regles de negoci com: El Preu de qualsevol producte sempre ha de ser positiu i diferent de zero. El nombre mínim d’unitats per (CodiModel, CodiProducte) també ha de ser positiu i diferent de zero.

37

Per tant, interessa dotar de mecanismes al sistema per tal que sempre es garanteixin totes les regles d’integritat estructurals. Les regles estructurals predefinides es defineixen mitjançant càlcul relacional CR o SQL. Per exemple: create table clients

( codi_client char(5) primary key constraint const_cli, codi_serie integer unique constraint const_num, nom_client char(40) not null, cf_pais char(2) references pais (codi_pais) )

En aquest exemple es defineix l'atribut codi_client com a clau primària de la relació clients. Es defineix l'atribut cf_pais com a clau forània que fa referència a l'atribut codi_pais de la relació pais. També es defineix l'atribut nom_client com obligatori, ja que aquest no pot adoptar el valor null. L'atribut codi_serie es defineix per tal que el seu valor sigui únic i per tant no accepti valors repetits d'aquest atribut entre les tuples de la relació clients. Les regles de negoci són les que sempre s'han de satisfer a partir del contingut de les relacions de la base de dades. Aquestes es defineixen mitjançant les sentències CHECK ON. La seva sintaxis és: CHECK ON nom_relacio [WHEN nom_operacio] ( def_condicio ) Llavors, quan s'executa l'operació indicada amb nom_operacio sobre la relació nom_relacio, sempre s'ha de verificar que la condició donada amb def_condicio es compleix. Si és així, s'executa l'operació i en cas contrari no s'executa i es retorna un missatge d'error. A continuació hi ha alguns exemples de definició de regles de negoci:

ckeck on factures (import > 0) En aquest cas, el contingut de l'atribut import de totes les tuples de la relació factures ha de ser positiu. Aquesta regla és valida quan es fa qualsevol operació sobre la relació. O bé si es vol assegurar que només es poden esborrar les tuples de la relació factures que el valor de l'atribut estat_factura valgui 'P', es defineix de forma:

check on factures when delete (estat_factura = 'P')

Seguretat

La seguretat de la informació és un aspecte molt important en els sistemes gestors, ja que sempre s'ha de garantir que les operacions que es fan sobre la informació sempre són correctes. Això és molt crític, ja que les bases de dades tenen molta informació que no pot ser consultada i/o modificada per tots els usuaris del sistema i molt menys per usuaris externs al sistema.

38

Per tal de garantir aquesta seguretat, s'han d'aplicar un conjunt de mecanismes que permetin gestionar-ho de forma totalment fiable. El que s'ha de resoldre és que només els usuaris autoritzats facin les operacions permeses sobre els objectes que tenen accés. O sigui, que per garantir la seguretat s'han de relacionar tres elements: Usuaris, Tipus d’operacions i Objectes. Llavors s’assignen privilegis als usuaris en funció dels tipus d'operacions que volen fer sobre les relacions que hi ha a la base de dades. Llavors es poden definir dos nivells de seguretat; la seguretat relativa a la base de dades i la seguretat relativa als objectes de la base de dades. Aquests dos nivells de seguretat són jeràrquics, ja que el sistema gestor sempre verifica primer els privilegis a nivell de la base de dades i si aquest és correcte valida el de les relacions.

Privilegis a nivell de base de dades

Els privilegis a nivell de base de dades es defineixen i/o treuen mitjançant les sentències:

GRANT permis_bd TO usuaris REVOKE permis_bd FROM usuaris

Mitjançant la sentència GRANT es donen privilegis, i amb REVOKE es treuen privilegis. Sempre cal especificar els usuaris a què es donen aquests privilegis. Aquests usuaris poden ser un sol usuari o un conjunt d'usuaris separats per coma o senzillament tots els usuaris (públic). Hi ha tres tipus diferents de permisos a nivell de base de dades, i que són els que s'han d'especificar a permis_bd. Aquests són:

CONNECT. Permet connectar-se a la base de dades, consultar i actualitzar el contingut de les relacions. RESOURCE. Té els mateixos privilegis que amb connect i també es poden crear índexs i relacions. DBA. Pot fer qualsevol tipus d'operació sobre la base de dades.

Cal destacar que l'usuari que crea la base de dades té tots els permisos sobre la base de dades i sobre les relacions d'aquesta. O sigui, que per defecte disposa de privilegis dba. A continuació hi ha alguns exemples.

GRANT connect TO públic. Tothom es pot connectar. GRANT resource TO maria, lluis, marc. Els usuaris maria, lluis i marc tenen privilegis de resource. GRANT dba TO sys_dba. L'usuari sys_dba té privilegis d'administració. REVOKE resource FROM lluis. Es treu el privilegi de resource a l'usuari lluis.

39

Privilegis de les relacions

Els privilegis relatius a les relacions són aquells que associen els privilegis als usuaris i els tipus d'operacions que poden fer sobre les relacions. Per tal d'assignar i treure aquests permisos es disposen de dues sentències SQL que són:

GRANT tipus_privilegi ON objecte TO usuaris REVOKE tipus_privilegi ON objecte FROM usuaris

En aquest cas, amb GRANT es dóna privilegis del tipus tipus_privilegi i amb REVOKE es treuen els privilegis especificats amb tipus_privilegi. Els possibles valors de tipus_privilegi són:

all. Es refereix a tots els privilegis. insert. Per afegir tuples a la relació. delete. Per esborrar tuples de la relació. select. Per consultar el contingut de la relació. update. Per modificar el contingut de les tuples de la relació. index. Per crear índex sobre la relació. alter. Per modificar l'estructura de la relació.

En el cas dels privilegis de select i update també es poden assignar o treure sobre un conjunt d'atributs. Per especificar els usuaris, cal indicar el nom de l'usuari o bé un conjut d'usuaris separats per coma o bé tots els usuaris utilitzant public. A continuació hi ha alguns exemples:

GRANT all on clients to public. Es donen tots els privilegis a tots els usuaris sobre la relació clients. GRANT select, insert on clients to marc. Es donen els privilegis de consulta i per afegir tuples a l'usuari marc sobre la relació clients. REVOKE all on clients from marc. Es treuen tots els privilegis de l'usuari marc sobre la relació clients. GRANT select (id_client, nom_client, import) on clients to jordi, joan. Es dóna el privilegi de consulta dels atributs id_client, nom_client, import de la relació clients als usuaris jordi i joan.

Cal destacar que quan un usuari crea una relació és el seu propietari i disposa de tots els privilegis sobre la relació. També tots els usuaris que tenen el privilegi de dba sobre la base de dades tenen tots els privilegis sobre les relacions que hi ha. La mateixa sintaxi utilitzada per donar o treure privilegis d'una relació és la que es fa servir sobre les vistes.

Rols per a la gestió de la seguretat

Els sistemes gestors faciliten la gestió de la seguretat mitjançant la utilització de rols, ja que tal com es veu a continuació es simplifica la seva utilització amb sistemes en què hi ha molts canvis, tant a nivell d'usuaris com de relacions.

40

Un rol es pot entendre com un conjunt de privilegis assignats a un grup d'usuaris que es pot anar actualitzant. Per crear o eliminar un rol cal utilitzar les sentències:

CREATE ROLE nom_rol. Per crear el rol amb nom nom_rol. DROP ROLE nom_rol. Per eliminar el rol amb nom_rol.

Un cop s'ha creat un rol, cal assignar i/o afegir-hi els usuaris que inclou. Per fer-ho s'utilitza la sentència:

GRANT nom_rol TO nom_usuaris. S'assignen al rol nom_rol els usuaris nom_usuaris.

I amb la sentència revoke es poden treure usuaris d'un rol de forma:

REVOKE nom_rol FROM nom\_usuaris. Es treuen els usuaris especificats a nom_usuaris del rol nom_rol.

Un cop s'ha definit un rol i ja s'han assignat els usuaris que inclou, cal definir els privilegis associats al rol. D'aquesta forma, els privilegis del rol són els privilegis de tots els usuaris que pertanyen al rol. Llavors, la sintaxi emprada per assignar i/o treure privilegis a un rol és la mateixa que la que es fa servir amb els privilegis per a les relacions, però en lloc d'especificar el nom d'una relació cal donar el nom d'un rol. A continuació hi ha dos exemples:

GRANT all on clients to grup_general. Es donen tots els privilegis a tots els usuaris que pertanyen al rol o grup d'usuaris grup_general. REVOKE select on factures from grup_secundari. Es treu el privilegi de consulta sobre la relació factures als usuaris que pertanyen al grup o rol grup_secundari.

D'aquesta forma es simplifica la gestió de la seguretat, ja que si s'ha d'afegir un nou usuari al sistema, només cal assignar-lo als grups o rols que permeten fer les operacions que s'han d'autoritzar per a aquest usuari. Tanmateix, quan s'afegeix una relació al sistema, només cal assignar els privilegis relatius a la relació als rols que interessi.

[Tamer1999] p161-p178

RESUM En aquesta sessió s’han estudiat els conceptes bàsics de la integritat i de la seguretat dels sistemes gestors de bases de dades.

41

SESSIÓ 6 Nom: Model bàsic d’un gestor relacional Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la darrera sessió del capítol de bases de dades relacionals. A les sessions anteriors s’ha definit el model relacional i s’han estudiat els conceptes relatius al càlcul relacional, la teoria de la normalització i l’àlgebra relacional, així com els mecanismes que utilitza el sistema per a mantenir la integritat i seguretat de la informació.

OBJECTIUS En aquesta sessió es dóna a conèixer el model arquitectònic bàsic que utilitza un sistema gestor relacional.

CONTINGUTS En aquesta sessió es descriu l’arquitectura bàsica d’un sistema gestor relacional a partir d’un model de capes.

1.5. Model bàsic d’un gestor relacional En aquest tema es presenta l’arquitectura bàsica d’un sistema gestor relacional. Un sistema gestor de bases de dades relacional és el programari que suporta el model relacional i un llenguatge basat en càlcul relacional. Aquest programari rep peticions dels usuaris o clients i s’encarrega de la seva execució per tal de retornar-li el resultat. A continuació es presenta el model que utilitza aquest sistema per fer tot el procés. Està format per sis capes que són: Interfície, Control, Compilació, Execució, Accés i Consistència. La capa d’interfície s’encarrega d’extraure les sentències d’accés a la informació de les aplicacions i de convertir les referències de vistes a relacions a partir de la informació de l’estructura de la base de dades que hi ha en el diccionari de dades. La sortida de la capa d’interfície està en càlcul relacional.

42

Model bàsic d’un sistema gestor relacional

La capa de control s’encarrega d’analitzar semànticament la petició i de validar els privilegis relatius a les dades, operacions i usuaris relacionats amb la petició. La capa de compilació converteix la petició que rep en càlcul relacional a àlgebra relacional a partir de la seva descomposició i optimització. La capa d’execució rep el pla d’execució amb àlgebra relacional de la capa de compilació i s’encarrega de la seva coordinació i execució. Aquesta capa rep el resultat de l’execució de cada operació i integra els diferents resultats per tal de retornar-los a les aplicacions mitjançant la capa d’interfície. La capa d’accés s’encarrega de la gestió de les operacions d’accés a les dades. També gestiona la memòria intermèdia (buffers) del sistema i n’optimitza la utilització amb la qual cosa s’aconsegueix un rendiment millor del sistema gestor.

43

La capa de consistència s’encarrega de la gestió de les transaccions i de les operacions amb operacions de modificació. Per fer-ho utilitza algorismes de control de concurrència, protocols de caiguda i recuperació basats en la informació continguda en les estructures de log. És la capa que s’encarrega de l’execució de les operacions a la base de dades.

[Tamer1999] p46-p51

RESUM En aquesta sessió s’ha vist l’arquitectura bàsica que modela un sistema gestor relacional.

45

SESSIÓ 7 Nom: Bases de dades distribuïdes Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la primera sessió del capítol de bases de dades distribuïdes.

OBJECTIUS En aquesta sessió es presenten els conceptes bàsics d’un sistema gestor de bases de dades distribuït i es presenta la seva arquitectura bàsica.

CONTINGUTS En aquesta sessió es tracten els primers apartats del capítol de bases de dades distribuïdes. Es comença amb la definició d’una base de dades distribuïda i la d’un sistema gestor i es presenta la seva arquitectura bàsica.

2. Bases de dades distribuïdes

2.1. Introducció En aquest tema es defineix una base de dades distribuïda i s’introdueix la seva arquitectura bàsica.

Definició d’una base de dades distribuïda

A continuació es defineixen i relacionen les Bases de Dades Distribuïdes BDD i els SGBDD. Una Base de Dades Distribuïda BDD és un conjunt de bases de dades locals lògicament integrades i que estan distribuïdes a través d'una xarxa d'ordinadors. Un SGBDD és el programari que permet la gestió de les bases de dades locals d'una BDD de forma transparent als usuaris del sistema. Perquè això sigui possible, cal que existeixi un diccionari de dades o metadata DD amb l'estructura de tot el conjunt i un mètode d'accés homogeni a la informació

46

continguda en la BDD, ja que així els nodes coneixen la ubicació de la informació i poden decidir els nodes on s'han de fer les operacions de consulta i modificació. Els SGBDD estan construïts a partir de nodes o processadors que no comparteixen res, excepte la xarxa, i que es passen les dades mitjançant missatges. Segons aquestes característiques, quan un usuari o procés accedeix a la informació d'una BDD no ha de notar cap diferència amb un accés típic a una base de dades local. Aquesta característica dels SGBDD s'anomena transparència de xarxa o distribució. Segons aquest model, un node pot executar dos tipus diferents d'aplicacions, que són aplicacions locals i aplicacions globals. Les aplicacions locals són aquelles que només s'executen en un node i només requereixen de les dades locals que hi ha al node. Les aplicacions globals són aquelles que per la seva execució requereixen de dades de diferents nodes. Ara bé, cal remarcar que en un SGBDD no hi pot haver un node centralitzat coordinador, ja que qualsevol node ha de poder coordinar l'execució de les peticions globals. Per tant, una BDD també es pot definir com: Una BDD és el conjunt de dades distribuïdes per diferents nodes d'una xarxa, on cada node té autonomia de procés per executar aplicacions locals i també pot participar en l'execució d'aplicacions globals. Per a l'execució de les aplicacions globals es requereix l'accés a les dades dels diferents nodes utilitzant un subsistema de comunicació. Aleshores, un SGBDD està format pel programari que s'encarrega de gestionar la BDD de forma transparent per les aplicacions. A la figura següent hi ha l'arquitectura bàsica d'un SGBDD.

47

Aquest sistema, està format per tres nodes que només comparteixen la xarxa. Cada node disposa d'una BD pròpia o local, i una rèplica del Diccionari de Dades DD. Es pot observar que es tracta d'un sistema totalment aïllat, ja que els diferents nodes només comparteixen la xarxa. Les unitats de memòria MU també són locals i el mateix SGBDD s'encarrega de mantenir de forma transparent a les aplicacions la consistència de totes les rèpliques que hi ha en els nodes del DD.

2.2. Definició i arquitectura En aquest tema es presenta el model bàsic d’un sistema gestor distribuït.

Arquitectura dels gestors distribuïts

A continuació es presenta l’arquitectura bàsica d’un sistema gestor distribuït a partir dels components que el formen i els diferents tipus d’operacions que resolen aquests components. En aquest model s’observa que l’accés a la informació local es fa amb el DB o Gestor Local. És aquest mòdul el que s’encarrega d’accedir a la informació que conté la base de dades local. Aquest gestor local és un sistema gestor centralitzat. El sistema gestor distribuït rep les peticions pels terminals locals. Aquestes peticions les rep el mòdul Data Communications, que s’encarrega de rebre la petició, i tornar el resultat de la seva execució al terminal que ho ha sol·licitat. Aquest procés és totalment transparent per a les aplicacions que envien les peticions i reben les respostes del sistema. Un cop el node rep una petició, consulta al Diccionari de Dades DD la ubicació de la informació necessària per executar la petició. A partir d’aquesta informació el Gestor del Sistema Distribuït DDB s’encarrega de generar un pla d’execució i de coordinar-ne l’execució. És llavors el DDB el que s’encarrega d’enviar les peticions necessàries a altres nodes per tal de poder executar l’estratègia. Es pot observar que d’aquesta forma es garanteix la transparència de xarxa o distribució, ja que és el DDB el que s’encarrega de generar l’estratègia d’execució de forma totalment autònoma.

48

Ara bé, el principal problema d’aquesta estructura és que es poden donar situacions en les que hi hagi molt tràfic de xarxa, cosa que penalitza força el rendiment del sistema. De totes formes, tal com hem vist a l’apartat anterior, si el disseny de la base de dades és correcte, el rendiment del sistema no ha d’estar penalitzat. A la figura següent es pot veure com una aplicació envia una petició a un sol servidor, que és el servidor coordinador de la seva execució.

Aquest servidor coordinador que rep la petició, és el que s’encarrega de coordinar-ne l’execució i retornar el resultat a l’aplicació. Cal que aquest consulti al diccionari de dades la ubicació de les dades involucrades en la petició per tal de conèixer-ne la ubicació.

49

A l’exemple anterior es pot observar que la petició q1 que envia l’aplicació s’ha descompost en tres subpeticions (q11, q12 i q13). La petició q11 es pot executar de forma local al node coordinador, però les altres dues peticions (q12 i q13) s’envien als nodes k i l respectivament. Un cop el node coordinador té tots els resultats de l’execució de les subpeticions q11, q12 i q13 integra els resultats i ho retorna a l’aplicació. Ara bé, es poden donar situacions en què els resultats parcials de l’execució d’alguna de les subpeticions s’hagin d’enviar a un altre node per tal que executi un altra subpetició i així fins que s’obtingui el resultat final per tal d’enviar-lo a l’aplicació. Aquest model que hem vist és un dels més utilitzats en els sistemes gestors distribuïts, i és el que nosaltres pressuposarem que disposen aquests tipus de sistemes per al seu estudi en els propers capítols.

[Tamer1999] p1-p8

RESUM En aquesta sessió s’han introduït els conceptes bàsics relatius als sistemes gestors distribuïts. S’ha començat amb la definició d’una base de dades distribuïda i la d’un sistema gestor. A continuació s’ha vist la seva arquitectura bàsica.

51

SESSIÓ 8 Nom: Serveis i problemes dels gestors distribuïts Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la segona sessió del capítol de bases de dades distribuïdes. A la primera sessió s’ha definit una base de dades distribuïda i s’ha vist la seva arquitectura bàsica.

OBJECTIUS En aquesta sessió s’estudien els serveis que ha de donar i els principals problemes que tenen els sistemes gestors distribuïts.

CONTINGUTS En aquesta sessió es tracten els serveis que han de donar els sistemes gestors distribuïts i s’analitzen les seves principals problemàtiques.

2.3. Serveis i problemes dels gestors distribuïts

En aquest tema es descriuen els principals serveis que ofereixen els gestors distribuïts.

Serveis dels gestors distribuïts

Per aconseguir un disseny acurat d'un SGBDD cal que aquest ofereixi un conjunt de serveis. Podríem destacar com a serveis bàsics els següents: 1.- Gestió transparent. La transparència es refereix a la separació entre l'alt nivell d'utilització d'un sistema i els detalls de baix nivell de la seva implementació. Per tant, és important que els sistemes disposin de nivells de transparència grans, atès que això en facilita la utilització. Els principals nivells de transparència que ha de donar un SGBDD són: Dades. La transparència de dades és la immunitat de les aplicacions d'usuari enfront els canvis en la definició i organització de les dades.

52

Xarxa. La transparència de xarxa permet que l'accés de les aplicacions a les dades es faci sense que aquestes coneguin cap detall de la xarxa, i han de treballar de forma independent de la seva construcció. Des de la perspectiva dels SGBDD, la transparència de xarxa requereix que les aplicacions no han d'especificar la ubicació de la informació. Aquesta transparència també es refereix a les comandes emprades per accedir a la informació així com respecte al nom dels objectes. Replicació. La transparència de replicació garanteix l'accés a la informació per part de les aplicacions, tant si aquesta està replicada com si no ho està, utilitzant els mateixos mètodes d'accés. En aquest cas, el sistema s'encarrega de gestionar la consistència de les rèpliques en modificar les aplicacions el seu contingut, atès que les aplicacions no distingeixen si una dada està o no replicada a l'hora d'accedir amb ella. Fragmentació. La transparència de fragmentació garanteix l'accés a la informació per part de les aplicacions, tant si aquesta està fragmentada com si no ho està, utilitzant els mateixos mètodes d'accés. 2.- Fiabilitat. En disposar d'informació replicada, si hi ha errors en algun dels nodes del sistema o bé per caigudes de la xarxa, el sistema no té per què deixar de funcionar, encara que no ofereixi totes les seves prestacions. Això és possible en el cas d'un SGBDD, ja que si es dissenya correctament la distribució i replicació de la informació, el sistema seguirà funcionant, atès que accedirà de forma transparent a l’usuari cap a altres parts de la BDD. 3.- Increment de rendiment. En el cas dels SGBDD, hi ha un increment important del rendiment del sistema. Aquest increment de rendiment es dóna principalment per dos motius que són: Localitat de la informació i Paral·lelisme Intraquery. La localitat de la informació és la possibilitat de guardar la informació el més pròximament possible als nodes que més la necessiten. Això provoca que les Unitats Centrals de Procés CPUs, en disposar només de part de la BDD, no tenen tanta contenció com en el cas dels SGBDC. És important, doncs, dissenyar la BDD perquè aquesta millori el seu rendiment a partir del partició i distribució de la informació. El paral·lelisme intraquery és la capacitat dels SGBDD de dividir una petició en diverses peticions, de tal forma que es puguin executar en paral·lel en diferents nodes del sistema. Ara bé, com que hi ha força peticions amb modificació de la informació, cal utilitzar protocols de Control de Concurrència CC per tal de garantir la consistència de la informació, aspecte que empitjora el rendiment del sistema.

Problemes dels gestors distribuïts

En aquest tema es presenten els principals problemes que hi ha en el disseny dels sistemes gestors distribuïts.

53

Per tal que els SGBDD disposin dels serveis detallats a l’apartat anterior, cal tenir en compte que apareixen un conjunt de problemes que en dificulten el disseny. Les principals problemàtiques que cal contemplar són:

Disseny de la Base de Dades

En els SGBDD sempre cal definir la millor distribució de les dades i programes en els nodes del sistema. En el cas dels programes sempre cal tenir present la seva localització respecte les dades que aquests gestionen. Evidentment que cal intentar que programes i dades emprades per aquests estiguin als mateixos nodes. Per tant, un dels principals problemes de la utilització dels SGBDD rau en el disseny de la distribució de les dades, ja que cal mantenir sempre la transparència de distribució. El punt de partida per aquest procés és el GCS de la BDD i el seu objectiu inicial és el d'obtenir tots els LCS per cada un dels nodes del sistema. El procés es divideix en dues fases: fragmentació i ubicació, que cal separar per tal de simplificar el seu disseny. Ara bé, cal tenir en compte que les relacions no es poden considerar com a unitat factible de distribució, ja que: La informació a la qual accedeixen els usuaris són subconjunts de les relacions i cal maximitzar el seu accés local. Els fragments proporcionen un nivell de granularitat més petit quan hi ha replicació, ja que el sistema decideix si cal replicar cada fragment en lloc de les relacions completes. Llavors, hi ha tres tipus diferents de fragmentació: Horitzontal, Vertical i Híbrida. Fragmentació horitzontal. Es parteixen les relacions a partir d'operacions de selecció sobre els atributs de la relació. Les operacions de selecció es defineixen a partir dels predicats simples que fan servir les peticions. Per decidir la viabilitat de la fragmentació, també es fa servir la freqüència d'utilització de totes les peticions per part dels usuaris. En [Tamer1999]p115 es presenta un mètode que a partir dels predicats simples emprats en les peticions, obté un conjunt de predicats minterm que determinen la definició de la fragmentació horitzontal. Ara bé, només cal contemplar una part de les transaccions més actives, ja que es pot aproximar que el 20% de les transaccions més actives són les que fan el 80% dels accessos a les dades. En [Tamer1999]p117 s'introdueix el concepte de fragmentació horitzontal derivada, en la qual es fragmenta la relació a partir d'una selecció sobre els atributs d'un altra relació. Fragmentació Vertical. Es parteix una relació agrupant atributs conjuntament amb la clau primària de la relació. El procés de fragmentació vertical parteix de la freqüència d'utilització dels atributs i intenta trobar conjunts d'atributs que tendeixen a fer-se servir de forma conjunta.

54

Ara bé, hi ha dues formes d'enfocar el procés de fragmentació vertical quan cal obtenir més de dos fragments: Anar agrupant atributs fins obtenir un fragment o bé anar tallant les relacions en fragments fins aconseguir un fragment òptim. Fragmentació Híbrida. Hi ha cops que no totes les aplicacions segueixen un patró d'accés horitzontal o vertical, i cal emprar fragmentació híbrida a partir de la definició alternativa de fragmentació horitzontal i vertical. El procés d’ubicació serveix per decidir en quin node del sistema es posa cada fragment i si cal replicar els diferents fragments. Aquest procés de replicació defineix si cada fragment està ubicat en un sol node o a més nodes. Es pot parlar de replicació total, si un fragment està en tots els nodes, i de replicació parcial si no està replicat a tots els nodes del sistema. Per tant, el procés d'ubicació es tracta d'un problema d'optimització, ja que cal definir una funció de cost global, i l'objectiu és el de determinar una estratègia d'ubicació dels fragments tal que minimitzi la funció de cost. Un problema que apareix en el procés de distribució és el del desequilibri en els volums d'informació entre els diferents nodes del sistema, cosa que pot portar a un desequilibri de procés entre els diferents nodes i per tant a un empitjorament del seu rendiment global.

Control semàntic de la informació

Un problema important dels SGBDD és el control semàntic de la informació. Una BDD sempre evoluciona d'un estat consistent a un altre estat consistent. Per garantir-ho es requereix d'un conjunt de mecanismes tal com el control de concurrència, fiabilitat i control d'integritat semàntica. En els apartats següents s'exposen els mecanismes de concurrència i fiabilitat. El control d'integritat semàntica CIS és el procés que s'encarrega de garantir que la BDD sempre estigui en un estat consistent. Això s'aconsegueix rebutjant els processos de modificació de la informació que porten a la BDD a un estat inconsistent, o bé que compensen els efectes de la inconsistència. Per garantir-ho cal que el sistema compleixi un conjunt de restriccions anomenades restriccions d'integritat semàntica. A continuació s'exposen els dos components bàsics d'aquestes regles que són: Llenguatge per la definició de les restriccions i els mecanismes de reforç de les restriccions. Llenguatge de definició de restriccions. La regles es poden definir de tres formes diferents, que són: Predefinides, Precompilades i Generals. Predefinides. Són les que es defineixen directament a partir del model de dades. Aquestes permeten definir les restriccions més habituals tals com els atributs not null, les claus úniques, claus primàries PK, claus forànies FK i dependències funcionals. Precompilades. Són les que donen les condicions que cal satisfer per a totes les tuples d'una relació per a un tipus d'operació donat. Aquestes s’acostumen a definir a partir de sentències del tipus CHECK ON.

55

Generals. Són expressions donades en Càlcul Relacional CR que sempre s'han de complir. Ara bé, el principal problema associat a la validació del conjunt de regles rau en el seu cost, que pot arribar a ser prohibitiu, ja que cal accedir a grans volums d'informació. Mecanismes de reforç de les restriccions. A partir de la definició de les regles cal aplicar tècniques que permetin detectar les modificacions que no les compleixen. La principal dificultat és trobar un mètode que permeti de forma òptima detectar aquests problemes. Es poden distingir mètodes basats en la detecció i mètodes basats en la prevenció. Detecció. En aquest cas s'executa la petició de modificació, i seguidament es valida que totes les restriccions són certes. Si hi ha alguna restricció que no es compleix, cal desfer els canvis de la petició de modificació i deixar la BDD en l'estat consistent anterior a l'execució de l’operació de modificació. Prevenció. Aquest mètode està basat en la prevenció de les inconsistències. Llavors, una modificació només s'executa si les verificacions de les regles són consistents. Les tècniques preventives són les mes efectives ja que mai cal desfer operacions fetes. Hi ha altres alternatives en què s'intenta millorar el rendiment del sistema mitjançant l'obtenció de regles compilades i el tractament de relacions diferencials.

Processament de peticions distribuïdes

El processament de peticions s'encarrega del disseny d'algorismes que a partir de les peticions dels usuaris expressades amb càlcul relacional CR les analitzi i generi una estratègia òptima d'execució. El principal problema rau que cal construir un model de cost del sistema, i a partir de totes les possibles solucions, intentar veure quina és la millor. És doncs un problema NP-hard, i cal emprar heurístiques per tal de minimitzar l'espai de cerca i trobar una estratègia més o menys bona. Un problema addicional d'aquesta fase és que cal tenir en compte molts factors que poden variar amb el temps, cosa que dificulta molt conèixer a priori el seu valor. Per tant, l'optimitzador parteix fent una cerca sobre un conjunt de plans candidats, anomenat espai de cerca i aplica la funció de cost escollida a les diferents estratègies. Aquella que minimitza el cost global d'execució és la que l'optimitzador dóna com a bona. Els mòduls en què es divideix un optimitzador són: Descomposició, Localització, Optimització global i Optimització local. Descomposició. Tradueix la petició en un arbre d'operadors en àlgebra relacional, més controlable a baix nivell. Necessita informació del diccionari de dades per conèixer la situació i estat de cada una de les relacions. Localització. Un cop coneguda l'estructura de la petició, cal conèixer la ubicació de les dades, les quals poden estar fragmentades i/o replicades. És una etapa important de l'optimitzador, ja que permet restringir l'espai de cerca. Aquesta etapa s'encarrega de cercar l'accés òptim a les dades requerides de forma que es redueixi la funció de cost.

56

Optimització Global. Tracta d'optimitzar globalment l'arbre d'operadors. Per tant, es basa en l'ordenació de les operacions més que en la implementació de cada una d'elles. Es divideix en dues parts importants: l'ordenació de les operacions de forma que es redueixi la cardinalitat i els costos, i l'ordenació de les operacions d'unió (una tècnica important és l'ús dels semijoins sempre que sigui possible). Optimització Local. Tracta d'implementar de forma òptima les operacions que tenen a veure amb un node en concret. En aquesta etapa se suposa que ja s'han organitzat i repartit les tasques a cada un dels nodes i, a partir d'aquí, l'execució local es fa de forma independent a la resta d'operacions de la mateixa operació. Al final se suposa que hi ha un node encarregat de recuperar i gestionar els resultats de cada operació local, però aquest aspecte ja no es controla des del punt de vista de l'optimització. Com es pot veure, l'estratègia emprada d'optimització es basa a intentar reduir l'espai de cerca dividint la tasca d'optimització en etapes. Un cop s'han eliminat les operacions que no aporten res a l'estratègia final, s'intenta reordenar l'arbre d'operadors per tal de minimitzar la funció de cost. Aquest model de cost contempla el cost de procés CPU, el cost d'entrada/sortida IO, el cost de xarxa COM i el cost de memorització STO. Ara bé, per tal d'anar calculant aquests costos, cal fer estimacions de grandària de les relacions intermèdies que s'obtenen. Per aconseguir-ho, s'utilitzen estadístiques associades als atributs de les relacions així com de la mateixa base de dades. Aquests són: cardinalitats dels atributs, valors mínims, valors màxims, cardinalitats de les relacions i principalment els factors de selectivitat dels diferents operadors de l'AR. De totes formes, el principal problema és que els optimitzadors no s'adapten a les variacions de càrrega del sistema i, per tant, no arriben a una solució òptima, motivat principalment per aquest comportament estàtic, encara que hi ha propostes que intenten resoldre i equilibrar la càrrega del sistema.

Gestió de transaccions distribuïdes

A causa del tipus d'operacions que han d'executar els SGBDD, és important que aquests suportin transaccions. Ara bé, per tal que aquestes es puguin executar, cal que, associat a cada transacció, hi hagi un node coordinador. Aquest node serà el que coordinarà l'execució de la transacció, dirigint els diferents nodes que hi intervenen. Aquesta gestió es complica a causa de la naturalesa distribuïda del sistema. Llavors, les transaccions sempre han de contemplar les propietats ACID, tal com s'exposa a continuació. Aquestes propietats són les de Atomicitat, Consistència, Aïllament i Durabilitat. Atomicitat. Un conjunt d'operacions són atòmiques si s'executen totes o cap d'elles. Per tant, la propietat d'atomicitat indica que les operacions que formen una transacció s'han de tractar com una única operació. Això requereix que si l'execució d'una transacció s'atura per qualsevol motiu, el SGBD s'encarrega de decidir què fer amb la transacció quan pugui seguir funcionant. En aquest cas hi ha dues alternatives: Acabar la transacció amb les operacions que falten o bé desfer les modificacions ja fetes durant l'execució de la transacció.

57

Hi ha dos tipus d'errors que poden aturar l'execució d'una transacció. Aquests són: De la mateixa transacció. Estan provocats per errors d'entrada de dades, interbloqueig (deadlock) o esperes per a garantir la consistència de la informació. La tècnica per a mantenir l'atomicitat de la transacció durant aquest tipus d'error és la recuperació de transaccions o Transaction Recovery TR. Del sistema. Són els errors que es presenten per la caiguda del sistema, CPU o problemes en les comunicacions. Per mantenir l'atomicitat durant aquest tipus d'error s'utilitzen tècniques de recuperació de caigudes o Crash Recovery CR. Consistència. La consistència és la propietat que s'encarrega de portar la base de dades d'un estat consistent a un altre estat consistent. La consistència d'una base de dades pot tenir diferents nivells, que van del nivell 0 (menor consistència) al nivell 3 (màxima consistència). Mitjançant aquests nivells, es defineix el grau de consistència que dóna el sistema. Ara bé, a mesura que el sistema dóna una consistència més gran, aquest ha d’aplicar cada cop més tècniques que la garanteixin, amb la qual cosa el rendiment es veu penalitzat. Cal, doncs, arribar a un compromís entre el nivell de consistència desitjat i el rendiment del sistema. Aïllament. L'aïllament és la propietat de les transaccions que requereix que cada transacció sempre vegi la base de dades en un estat consistent. Per aconseguir-ho, una transacció no pot actualitzar els seus canvis fins que arribi al seu final o commit. D'aquesta forma, en assegurar l'aïllament s'aconsegueix que la informació llegida per qualsevol transició és correcta. Tanmateix amb l'aïllament s'eviten els avortaments en cascada, ja que si una transacció deixa veure a la resta de transaccions el resultat de les seves modificacions abans del seu commit, si aquesta acaba amb un avortament, la resta de transaccions també han de desfer els canvis fets a partir d'aquesta informació llegida (Dirty Data). Durabilitat. La durabilitat és la propietat de les transaccions que assegura que un cop una transacció ha executat satisfactòriament una operació de commit, els seus resultats són permanents i no es perdran de la base de dades. A partir de les propietats ACID que han de garantir els sistemes transaccionals es garanteix que la informació memoritzada per el SGBDD sigui sempre consistent. Les solucions habituals garanteixen aquestes propietats, però fan que els sistemes amb moltes transaccions actives i amb probabilitat de conflictes gran, el seu rendiment sigui dolent. Les línies de recerca actuals dintre de la gestió de transaccions intenten trobar alternatives per a aquestes situacions que tinguin un rendiment millor. Aquesta problemàtica de la gestió de les transaccions està força relacionada amb el control de concurrència, tal com es veu en l'apartat següent. Per tant, la gestió de transaccions dintre dels SGBDD és una línia de recerca força oberta, ja que s'està intentant millorar el rendiment dels sistemes gestors que permeten l'execució de transaccions en entorns amb nivells grans de concurrència.

58

Control de concurrència

El control de concurrència CC s'encarrega de sincronitzar els accessos a la BDD. Aquest control és molt més complicat en els SGBDD que en el cas dels SGBDC, atès que a part de gestionar la integritat d'una sola BD, cal que gestioni la integritat de les rèpliques de la BD. Per aconseguir-ho s'utilitzen els algorismes de control de concurrència CCA. Tal com s'ha vist a l'apartat anterior de gestió de transaccions distribuïdes, el control de concurrència és un aspecte força crític a contemplar en els SGBDD. A continuació es detallen els seus principals objectius i es presenten les idees bàsiques per a la seva solució. El control de concurrència apareix quan hi ha una dada o informació sobre la qual diferents processos hi volen fer operacions de lectura i/o escriptura. Si tots els processos només llegeixen la dada, el funcionament sempre serà correcte. Ara bé, els problemes apareixen quan hi ha més d'un procés que vol modificar la dada. En aquest cas, es poden presentar inconsistències en el valor de la dada. Per exemple, si dos processos llegeixen alhora el valor de la dada i després la volen modificar de forma independent, es pot assegurar que les modificacions d'un procés no seran efectives, ja que l'altre procés actualitzarà els seus canvis. Per tant, cal un mecanisme que asseguri que això no passi, essent aquest el control de concurrència. Aquest problema es complica amb l'existència de transaccions, i sobretot si es tracta d'un sistema distribuït i amb existència de replicació en les seves dades. Per a la gestió de les rèpliques, hi ha força propostes d'algorismes per al manteniment de la seva consistència. Una solució inicial per tal d'assegurar l'exclusió mútua d'aquestes operacions de lectura/escriptura, és la utilització d'adquisicions de les dades. El principal problema d'aquesta solució rau en el fet que les adquisicions de les dades acostumen a incrementar la contenció del sistema, sobretot quan hi ha transaccions llargues i en sistemes amb un nivell de concurrència gran. Llavors els CCA intenten incrementar el nivell de concurrència, mantenint sempre la consistència de la informació. Hi ha tres tipus diferents d'algorismes de CC: basats en adquisicions, basats en l'ordenació temporal de les operacions i els optimistes. Els algorismes basats en adquisicions i ordenació temporal de les operacions acostumen a ser pessimistes i els optimistes utilitzen de forma mixta adquisicions i marques temporals TS en la seva implementació. Els algorismes pessimistes són els algorismes que sempre assumeixen que hi pot haver un conflicte, i validen la compatibilitat de les operacions per a cada petició d'operació. Els algorismes optimistes són els algorismes que no validen la compatibilitat de les operacions abans d'executar-les, però al final de la transacció sí que validen totes les operacions. El CCA més utilitzat en els sistemes comercials és el Strict Two Phase Locking S2PL. Aquest és un algorisme pessimista basat en adquisicions. Un problema d’aquest algorisme és que apareixen esperes de transaccions, amb la qual cosa poden haver-hi situacions d’interbloqueig.

59

Per aquest motiu, el sistema ha de detectar i resoldre els interbloquejos, cosa que provoca una càrrega addicional del sistema que provoca una disminució del seu rendiment. Per tal d'evitar aquesta sobrecàrrega del sistema, hi ha variants de l'algorisme S2PL que eviten l'existència dels interbloquejos. És el cas dels algorismes Wound Wait Two Phase Locking WW2PL i Distributed Time Ordering DTO, que aporten tècniques preventives dels interbloquejos. Aquests algorismes fan servir Marques Temporals TS associades a les operacions de les transaccions, fent que les esperes del sistema sempre siguin acícliques. Tot això va força bé per a sistemes amb un nivell de contenció gran, però en sistemes amb menys probabilitat de conflictes els CCA optimistes donen millors rendiments. Un d'aquests algorismes és el Optimistic Distributed Time Ordering ODTO. En aquest algorisme l'execució de qualsevol operació segueix quatre fases: lectura, procés, validació i actualització. Les fases de lectura, procés i validació es fan sense modificar la BD. En la fase de validació és verifica que totes les operacions mantenen la consistència del sistema. Llavors, si hi ha consistència, es modifica la BD, i en cas contrari s'avorta la transacció. Tal com hem vist, el control de concurrència és un dels aspectes més importants que afecten el rendiment dels SGBDD. Per aquest motiu és una línia de recerca força activa en l'actualitat en la que es pretén millorar els algorismes actuals o cercar nous algorismes que permetin un increment del rendiment del SGBDD.

Gestió d’interbloquejos distribuïts

A causa del control de concurrència o accés concurrent a les informacions per part de diferents processos, poden aparèixer esperes entre les diferents operacions. Tal com succeeix en els SGBDC, aquestes esperes poden portar al sistema a una situació d’interbloqueig. Ara bé, en el cas dels SGBDD aquest problema és més complex, atès que l’interbloqueig pot ser distribuït, per la qual cosa caldrà aplicar-hi tècniques tant preventives com resolutives. El principal problema d'un interbloqueig és que es tracta d'una situació permanent, ja que si existeix en el sistema, no desapareixerà si no es pren cap iniciativa específica. Una eina habitual per a detectar els interbloquejos és el Wait For Graph WFG, el qual representa les esperes entre les diferents transaccions. En aquest cas, si el WFG conté un cicle d'esperes, indica que hi ha un interbloqueig i cal avortar una transacció per tal que el sistema segueixi avançant. Un problema addicional és el de determinar quina de les transaccions dintre del cicle del WFG cal avortar, ja que depenent de la dinàmica del sistema aquest factor pot ser crític per al seu rendiment. Una solució habitual és la d'avortar la transacció més jove o la transacció que menys feina ha fet, tal com ja fan altres tipus de sistemes que també es troben en aquesta situació. En el cas dels SGBDD els interbloquejos poden ser tant locals a un node com distribuïts. Per tant, cada node ha de guardar el seu propi WFG o Local Wait For Graph LWFG, però cal pensar en algun mecanisme per a detectar els interbloquejos distribuïts. Una solució típica per fer-ho és guardar un GWFG de tot el sistema, que no és res més que la unió de tots els LWFG dels nodes del sistema.

60

En l'actualitat la gestió dels interbloquejos distribuïts és una línia de recerca oberta, ja que s'intenten trobar algorismes de detecció i/o resolució d’interbloquejos que tinguin un baix impacte en el rendiment del sistema.

Fiabilitat

Tal com s'ha esmentat en l'apartat anterior, un dels avantatges de la utilització dels SGBDD és que s'incrementa la fiabilitat i disponibilitat del sistema. Per aconseguir-ho cal definir mecanismes que assegurin la consistència de la BDD i que detectin errors del sistema i s'apliquin protocols d'acabament TP i protocols de recuperació RP. Un SGBDD és fiable si és capaç d'executar les peticions dels usuaris sense violar la consistència de la base de dades quan hi ha fallides en algun dels components del sistema. D'una manera més formal es pot definir la fiabilitat com la probabilitat que el sistema gestor de base de dades no tingui cap error en un interval de temps donat. Per tant, en el cas que en un SGBDD hi hagi un problema en la xarxa o en algun dels nodes, el sistema ha de seguir funcionant correctament i mantenint les propietats ACID de les transaccions. Per aconseguir-ho es fan servir protocols de recuperació local per als errors que només afecten un node, i els protocols de dues o tres fases per a la gestió dels errors quan intervenen diferents nodes.

Protocols de recuperació local

Per tal de millorar l'accés a les dades, el SGBD disposa d'una memòria intermèdia (buffer) de la base de dades a memòria, on guarda les dades llegides del disc i les dades modificades pel sistema. L'objectiu d'aquesta memòria intermèdia és el de millorar el temps d'accés a la informació, ja que aquest sempre serà més ràpid a memòria que a disc. La gestió d'aquesta memòria intermèdia i la informació del disc per tal de garantir la seva consistència la gestiona el Database Buffer Manager o DBM. En un sistema d'aquestes característiques apareixen problemes quan a la memòria intermèdia hi ha informació no actualitzada a disc i es produeix un error en el sistema. Llavors s'executa el protocol de recuperació local, el qual fa les operacions de Redo/Undo per tal de deixar el sistema en un estat consistent. Les operacions de Redo agafen les dades no actualitzades a la BD del fitxer de log i llavors les actualitzen, ja que si no es fa aquest procés, no es pot garantir la propietat de durabilitat de les transaccions. Un cas típic d'aquesta situació és quan es produeix un error i encara no s'han actualitzat totes les operacions a disc d'una transacció que ha finalitzat la seva execució amb una operació de commit. Les operacions de Undo han de desfer les operacions ja actualitzades a disc però que no s'han de mantenir per tal de garantir la propietat d'atomicitat de les transaccions. Un cas típic d'aquesta situació és quan hi ha un error i una transacció encara no ha acabat. Llavors caldrà desfer totes les modificacions fetes per aquesta transacció, agafant del fitxer de log les imatges anteriors de les dades. Aquest protocol de recuperació local l'executa el Local Recovery Manager o LRM. Quan aquest detecta una recuperació del sistema com a resultat d'un error, posa el

61

sistema en un estat consistent. Aquest estat consistent s'obté a partir del darrer checkpoint o punt de sincronisme del sistema, aplicant les operacions de Redo/Undo.

Protocols de dues fases

En els SGBDD s'acostuma a executar protocols que garanteixen l'execució d'una mateixa operació per a un conjunt de nodes. Aquests protocols són de dues fases. En la primera fase es demana permís per fer l'operació, i si tots contesten afirmativament, en la segona fase es fa l’operació. Ara bé, si un sol node no dóna permís en la primera fase per fer l'operació, en la segona fase cap node no la farà. En aquests protocols sempre es defineixen els protocols de terminació i de recuperació. El protocol de terminació és el protocol que ha d'executar un node quan detecta que un altre node no respon. El protocol de recuperació és el que ha d'executar un node quan detecta que arranca o es recupera després d'un error.

Gestió del diccionari del sistema

La principal informació que guarda el DD és la referent a la ubicació de la informació del sistema. Aquest DD normalment està centralitzat i totalment replicat, per la qual cosa, cal anar amb compte amb les operacions de modificació sobre el seu contingut. El Diccionari d'un SGBDD conté tota la informació útil per al sistema per accedir a les dades de forma correcta i eficient, així com per verificar que els usuaris tenen els privilegis per a fer-ho. Aquests s'utilitzen per: Descripció de l'Esquema Global Conceptual GCS. Inclou el nom de les relacions, atributs, tipus i unions entre les diferents relacions (PK i FK). Mapatge de les dades. Mapar les dades referenciades per les aplicacions amb les dades físiques. Optimitzar peticions. Per construir un bon pla d'execució cal conèixer la ubicació de les dades, els mètodes d'accés a cada node i informació estadística del sistema. Execució de peticions. Per verificar que les estratègies d'execució són correctes i que els usuaris tenen els permisos necessaris per les operacions que volen fer. En el cas d'un SGBDC la gestió del diccionari és simple, ja que aquest està centralitzat en un sol node. Ara bé, en els SGBDD aquest problema és més complex, i la distribució dels diccionaris es pot tractar en funció de si els nodes tenen o no autonomia local. Si els nodes no tenen autonomia local, la gestió del diccionari està centralitzada, així que la millor solució és la d'un diccionari no distribuït i totalment replicat. Ara bé, si la majoria de tràfic és local, pot ser interessant que el diccionari estigui distribuït i no replicat. En canvi, si els nodes tenen autonomia local, s’ha de permetre a cada usuari local la creació i assignació d'un nom a un objecte de forma independent d'un control global,

62

permetent que diferents usuaris hi puguin accedir. En aquest cas la millor solució és la de disposar d'un diccionari distribuït i no replicat. Per tant, en el cas dels SGBDD fortament acoblats, la solució habitual és la de disposar d'un diccionari no distribuït i totalment replicat. Ara bé, en aquest tipus de sistemes cal fixar i gestionar molt bé l'accés als diccionaris per part dels diferents administradors del sistema. Segons els apartats anteriors es pot observar que els SGBDD ens permetran en els propers anys disposar de sistemes més econòmics, fiables i extensibles. Tanmateix, per arribar a productes comercials amb aquestes tecnologies, cal resoldre un conjunt de problemàtiques que no són gens trivials.

[Tamer1999] p8-p24

RESUM En aquesta sessió s’han vist els principals serveis que ofereixen els sistemes gestors distribuïts i els problemes que hi ha en el seu disseny.

63

SESSIÓ 9 Nom: Nivells de transparència. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la tercera sessió del capítol de bases de dades distribuïdes. A les sessions anteriors s’ha fet una introducció a les bases de dades, arquitectura, serveis i principals problemes que hi ha en el seu disseny.

OBJECTIUS En aquesta sessió s’introdueixen els conceptes bàsics referents als nivells de transparència d’un sistema gestor.

CONTINGUTS En aquesta sessió es tracten els primers apartats relatius a l’arquitectura d’un sistema gestor. Es comença amb una introducció, es segueix amb l’estudi dels nivells de transparència que el sistema ha de donar i finalment es presenta el model ANSI/X3/SPARC que facilita la definició dels models distribuïts. En aquest tema es fa una introducció a la definició de l’arquitectura d’un sistema gestor.

Introducció

L'arquitectura d'un gestor distribuït defineix la seva estructura. Aquesta estructura està formada per un conjunt de components. Llavors cal identificar i descriure el comportament de cada un dels components que formen el sistema. Ara bé, els components del sistema estan relacionats entre si en funció de les operacions que resolen. Llavors, per tal de modelar el comportament del sistema, cal descriure les relacions que hi ha entre els diferents components així com les dades i operacions que aquests comparteixen. En aquest capítol primer s'analitza l'arquitectura d'un sistema gestor centralitzat i a continuació s’estén aquest per tal d'obtindre l'arquitectura d'un gestor distribuït. Per centrar l'estudi de l'arquitectura d'un sistema gestor centralitzat, primer es detallen els nivells de transparència que aquests sistemes han de proporcionar.

64

A continuació es detalla el model ANSI/X3/SPARC que és una arquitectura força utilitzada tant per a sistemes centralitzats com distribuïts. Finalment es presenta un model que permet classificar els diferents tipus de sistemes gestors distribuïts així com l'estudi de la gestió del diccionari de dades que aquests han de mantenir.

2.4. Transparència i models distribuïts En aquest tema es descriuen els nivells de transparència que ha de suportar un sistema gestor de base de dades.

Nivells de transparència

La transparència en un sistema gestor es refereix a la separació entre l'alt nivell d'utilització d'un sistema i els detalls de baix nivell de la seva implementació. Per tant, és important que els sistemes disposin de nivells de transparència grans, atès que això facilita la seva utilització. En el cas dels sistemes gestors de bases de dades, l'existència de transparència fa que les aplicacions que hi accedeixen vegin el sistema de forma totalment independent a la seva construcció, o sigui, que no distingeixen entre un sistema centralitzat i un de distribuït, ja que sempre reben la resposta a la petició sol·licitada. En el cas d'un sistema distribuït, també és molt útil que sigui el més transparent possible, ja que així facilita la seva utilització per part dels clients o aplicacions que envien les peticions d'execució. Els principals nivells de transparència que ha de donar un SGBDD són:

Dades

La transparència de dades és refereix a la immunitat de les aplicacions d'usuari enfront els canvis en la definició i organització de les dades. La transparència de les dades es divideix en dos nivells; respecte l'estructura lògica i respecte l'estructura física. La transparència respecte l'estructura lògica es refereix a la transparència enfront de canvis en l'esquema de la BD. La transparència respecte l'estructura física indica que les aplicacions d'accés a les dades ni depenen ni coneixen els detalls relatius a l'organització física de les dades, així com no ha de canviar els mètodes d'accés enfront de qualsevol canvi d'organització de les dades.

Xarxa

La transparència de xarxa permet que l'accés de les aplicacions a les dades es faci sense que aquestes coneguin cap detall de la xarxa, i han de treballar de forma independent de la seva construcció.

65

Des de la perspectiva dels SGBDD, la transparència de xarxa requereix que les aplicacions no han d'especificar la ubicació de la informació. Aquesta transparència també es refereix a les comandes emprades per accedir a la informació així com respecte al nom dels objectes.

Replicació

La transparència de replicació garanteix l'accés a la informació per part de les aplicacions, tant si aquesta està replicada com si no ho està, utilitzant els mateixos mètodes d'accés. En aquest cas, el sistema s'encarrega de gestionar la consistència de les rèpliques en modificar les aplicacions el seu contingut, atès que les aplicacions no distingeixen si una dada està o no replicada a l'hora d'accedir-hi.

Fragmentació

La transparència de fragmentació garanteix l'accés a la informació per part de les aplicacions, tant si aquesta està fragmentada com si no ho està, utilitzant els mateixos mètodes d'accés. Amb els apartats anteriors hem vist que si es garanteixen els nivells de transparència es facilita la utilització del sistema gestor. Ara bé, a mesura que creix el nivell de transparència que dóna el sistema, hi ha un increment en el cost per donar-la, cosa que pot provocar una disminució en el seu rendiment. Llavors, sempre cal arribar a un compromís entre el nivell de transparència i el rendiment que es desitja que doni el sistema.

El model ANSI/X3/SPARC

En aquest tema es fa una descripció del model ANSI/X3/SPARC.

El model ANSI/X3/SPARC

Tal com ja hem comentat a l'apartat anterior, l'arquitectura d'un SGBDD defineix la seva estructura a partir de la identificació dels components que la formen, especificar la funció de cada un dels components i definir les relacions existents entre els diferents components. Cada cop més es tendeix a estandarditzar el disseny dels sistemes complexos. Una forma de fer-ho és dividint el SGBDD en components estàndard, especificant quina és la seva funció i com es comuniquen entre si. Això permet definir les interfícies estàndard entre els diferents nivells. El primer intent de modelització d'un sistema gestor centralitzat es presenta en [Cod1969] preparat pel Database Task Group DBTG del comitè de sistemes CODASYL.

66

A l'any 1971 i després de diverses millores, aquest grup de treball va presentar una altra versió d'aquest model. Un fet que va motivar un ampli debat sobre la creació d'un model estàndard va ser la publicació dels articles d'en Codd en què es defineix de forma molt acurada el model relacional. Seguidament, a l'any 1972 el Computer and Information Processing Committee X3 del American National Standards Institute ANSI, va crear un comitè sobre els SGBD amb l'elaboració posterior del Standards Planning and Requirements Commitee SPARC. Aquest grup va presentar el seu primer model a l'any 1975 i finalment a l'any 1977 el seu informe final. Aquest estàndard s'anomena ANSI/X3/SPARC DBMS. Aquest estàndard defineix els components del SGBDD a partir de dues visions diferents, en funció de les dades i en funció dels usuaris del sistema. Un cop es defineixen aquests diferents components, els relacionen en funció del tipus d'operacions que fan. A la figura següent es detalla el model d'un SGBDD definit a partir de les dades. Es distingeixen tres tipus diferents d'esquemes: Intern, Conceptual i Extern.

L'esquema intern és l'esquema que conté la informació física, organització i mètodes d'accés de les dades a baix nivell. En el cas d'un SGBDD cada node disposa del seu esquema intern anomenat LIS que sempre es defineix localment a cada node. L'esquema conceptual és l'esquema que conté la informació de l’esquema de la BD. Cada node disposa del seu Esquema Local Conceptual LCS i la unió de tots ells és el GCS. En el cas dels SGBDD l'accés a les dades sempre es fa a partir del GCS amb visió de tota la BDD. L'esquema extern és l'esquema que organitza, agrupa i protegeix la informació del GCS i ho presenta per facilitar l'accés fàcil i eficient a les dades a partir seu. Cada node pot disposar del seu Esquema Local Extern, però tots els accessos es fan a partir del Esquema Global Extern GES. En funció dels usuaris, l'estàndard ANSI/X3/SPARC també relaciona els diferents perfils d'usuaris del sistema. Llavors, els diferents perfils d'usuari segons l'estàndard ANSI/X3/SPARC són:

67

Administrador corporatiu. És l'expert del negoci del sistema d'informació i s'encarrega de definir i administrar el GCS. Administrador d'aplicacions. És l'usuari que s'encarrega de definir el GES, ja que és el que es fa servir per accedir al GCS. Administrador de la BD. És l'usuari responsable de l'ajust del sistema, i per tant defineix els diferents LIS. Programador d'aplicacions de sistema. És el programador que construeix utilitats de sistema que requereixen accedir als diferents LIS. Programador d'aplicacions. És l'usuari que accedeix al sistema a partir del GCS. Usuaris externs. Són els usuaris del sistema d'informació amb accés a partir de les aplicacions mitjançant el GES. Usuaris temporals. Són els usuaris que temporalment accedeixen mitjançant utilitats a la informació del sistema. La relació entre els diferents tipus d'usuaris i els esquemes del sistema gestor estan molt ben descrites a [Tamer1999] p.78. A partir d'aquesta estructura ja es pot construir un model de capes del SGBDD. Segons aquest model, nosaltres ens centrem en els SGBDD fortament acoblats, descartant els sistemes gestors federats SGBDF i les multidatabases MDB. Els SGBDF tenen més autonomia de procés local que els SGBDD, ja que permeten l'accés a les dades locals mitjançant esquemes locals externs LES. En el cas dels sistemes multidatabase MDB l'autonomia de procés és molt alta.

[Tamer1999] p75-p82

RESUM En aquesta sessió s’han tractat els primers apartats relatius al conjunt de transparències que donen els sistemes gestors, així com el model ANSI/X3/SPARC que facilita la definició de l’arquitectura del sistema gestor.

69

SESSIÓ 10 Nom: Models distribuïts Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la quarta sessió del capítol de bases de dades distribuïdes. A les sessions anteriors s’han presentat els conceptes i l’arquitectura bàsica dels gestors distribuïts. S’han estudiat els serveis i nivells de transparència que han de donar.

OBJECTIUS En aquesta sessió s’analitzen els diferents tipus de models que hi ha per classificar els sistemes gestors distribuïts.

CONTINGUTS En aquesta sessió s’estudien els diferents tipus de model en què es poden classificar els sistemes gestors distribuïts.

Models distribuïts

En aquest tema es presenten els diferents tipus de models en què es poden classificar els sistemes gestors.

Models distribuïts

A partir de l'arquitectura presentada en el model ANSI/X3/SPARC es pot pensar en la seva extensió cap a un model distribuït. A [Tamer1999] p.84 es presenta una d'aquestes extensions. Cal remarcar que en el cas d'un sistema gestor distribuït, el model arquitectònic depèn de diferents paràmetres que condicionen força tant el seu funcionament com el seu disseny. Llavors, abans de descriure una arquitectura concreta, es detallen els tres principals criteris que ens permeten classificar els diferents tipus de sistemes gestors. Aquests són: Nivell de distribució, Nivell d'autonomia i Nivell d’homogeneïtat.

70

Nivell de distribució. Aquest es refereix al nivell de distribució de les dades. Hi ha dos possibles models que són: Sense distribució. La informació està centralitzada en un sol node. Amb distribució. La informació està repartida o distribuïda entre els diferents nodes del sistema. Nivell d'autonomia. Aquest indica el nivell en què un node pot treballar de forma autònoma i independentment de la resta de nodes. Podem diferenciar tres nivells d'autonomia que són: Sistemes fortament acoblats. En aquest cas, els nodes no tenen cap tipus d'autonomia i depenen de la resta de nodes per resoldre les operacions. Sistemes semiautònoms. Són aquells que poden treballar de forma totalment autònoma o bé de forma totalment integrada amb la resta de nodes. Un bon exemple de sistemes d'aquest tipus són els Sistemes Gestors de Bases de Dades Federats SGBDF. Aquests sistemes disposen d'informació que només es pot utilitzar de forma local i amb una gran autonomia i d'informació amb accés coordinat amb la resta de nodes. Sistemes autònoms. Són sistemes que només poden resoldre operacions locals i en què l'execució d'aplicacions global és molt costosa, ja que no hi ha cap tipus de control global del sistema. Nivell d’homogeneïtat. L'estudi de la homogeneïtat d'un sistema es pot tractar des de diferents aspectes com: maquinari, models de dades, xarxa de comunicacions, llenguatge d'accés, etc. Ara bé, per tal de classificar els diferents tipus de sistemes gestors distribuïts s'entén com a nivell d’homogeneïtat en funció del model de dades i llenguatge d'accés utilitzat. Segons aquest criteri hi ha dos tipus de sistemes: Homogenis. Són aquells sistemes en el quals els diferents gestors locals utilitzen el mateix llenguatge d'accés i model de dades. Heterogenis. Els sistemes heterogenis estan formats per gestors locals que fan servir diferents models de dades i llenguatges d'accés a les dades. Segons els tres criteris anteriors, a la figura següent hi ha diferents possibilitats d'arquitectures.

71

Sistemes Gestors de Bases de Dades Centralitzades SGBDC

En aquest tipus de sistemes tota la informació està centralitzada en un sol node i tot ho gestiona un sol sistema gestor.

Sistemes Gestors de Bases de Dades Federades SGBDF

Un sistema gestor de bases de dades federades és un sistema amb un nivell mig d'autonomia de procés. En aquests sistemes cada node es reserva un conjunt de dades en les que només es poden executar operacions d'accés local i un altre conjunt de dades que es comparteixen amb la resta de nodes. En referència a les dades locals que no es comparteixen amb la resta de nodes el sistema té molta autonomia de procés, ja que no depèn de cap altre node per accedir-hi. En canvi, per accedir a les dades que comparteix amb la resta de nodes, es tracta d'un sistema fortament acoblat o sense cap autonomia de procés.

Multidatabases MDB

Una característica dels sistemes gestors multidatabase és que són sistemes heterogenis. Per aquest motiu cada node disposa del seu LIS i a partir d'aquest esquema es defineix el corresponent LCS. Llavors es poden distingir dos tipus diferents de sistemes MDB que són els que tenen GCS i els que no tenen GCS. MDB amb GCS En aquest tipus de sistemes MDB hi ha un GCS que es construeix a partir de la unió dels diferents LCS dels nodes. A la figura següent es pot observar aquesta estructura.

En aquest tipus de MDB es pot accedir de forma local amb molta autonomia de procés a la informació a partir dels LES que s'han definit segons el LCS del node. Amb aquest tipus d'accés només es poden executar operacions sobre les dades locals al node.

72

Ara bé, un altra alternativa d'accés a la informació del sistema és a partir dels GES, ja que d'aquesta forma es pot accedir a la informació que s'ha distribuït entre els diferents nodes i que està definida al GCS. MDB sense GCS Aquest tipus de sistemes gestors no disposen d'un GCS, ja que en sistemes heterogenis és força difícil la seva construcció. A continuació hi ha la seva estructura. Llavors l'accés de les aplicacions als esquemes locals dels diferents nodes sempre es fa a partir d'esquemes externs locals, i aquests estan definits a partir dels LCS. Així doncs es pot accedir tant a informació local com distribuïda. Un cop ja s'han vist els diferents tipus de sistemes gestors, a continuació ens centrarem en l'estudi dels SGBDC i els SGBDD.

[Tamer1999] p75-p99

RESUM En aquesta sessió s’ha estudiat els diferents tipus de models en què es poden classificar els sistemes gestors distribuïts.

73

SESSIÓ 11 Nom: Diccionari de dades Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la cinquena sessió del capítol de bases de dades distribuïdes. A les sessions anteriors s’ha estudiat l’arquitectura bàsica i els diferents models dels gestors distribuïts.

OBJECTIUS En aquesta sessió s’analitzen els diferents tipus de diccionari de dades i el seu suport per a la gestió i control.

CONTINGUTS Es descriuen els diferents tipus de diccionari de dades que hi ha i les diferents formes de gestionar-ho.

2.5. Diccionari de dades En aquest tema es descriuen els diferents tipus de diccionari de dades que hi ha i es veu com es suporta la seva gestió i control.

Gestió i control dels diccionaris

El Diccionari d'un SGBDD conté tota la informació útil per al sistema per accedir a les dades de forma correcta i eficient, així com per verificar que els usuaris tenen els privilegis per a fer-ho. Aquests s'utilitzen per: Descripció de l'Esquema Global Conceptual GCS Inclou el nom de les relacions, atributs, tipus i unions entre les diferents relacions (claus primàries i claus alienes). Mapatge de les dades Mapar les dades referenciades per les aplicacions amb les dades físiques.

74

Optimitzar peticions Per construir un bon pla d'execució cal conèixer la ubicació de les dades, els mètodes d'accés a cada node i informació estadística del sistema. Execució de peticions Per verificar que les estratègies d'execució són correctes i que els usuaris tenen els permisos necessaris per a les operacions que volen fer. En el cas d'un SGBDC la gestió del diccionari és simple, ja que aquest està centralitzat en un sol node. Ara bé, en els SGBDD aquest problema és més complex, i la distribució dels diccionaris es pot tractar en funció de si els nodes tenen o no autonomia de procés local. 1.- SGBD sense autonomia local. La gestió del diccionari està centralitzada, així que la millor solució és la d'un diccionari no distribuït i totalment replicat. Ara bé, si la majoria de tràfic és local, pot ser interessant que el diccionari estigui distribuït i no replicat. 2.- SGBD amb autonomia local. Ha de permetre a cada usuari local la creació i assignació d'un nom a un objecte de forma independent d'un control global, permetent que diferents usuaris hi puguin accedir. En aquest cas la millor solució és la de disposar d'un diccionari distribuït i no replicat. Per tant, en el cas dels SGBDD fortament acoblats, la solució habitual és la de disposar d'un diccionari no distribuït i totalment replicat. Ara bé, en aquest tipus de sistemes cal fixar i gestionar molt bé l'accés als diccionaris per part dels diferents administradors del sistema.

[Tamer1999] p97-p99

RESUM En aquesta sessió s’han descrit els diferents tipus que hi ha en la gestió i control dels diccionaris de dades.

75

SESSIÓ 12 Nom: Model bàsic d’un gestor distribuït Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la darrera sessió del capítol de bases de dades distribuïdes. A les sessions anteriors s’han estudiat els conceptes bàsics relatius a les bases de dades distribuïdes.

OBJECTIUS En aquesta sessió s’analitza el model bàsic d’un gestor distribuït.

CONTINGUTS Es descriu el model bàsic d’un gestor distribuït a partir del seu model de capes.

2.6. Model bàsic d’un gestor distribuït En aquest tema es descriu el model bàsic d’un gestor distribuït. Es presenta a partir d’un model de capes i seguidament es detallen les seves funcionalitats.

Model bàsic d’un gestor distribuït

Es tracta d'un sistema que integra un conjunt de sistemes gestors homogenis que estan distribuïts per una xarxa. Els diferents sistemes gestors estan fortament integrats, amb la qual cosa no tenen cap tipus d'autonomia de procés. En aquests sistemes cada node té el seu LIS i LCS. Llavors, hi ha un GCS que dóna un esquema global de tot el sistema de forma totalment transparent. Aquest GCS és el resultat de la unió dels diferents LCS dels diferents sistemes. L'accés de les aplicacions sempre es fa a partir d'un conjunt d'esquemes externs que accedeixen al GCS. A la figura següent es pot observar aquesta estructura.

76

Les peticions sempre es fan a partir dels esquemes externs que estan definits a partir de l’esquema global conceptual GCS. Com que el GCS està definit a partir de tot el conjunt de LCS, l'accés a la informació es pot fer de forma transparent. D'aquesta forma es garanteixen tots els nivells de transparència que ha de donar el sistema: Dades (a partir del LIS), Xarxa (mitjançant el GCS) i els nivells de transparència de fragmentació i distribució (GCS). En aquest cas quan el SGBDD rep una petició la converteix a un conjunt de peticions locals i aquestes s'executen en els servidors locals. El resultat de l'execució de les peticions locals s'envien al node que ha de retornar el resultat a l'aplicació que li ha sol·licitat. Llavors, quan un node rep una petició d'accés a una informació, aquest ha de conèixer la seva ubicació. Per resoldre aquesta problemàtica el sistema té un diccionari de dades globals. Aquest diccionari conté la ubicació de les relacions del GCS i del seu nivell de fragmentació i replicació. A continuació es detalla l'arquitectura d'un SGBDD mitjançant un model de capes i la seva relació amb els diferents esquemes del sistema. Aquests components són: Interfície. S'encarrega d'interpretar les operacions que envien les aplicacions i de formatar el resultat de l'execució d'aquestes operacions. Control semàntic de les dades. A partir de les restriccions d'integritat i seguretat que s'han definit en el GCS comprova que la petició es pot executar. Optimitzador global. A partir de la petició construeix un pla d'execució òptim. Per fer-ho utilitza un model de cost que serveix per avaluar el cost d'un conjunt de possibles estratègies d'execució. Monitor d'execució global. Aquest monitor s'encarrega de coordinar l'estratègia d'execució que ha generat el mòdul optimitzador global. Aquest monitor es comunica amb els processadors locals de tots els nodes involucrats en l'execució de l'estratègia.

77

Processador local. Aquest rep ordres d'execució des de el monitor d'execució local i s'encarrega de la seva execució local. Per fer-ho, ha d'escollir la millor estratègia local per a l'execució de l'operació. Gestor de recuperació local. S'encarrega de mantenir sempre el sistema gestor en un estat consistent. Per fer-ho ha de suportar protocols de caiguda i recuperació. Processador de suport d'execució. Aquest mòdul és el que s'encarrega de l'execució final de les operacions i actua com a interfície en el sistema operatiu.

Cal destacar que el monitor d’execució global coordina l’execució de la petició, ja que envia les operacions als processadors locals dels diferents nodes. Per això, aquest ha

78

de coordinar i sincronitzar l’execució de totes les operacions i retornar el resultat final de l’execució de la petició a la capa d’interfície, ja que aquesta s’encarrega de preparar i donar el resultat al client que ha fet la petició. Els diferents nodes que intervenen en l’execució de la petició, també optimitzen la seva execució a partir de l’accés a l’esquema local conceptual i intern.

RESUM En aquesta sessió s’ha descrit el model bàsic d’un gestor distribuït a partir d’un model de capes.

79

SESSIÓ 13 Nom: Introducció i estratègies de disseny. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la primera sessió del capítol de disseny de gestors distribuïts.

OBJECTIUS En aquesta sessió es coneixen els conceptes bàsics del disseny de gestors distribuïts.

CONTINGUTS En aquesta sessió es fa una introducció al disseny de gestors distribuïts. S’analitzen els principals paràmetres que afecten al procés i seguidament s’estudien les diferents tècniques de disseny que es poden emprar.

3. Disseny de gestors distribuïts

3.1. Introducció En aquest tema s’introdueix el disseny de gestors distribuïts.

Introducció

En la fase de disseny d’un sistema distribuït cal definir la ubicació dels gestors, de les aplicacions, de les dades i de la topologia de la xarxa de comunicacions. En funció de la distribució d’aquests components, el rendiment i equilibrat del sistema pot variar força. És per aquest motiu que és un dels aspectes més importants a l’hora de dissenyar un sistema gestor distribuït. En el cas dels sistemes gestors distribuïts, tant els gestors com les aplicacions que aquests executen estan en tots els nodes del sistema. És per això que es centra el seu estudi en la distribució de les dades.

80

Ara bé, abans de dissenyar el sistema gestor, és convenient conèixer tres paràmetres relatius al seu comportament. Aquests són: 1.- Patró d’accés. Aquest defineix els nodes on els clients o aplicacions envien les peticions, així com els camins que utilitzen els diferents nodes del sistema per buscar la informació que necessiten per executar les peticions. Hi ha dos models diferents: a) Patró d’accés estàtic. Les peticions sempre s’envien a un node predeterminat o bé el node que rep una petició segueix camins prèviament definits per accedir a la informació que necessita. b) Patró d’accés dinàmic. En aquest cas, qualsevol node pot rebre qualsevol tipus de petició i pot seguir qualsevol camí per accedir a la informació que li fa falta per executar la petició que rep. Tot això sense estar prèviament definit quins són aquests camins i tenint en compte que poden canviar en el temps. El model que dóna un millor comportament del sistema gestor és el que utilitza un patró d’accés dinàmic, encara que és el més difícil d’implementar. De fet, no és gens habitual disposar d’un sistema distribuït amb un patró d’accés estàtic. 2.- Tipus de diccionari. El diccionari del sistema pot estar distribuït entre els diferents nodes del sistema o bé totalment replicat entre aquests. En funció del seu disseny, els camins que han d’utilitzar els nodes per fer-hi consultes, així com els protocols utilitzats per a la seva actualització poden afectar molt el seu rendiment. La solució típicament emprada és la d’utilitzar un diccionari centralitzat i totalment replicat. 3.- Nivell de cooperació. Amb aquest paràmetre es defineix el nivell en què els diferents nodes comparteixen els programes i les dades del sistema. Es poden donar tres situacions que són: a) Nul. Les aplicacions i les dades són locals a cada node que és el node on aquestes s’executen. Llavors els nodes no es poden intercanviar cap tipus de dades i les aplicacions són estrictament locals. b) Dades. En aquest model les aplicacions estan replicades en tots els nodes del sistema, però les dades són locals a cada node. A partir d’aquest model, les peticions sempre s’executen en el node que s’envien, la qual cosa provoca el moviment de les dades entre els diferents nodes del sistema. c) Aplicacions i dades. Les dades i els programes es comparteixen entre tots els nodes del sistema. Això vol dir que un programa que està ubicat en un node pot enviar una petició a un altre programa que està en un altre node, encara que la informació que aquests necessitin per la seva execució no la tinguin disponible localment. Per tant, a l’hora de dissenyar un sistema gestor distribuït cal contemplar el comportament que té el sistema gestor en funció dels paràmetres ja detallats. Un cop aquest comportament es coneix, s’ha de decidir la distribució i ubicació de la informació de la base de dades de tal forma que s’intenti maximitzar el seu rendiment, cosa que no és gens fàcil i que estudiarem amb detall en els apartats següents.

81

3.2. Disseny i distribució En aquest tema es presenten les diferents estratègies de disseny que es poden utilitzar.

Estratègies de disseny

A l’hora de dissenyar una base de dades distribuïda es poden emprar tècniques de disseny top-down o bé bottom-up. Tal com indica el seu nom, són estratègies força diferents per dissenyar una base de dades distribuïda. Ara bé, són dues tècniques força oposades, amb la qual cosa en sistemes reals es pot donar el cas d’utilitzar solucions intermèdies. A continuació es fa una descripció d’aquestes amb detall.

Disseny top-down

Aquest procés de disseny comença a partir de l’estudi de requeriments que defineix l’entorn del sistema i que té com a principal objectiu la definició de les dades i processos requerits pels usuaris del sistema. És doncs una fase preliminar al disseny, ja que ha de recollir el rendiment esperat del sistema, el seu grau de fiabilitat, disponibilitat de les dades, capacitat de creixement i cost. Un cop s’han definit els requeriments del sistema cal seguir amb l’estudi de les interfícies requerides pels usuaris per tal d’accedir al sistema així com l’esquema conceptual del sistema requerit per guardar les informacions. Aquest procés es pot fer en paral·lel, ja que hi intervenen diferents tipus d’usuaris. Els experts en el negoci han d’ajudar a la definició del GCS i els usuaris externs en definir les interfícies o vistes d’accés al sistema, o sigui, l’esquema global extern GES. Encara que aquest darrer procés es pugui fer en paral·lel, sempre es necessita integrar els dos models per tal que siguin consistents.

82

A continuació, a partir dels esquemes GCS i GES del sistema s’obtenen els esquemes conceptuals locals LCSs dels diferents nodes. Aquest procés de disseny es divideix en dues etapes: fragmentació i ubicació. L’etapa de fragmentació s’encarrega de decidir si la granularitat de memorització de les relacions, ja que aquestes es poden guardar sense fer cap tipus de divisió o partició, o bé dividint-les en fragments. L’etapa d’ubicació s’encarrega de decidir els nodes on s’han de posar els diferents fragments. Tant el procés de fragmentació com el procés d’ubicació requereixen d’informació estadística del sistema per resoldre el procés. Aquesta informació estadística es refereix tant a la grandària de les dades que utilitzen les diferents peticions com a la utilització dels clients de cada petició. Aquesta fase de disseny de distribució és la que estudiarem en aquest capítol. La darrera fase és la del disseny físic, ja que s’encarrega d’assignar els diferents objectes dels LCs als dispositius físics que hi ha disponibles, definint d’aquesta forma els diferents esquemes interns dels nodes LISs. Per tant, l’estratègia de disseny d’una base de dades distribuïda està pensada per a la implementació d’un sistema nou, ja que si es disposen de bases de dades locals ja implementades per tal d’integrar-les en un sistema nou, es tracta d’una estratègia de disseny bottom-up, tal com estudiarem en l’apartat següent.

83

Disseny bottom-up

Aquest procés de disseny és útil quan es dissenya la base de dades distribuïda a partir d’un conjunt de nodes ja existents i només cal integrar-los. En aquest cas, el punt de partida són els diferents LCSs del sistema, ja que s’han d'ajuntar per tal de crear un sol GCS. El procés d’integració dels LCSs es complica força per a sistemes heterogenis, tant en el cas de sistemes federats com sistemes multidatabase. Nosaltres ens centrarem en l’estudi dels sistemes gestors fortament acoblats, ja que en aquest cas el procés de disseny lògic a emprar és el top-down.

[Tamer1999] p102-p106

RESUM En aquesta sessió s’ha fet una introducció al disseny de gestors distribuïts. Primer s’han analitzat els principals paràmetres que afecten el procés i després s’han estudiat les diferents tècniques de disseny que es poden emprar.

85

SESSIÓ 14 Nom: Distribució. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la segona sessió del capítol de disseny de gestors distribuïts. A la primera sessió s’ha fet una introducció al disseny de gestors distribuïts i s’han vist les estratègies de disseny que es poden utilitzar.

OBJECTIUS En aquesta sessió es coneixen les tècniques de disseny que es poden utilitzar. S’estudien les regles que el procés de disseny ha de complir per tal que el procés de disseny sigui correcte.

CONTINGUTS En aquesta sessió es fa un estudi de les diferents tècniques de disseny que es poden emprar. Inicialment es justifica el procés, seguidament es donen les regles que s’han de complir i finalment es concreta amb els diferents tipus de fragmentació i criteris de correcció. En aquest tema s’estudien les tècniques de distribució que es poden emprar en el procés de disseny d’un sistema gestor distribuït.

Distribució

Tal com hem vist a la secció anterior, les relacions de la base de dades es parteixen en trossos més petits anomenats fragments. Ara bé, cal detallar quines relacions es fragmenten, de quina forma es fragmenten i en quins nodes s’ubiquen els fragments. Tanmateix cal trobar algun procés de validació del procés de fragmentació així com la informació necessària per poder fer-ho. En els apartats següents estudiem amb detall aquests conceptes.

Justificació del procés de fragmentació

El procés de fragmentació és recomanable per a sistemes gestors distribuïts, ja que produeix un increment en el rendiment del sistema, evidentment sempre que es

86

fragmentin correctament les diferents relacions. Aquest increment del rendiment es dóna principalment per tres motius que són: 1.- Es minimitza el volum de dades a tractar. Si per executar una petició només es requereix la utilització de les dades d’un fragment en lloc de fer-ho amb tota la relació, s’aconsegueix que el sistema treballi amb menys informació, amb la qual cosa es millora el temps de resposta de l’execució de la petició. Aquesta millora és més important a mesura que creix la complexitat de les peticions, ja que llavors no s’incrementen tant les cardinalitats dels resultats parcials que hi ha en el pla d’execució de les peticions. Independentment de la millora en el temps de resposta de l’execució de les operacions locals a cada node, com que es treballa amb un volum de dades més petit, quan s’hagin d’enviar fragments entre els diferents nodes, el seu temps de resposta disminueix, amb la qual cosa encara es millora més el rendiment del sistema. 2.- Provoca l’execució de peticions intraquery. Si una relació està fragmentada i els fragments estan ubicats en diferents nodes, quan s’ha d’executar una petició sobre tota la relació es pot fer en paral·lel, amb la qual cosa es millora el rendiment del sistema. 3.- Increment en l’execució de peticions interquery. Un altre efecte associat a la disminució de la grandària de les relacions en què s’executen les peticions, és que permet aïllar l’execució de les operacions per diferents nodes, amb la qual cosa la probabilitat de conflictes disminueix i, per tant, provoca una millora en el rendiment del sistema al poder executar més peticions de forma concurrent. De totes formes, hi ha situacions en què l’existència de fragmentació pot provocar una disminució en el rendiment del sistema. Això es pot donar principalment en dues situacions diferents, que són: 1.- Peticions que utilitzen tota la relació. Si s’ha d’executar una petició que requereixi disposar d’una relació o més d’un fragment en un sol node, el rendiment del sistema es veu força penalitzat, ja que el node que ha de resoldre el procés d’execució ha de demanar a la resta de nodes els fragments que no té, amb la qual cosa el rendiment del sistema disminueix. 2.- Validació de restriccions més complex. Quan a causa de l’execució d’una petició de modificació s’han de validar regles associades a les dades que es modifiquen, es pot donar el cas que aquestes regles afectin més d’un fragment, amb la qual cosa el rendiment del sistema es veu penalitzat. Per tant, abans de decidir els criteris de fragmentació d’una relació i d’ubicació dels fragments creats, cal tenir presents tant els avantatges com els inconvenients del procés per tal de decidir com es fragmenta la relació i s’ubiquen els diferents fragments.

Tipus de fragmentació

El procés de fragmentació divideix les relacions en relacions més petites que s’anomenen fragments. Aquest procés de divisió pot ser de dos tipus diferent; horitzontal o vertical.

87

a) Fragmentació horitzontal. En aquest cas es divideix la relació en diferents grups de tuples. Per fer-ho s’utilitza l’operació de selecció. Per tant, el criteri utilitzat per dividir una relació sempre es fa en funció del contingut d’algun atribut de la taula. A continuació hi ha un exemple amb la relació Models que es fragmenta en dos fragments horitzontals a partir de l’atribut Preu.

b) Fragmentació vertical. Es divideix una relació a partir dels seus atributs, o sigui, en un fragment vertical d’una relació hi ha un subconjunt dels atributs de la relació. Per tal que el procés de fragmentació vertical d’una relació permeti la reconstrucció de la relació inicial a partir dels fragments, sempre ha d’estar la clau primària de la relació en tots els fragments. A continuació hi ha un exemple d’un fragment de la relació Models que s’obté a partir de l’execució de la petició:

88

Un altre tipus de fragmentació és la fragmentació híbrida. En aquest cas, la relació que s’obté és el resultat d’aplicar una fragmentació horitzontal i vertical alhora sobre una relació. Un aspecte que cal tenir molt present és el d’escollir el nivell de fragmentació utilitzat, ja que una relació es pot dividir amb més o menys fragments. En el cas de la fragmentació horitzontal es pot arribar al límit d’un fragment per tupla i en el cas de la fragmentació vertical a un atribut per tupla. Evidentment, en funció del tipus d’aplicacions i peticions, s’ha de decidir el nivell del procés de fragmentació, que potser es pot donar el cas que aquest sigui null, o sigui, que no s’hagi de fragmentar la relació.

Criteris de correcció

Per tal que el procés de fragmentació d’una relació sigui correcte cal que aquest respecti tres propietats, ja que en cas contrari no es podria garantir la consistència de la informació. Aquestes propietats són:

1.- Complitud. Si una relació R es divideix en n fragments , cada ítem d’informació que està en la relació original R es pot trobar en un dels fragments. O sigui, vol dir que en el procés de fragmentació no hi ha pèrdua d’informació. En el cas de la fragmentació horitzontal, el ítems són les tuples i per a la fragmentació vertical els ítems són els atributs de la relació. 2.- Disjunció. Quan una relació R està fragmentada horitzontalment, les tuples de cada fragment només estan en aquest fragment, o sigui, que els fragments són disjunts. Això vol dir que no hi ha tuples repetides entre els diferents fragments de la relació. Per a les situacions en què una relació R està fragmentada verticalment, els atributs de la relació original només estan en un fragment, excepte la clau primària de la relació, que està en tots els fragments. Si no fos així, no es podria complir la tercera propietat de reconstrucció. 3.- Reconstrucció. Si una relació R es fragmenta amb n fragments

, ha de ser possible definir un operador relacional . Això vol dir que a partir dels fragments d’una relació sempre

s’ha de poder reconstruir la relació R original. L’operador no ha de ser el mateix per als diferents tipus de fragmentació, tal com es pot veure a continuació.

89

a) Fragmentació Horitzontal. En aquest cas ja que permet reconstruir la relació R a partir de tots els fragments.

b) Fragmentació Vertical. i permet reconstruir la relació original. Per tant;

On a1 és la clau primària de la relació R i que està en tots els fragments i A són els atributs de la relació R. El procés de reconstrucció es pot fer ja que en els diferents fragments hi ha la clau primària de la relacions i per tant es pot executar correctament l’operació de join.

Alternatives d’ubicació

Un cop s’ha fet tot el procés de fragmentació s’ha de decidir en quins nodes s’ubiquen els fragments. Un fragment s’acostuma a ubicar en el node que més s’utilitza, ja que així el node que més l’utilitza no l’ha de demanar a un altre node, cosa que penalitzaria força el rendiment del sistema, sobretot en xarxes de comunicació lentes. Per aquest motiu és important conèixer la freqüència d’utilització de les peticions del sistema per part dels nodes, ja que com que les dades que utilitza cada petició estan perfectament definides, s’obté fàcilment la freqüència d’utilització de les dades per a cada node del sistema. En aquest cas, els fragments s’ubiquen en els nodes que més els utilitzen. Un cop es decideix la ubicació dels fragments, també s’ha de fixar el nivell de replicació de cada fragment, o sigui, si interessa replicar els fragments i en quins nodes s’han de posar les rèpliques. Una solució és la de replicar totalment els fragments, amb la qual cosa s’obté una base de dades totalment replicada. D’aquesta forma, l’execució de les operacions de consulta és molt òptima, però es penalitza l’execució de les peticions de modificació, ja que s’ha de mantenir la consistència de la informació modificada en les rèpliques. Llavors, si és coneguda la freqüència d’utilització de totes les peticions en els nodes, es pot decidir el nivell de replicació de cada un dels fragments. Les dades que més es modifiquen no interessa que estiguin molt replicades, i en canvi, les dades que més es consulten interessa que estiguin més replicades. Per aquest motiu, en funció del tipus de peticions i freqüència d’utilització s’ha de decidir els nodes on s’ubiquen els fragments així com el seu nivell de replicació.

Informació necessària

Segons els diferents tipus de fragmentació de les relacions així com del nivell de replicació dels fragments, és útil disposar d’un model de cost del sistema per tal de

90

poder decidir com es fa tot el procés. Aquest model de cost es construeix a partir d’un conjunt de variables que depenen de: 1.- Informació de la base de dades relativa al model conceptual GCS. 2.- Utilització de les peticions en els diferents nodes. 3.- Model emprat en l’obtenció del pla d’execució de les peticions. 4.- Topologia i tipus de xarxa de comunicació utilitzada. En els apartats següents s’estudien aquestes variables aplicades als diferents tipus de fragmentació i també en el procés d’ubicació.

[Tamer1999] p107-p112

RESUM En aquesta sessió s’ha fet un estudi de les diferents tècniques de disseny que s’utilitzen en el disseny d’un sistema gestor distribuït. Inicialment s’ha justificat el procés, s’han vist les regles que s’han de complir i finalment s’ha concretat amb els diferents tipus de fragmentació i criteris de correcció.

91

SESSIÓ 15 Nom: Fragmentació horitzontal. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la tercera sessió del capítol de disseny de gestors distribuïts. A les primeres sessions del capítol s’ha fet una introducció al disseny de gestors distribuïts, s’han vist les estratègies de disseny que es poden utilitzar i s’han estudiat diferents tècniques de distribució.

OBJECTIUS En aquesta sessió s’estudia el procés de fragmentació horitzontal.

CONTINGUTS En aquesta sessió es tracta el procés de fragmentació horitzontal. S’estudien els requeriments d’informació que es requereixen i seguidament s’analitza el procés de fragmentació horitzontal primària i derivada.

3.3. Fragmentació horitzontal En aquest tema s’estudia el procés de fragmentació horitzontal.

Fragmentació horitzontal

El procés de fragmentació horitzontal divideix les relacions en grups de files, on cada grup s’anomena fragment. Hi ha dos tipus diferents de fragmentació horitzontal, que són la fragmentació horitzontal primària i la fragmentació horitzontal derivada. La fragmentació horitzontal d’una relació es fa a partir de la utilització de predicats que s’han definit amb atributs de la mateixa relació. La fragmentació horitzontal derivada d’una relació es fa a partir de la utilització de predicats que s’han definit a partir d’atributs d’altres relacions. A continuació hi ha un exemple de fragmentació horitzontal primària de la relació productes.

92

El contingut dels fragments Productes1 i Productes2 és:

Els fragments Models1 i Models obtinguts com a resultat de la fragmentació són:

93

En aquest cas, la fragmentació de la relació Models s’ha fet a partir d’un predicat definit en un altra relació. Es pot veure que aquest atribut és l’atribut Preu que hi ha a la relació Productes. A continuació s’enfoca la problemàtica de la fragmentació horitzontal. Primer s’analitzen els requeriments d’informació necessària per al procés de fragmentació. Seguidament s’estudia el procés de fragmentació horitzontal primària i després la fragmentació horitzontal derivada.

Requeriments d’informació

En el procés de fragmentació horitzontal cal conèixer informació relativa a la base de dades i informació relativa a les aplicacions que accedeixen al sistema. a) Base de dades. Cal conèixer el model de dades o l’esquema global conceptual GCS de la base de dades. En aquest esquema s’han de detallar els links que hi ha entre les relacions. Per fer-ho s’ha de definir l’owner i el member de cada link. L’owner d’un link és la relació de la que parteix la relació, i el member és la relació destí. Un exemple de link és el que hi ha entre les relacions models i productes. Productes(CodiProducte, Descripcio, Preu) Models(CodiModel, CodiProducte, Unitats) On el link que hi ha entre les relacions és L1 i llavors es pot definir: owner(L1) = Models member(L1) = Productes b) Aplicacions. Cal conèixer els predicats que s’utilitzen en les diferents peticions. Ara bé, no s’ha de fer un estudi exhaustiu de totes les peticions, ja que és una informació que no és sempre coneguda. S’ha d’intentar trobar les peticions més actives per part dels usuaris o bé aquelles que més penalitzen el rendiment del sistema. Un cop s’han identificat aquestes peticions, s’han de determinar els predicats simples que aquestes utilitzen. Aquests predicats es donen de forma:

94

Ai és un atribut de la relació amb un domini

. Llavors al conjunt de tots els possibles predicats simples que accedeixen a una relació Ri són Pr, i els seus membres són pij. Ara bé, la majoria de peticions utilitzen combinacions booleanes de predicats simples. D’aquestes combinacions n’hi ha unes que són interessants per poder fragmentar les relacions, i que s’anomenen predicats minterm. Donat un conjunt , es defineix de forma: En aquest cas, , o sigui, que cada predicat simple pot aparèixer en un predicat minterm tant en la seva forma simple com negat. Un cop s’han identificat els predicats minterm, cal disposar de dues informacions quantitatives que són la selectivitat minterm i la freqüència d’accés. La selectivitat minterm és el nombre de tuples accedides de la relació per una petició donada a partir del predicat minterm. La freqüència d’accés és la freqüència en què les aplicacions accedeixen a les dades. En el cas d’una petició qi, acc(qi) és igual a la freqüència d’accés de la petició qi en un període de temps prefixat.

Fragmentació horitzontal primària

Un fragment horitzontal Ri de la relació R es defineix com el conjunt de tuples d’R que satisfan el predicat minterm mi. Per tant, cal trobar els predicats minterms que permetin definir el procés de fragmentació horitzontal. Aquest procés el podem dividir en tres fases que són: Obtenció d’un conjunt de predicats simples mínim i complet Pr’ A partir del conjunt de predicats simples s’ha de verificar que aquest sigui complert. On un conjunt de predicats simples Pr és complet si la probabilitat d’accés de totes les aplicacions a un fragment és aproximadament la mateixa. La propietat que el conjunt de predicats simples és mínim es compleix si cada predicat simple pij és rellevant. On pij és rellevant si almenys hi ha aplicacions que hi accedeixen de forma diferent, o sigui, si alguna aplicació hi guanya pel fet que estigui fragmentada la relació. Si hi ha dos predicats minterm mi i mj que són idèntics en la seva definició, però mi conté l’atribut simple pi i mj conté l’atribut simple ¬pi i Fi és un fragment definit a partir de mi i Fj és un altre fragment definit a partir de mj, es pot afirmar que pi és rellevant si:

95

Llavors inicialment s’ha d’obtenir el conjunt de predicats simples que sigui mínim i complet (Pr’). Si tenim un conjunt de peticions Q que utilitzen la relació Productes i que utilitzen els predicats simples mínim i complet Pr’={p1,p2} definits com: A continuació es detalla el procés per a l’obtenció del conjunt Pr’ Obtenció d’un conjunt de predicats minterm a partir de Pr’ A partir del conjunt de predicats Pr’ s’ha d’obtenir un conjunt inicial M amb tots els possibles predicats minterm. Aquests s’obtenen a partir de la definició: Un problema del conjunt M és que conté totes les possibles combinacions de predicats simples, cosa que no garanteix que aquests siguin consistents. Per aquest motiu, a la següent fase es redueix aquest conjunt. Seguint l’exemple de l’apartat anterior, alguns elements del conjunt M poden ser: Eliminar els predicats minterm de Pr’ que són inconsistents Un cop es té el conjunt M, s’ha de definir un conjunt d’implicacions I relatives a tots els predicats simples. L’objectiu del conjunt I és que permet treure tots els predicats minterms inconsistents del conjunt Pr. Hi ha dos tipus diferents d’implicacions que són les pròpies relatives a la semàntica de la base de dades i les implicacions bàsiques, que poden ser:

96

Si s’apliquen el conjunt d’implicacions I a Pr’ es veu que els predicats minterm m1 i m4 són inconsistents, amb la qual cosa es pot simplificar M quedant de forma:

M={m2,m3} Llavors, un cop s’obté el conjunt M amb els predicats minterm consistents, aquests defineixen directament el predicat que permet la construcció dels fragments horitzontals de les diferents relacions. A l’exemple anterior, la relació Productes es fragmenta en dos fragments de forma:

Validació del procés de fragmentació horitzontal primària: Un cop s’ha fragmentat en horitzontal una relació, cal validar que aquest procés garanteix les propietats de Complitud, Disjunció i Reconstrucció. Propietat de Complitud. Aquesta es compleix, ja que es pot assegurar que una tupla de la relació inicial està en algun fragment. Això és així ja que els predicats minterms són consistents I en ells intervenen tots els predicats simples, amb la qual cosa es pot garantir que no hi ha pèrdua d’informació en el procés de fragmentació. Propietat de Disjunció. Com els predicats minterms que formen el conjunt M s’exclouen mútuament, es pot garantir que una tupla de la relació original només està en un sol fragment. Propietat de Reconstrucció. Aquesta propietat es garanteix amb l’operador d’unió de tots els n fragments de forma:

Fragmentació horitzontal derivada

La fragmentació horitzontal derivada es defineix en una relació member d’un link del model de dades. En aquest cas, l’atribut utilitzat per a la creació del fragment és el de la relació owner. D’aquesta forma s’aconsegueix fragmentar una relació a partir d’un atribut d’un altra relació. Si la relació owner és S i la relació member és la relació R, aquesta es fragmenta de forma:

Per tant, el procés de fragmentació horitzontal derivada es crea a partir dels links que hi ha en el model de dades o GCS. Es pot donar el cas que una relació sigui member de més d’un link. Llavors, s’ha d’escollir el link més utilitzat o aquell que facilita l’execució de joins o bé aquell que s’utilitza per més aplicacions. El procés de validació de la fragmentació horitzontal derivada és similar a l’emprat en la fragmentació horitzontal primària. La propietat de Complitud es manté. Es pot

97

assegurar que una tupla de la relació sense fragmentar està en un fragment, ja que en fragmentar-se aquesta a partir d’una operació de semijoin sobre un conjunt de fragments que són complerts, els fragments obtinguts també són complerts. Tanmateix, com que els fragments són disjunts, també és compleix la propietat de Disjunció. La propietat de Reconstrucció també es compleix, ja que:

En aquest cas, com que les tuples que estan en un fragment no poden estar en un altre fragment, i no hi ha pèrdua de tuples en el procés de fragmentació, llavors, la unió de tots els fragments dóna la relació original.

[Tamer1999] p112-131

RESUM En aquesta sessió s’han estudiat les tècniques de fragmentació horitzontal primària i derivada.

99

SESSIÓ 16 Nom: Models de cost i ubicació. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la quarta sessió del capítol de disseny de gestors distribuïts. A la resta de sessions del capítol s’han estudiat les estratègies de disseny de gestors distribuïts. S’han estudiat les tècniques de fragmentació horitzontal i vertical.

OBJECTIUS En aquesta sessió s’estudia el procés d’ubicació de les relacions i fragments que són el resultat del disseny del sistema.

CONTINGUTS En aquesta sessió es tracta la problemàtica del procés d’ubicació de les relacions i fragments del sistema. Per fer-ho cal construir un model de cost del sistema i llavors cercar una bona solució d’ubicació.

3.4. Models de cost i ubicació En aquest tema s’estudia el procés d’ubicació de les relacions i fragments del sistema.

Ubicació

Un cop s’han obtingut els fragments de les diferents relacions, cal decidir els nodes en què aquests s’ubiquen. A continuació es presenta un model que permet decidir la ubicació d’un fragment. La notació utilitzada és:

= És el nombre de cops que el node i executa peticions que consulten el fragment F.

= És el nombre de cops que el node i executa peticions que modifiquen el fragment F.

si el fragment F està ubicat en el node i. Si el fragment F no està ubicat en el node i llavors val 0.

100

= És el cost de comunicació que hi ha entre el node i i el node j associat a una operació de consulta.

= És el cost de comunicació que hi ha entre el node i i el node j associat a una operació de modificació.

= És el tràfic de bytes que hi ha associat a una operació de modificació. = És el tràfic de bytes que hi ha associat a una operació de modificació. = És el cost de memorització del fragment F en el node j.

Segons aquesta notació, es pot trobar la ubicació d’un fragment minimitzant la funció següent:

Si s’analitza la funció anterior, aquesta està formada per dos termes. El primer terme dóna el cost de memorització o STO (Storage) del fragment. Aquest cost és igual a la suma de costos de memorització de tots els nodes. El segon terme dóna el cost de comunicació associat a l’execució de peticions que consulten o modifiquen el fragment F. Aquest cost es calcula per a tots els nodes que poden originar les peticions sobre tota la resta de nodes. El cost de consulta és igual al cost mínim de comunicació amb un node que tingui el fragment, ja que no cal fer l’operació sobre tots els nodes. En el cas d’una operació de modificació, és la suma del cost per a tots els nodes que tenen el fragment. Aquest model permet avaluar el cost associat a la ubicació d’un fragment F en el sistema. Per tant, cal anar avaluant diferents alternatives i escollir aquella en què el valor de COST sigui més petit. Ara bé, aquest model resol el problema de forma parcial, ja que no té en compte els aspectes següents: 1.- Només tracta la problemàtica de la ubicació d’un sol fragment. 2.- No es contempla la possible relació que hi ha entre els diferents fragments. 3.- No es contempla el cost associat a la gestió de la integritat de la informació i de la càrrega associada al control de concurrència. 4.- No té en compte el cost de processament de les peticions, ni el cost d’entrada/sortida.

101

Per tant, a continuació es presenta un model de cost més complert per tal de resoldre la problemàtica de la ubicació d’un conjunt de fragments. La notació utilitzada és: seli(Fj). És el nombre de tuples que retorna la petició qi en accedir al fragment Fj . size(Fj). És la mida en bytes del fragment Fj. long(Fj). És la mida en bytes d’una tupla del fragment Fj. Rrij. És el nombre de planes que accedeix la petició qi al fragment Fj per resoldre una operació de consulta. URij. És el nombre de planes que accedeix la petició qi al fragment Fj per resoldre una operació de modificació. rij. Adopta el valor 1 si la petició qi accedeix per lectura al fragment Fj. En cas contrari adopta el valor zero. uij. Adopta el valor 1 si la petició qi accedeix per escriptura al fragment Fj. En cas contrari adopta el valor zero. RM. És la matriu que per a totes les peticions i fragments inclou rij. UM. És la matriu que per a totes les peticions i fragments inclou uij. o(i). És el node que origina la petició qi. USCk. És el cost unitari per byte de memorització STO del node k. LPCk. És el cost unitari de procés del node k. gij. És el cost de comunicació d’enviar una trama del node i al node j. fsize. És la mida en bytes d’una trama. xjk. Adopta el valor 1 si el fragment F j està ubicat en el node k. En cas contrari adopta el valor zero. A partir de la notació detallada, a continuació hi ha el model de cost associat al procés d’ubicació. Aquest és: Segons aquest model, el cost total TOC és igual a la suma del cost de procés i el cost de memorització. El cost de memorització és igual a:

102

És igual a la suma de costos per a tots els nodes del sistema i per a tots els fragments que tenen aquests nodes. En aquest cas, STCjk és el cost de memorització del fragment Fj en el node k i és igual al producte del cost de memorització del node k (USCk) amb la mida del fragment Fjj si el node k té el fragment Fj, tal com indica xjk. El cost de procés és igual a: O sigui, és igual a la suma del cost de procés associat a cada petició (QPCi) per a totes les peticions Q que pot rebre el sistema. Llavors, el cost de procés associat a una petició qi és igual a: Aquest és igual a la suma del cost de procés de la petició (PCi) més el cost de comunicació associat a l’execució de la petició qi que és TCi. El cost de procés PCi és igual a la suma del cost d’execució ACi amb el cost associat al procés de manteniment de la integritat referencial IEi i el cost de control de concurrència Cci.

A continuació es detalla el cost d’execució ACi. El cost IE i CC es pot obtenir seguint el mateix procediment que el seguit per obtenir el cost AC.

El cost d’execució Aci s’obté calculant la suma de costos associats a cada node que té un fragment que es modifica o consulta per la petició qi a LPCk és el cost d’execució associat al node k. El cost de comunicació TCii és igual a la suma del cost associat al procés de modificació TCUi amb el cost del procés de consulta TCRi. Llavors:

103

El primer terme del cost TCUi es refereix al cost de comunicació associat al procés d’enviar una trama amb la petició de modificació, i el segon terme al cost associat a la trama que informa que s’ha fet l’operació de modificació. El cost associat al procés de consulta és:

El cost final és la suma dels costos per a tots els fragments. El cost del procés de consulta d’un fragment és el mínim de tots els possibles costos en els diferents nodes. Aquest només s’ha de contemplar en els nodes que tenen el fragment que s’ha de consultar. El cost TCRi té en compte el cost de comunicació associat al procés de fer la consulta més el cost associat al procés de comunicació amb el resultat de l’execució de la petició de consulta. Llavors, amb la funció de cost TOC es coneix el cost associat a la ubicació d’un conjunt de fragments. Ara bé, per tal que la solució proposada sigui implementable en el sistema que es disposa, cal que aquesta compleixi un conjunt de requeriments o restriccions. Aquestes es poden resumir en tres que són: 1.- El temps d’execució de cada una de les peticions qi sempre ha de ser més petit que una constant definida pel sistema. 2.- La capacitat de memorització de cada node k sempre ha de ser més gran o igual que:

3.- El cost d’execució de cada petició qi en un node sempre ha de ser més petit que la capacitat de procés del node. Si la proposta de millor ubicació compleix aquestes tres restriccions, llavors la solució és factible i implementable.

[Tamer1999] p147-p155

RESUM En aquesta sessió s’ha estudiat el procés d’ubicació de les relacions i fragments del sistema. S’ha vist com es construeix un model de cost del sistema i llavors cercar una bona solució d’ubicació.

105

SESSIÓ 17 Nom: Exercicis. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la darrera sessió del capítol de disseny de gestors distribuïts. A la resta de sessions del capítol s’han estudiat les tècniques de disseny dels sistemes gestors distribuïts.

OBJECTIUS En aquesta sessió es resolen exercicis de disseny.

CONTINGUTS En aquesta sessió es resolen exercicis de disseny de sistemes gestors distribuïts.

3.5. Exercicis

Cost d’ubicació

Es resol un exercici on a partir d’un disseny s’ha de calcular el cost d’execució de dues peticions. Disposem d’un sistema format per quatre nodes i que executa dues peticions q1 i q2. La ubicació dels fragments en els nodes del sistema és:

106

Les peticions que s’executen són: I les dades conegudes del sistema són Ens demanen el cost d’execució de les peticions q1 i q2. SOLUCIÓ A partir dels valors d’acc es pot observar que totes les operacions són distribuïdes, ja que s'origina l'execució de la petició q1 en els nodes que no tenen la relació que fa servir R, i passa exactament el mateix amb la petició q2 i S. El cost de la petició q1 és: Cost(q1 en el node 3)= 2 * 5 * ( 10 + 10K + 10 * ( 50 * 5K / 1K ) ) = 10 * 12K5 = 125K Cost(q1 en el node 4)= 2 * 15 * ( 10 + 10K + 10 * ( 50 * 5K / 1K ) ) = 30 * 12K5 = 375K Cost(q1)= 125K + 375K = 500K Els valors 5 i 15 són les acc de la petició q1 en els nodes 3 i 4 respectivament. Aquestes estan multiplicades per 2, ja que per executar la petició originada en un node, aquesta s'envia als dos nodes que tenen els fragments. Això es pot fer així ja que el cost d'execució en els dos fragments és el mateix. El cost de la petició q2 és: Cost(q2 en el node 1)= 2 * 10 * ( 10 + 1K + 10 * ( 20 * 1K / 1K ) ) = 20 * 1K2 = 24K Cost(q2 en el node 2)= 2 * 20 * ( 10 + 1K + 10 * ( 20 * 1K / 1K ) ) = 40 * 1K2 = 48K Cost(q2)= 24K + 48K = 72K En aquest cas els valors d’acc són 10 i 20 i també es multiplica el cost d'execució sobre un fragment per 2, ja que el cost d'execució a l'altre fragment és el mateix.

107

Ubicació i nivell de replicació

Tenim un sistema amb tres nodes i es vol analitzar la ubicació d’una relació R. Hi ha tres peticions que fan servir R i amb una accessibilitat igual a: Sabem que IOR=IOW=1, COM=10, fsize=1K, card(R)=1K, card(dom(pais))=4, long(R)=100 i la relació R no té cap índex. Ens demanen:

1) El nivell de replicació d’R i la seva ubicació per a la millor solució. 2) El cost de les diferents opcions d’ubicació i nivells de replicació analitzats.

SOLUCIÓ Es contemplen tres casos, un per cada nivell de replicació. Inicialment es busca la millor opció d'ubicació sense replicació, després amb un nivell de replicació i finalment amb dos nivells de replicació o replicació total.

Disseny sense replicació

El cost de consulta RC i modificació UC locals de les diferents peticions és: RC(q1)= 1K RC(q3)= 1K UC(q2)= 100 I amb el cas d'operacions distribuïdes, el cost és: RC(q1)= 10 + 1K + 10 * (1K * 100 / 1K) = 2K RC(q3)= 10 + 1K + 10 * (250 * 100 / 1K) = 1260 UC(q2) = 10 + 10 + 100 = 120 El cost de les peticions és: Ubicació d’R en el node 1. Cost(q1, R node 1)= 25 * 1K + 10 * 2K = 45K Cost(q2, R node 1)= 10 * 100 + 20 * 120 = 3K4 Cost(q3, R node 1)= 30 * 1K + 10 * 1260 = 42K6 Cost(R node 1)= 45K + 3K4 + 42K6 = 91K Ubicació d’R en el node 2. Cost(q1, R node 2) = 5 * 1K + 30 * 2K = 65K Cost(q2, R node 2) = 10 * + 20 * 120 = 3K4 Cost(q3, R node 2) = 5 * 1K + 35 * 1260 = 49K1 Cost(R node 2)= 65K + 3K4 + 49K1 = 117K5

108

Ubicació d’R en el node 3. Com que les acc del node 2 i 3 són les mateixes, el Cost(R node 3)=Cost(R node 2)=117K5 Per tant, la millor solució és ubicar R al node 1 amb un cost de 91K.

Disseny amb un nivell de replicació

El cost de les peticions és: R amb ubicació als nodes 1 i 2. Cost(q1, R als nodes 1 i 2) = 30 * 1K + 5 * 2K = 40K Cost(q2, R als nodes 1 i 2) = 20 * ( 100 + 120 ) + 10 * 240 = 6K8 El terme ( 100 + 120 ) es refereix al cost d'execució d'una operació de modificació local i un altra de distribuïda. Amb el cas de dues operacions distribuïdes el seu cost és igual a 240. Cost(q3, R als nodes 1 i 2) = 35 * 1K + 5 * 1260 = 41K3 Cost(R amb ubicació als nodes 1 i 2)= 40K + 6K8 + 41K3 = 88K1 R amb ubicació als nodes 1 i 3. Com que els valors d'acc del node 2 i del node 3 són iguals, llavors: Cost(R amb ubicació als nodes 1 i 2)=Cost(R amb ubicació als nodes 1 i 3) En aquest cas com que el cost és el mateix per les dues opcions, és igual a: Cost(R amb ubicació als nodes 1 i 2)=Cost(R amb ubicació als nodes 1 i 3)= 88K1

Disseny amb replicació total

Cost(q1, R totalment replicada) = 35 * 1K = 35K Cost(q2, R totalment replicada) = 30 * ( 100 + 2 * 120 ) = 30 * 340 = 10K2 En aquest cas el valor 100 es refereix al cost local i el (2 * 120) a les dues operacions distribuïdes amb cost 120. Cost(q3, R totalment replicada) = 40 * 1K = 40K Cost amb Replicació Total = 35K + 10K2 + 40K = 85K2. Es pot concloure que la millor solució és un disseny amb replicació total i amb un cost de 85.200.

RESUM En aquesta sessió s’han resolt dos exercicis de disseny, de càlcul de cost d’execució de peticions i de disseny d’ubicació i nivell de replicació.

109

SESSIÓ 18 Nom: Introducció al processament de peticions Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:

o Bibliografia bàsica: [Tamer1999] [Abdel1998] [Kim1995] [Bell1992] [Lu1994]

PRECEDENTS Aquesta és la primera sessió del capítol de processament de peticions. En aquest capítol s’estudien les tècniques bàsiques que utilitzen els sistemes gestors per a executar les peticions.

OBJECTIUS En aquesta sessió s’introdueixen els conceptes bàsics referents al processament de peticions.

CONTINGUTS En aquesta sessió es tracten els primers apartats del capítol de processament de peticions. Es comença amb una introducció a la problemàtica del processament de peticions i es justifica aquesta com un dels aspectes que més afecten el rendiment dels sistemes gestors.

4. Processament de peticions

4.1. Introducció En aquest tema s’introdueix la problemàtica del processament de peticions i es veu com aquesta pot afectar d’una forma molt important el rendiment del sistema gestor.

Conversió SQL a estratègia d’execució

El subllenguatge d’accés a la informació que hi ha a la BD és l’SQL. Aquest és un llenguatge no processual i s’ha convertit en un estàndard. Ara bé, el sistema gestor ha de convertir les sentències SQL a estratègies d’execució. Aquest procés de conversió no és directe, ja que ha de generar una estratègia òptima.

110

De fet, per cada petició SQL hi ha moltes estratègies possibles d’execució i el sistema ha de poder valorar quina n’és la millor. Un problema afegit és que en aquest procés d’optimització s’ha d’incloure la ubicació i localització de les relacions i fragments que intervenen en la petició. El procés de conversió d’SQL a una estratègia d’execució pot ser computacionalment molt costós. Per aquest motiu, no es poden contemplar totes les possibles estratègies d’execució i per tant, s’han d’aplicar heurístiques que redueixin l’espai de cerca inicial. Un cop el sistema disposa d’un conjunt de possibles estratègies d’execució, les valora mitjançant un model de cost i escull aquella que té un cost d’execució mínim. El model de cost aplicat està en funció de:

COST= f(CPU, IO, COM, STO)

CPU és el cost del processador, IO és el cost d’entrada/sortida, COM és el cost de comunicació o xarxa i STO és el cost de memorització. Llavors, en funció del sistema, algun d’aquests costos no es contemplem, ja que són molt petits respecte la resta de costos. Un model força utilitzat és el que només contempla el cost de comunicació COM, ja que el considera predominant. Per tot això, el principal objectiu és la transformació les peticions que rep amb càlcul relacional en una estratègia d’execució òptima. L’estratègia d’execució s’especifica amb una extensió d’àlgebra relacional amb operacions de comunicació per tal d’enviar els objectes entre els nodes del sistema gestor. Un aspecte important en el processament de peticions és l’optimització de les peticions. Aquest es fa convertint la petició inicial a àlgebra relacional i seguidament a l’estratègia d’execució. Com que hi ha moltes estratègies que es corresponen a la petició original, en aplicar un model de cost que permeti avaluar les diferents alternatives i així escollir la més òptima. En aquest cost, el cost de comunicació acostuma a ser el predominant. Ara bé, un aspecte important en els sistemes gestors distribuïts és el temps d’execució de les peticions. Si per generar l’estratègia final d’execució només es contempla el cost d’execució això no assegura que això minimitzi el seu temps d’execució. El fet que l’estratègia “gasti” pocs recursos del sistema pot provocar que el seu temps d’execució sigui molt gran. En canvi, es pot trobar que l’estratègia d’execució més ràpida sigui una de les estratègies que consumeix més recursos del sistema i per tant que tingui un cost d’execució molt gran. Cal arribar a un compromís a l’hora d’escollir la millor estratègia, tant des del punt de vista de recursos o cost com del seu temps d’execució. És doncs un dels principals objectius del processament de peticions la construcció dels models que ho permetin avaluar així com aplicar-los correctament en el moment de l’optimització.

111

Exemple d’obtenció d’una estratègia d’execució

Es disposa de l’esquema d’una base de dades amb dues relacions que són: TRE(codi, nom, carrec) TAS(codi, proj, resp, durada) I ens demanen el nom dels treballadors (TRE.nom) que són directors (DIR) d’algun projecte. La petició SQL que ha de retornar aquesta informació és: select nom from tre, tas where tre.codi = tas.codi and tas.resp = ‘dir’

Aquesta petició es converteix inicialment a àlgebra relacional i en podem destacar dues: 1.- )))(..''(( TASTREcoditascoditreDIRrespnom ×=∧=∏ σ 2.- )))''((( TASDIRrespcodiTREnom =∏ σ>< En aquest cas es veu que la segona expressió és més òptima, ja que no parteix del producte cartesià de les relacions TRE i TAS, cosa que penalitza molt el seu rendiment. Però amb això no és suficient, ja que l’expressió d’àlgebra relacional no és directament l’estratègia d’execució. Cal donar l’ordre de les operacions bàsiques d’execució i especificar la ubicació de les relacions i fragments que intervenen en la petició. El disseny de les relacions TRE i TAS és: Es disposa de les informacions del sistema següents: Ubicació(TRE1)=3, ubicació(TRE2)=4, ubicació(TAS1)=1, ubicació(TAS2)=2, card(TRE)=400, card(TAS)=1K i COM= 10 * IO. Hi ha un total de 20 directors diferents i el node que sol·licita la petició és el node 5. A partir de la informació anterior es poden generar moltes estratègies. A continuació en comentem tres i es valora el seu cost.

1) Estratègia sèrie.

112

El seu cost és COM = 400 * 10 + 1000 * 10 + 1000 * 1 + 20 * 400 * 1 = 23000

2) Estratègia paral·lela.

El seu cost és COM = 1000 * 1 + 20 * 10 + 2 * ( 200 * 10 ) + 20 * 10= 5400

3) Estratègia distribuïda.

El seu cost és COM = 200 * 10 + 500 * 10 + 1000 * 1 + 20 * 10 + 20 * 400 * 1 + 20 * 10 = 16400

En aquest cas, la segona estratègia és millor que les altres dues, ja que el seu cost total d'execució és de 5400 unitats. Ara bé, també es pot fer una anàlisi del temps d'execució de les diferents estratègies. A continuació es poden observar les diferències en el temps d'execució de les tres estratègies.

113

Segons això l'estratègia que utilitza menys recursos és la segona (5400) i la més ràpida també ho és la segona (2700). Ara bé, si comparem la primera i la tercera estratègia es pot veure que la primera estratègia gasta més recursos que la tercera, però en canvi és més ràpida.

En aquest procés es pot observar que hi ha operacions que són més complexes que d’altres, i que això afecta de forma considerable el cost d’execució de la petició. El factor predominant en la complexitat és la cardinalitat de les relacions i que es representa per la variable n. La complexitat d’aquestes operacions és:

1. Selecció o projecció sense eliminar duplicats. O(n) 2. Selecció, projecció o agrupació eliminant duplicats. O(n · log n) 3. Join, semijoin o divisió. O(n · log n) 4. Producte cartesià. O(n2)

Segons la complexitat de les operacions anteriors, quan l’optimitzador ha de generar una estratègia, sempre ha d’intentar minimitzar les cardinalitats de les relacions, ja que així està minimitzant el cost d’execució en les fases següents.

114

Llavors, una estratègia força utilitzada és la de posar les operacions que tenen una complexitat més petita al principi de l’estratègia. D’aquesta forma s’aconsegueix minimitzar el nombre de tuples de les relacions amb un cost mínim. És per aquest motiu que els optimitzadors ordenen les operacions en funció de la seva complexitat i a partir d’aquest ordre van generant l’estratègia d’execució. Ara bé, hi ha molts més factors que afecten el disseny de l’optimitzador, i per tant el seu rendiment, però en podríem destacar tres, i que són:

1) Tipus d’optimització. Hi ha dos diferents mètodes per la generació del conjunt d’estratègies que cal avaluar. Aquests són: Força bruta o amb Heurístiques.

Força bruta. Es construeixen totes les possibles estratègies d’execució i es calcula el cost de totes. Llavors s’escull l’estratègia amb el cost mínim. El principal problema d’aquesta solució és que s’han d’avaluar molts casos i per tant el cost d’avaluació pot ser molt gran.

Heurístiques. S’apliquen heurístiques per tal de reduir l’espai de cerca i així minimitzar les estratègies a avaluar. Algunes d’aquestes heurístiques poden ser: Minimitzar la cardinalitat de les relacions intermèdies, executar primer les operacions algebraiques unàries i després les binàries, o bé substituir les operacions de Join per operacions equivalents amb SemiJoin.

2) Moment de l’optimització.

Hi ha dos tipus diferents d’optimitzadors: Estàtics i Dinàmics.

Estàtics. Un optimitzador és estàtic si genera l’estratègia d’execució directament i sense executar cap tipus d’operació amb anterioritat.

Dinàmics. Un optimitzador és dinàmic si aquest va generant l’estratègia d’execució a mesura que va executant les operacions de l’estratègia.

3) Nodes de decisió.

Es tracta de decidir si l’estratègia la genera un sol node o bé si aquesta es construeix de forma distribuïda per un conjunt de nodes.

[Tamer1999] p188-p198

[Bell1992] p122-p130

[Lu1994] p289-p299

[Abdel1998] p28-p130

[Kim1995] p501-p502

115

RESUM En aquesta sessió s’han introduït els conceptes bàsics referents al processament de peticions.

117

SESSIÓ 19 Nom: Nivells en el processament de peticions Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la segona sessió del capítol de processament de peticions. A la primera sessió s’han estudiat les tècniques bàsiques que utilitzen els sistemes gestors per a executar les peticions i en aquesta sessió s’analitzen els nivells en el processament de les peticions.

OBJECTIUS En aquesta sessió s’estudia amb detall el procés que segueix el gestor per tal d’obtenir l’estratègia d’execució a partir d’una petició amb càlcul relacional.

CONTINGUTS El procés de generació de les estratègies d’execució es divideix a partir d’un conjunt de nivells que són: Descomposició de la petició, Localització de les dades, Optimització global i Optimització local.

4.2. Nivells en el processament de peticions En aquest tema s’estudien els diferents nivells que hi ha en el procés de construcció d’una estratègia d’execució.

Nivells en el processament de peticions

El procés de generació d’una estratègia d’execució es resol en diferents fases que són: Descomposició de la petició, Localització de les dades, Optimització global i Optimització local. A continuació es detalla el funcionament de cada una d’aquestes fases.

1) Descomposició de la petició. Es converteix la petició en càlcul relacional a àlgebra relacional. Per fer-ho accedeix a l’esquema global conceptual.

2) Localització de les dades. A partir de les relacions que hi ha a l’expressió

amb àlgebra relacional es substitueixen les relacions pels seus fragments i la seva ubicació.

118

3) Optimització global. Es genera l’estratègia a partir de l’expressió d’àlgebra

relacional obtinguda a la fase de localització de les dades.

4) Optimització local. Un cop s’ha generat l’estratègia global, aquesta s’executa i coordina a partir d’un monitor d’execució. Llavors, quan un node rep una operació simple a executar fa una optimització local d’aquesta.

Descomposició de la petició

El procés de descomposició de peticions es divideix en quatre fases: Normalització, Anàlisi, Eliminar redundàncies i Reescriptura. A continuació es detalla el funcionament del sistema segons aquestes quatre fases. Normalització. En aquesta fase es transforma l’operació de selecció que inclou la petició. Amb SQL aquesta sempre està a continuació del where. El procés de transformació la converteix a forma conjuntiva, ja que d’aquesta forma, es facilita la seva avaluació per part del sistema gestor. Com que interessa conèixer amb un cost mínim si una tupla analitzada de la relació està en el resultat, i com que també sabem que el factor de selectivitat de les operacions de selecció és petit, ens interessa conèixer com abans millor si el predicat és fals. Per tant, si aquest està en forma conjuntiva millor, ja que si un terme és fals, el predicat és fals i no cal seguir avaluant la resta de predicats, cosa que no passaria si el predicat està en forma disjuntiva. Llavors, caldrà sempre convertir el predicat d’entrada a forma conjuntiva. Per fer-ho cal emprar les regles d’equivalència següents:

Anàlisi. En aquesta fase s’eliminen les peticions semànticament incorrectes. Per tant, no hi ha cap tipus de transformació, ja que només retorna si la petició és correcta o bé si no ho és. Hi ha diferents motius pels que es pot rebutjar una petició. A continuació es detallen algun d’aquests:

1.- Atributs que no pertanyin a cap relació de la petició. 2.- Relacions que no estiguin en l’esquema o GCS de la base de dades. 3.- Operacions inconsistents amb els operands. 4.- Existència d’elements que no contribueixen a l’obtenció del resultat.

119

Eliminar redundàncies. En aquesta fase es transforma el predicat que hi ha a la petició per tal de simplificar-la. Aquest procés es fa mitjançant la utilització de les regles d’idempotència següents:

Llavors s’aconsegueix reduir el predicat que acompanya l’operació de selecció o where de la petició d’entrada. Reescriptura. En aquesta fase la petició ja està normalitzada, no té cap tipus de redundància i és semànticament correcta. Llavors es converteix primer a àlgebra relacional AR i a continuació és modifica aquesta per tal de millorar el seu rendiment. El procés de conversió a AR es fa mitjançant un arbre d’àlgebra relacional AAR. En aquest hi ha una fulla per cada relació que hi ha en la petició. El tronc de l’arbre es va construint a partir de la condició de projecció de la petició. Seguidament en el tronc es posen les operacions de selecció per acabar amb les branques finals a partir de les operacions de join. En [Tamer1999] p211,214 hi ha exemples de construcció d’arbres d’àlgebra relacional. Un cop s’ha construït l’AAR es pot modificar per tal de millorar el seu rendiment. Per fer-ho s’utilitzen sis regles que són:

1) Operacions binàries commutatives de producte cartesià, join, unió i intersecció.

2) Operacions binàries associatives.

3) Idempotència de les operacions unàries. Respecte la Projecció, es poden agrupar i separar les projeccions successives.

120

Respecte l’operació de Selecció, una doble selecció sempre és equivalent a la intersecció de les dues seleccions.

4) Commutació de la selecció amb la projecció.

5) Commutació de la selecció amb les operacions binàries.

6) Commutació de la projecció amb les operacions binàries. Amb el producte

cartesià tenim que:

En aquest cas és un subconjunt dels atributs A i B’ és un subconjunt dels atributs B. On A són els atributs de la relació R i B els atributs de la relació S.

També es pot aplicar de forma similar amb el Join i la Unió. Aquestes són:

O bé:

Un cop s’han seguit les quatre fases del procés es disposa d’un arbre d’àlgebra relacional correcte i mínimament optimitzat. A partir d’aquest AAR cal generar una estratègia optimitzada, ja que encara falta substituir les relacions pels seus fragments, afegir la informació relativa als nodes on estan ubicades les relacions i els fragments i finalment decidir una estratègia optimitzada a partir de tot el conjunt possible. A l’apartat següent s’indica com fer tot aquest procés.

Localització de les dades

A partir de l’AAR s’han de substituir les relacions pels seus fragments. Evidentment, si hi ha relacions no fragmentades, aquestes no s’han de modificar. Un cop fet aquest procés s’obté un arbre genèric AG. El procés de construcció de l’AG es fa segons el tipus de fragmentació que hi ha a cada relació. Llavors es presenten quatre situacions diferents que són:

1) No hi ha fragmentació.

121

En aquest cas no cal fer res i deixar la relació com està.

2) Fragmentació Horitzontal. Primer es substitueix la relació per la Unió dels diferents fragments. A continuació s’eliminen els fragments que no aporten cap informació al resultat. Aquests són els fragments que cap de les seves tuples estan al resultat final. En el cas de les operacions de Join, aquest es pot distribuir pels diferents fragments. Per exemple:

3) Fragmentació Vertical. Primer s’ha de substituir la relació pel Join dels diferents fragments verticals. Llavors, quan hi ha un fragment que no aporta cap atribut al resultat, aquest es pot eliminar i llavors queda l’altre fragment, amb la qual cosa, s’ha simplificat l’AG.

4) Fragmentació Derivada. Per a aquesta situació i després de substituir les relacions pels seus fragments, s’han de trobar els Joins que no retornen res, i llavors aquests es poden eliminar de l’arbre.

Un cop es disposa d’un AG inicial, a continuació només cal especificar la ubicació de les diferents relacions i fragments.

[Tamer1999]p204-p223

RESUM En aquesta sessió s’ha estudiat amb detall el procés que segueix el gestor per tal d’obtenir l’estratègia d’execució a partir d’una petició amb càlcul relacional. Aquest és un procés molt crític, ja que afecta directament el rendiment del sistema gestor. A partir de les tècniques explicades, al següent capítol s’explicaran els principals algorismes o implementacions que basen el seu funcionament en els conceptes explicats en aquesta sessió.

123

SESSIÓ 20 Nom: Exercicis de processament de peticions Tipus: Problemes Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la tercera sessió del capítol de processament de peticions. En aquest capítol s’estudien les tècniques bàsiques que utilitzen els sistemes gestors per a executar les peticions. Això s’ha fet a les dues sessions anteriors i en aquesta sessió es resolen uns exercicis per tal de posar en pràctica els coneixements adquirits.

OBJECTIUS En aquesta sessió es reforça el coneixement dels conceptes relatius al processament de peticions adquirits en les dues sessions anteriors mitjançant la resolució de problemes.

CONTINGUTS En aquesta sessió es realitzen tres d’exercicis relatius al processament de peticions.

Millora d’un arbre d’àlgebra relacional

Es disposa d’un sistema gestor centralitzat que rep una petició i el sistema la converteix en una expressió d’àlgebra relacional AR. Es demana millorar i optimitzar l’expressió d’AR i donar-ho en format d’un arbre d’àlgebra relacional AAR. L’expressió AR és: AR: SOLUCIÓ Inicialment es converteix el Join de la part final de l’arbre. AR1: Si ara es substitueix AR1 a l’expressió AR inicial, s’obté:

124

AR2: I finalment si s’afegeixen les operacions de projecció tenim l’AAR final que és:

Obtenció i optimització d’AG a partir de CR

Es disposa d’un sistema gestor centralitzat que rep una petició q. Cal obtenir l’arbre d’àlgebra relacional òptim que dóna el sistema un cop la petició d’entrada s’ha convertit a AR. La petició q és: Les relacions e, g i j estan fragmentades de forma:

SOLUCIÓ

I finalment l’arbre d’àlgebra relacional optimitzat que s’obté és:

125

Optimització i obtenció AAR

Un sistema gestor distribuït rep una petició q, la converteix a una expressió AR i a continuació l’optimitza obtenint un AAR. Es demana l’arbre AAR que es correspon a la petició q:

L’esquema de les relacions és:

El disseny o nivell de fragmentació de les relacions R i S és:

El node 1 té els fragments R1 i S1, el node 2 R2 i S3, el node 3 R3 i el node 4 té S1. SOLUCIÓ Inicialment es construeix l’arbre d’àlgebra relacional a partir de la petició q. Aquest és:

Si llavors es mouen les operacions de selecció, tenim que:

I si a continuació es substitueixen les relacions R i S pels seus fragments:

126

RESUM En aquesta sessió s’han resolt tres exercicis que han reforçat i posat en pràctica els coneixements adquirits sobre el processament de peticions.

127

SESSIÓ 21 Nom: Algorismes d’execució de joins. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:

o Bibliografia bàsica: [Lu1994]

PRECEDENTS A les sessions anteriors s’han estudiat els conceptes bàsics relatius al processament de peticions.

OBJECTIUS En aquesta sessió s’estudien els algorismes d’execució de joins tant en entorns centralitzats com distribuïts.

CONTINGUTS En aquesta sessió es presenten un conjunt d’algorismes d’execució de joins amb entorns centralitzats i distribuïts.

4.3. Algorismes d’execució de joins En aquest apartat es presenten un conjunt d’algorismes d’execució de joins amb entorns centralitzats.

Algorismes d’execució de joins centralitzats

Tal com hem vist en els temes anteriors, el processament d’una operació de join de dues relacions grans és molt costós. És per tant un factor crític trobar un mètode d’execució que optimitzi al màxim aquest procés. En el cas dels sistemes gestors centralitzats aquest procés és molt crític. L’operació d’EquiJoin és la més utilitzada en els sistemes gestors ja que és la que permet relacionar les diferents relacions del model de dades. En aquest cas, el resultat d’una operació d’EquiJoin entre les relacions R i S i amb els atributs de join r.a i s.b consisteix en les tuples que resulten de la concatenació de les tuples d’R i les tuples d’S amb la condició r.a=s.b. D’entrada per resoldre aquesta operació de join cal comparar cada tupla d’R amb totes les tuples d’S, cosa que és molt costosa. Una manera de minimitzar aquest cost és la d’ubicar una o dues relacions en la memòria del sistema amb la qual cosa és

128

minimitzen les operacions d’entrada/sortida, encara que el nombre de comparacions que s’han de realitzar són les mateixes. El problema rau en les limitacions de memòria dels sistemes actuals, i és per això que cal pensar en algorismes d’execució dels joins que intentin minimitzar el seu cost d’execució. Aquests algorismes es poden classificar en tres grans grups que són:

NestedLoop

És un algorisme que implementa directament la pròpia definició de les operacions de join. La seva resolució es fa a partir de l’aniuament de les operacions de lectura de les dues relacions que hi ha en el join.

Si es vol resoldre l’operació de join ( R join S ), es defineix la relació R com la relació outer i la relació S com la relació inner. Llavors, per cada tupla d’R es fa una lectura de totes les tuples de la relació S i si es compleix la condició r.a=s.b vol dir que les tuples estan en el resultat.

A partir d’aquesta idea hi ha diferents implementacions d’algorismes NestedLoop que són les que es detallen a continuació. Algorisme Nested Loop Basic En aquest algorisme inicialment es fa el producte cartesià de totes les files r d’R per a totes les files d’S i seguidament es verifica la condició del join r.a=s.b. És un algorisme força simple, però té un problema important de rendiment, ja que el nombre d'operacions d'entrada/sortida és gran. Podem dir que el seu cost és:

COST(NestedLoopBasic)= card(R) * card(S) Un algorisme que millora el rendiment de l'execució de l’operació de join és el NestedLoopBlocs.

129

Algorisme Nested Loop Blocs L'algorisme NestedLoopBlocs optimitza la utilització de la memòria disponible del El sistema M és el nombre de planes de memòria disponibles que té el sistema. Per això utilitza (M-1) planes per guardar les tuples d’R i es reserva una plana de memòria per anar posant-hi les tuples d’S. Si no hi cap tota la relació R a memòria, l'algorisme resol el join amb les tuples d’R que estan a memòria i després hi va posant la resta de tuples d’R fins que ha processat tota la relació R. Per tant, com més memòria disponible tingui el sistema, més òptima serà l’execució del join. El cost d'execució és:

COST(NestedLoopBlocs)= NumPage(R) + | NumPage(R) / (M-1) | * NumPage(S) Es pot observar que si la relació R cap tota a memòria, el cost és: COST(NestedLoopBlocs)= NumPage(R) + NumPage(S) Aquest és doncs un bon rendiment, encara que cap de les relacions que intervenen en el join tingui un índex per l'atribut de join. Ara bé, si la relació S té un índex per l'atribut b, generalment l'algorisme Nested Loop Index dóna un rendiment millor. A continuació hi ha aquest algorisme.

130

Algorisme Nested Loop Index En aquest cas la relació R només es llegeix un cop i es llegeixen tantes tuples d'S com tuples hi ha al resultat del join. Per tant, el cost d'execució de l'algorisme NestedLoopIndex és:

COST(NestedLoopIndex)= NumPage(R) + card(R) * card(S) * SF_Join (R,S) Segons els tres algorismes, si el sistema disposa de molta memòria disponible i en aquesta hi cap tota la relació R, l'algorisme NestedLoopBlocs és el millor, ja que el cost és NumPage(R)+NumPage(S) i per tant, no cal posar-hi cap índex a la relació inner S. Ara bé, si la relació R no cap a memòria, l'algorisme NestedLoopIndex té un bon rendiment, sobretot si el factor de selectivitat del join és petit. Evidentment que en aquest darrer cas cal que hi hagi un índex per l'atribut b de la relació S.

SortMerge

Els algorismes SortMerge primer ordenen les dues relacions que intervenen en el join i llavors fan un merge de les tuples que coincideixen segons l’atribut de join de les dues relacions. Evidentment, si alguna de les relacions ja està ordenada per l’atribut de join, el procés d’ordenació no es fa. El procés de merge de les dues relacions comença pel primer parell de tuples de les dues relacions. Es va examinant cada parell de tuples per tal de veure si coincideixen els valors dels atributs de join r.a=s.b i es van avançant de forma seqüencial els punters de lectura de les dues relacions. El principal avantatge d’aquest mètode és que només es llegeix un cop cada una de les relacions, amb la qual cosa es minimitza molt el seu cost d’execució. Ara bé, el principal inconvenient d’aquest tipus d’algorisme és que cal ordenar les dues relacions, cosa que penalitza el seu rendiment.

131

Algorisme Sort Merge Inicialment s'ordenen les relacions R i S pels atributs del join r.a i s.b respectivament. Llavors es van recorrent les relacions buscant els valors iguals de r.a i s.b. En funció del seu valor va avançant els punters de lectura. Aquest procés es finalitza quan s'arriba al final d'alguna de les dues relacions. Quan hi ha dues tuples amb el mateix valor dels atributs a i b aquestes estan en el resultat del join. En aquest cas es va llegint S fins que aquesta condició no és certa o bé s'arriba al final de la relació S. Llavors, es llegeix la fila següent d’R i es repeteix el procés. Ara bé, si el nou valor de l'atribut r.a és igual al seu valor anterior, cal restablir el punter de lectura de la relació S al valor inicial s.cur.b, ja que s'han de treure totes les tuples d’S que compleixen amb la condició del join. Aquest algorisme de SortMerge és força òptim quan les dues relacions tenen un índex per l'atribut de join, ja que així no cal ordenar les relacions i el seu cost d'execució és mínim.

COST(SortMerge) ≈ card(R) + card(S) Si per una tupla d’R hi ha més d'una tupla d'S que esta en el resultat del join, llavors es llegeixen més de card(S) tuples d’S. Ara bé, per principi de localitat, és molt probable

132

que aquestes tuples encara estiguin a memòria, amb la qual cosa llavors sí que podem afirmar que el cost és igual a la suma de cardinalitats de les dues relacions, i per tant:

COST(SortMerge) = card(R) + card(S)

1) Hash. El principal problema dels algorismes NestedLoop i SortMerge és que fan moltes operacions de comparació r.a=s.b. Llavors, quan el factor de selectivitat és baix, moltes de les operacions de comparació no serveixen per a res. Els algorismes de join que utilitzen tècniques de hash intenten aprofitar aquest comportament. Inicialment es parteixen les relacions amb horitzontal a partir d’una funció de hash. Llavors aquestes relacions són disjuntes. O sigui, que el join (Ri join Sj) on i és diferent de j no retorna cap tupla, ja que el hash de l’atribut de join de les tuples de les dues relacions sempre és diferent, i per tant no es pot tractar del mateix valor. És a partir d’aquesta funció de hash que es pot assegurar que: Segons això a continuació s'analitzen quatre algorismes que fan servir tècniques de hash. Aquests són: Basic Hash, Hybrid Hash, Hash Based Nested Loop i Simple Hash.

Algorisme Basic Hash

L'algorisme BasicHash inicialment parteix les relacions R i S en fragments o paquets segons la funció de hash aplicada sobre l'atribut del join. Segons aquest procés de partició, es garanteix que per tots els valors de i diferents de j: (Ri a Join b Sj) no retorna cap tupla, ja que els valors de hash són diferents, i per tant es pot assegurar que r.a ≠ s.b.

133

És per això que l'algorisme fa l’operació de join pels fragments d’R i S que pertanyen al mateix paquet. Llavors es calcula el hash de les tuples s.b i es busquen les tuples d’R que tenen el mateix valor de hash i que compleixen la condició r.a=h.b. Són aquestes tuples les que estan al resultat del join. L'algorisme Basic Hash minimitza el nombre de comparacions r.a=s.b, ja que només ho fa a les tuples que coincideixen en el seu valor de hash. Un cop les relacions estan fragmentades segons la funció de hash, el seu cost es pot aproximar amb:

COST(BasicHash) ≈ 2 * card(R) + card(S) Es pot observar que la relació R es llegeix dos cops, una per crear la taula de hash i després cal tornar-la a llegir per tal d'accedir a les tuples d’R que estan en el resultat final. Aquest cost també es pot aproximar com:

COST(BasicHash) ≈ card(R) + card(S) + card(R) * card(S) * SFJoin (R,S) El primer terme card(R) és el cost per crear la taula de hash, el segon terme card(S) és el cost de lectura seqüencial de la relació S i el darrer terme és el nombre de tuples llegides d’R que es pot aproximar al nombre de tuples del resultat del join card(R) * card(S) * SF Join (R,S).

Algorisme Hybrid Hash

En aquest algorisme es parteixen les relacions R i S en blocs a partir de la funció de hash. El que s'intenta és que els fragments R0 i S0 siguin el més grans possibles, ja que aquests són els que es posen a memòria i així el seu cost de lectura és mínim. Les tuples que no caben a R0 i S0 es guarden a disc en fragments, ja que posteriorment sobre aquests blocs s'aplica l'algorisme BasicHash. Si comparem aquest algorisme Hybrid Hash amb l'anterior BasicHash es pot observar amb el cost de creació dels fragments, com R0 i S0 ja es guarden a memòria, després no els caldrà tornar a llegir de disc.

134

Si no es contempla el cost de creació dels fragments, el cost d'aquest algorisme es pot aproximar amb:

COST(HybridHash) ≈ 2 * card(R') + card(S') On R'= R - R0 i S'=S - S0, ja que el join dels fragments R0 i S0 ja s'ha resolt el la fase de partició de les relacions inicials R i S. Es pot observar que la relació R' es llegeix dos cops, una per crear la taula de hash i després cal tornar-la a llegir per tal d'accedir a les tuples de R' que estan en el resultat final. Aquest cost també es pot aproximar com: COST(HybridHash) ≈ card(R') + card(S') + card(R') * card(S') * SF Join (R',S') En aquest cost s'aproxima el nombre total de tuples llegides amb el nombre de tuples del resultat de l'execució del join.

135

Algorisme Hash Based Nested Loop

El cost aproximat d’aquest algorisme és:

COST(HashBasedNestedLoop)=NumPage(R) + | NumPage(R) / (M-2) | * NumPage(S)

Per tant, aquest algorisme millora molt el seu rendiment quan hi ha força planes de memòria disponible M, ja que llavors es processa molta informació quan es fa la lectura inicial de les (M-2) planes de la relació R.

Algorisme Simple Hash

Una alternativa als tres algorismes basats en tècniques de hash és el Simple Hash. En aquest algorisme s'intenta minimitzar les operacions de lectura sobre les relacions R i S. Inicialment es fa una selecció de les tuples d’R i S a partir de la definició d'un bloc actual. Com les tuples seleccionades, d’R i S, tenen el mateix hash, a continuació es comprova que compleixin la condició r.a=s.b, de tal forma que si és així es posen al resultat final. Un cop s'han processat totes les tuples del bloc inicial, es torna a repetir el procés amb les tuples que queden a disc i es va repetint el procés fins que no queden tuples d’R per processar.

136

El cost d'execució del join depèn de la grandària del bloc inicial, ja que interessa que aquest sigui gran per tal de minimitzar el seu cost d'execució. Si no contemplem el cost inicial de fragmentació d’R i S (que seria NumPage(R) + NumPage(S)), el cost d'execució del join es pot aproximar amb:

COST(SimpleHash) ≈ k * card(R') + l * card(S') En aquest cas, k i l són el nombre de cops que s'han de llegir les tuples no processades d’R i S respectivament en la fase inicial de l'algorisme.

Algorismes d’execució de joins distribuïts.

En aquest apartat es presenten un conjunt d’algorismes d’execució de joins amb entorns distribuïts. Amb els algorismes detallats a l’apartat anterior el rendiment del sistema es pot incrementar força. Ara bé, un altre mecanisme que permet incrementar el rendiment del sistema s’aconsegueix executant de forma distribuïda les operacions de join mitjançant la utilització de més d’un processador. De forma similar a com ho resolen altres algorismes, aquest procés paral·lel es pot organitzar en tres fases, que són:

1.- Descomposició de l’operació de join en diferents processos. 2.- Assignar aquests processos als processadors disponibles.

137

3.- Integrar els diferents resultats.

Igual que passa en els sistemes gestors centralitzats, hi ha tres tipus diferents d’algorismes que resolen l’operació de join amb tècniques de NestedLoop, SortMerge i Hash.

Nested Loop Distribuït

En aquest cas s'aprofita el disseny fragmentat de les relacions R i/o S. Podem distingir els casos següents:

• R i S estan fragmentades pels atributs r.a i s.b respectivament o bé S està fragmentada en horitzontal derivada respecte R.

Es pot executar en paral·lel el join de forma

• R fragmentada i S no fragmentada

S'envia S a tots els nodes que tenen un fragment Ri i llavors s'executa en tots ells l’operació (Ri Join S) essent el resultat

Però si R està fragmentada per r.a, un altra alternativa seria la de fragmentar S per s.b i llavors enviar cada fragment Si al node que té el fragment Ri per tal d'executar el join en paral·lel.

• R no fragmentada i S fragmentada

S'envia R a tots els nodes que tenen un fragment Si i s'executa en tots ells l’operació (R Join Si) essent el resultat

En aquest cas el cost de comunicació és igual a (n * size(R)).

• R i S fragmentades per qualsevol atribut

En aquest cas cal enviar els fragments d'R o S a tots els nodes. Llavors, el cost de comunicació és igual a (n * min( size(R), size(S)). On n és el nombre de nodes del sistema on cal enviar els fragments. Ara bé, això es pot millorar amb l'algorisme SubsetParallelNestedLoop El cost d'aquest algorisme és igual a:

COST(Subset Parallel Nested Loop)= MapS + size(R.a) + size(R)

que es pot observar que és més petit que la proposta inicial amb cost n * min( size(R), size(S)).

138

Sort Merge Distribuït

En aquests algorismes es pot optimitzar el procés d'ordenació. Ara bé, també es pot millorar molt el rendiment si es distribueix l’operació de Merge de les dues relacions. En aquesta operació de Merge es poden plantejar tres escenaris diferents que són:

• Si R i S estan fragmentades per l'atribut de join El resultat és igual a:

• Si R està ordenada i totalment replicada. S està distribuïda i ordenada per cada fragment. Aquesta distribució d'S es pot fer per qualsevol atribut que no té per què ser l'atribut de join. El resultat és igual a:

• Si S està ordenada i totalment replicada. R està distribuïda i ordenada per cada fragment. Aquesta distribució d'R es pot fer per qualsevol atribut que no té perquè ser l'atribut de join. El resultat és igual a:

139

Hash Distribuït

En aquest cas s'optimitza molt el temps d'execució, ja que com sempre es parteix dels fragments de les relacions R i S construïts a partir d'una funció de hash, el resultat es pot obtindre a partir de l'execució en paral·lel dels diferents join (Ri a Join b Si).

RESUM En aquesta sessió s’han estudiat els algorismes emprats pels sistemes gestors per a l’execució de joins de dues relacions. Primer s’han estudiat les tècniques centralitzades per seguir amb les tècniques emprades per a la seva execució distribuïda.

141

SESSIÓ 22 Nom: Optimització de peticions Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la cinquena sessió del capítol de processament de peticions. En aquest capítol s’estudien les tècniques que utilitzen els sistemes gestors per generar una estratègia d’execució optimitzada.

OBJECTIUS En aquesta sessió s’introdueixen els conceptes bàsics referents a l’optimització de peticions. S’estudien les tècniques emprades pels gestors centralitzats i distribuïts així com els algorismes que aquests utilitzen.

CONTINGUTS En aquesta sessió es comença amb una introducció al funcionament bàsic dels optimitzadors de peticions i es segueix amb la construcció del model de sistema que permetrà l’estudi dels processos d’optimització.

4.4. Modelització del sistema En aquest tema s’introdueix l’esquema bàsic de funcionament d’un optimitzador de peticions.

Introducció

Quan el sistema gestor rep una petició amb CR, la converteix a AR per tal que aquesta es pugui optimitzar. El principal problema d’aquesta conversió és que hi ha múltiples expressions amb AR que es corresponen a la de CR inicial. Seguidament, i a partir de la informació del GCS el sistema converteix l’expressió d’AR a un AAR. Aquest procés també té múltiples solucions i per tant, de totes elles cal escollir la més òptima. A les tres sessions anteriors ja hem vist el procés habitual que segueix el sistema gestor per tal d’obtenir una expressió AAR. Llavors, a partir de l’expressió amb l’AAR s’obté l’estratègia final d’execució. Aquesta estratègia d’execució inclou les operacional algebraiques sobre els fragments i les

142

operacions de comunicació que hi ha entre els diferents nodes del sistema. Tal com ja s’ha vist a la sessió anterior, per cada AAR hi ha múltiples estratègies d’execució. Per tant, si el sistema parteix d’una petició amb CR, en tenim n d’AR. Per cada una d’AR en tenim m AAR i llavors per cada AAR k solucions o estratègies d’execució. O sigui, que hi ha un espai de cerca de ( n x m x k ) possibles solucions. El pas següent consisteix a avaluar de totes les possibles solucions i veure quina és millor o té un cost d’execució menor. Per fer-ho es construeix un model de cost del sistema i s’aplica a tot el conjunt de possibles estratègies. D’aquesta forma es pot escollir la millor estratègia de tot el conjunt inicial. Ara bé, aquest procés d’aplicació del model de cost a totes les possibles solucions és molt costós i per tant no es pot aplicar. Per aquest motiu es redueix l’espai de cerca inicial mitjançant heurístiques amb les que s’aconsegueix trobar una estratègia més o menys òptima. Aquestes heurístiques sempre es basen en informació continguda en el diccionari de dades (estadístiques dels fragments i cardinalitats de les relacions). A continuació es presenta el procés que cal seguir per a la construcció d’un model de cost del sistema. L’optimitzador de peticions analitza les diferents alternatives d’estratègies d’execució mitjançant la utilització d’un model del sistema i del seu corresponent model de cost. En aquest tema s’estudia el model bàsic del sistema així com un model de cost genèric. Es presenten els diferents paràmetres que permeten determinar el funcionament de l’optimitzador.

Modelització del sistema

Els models del sistema es poden classificar en dues grans famílies que són: Models de cost o models temporals. Els models de cost donen el cost d’execució d’una estratègia o el que és el mateix, una valoració dels recursos gastats per a la seva execució. En el cas dels models temporals donen el temps d’execució d’una estratègia. En el cas dels sistemes gestors distribuïts, aquests costos no tenen una relació directa, ja que pel fet que una estratègia tingui el cost més petit no implica necessàriament que el seu temps d’execució sigui el millor. Això es veu evident en situacions en què l’estratègia d’execució utilitza recursos dels diferents nodes per tal de minimitzar el seu temps d’execució, ja que s’optimitza el temps però no el cost. És per aquest motiu que sempre cal indicar als optimitzadors de peticions el tipus d’optimització que es vol fer, per cost o per temps. Ara bé, tal com podrem veure als propers temes, hi ha optimitzadors que només disposen d’un model d’optimització per cost. A continuació es presenta un esquema dels dos models del sistema, el de cost i el de temps.

143

Model de cost

COST = Suma de tots els costos que intervenen durant l’estratègia.

Ccpu és el cost de la CPU per executar una instrucció. Cio és el cost d’entrada/sortida o el cost d’accés a disc. Cmsg és el cost d’enviar un missatge o trama i Ctr és el cost d’enviar un byte per la xarxa. El primer terme es pot donar com CPU, el segon com IO i els termes donen el cost de xarxa d’enviar una trama de # bytes i s’especifica com COM.

Model de temps

TEMPS = Temps d’execució d’una estratègia.

En aquest model els costos Ccpu, Cio, Cmsg, Ctr són unitats de temps. El terme seq # instruccions és el nombre màxim d’instruccions requerides per a l’execució del procés. El mateix concepte s’aplica a les operacions d’entrada/sortida i a les operacions de comunicació. Per tal de poder aplicar el model de cost o el model de temps cal disposar d’un conjunt d’informacions que són: Estadístiques relatives a la base de dades i estadístiques per calcular la grandària de les relacions intermèdies. A continuació es detallen aquestes informacions. 1) Estadístiques relatives a la base de dades.

Respecte els atributs de les relacions.

Long(ai)= Longitud en bytes de l’atribut ai.

Card(dom(ai))= Nombre de valors diferents que pot adoptar l’atribut ai.

Card(diferents(Projecció (ai) R))= Nombre de valors diferents de l’atribut ai a R.

Min(ai)= Valor més petit que pot adoptar l’atribut ai.

Max(ai)= Valor més gran que pot adoptar l’atribut ai.

Min(ai,R)=Min(diferents(Projecció (ai) R))= Valor més petit de l’atribut ai a R.

Max(ai,R)=Max(diferents(Projecció (ai) R))= Valor més gran de l’atribut ai a R.

144

Respecte els fragments o relacions.

Card(Rj)= Nombre de tuples del fragment Rj.

Long(Rj)= Longitud en bytes d’una tupla de la relació Rj.

SFJ(R,S)= Factor de selectivitat de join d’R i S = card (R join S) / (card(R) * card(S)

Size (R join S)= card(R) * card(S) * SFJ(R,S) * long(RS).

On long(RS)= long(R) + long(S) – long (atribut de join)

El factor de selectivitat de join de les relacions R i S és SFJ(R,S). Aquest adopta un valor comprés entre 0 i 1 i és el % de tuples del producte cartesià que retorna l’operació de join entre les relacions R i S. Com més proper a zero sigui el seu valor, millor, ja que el nombre de tuples del resultat del join és petit i facilita l’execució de les operacions següents de l’estratègia.

Aquest valor de SFJ(R,S) és molt útil, ja que permet fer estimacions de la grandària de les relacions intermèdies que s’utilitzen en les properes operacions de l’estratègia, i per tant permet escollir la millor alternativa a seguir per a l’estratègia. 2) Estadístiques per calcular la grandària de les relacions intermèdies. Per fer prediccions en la grandària de les relacions intermèdies que s’obtenen durant l’execució de l’estratègia, cal conèixer el valor del factor de selectivitat SF de les diferents operacions. A continuació es detallen els valors que aquests factors de selectivitat poden adoptar.

Llavors, es pot veure que el SFS és el % de tuples de la relació que estan en el resultat després d’executar l’operació de selecció. Si el predicat és simple i del tipus (ai=k), el factor de selectivitat es pot calcular de forma:

Si el predicat és simple i del tipus (ai > k), el factor de selectivitat es pot calcular de forma:

Si el predicat és simple i del tipus ( ai > k), el factor de selectivitat es pot calcular de forma:

Però el predicat utilitzat en l’operació de selecció pot ser compost del tipus ( p1 and p2 ), on p1 i p2 són predicats simples. Llavors el factor de selectivitat es pot calcular de forma

145

Si en aquest cas el predicat compost és del tipus ( p1 or p2 ), quedaria de forma:

En el cas que el predicat compost sigui del tipus ( p1 in (conjunt de valors) ), el SFS es pot calcular de forma:

A partir de tot aquest conjunt d’estadístiques, es poden aplicar correctament els models de cost del sistema, i per tant decidir les estratègies que ha de seguir el sistema per tal d’executar les peticions. Un factor de qualitat molt important d’un sistema gestor és el fet que pugui ajustar el màxim possible els valors dels factors de selectivitat, ja que llavors els models de cost i temps s’aproparan més a la realitat, i per tant les estratègies escollides seran les millors de tot el conjunt de cerca.

[Tamer1999] p228-p238

RESUM En aquesta sessió s’han introduït els conceptes bàsics referents a l’optimització de peticions. S’ha vist que hi ha moltes possibles estratègies d’execució per a cada petició d’entrada i que cal emprar un model del sistema per tal de valorar-les i llavors escollir la millor de totes elles. Finalment s’ha fet una descripció de la informació que necessita el sistema per tal de poder calcular els models del sistema.

147

SESSIÓ 23 Nom: Optimitzadors estàtics en els gestors centralitzats Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:

o Bibliografia bàsica: [Tamer1999] [Bell1992]

PRECEDENTS A les sessions anteriors s’han introduït els conceptes bàsics referents a l’optimització de peticions. S’han presentat els diferents tipus de models que els sistemes poden emprar així com la informació necessària que ha de disposar el diccionari de dades per poder-ho aplicar.

OBJECTIUS En aquesta sessió s’estudien els diferents tipus d’optimitzadors que utilitzen els sistemes gestors centralitzats i es concreta amb l’estudi dels algorismes estàtics.

CONTINGUTS En aquesta sessió s’analitzen els tipus d’optimitzadors que utilitzen els sistemes gestors centralitzats i a continuació es presenta un exemple d’optimitzador estàtic que és el System R. Es finalitza la sessió amb un exemple d’optimitzador estàtic.

4.5. Optimització en els gestors centralitzats En aquest tema es presenta una classificació del tipus d’optimització que es dóna en els sistemes gestors centralitzats. Aquests poden ser estàtics o dinàmics.

Optimització en els gestors centralitzats

Els optimitzadors que s’utilitzen en els sistemes gestors centralitzats poden ser estàtics OE o bé dinàmics OD. Els optimitzadors estàtics donen l’estratègia d’execució d’una petició immediatament després de rebre la petició. Per tant, el procés de generació de l’estratègia es fa un sol cop i de forma complerta. Aquest tipus d’optimització facilita la generació i execució de l’estratègia, però requereix d’estadístics (factors de selectivitat o similars) per tal d’anar escollint la millor estratègia.

148

Els optimitzadors dinàmics van generant l’estratègia d’execució per parts, ja que un cop han generat una part de l’estratègia seguidament s’executa. Un cop ha finalitzat l’execució parcial segueixen generant la continuació de l’estratègia fins que es finalitza amb aquest procés amb la seva execució. Aquest tipus d’optimitzadors van generant l’estratègia a partir de resultats que ja han executat, amb la qual cosa no requereixen d’estadístics per fer estimacions de la grandària de les relacions intermèdies. Per tant, són més acurats que els optimitzadors estàtics, però es més difícil de resoldre tot el procés d’optimització i execució.

[Bell1992] p148-p149

[Tamer1999] p239

Algorismes d’optimització estàtics. OE

En aquest tema s’estudien el funcionament habitual d’un optimitzador estàtic OE. Aquest tipus de funcionament és el més emprat pels sistemes comercials de gestors de bases de dades centralitzats. El principal objectiu de l’optimitzador és el de donar una estratègia d’execució a partir d’una entrada amb càlcul relacional o SQL. Inicialment es converteix la petició a àlgebra relacional AR i seguidament aquesta es converteix amb una estratègia d’execució. L’expressió d’AR està formada per dos tipus d’operacions, que són les operacions unàries i les binàries. Tal com fan la majoria d’optimitzadors el sistema primer executa les operacions unàries i seguidament les binàries. L’objectiu d’aquest tipus d’heurística és la de minimitzar el màxim possible les grandàries de les relacions que han de tractar les operacions binàries, que són majoritàriament operacions de join. Abans de resoldre cap operació unària, el sistema decideix el tipus d’accés que farà en tot el procés a les relacions Outer quan aquestes estiguin involucrades en una operació de Join. Cal recordar que si es disposa d’una operació de Join del tipus ( R Join S ), la relació R és la relació Outer i la relació S és la relació Inner.

Accés a les relacions outer

El criteri emprat en aquest procés és:

a) Resolució de les operacions de selecció sobre les relacions Outer R. Si hi ha una operació de selecció sobre la relació Outer R i aquesta relació té un índex per l’atribut emprat en el predicat simple de l’operació de selecció, llavors l’accés a la relació R es fa mitjançant aquest índex. En aquest cas, el procés de selecció sobre R i el join sobre S es fa amb una sola operació, cosa que minimitza força el cost de l’estratègia generada.

Si la condició a no és certa, el sistema pot decidir tres tipus diferents d’accés, que són:

149

b) Si hi ha una operació de selecció sobre R, primer s’obté R’ que és el resultat d’executar l’operació de selecció sobre R i seguidament s’analitzen les condicions c i d.

Si la condició a no es compleix, llavors s’executa el join ( R join S ) o ( R’ join S) segons els criteris següents:

c) Si R o R’ té un índex per l’atribut de join i S també té un índex per l’atribut de

join, el join ( (R o R’) join S ) s’executa mitjançant un procés de Sort-Merge.

d) Si R no té un índex per l’atribut de join, l’accés amb aquesta relació es fa de forma seqüencial i resol el join amb un procés de Nested-Loop. En aquest cas, si la relació S té un índex per l’atribut del Join el fa servir.

També es pot donar la situació d’execució del join ( R join S ) i que hi ha una operació de selecció sobre S. Llavors, s’executa primer l’operació de selecció sobre S, i seguidament el join ( R join S’ ).

Accés a les relacions inner

Si la relació inner S té un índex per l’atribut de join, aquest sempre es fa servir, tant si la resolució del join es fa amb un Sort-Merge com si es fa amb un Nested-Loop. Llavors, un cop el sistema ha decidit el tipus d’accés a les relacions outer, i ha executat les operacions unàries sobre totes les relacions, comença a generar l’estratègia d’execució. A continuació es detalla aquest procés.

Construcció de l’arbre d’execució

El procés de construcció de l’arbre d’execució es comença a preparar inicialment a partir de les relacions que hi ha en la petició i els possible joins d’aquesta relació amb la resta de relacions segons el join graf. A continuació hi ha un exemple de join graf.

R

S

T

ba

En aquest cas l’arbre inicial amb totes les possibilitats d’execució de joins és:

150

Estratègia d'execució

R S T

(R join_a S) (S join_a R) (S join_b T ) (T join_b S)

Llavors s’analitzen les peticions equivalents que hi ha en les fulles de l’arbre. En aquest cas hi ha dues equivalències que són: (R join_a S) és equivalent amb (S join_a R). (S join_b T) és equivalent amb (T join_b S). Llavors, per cada petició equivalent s’analitza el cost de les dues possibilitats i s’agafa aquella que té un cost més petit. Això permet simplificar les branques de l’arbre i queda un arbre sense peticions equivalents. A l’exemple anterior l’arbre podria quedar de forma:


R T

(R join_a S) (T join_b S) Llavors a partir del nou arbre, s’afegeix un nivell més a les branques amb les possibles relacions que poden fer un join amb les branques existents. A l’exemple anterior i segons el join graf, quedaria de forma:

151


R T

(R join_a S) (T join_b S)

((T join_b S) join_a R)((R join_a S) join_b T ) Llavors cal buscar les peticions equivalents i eliminar de l’arbre aquella que tingui el cost més gran. Aquest procés es va repetint fins que la petició final coincideix amb la petició donada al join graf. Aquesta és la situació que es dóna a l’arbre anterior, i per tant, cal mirar de les dues possibles estratègies la que té un cost més petit, ja que aquesta és la que s’ha d’executar.

[Tamer1999] p243-p247

Problema d’optimitzador estàtic

En aquest apartat es resol un exercici d’optimitzador estàtic que ha de permetre completar els coneixements adquirits a l’apartat teòric anterior. Disposem d'un gestor de bases de dades centralitzat que utilitza un algorisme d'optimització de peticions estàtic OE. Aquest rep una petició q1 i ha de crear una estratègia d'execució. Aquesta petició és:

El join graf associat a la petició q1 és:

152

R

S

T

ba

card(R)= 1Klong(R)=100

card( T )= 5Klong( T )=50

card(S)= 100Klong(S)=250

Disposem de les informacions següents relatives a les relacions: long(a)=10 i long(b)=5. El nombre de valors diferents de l’atribut c a la relació S és igual a 5. El nombre de valors diferents de l’atribut d a la relació S és igual a 10. El nombre de valors diferents de l’atribut a a les relacions R i S és igual a 5. El nombre de valors diferents de l’atribut b a les relacions S i T és igual a 7. La relació R té un índex per l'atribut a, la relació S té un índex per l'atribut a i un altre índex per l'atribut b. La relació T no té cap índex. Els costos que cal contemplar en els models són: LCR=LCW=1. El Factor de selectivitat de join de (R,S) és igual al factor de selectivitat de join de (S,T) i val 0,0001. Ens demanen: L'estratègia relativa a l'execució de la petició q1. El cost d'execució d'aquesta estratègia. La grandària de la relació resultant. SOLUCIÓ Com que hi ha una operació de selecció sobre la relació S, inicialment cal calcular el seu factor de selectivitat. Si s’aplica l’operació de selecció sobre la relació S:

153

Card(S’)=100K · 0,28 = 28K Size(S’)=28K · 250 = 7M A continuació es construeix l’arbre amb el primer nivell. Aquest és:


R S T

(R join_a S) (S join_a R) (S join_b T ) (T join_b S)

Per poder simplificar les branques s’analitza el cost de cada possible opció. Aquest cost és:

Llavors, a partir del cost calculat per cada estratègia, l’arbre resultant queda de forma:

154


R T

(S join_a R) (T join_b S)

((T join_b S) join_a R)((S join_a R) join_b T ) Llavors cal calcular el cost d’execució de les branques finals. Aquestes són:

El cost global de les dues estratègies és:

Per tant, l’estratègia d’execució és: Amb un cost d’execució de 167K. La grandària del resultat és: size(Resultat)=(100+250+50-10-5) · 1K9 = 385 · 1K9 = 731K5

RESUM En aquesta sessió s’han estudiat els diferents tipus d’optimitzadors emprats pels sistemes gestors centralitzats. S’ha estudiat el comportament dels optimitzadors estàtics i s’han completat els conceptes teòrics mitjançant la resolució d’un problema.

155

SESSIÓ 24 Nom: Optimitzadors dinàmics en els gestors centralitzats Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:


PRECEDENTS En aquest capítol s’estudien les tècniques que utilitzen els sistemes gestors per generar una estratègia d’execució optimitzada. S’han estudiat de forma genèrica els criteris emprats pels optimitzadors i s’ha detallat el comportament dels optimitzadors estàtics.

OBJECTIUS En aquesta sessió s’estudia el funcionament dels optimitzadors dinàmics amb detall.

CONTINGUTS En aquesta sessió es tracta inicialment el funcionament dels optimitzadors dinàmics i a continuació es resol un problema que facilita la comprensió dels conceptes teòrics previs.

Algorismes d’optimització dinàmics. OD

En aquest tema s’introdueix l’esquema bàsic de funcionament d’un optimitzador dinàmic de peticions. El principal objectiu d’un optimitzador és el de donar una estratègia d’execució a partir d’una entrada amb càlcul relacional o SQL. Aquest procés d’optimització es pot fer de cop al principi de rebre la petició o bé per fases a mesura que aquestes es van executant. Quan la generació de l’estratègia es fa per fases, es diu que es tracta d’un optimitzador dinàmic. El principi de funcionament d’un OD és el de convertir la petició original multivariable (intervenen moltes relacions) amb un conjunt sèrie de peticions monovariable on només s’accedeix amb una sola relació. Això s’aconsegueix en dues fases:

1) Execució de les peticions monovariable. Això vol dir que primer s’executen les

operacions unàries d’àlgebra relacional.

156

2) Execució de la petició resultant mitjançant la utilització de tècniques de separació o substitució.

En el cas de les peticions monovariables el sistema accedeix a la relació mitjançant el seu índex si aquesta inclou un predicat simple amb algun dels operands (<, >, =), ja que en cas contrari s’accedeix de forma seqüencial. L’execució de la petició resultant es fa de forma dinàmica de dues en dues relacions i guardant sempre el resultat en una relació temporal. Aquest procés sempre es fa a partir de l’ordenació de les relacions en funció de la seva grandària (de més petita a més gran) fins que s’arriba al resultat final del join. Si es disposa de la petició d’entrada q1, el sistema genera una estratègia dinàmica d’execució tal com es detalla a continuació. La petició inicial q1 és:

Primer s’executa l’operació de selecció i llavors s’obté R’. A continuació es segueix amb el procés de separació. S’ordenen les relacions per grandària i si suposem que aquest és:

Seguidament cal ajuntar el resultat que hi ha a la relació temporal TempoR amb la relació T.

En aquest punt, el sistema ja disposa del resultat final. També el sistema pot simplificar l’execució d’un join mitjançant una substitució. Això permet simplificar una petició de forma: Unió de totes les seleccions fetes sobre el domini de l’atribut del join. Aquest procediment només és útil quan la cardinalitat del domini de l’atribut és petita.

[Tamer1999] p239-p243

Problema d’optimitzador dinàmic

En aquest apartat es resol un exercici d’optimitzador dinàmic que ha de permetre completar els coneixements adquirits a l’apartat teòric anterior.

157

Problema d’optimitzador dinàmic

Disposem d'un gestor de bases de dades centralitzat que utilitza un algorisme d'optimització de peticions dinàmic OD. Aquest rep una petició q1 i ha de crear una estratègia d'execució. Aquesta petició és:

El join graf associat a la petició q1 és:

R

S

T

ba

card(R)= 1Klong(R)=100

card( T )= 5Klong( T )=50

card(S)= 100Klong(S)=250

Disposem de les informacions següents relatives a les relacions: long(a)=10 i long(b)=5. El nombre de valors diferents de l’atribut c a la relació S és igual a 5. El nombre de valors diferents de l’atribut d a la relació S és igual a 10. El nombre de valors diferents de l’atribut a a les relacions R i S és igual a 5. El nombre de valors diferents de l’atribut b a les relacions S i T és igual a 7. La relació R té un índex per a l'atribut a, la relació S té un índex per l'atribut a i un altre índex per a l'atribut b. La relació T no té cap índex. Els costos que cal contemplar en els models són: LCR=LCW=1. El Factor de selectivitat de join de (R,S) és igual al factor de selectivitat de join de (S,T) i val 0,0001.

158

Ens demanen: - L'estratègia relativa a l'execució de la petició q1. - El cost d'execució d'aquesta estratègia. - La grandària de la relació resultant. - Comparar els resultats amb la resolució feta amb un optimitzador estàtic.

SOLUCIÓ Inicialment es calcula el factor de selectivitat associat a l’operació de selecció. Aquest és:

Si llavors s’aplica l’operació de selecció sobre la relació S i s’obté S’:

En aquest cas cal ordenar les relacions per grandària. Aquest és:

Per tant, tenim que:

I s’executa el join que conté la relació més petita que és R.

A continuació s’executa el join final.

L’estratègia d’execució final és:

I el cost d’execució és:

159

La mida de la relació resultant és de 539K i si es compara aquest cost amb el de l’optimitzador estàtic OE de 167K, l’optimitzador dinàmic OD dóna un resultat pitjor.

RESUM En aquesta sessió s’han estudiat els optimitzadors dinàmics i s’han completat els conceptes teòrics amb la resolució d’un problema.

161

SESSIÓ 25 Nom: Ordenació de joins entre fragments. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:


PRECEDENTS A les sessions anteriors s’han estudiat les tècniques més emprades pels optimitzadors dels sistemes gestors centralitzats.

OBJECTIUS En aquesta sessió s’introdueixen les tècniques bàsiques emprades pels sistemes gestors distribuïts referents a l’optimització de peticions. Aquest estudi es centra en l’anàlisi d’algorismes tant basats en l’ordenació de joins com en la utilització de semijoins.

CONTINGUTS En aquesta sessió es tracten els dos primers apartats del capítol de processament de peticions en sistemes gestors distribuïts. Es comença amb una introducció a l’ordenació de joins entre fragments i es segueix amb la justificació de la utilització de les operacions de semijoin.

Ordenació de joins entre fragments.

En aquest tema s’exposen les tècniques d’ordenació de joins entre fragments emprades pels sistemes gestors distribuïts. L’ordre en què s’executen les operacions de joins és molt important, ja que la grandària de les relacions que es van creant a mesura que avança la seva execució pot produir un increment important en el cost de comunicació COM. És evident que interessa que aquesta grandària sigui sempre mínima, ja que així es va minimitzant el cost COM de l’estratègia. Un altra forma de minimitzar el cost de comunicació COM és mitjançant la utilització de tècniques basades en semijoins, tal com s’estudia a l’apartat següent. Quan es genera una estratègia d’execució no es distingeix entre les relacions i els fragments, ja que sempre cal contemplar el cost COM independentment del tipus d’objecte que es tracta.

162

També cal tindre present que hi ha força sistemes que no contemplen el cost associat a les operacions de selecció i projecció, ja que aquest acostuma a ser molt més petit que el cost de comunicació. Ara bé, a mesura que els sistemes actuals disposen de xarxes de comunicació més ràpides, aquest cost s’ha de contemplar per tal de fer un estudi més acurat del cost de l’estratègia. Un aspecte que fa que el cost COM sigui predominant és en el cas dels sistemes gestors distribuïts i amb relacions ubicades a diferents nodes. En aquest cas sempre s’intenta minimitzar la transferència d’informació per a la xarxa. A la figura següent es pot observar una situació en què s’ha d’executar una operació de join entre dues relacions, R i S. La relació R està ubicada al node 1 i la S al node 2.

R S

Site 1 Site 2

Llavors, per tal d’optimitzar el cost de l’estratègia, i abans d’executar el join, cal moure la relació més petita. Per tant, si size(R) < size(T) < size(S’) cal moure R al node 2 i llavors executar el join en el node 2. Per la resta de situacions, s’ha de moure la relació S al node 1 i llavors executar el join d’R amb S al node 1. Aquesta situació es pot complicar si el join que s’ha de fer és de tres o més relacions, ja que en aquest cas és important el node en què s’ubiquen les relacions parcials obtingudes com a resultat de l’execució dels joins.

En aquest cas, l’estratègia d’execució no és tant simple, ja que es pot començar executant el join d’R amb S o bé el join d’S amb T. Aquesta situació és va complicant a mesura que intervenen més relacions en el join, i no és fàcil fer una previsió de les grandàries de les relacions que s’obtenen. Com sempre s’ha d’intentar minimitzar el cost de comunicació, una estratègia que s’acostuma a utilitzar és començar amb l’execució dels joins en què intervenen les relacions més petites, i així s’aconsegueix minimitzar el cost COM. Per tant, si en les relacions de la figura anterior sabem que:

R

S

Site 1 Site 3

T

Site 2

163

1) Size(R) < size(S) < size(T)

Es comença amb l’execució del join d’R amb S i a continuació es segueix amb l’execució del join amb T.

2) Size(T) < size(S) < size(R)

Es comença amb l’execució del join de T amb S i a continuació es segueix amb l’execució del join amb R.

3) Size(R) < size(T) < size(S)

En aquest cas es comença amb l’execució del join d’R amb S i després es segueix amb el join amb la relació T. Amb aquesta situació es veu que sempre es comença per executar el join amb la relació més petita, que en aquest cas és R. Encara que la relació següent ordenada segons la seva grandària és T, com que el join d’R amb T no és factible, es fa el join d’R amb la relació següent en què el join es pot fer, o sigui, S.

4) Size(S) < size(R) < size(T)

Es comença amb l’execució del join d’S amb R i a continuació es segueix amb l’execució del join amb T.

5) Size(S) < size(T) < size(R)

Es comença amb l’execució del join d’S amb T i a continuació es segueix amb l’execució del join amb R.

Per tant, aquesta heurística d’executar els joins a partir de la seva grandària funciona bastant bé, ja que minimitza la grandària de les relacions que s’han d’enviar per la xarxa. En canvi, si les relacions no estan ubicades en nodes diferents, no sempre surt a compte enviar la relació més petita, ja que cal vigilar en el node on es deixa el resultat parcial, ja que en el pas següent ens pot permetre minimitzar molt el cost COM. A continuació hi ha un exemple d’aquesta situació.

R

S

Site 1size(R)=100

Site 2size( T )=200

T

Site 2size(S)=50

Segons les recomanacions anteriors, primer caldria executar el join d’S amb R. Per tant, inicialment cal enviar S al node 1, executar en aquest el join i després executar el

164

join amb T. Amb aquest darrer pas, caldria enviar T al node 1 o bé el resultat del join del primer pas al node 2. O sigui: Si size(S join R) < size (T) cal enviar el resultat del join d’S amb R al node 2. Si nó cal enviar T al node 1. Si tenim que

podem calcular de forma aproximada el cost d’aquesta darrera fase com:

i per tant

. En aquest cas, com que T és més petita que el resultat del join, cal moure T al node 1. El cost COM de l’estratègia complerta és: 50 + 200 = 250. Una alternativa amb aquesta estratègia seria: Executar el join d’S amb R però enviant R al node d’S amb un cost de 100. Seguidament es pot executar el join d’S amb R, però com que el resultat està al mateix node que la relació T, en el pas següent no caldrà moure cap relació. En aquest cas, el cost COM és igual a 100, cosa que millora molt el cost de 250 de la solució anterior. Per tant, podem concloure que cal mirar la grandària de les relacions a moure, però sempre s’ha de contemplar l’evolució de l’estratègia en els passos següents, cosa que dificulta molt la seva creació. És important recordar que mitjançant l’ordenació de les relacions a partir de la seva grandària és una heurística que facilita la creació d’una estratègia més o menys òptima, però no es pot assegurar que aquesta estratègia sigui la millor. Es pot donar el cas, que en funció dels factors de selectivitat de les operacions de Join, sigui millor començar l’execució del join amb les relacions que tenen un factor de reducció (factor de selectivitat més petit), en lloc de fer-ho a partir de les relacions més petites. Llavors caldria comparar els diferents mètodes, cosa que ho complica força i per tant cal tendir a simplificar-ho. És doncs per aquest motiu que el criteri més emprat és l’ordenació a partir de les grandàries de les relacions.

[Tamer1999] p247-p249

Semijoins

En aquest tema s’exposen les tècniques d’utilització de semijoins per a la resolució d’operacions de join en sistemes gestors distribuïts. El principal objectiu de la utilització de les operacions de semijoin rau en el fet que es vol minimitzar la grandària de les relacions que s’envien entre els diferents nodes per la xarxa. El principal problema d’enviar una relació cap a un node és el fet que en el node receptor no es faran servir totes les tuples de la relació, ja que possiblement hi ha

165

moltes tuples enviades que no estaran al resultat del join executat a continuació. Per tant, un objectiu a complir és el d’enviar les tuples de la relació que podem assegurar que estaran al resultat del join. Doncs això s’aconsegueix mitjançant la utilització d’operacions de semijoin. El semijoin de dues relacions R i S es defineix com les tuples de la relació R que estan en el Join d’R amb S. Es defineix com:

. On A és el conjunt dels atributs de la relació R.

R S

Site 1 Site 2

Llavors, si volem realitzar el Join de les relacions R i S per a l’atribut a, hi ha diferents alternatives que són: Ara bé, si l’operació de Semijoin es defineix a partir d’una operació de projecció sobre el resultat de l’execució d’un Join, com que primer caldrà executar el Join no es veu guany possible. La solució és executar el Semijoin, per exemple R Semijoin S de forma:

1) S’envia .

2) En el Site 1 s’executa una operació de selecció d’R amb els valors de l’atribut a què s’ha enviat a la fase anterior. Amb això s’obté una nova relació R que és R’ i que només conté les tuples de la relació R que estan al resultat del join d’R amb S.

3) El pas següent és enviar la nova relació R’ creada al Site 1 al Site 2 i en aquest

node executar el join final amb S. Llavors, el cost d’execució de la petició és:

166

El cost d’execució d’aquesta estratègia sense utilització de semijoin és: size(R). Per tant, si:

llavors surt a compte fer el semijoin per executar la petició. Es pot observar que com més petit és el factor de selectivitat de semijoin, la reducció de la relació R és més gran i llavors hi ha un estalvi de comunicació important, ja que size(R’) << size(R). Podem dir que la diferència size(R) - size(R’) és el guany assolit pel fet d’utilitzar un semijoin. En aquest cas, el cost afegit pel fet d’utilitzar el semijoin és:

Segons el que hem vist fins ara, el semijoin és força útil en sistemes en què el cost COM és elevat i quan el factor de selectivitat de semijoin és petit. A continuació es presenta una variant de Semijoin que es completa amb la utilització d’una funció de Hash. Aquest s’anomena HashSemijoin i seguidament es detalla el seu funcionament.

R S

R'

Site 2

AH(hash(a,S))

Site 1

En aquest algorisme inicialment es construeix en el Site 2 un array de booleans anomenat AH i s’envia al Site 1. Aquest array AH està format per n posicions on el domini de hash(a)=n. El procés de construcció d’aquest array és:

1) Per a condicions inicials totes les posicions de l’array valen fals. 2) Per a totes les tuples d’S es calcula hash(a,S) i es posa en cert la posició hash(a,S) de l’array AH.

Per tant, si una posició i de l’array AH val cert vol dir que hi ha alguna tupla a S que el hash del seu atribut a val i. En canvi, si una posició j de l’array AH val fals, vol dir que no hi ha cap tupla de la relació S que el hash del seu atribut valgui j. Un cop s’ha obtingut l’array AH al Site 2, aquest s’envia al Site 1. Llavors en el Site 1 es fa una selecció de les tuples d’R que el seu hash(a,R) es correspongui amb una posició de l’array AH amb valor cert. Si és així, aquesta tupla s’ha d’afegir a R’. En cas contrari, es pot assegurar que la tupla no estarà inclosa en el join final d’R amb S i per tant no cal afegir-la a la relació R’.

167

Finalment s’envia R’ al Site 2 per tal que en aquest s’executi el Join d’R’ amb S. La principal aportació d’aquest mètode és que minimitza el cost de comunicació que hi ha a la fase inicial d’enviar els atributs d’S al node 1. Per tant, podem concloure afirmant que es recomana utilitzar aquestes estratègies basades en semijoin en sistemes amb un cost de comunicació COM gran.

[Tamer1999] p238,249-253

RESUM En aquesta sessió s’han estudiat els conceptes d’ordenació de joins entre fragments i s’ha justificat la utilització de les operacions de semijoin. Finalment s’han analitzat les diferents situacions en què aquests tipus de tècniques van millor per a la generació d’estratègies d’optimització més òptimes.

169

SESSIÓ 26 Nom: Optimitzador estàtic basat en ordenació de joins. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:


PRECEDENTS A les sessions anteriors s’han estudiat les tècniques emprades tant pels optimitzadors estàtics com els dinàmics per a la generació de les estratègies d’execució.

OBJECTIUS En aquesta sessió s’estudia un algorisme d’optimització estàtic basat en ordenació de joins per a sistemes gestors distribuïts. Amb això es pretén reforçar els conceptes teòrics assolits a les sessions anteriors.

CONTINGUTS En aquesta sessió es presenta un algorisme genèric d’optimització estàtic basat en ordenació de joins per a sistemes gestors distribuïts.

4.6 Optimització en els gestors distribuïts. En aquest apartat es presenta un algorisme d’optimització estàtic basat en l’ordenació de joins per a sistemes gestors distribuïts.

Algorisme d’optimització estàtic basat en l’ordenació de joins

Aquest algorisme funciona segons els criteris marcats per l’optimitzador estàtic centralitzat. Ara bé, com que la informació està distribuïda entre els diferents nodes del sistema, cal ampliar el seu model de funcionament. El procés d’optimització contempla els costos de CPU, Entrada/Sortida IO i Comunicació COM. Inicialment es busca el millor mètode d’accés per a cada relació i a continuació la millor estratègia a partir de l’ordenació de joins. Per resoldre un join es pot utilitzar un algorisme de NestedLoop o bé de SortMerge. L’accés a les relacions es pot fer de forma seqüencial o bé a partir d’un accés per índex.

170

Un aspecte important en el funcionament de l’algorisme és quan s’ha de resoldre un join entre dues relacions R i S que estan ubicades a diferents nodes. En aquest cas hi ha dues formes de resoldre el join: 1.- S’envia tota la relació d’un node a l’altre i el node receptor guarda la relació en un espai temporal. Llavors, quan el node receptor té tota la relació executa el join. 2.- Es va enviant la relació d’un node a l’altre i llavors el node receptor va executant el join amb les tuples que rep i va guardant el resultat del join. Aquest mètode segueix el principi de funcionament JustInTime. L’algorisme que segueix l’optimitzador estàtic parteix dels principis de funcionament anteriors. A continuació es detalla el seu funcionament. El procés d’obtenció de l’arbre és el mateix que en el cas del sistema gestor centralitzat. Ara bé, el principal canvi està en els diferents mètodes que el sistema pot emprar per tal d’executar els joins. Per tal de calcular la grandària de les relacions que es van creant a mesura que s’executa la petició. Aquesta grandària es pot calcular a partir del factor de selectivitat o del valor s que s’obté a partir d’aquest. Aquests dos valors es relacionen de forma:

A continuació és detallen les quatre possibles estratègies que pot seguir el sistema per executar el join (R Join S). 1.- S’envia la relació R al node que té la relació S i a continuació s’executa el join amb tècnica JustInTime. El seu cost és:

El primer terme del model de cost és el cost associat a la lectura de la relació R. El segon terme és el cost d’enviar R per la xarxa. El tercer terme dóna el cost de lectura de les tuples d’S a mesura que es rep una tupla d’R (JustInTime). Llavors, si la relació S té un índex per l’atribut de join, aquest s’utilitza i el darrer terme utilitza el valor s. En canvi, si S no té índex per l’atribut de join, per cada lectura d’una tupla d’R cal llegir tota la relació S i per això s’adopta el valor card(S). 2.- S’envia S al node que té la relació R i es guarda de forma temporal. Un cop el node destí ja té tota la relació S executa el join d’R amb S. El seu cost és:

3.- S’envien els valors de l’atribut del join a que hi ha a la relació R al node que té la relació S. Llavors s’executa una operació de selecció sobre la relació S mitjançant els valors de l’atribut a que s’han enviat i s’envia el resultat al node que té la relació R i ja s’executa el join final. El seu cost és:

171

El primer terme del model de cost és el cost associat a la lectura de la relació R. El segon terme és el cost d’enviar el conjunt de valors de l’atribut a que hi ha a la relació R al node destí. El tercer terme és el cost de lectura de les tuples de la relació S per tal de fer l’operació de selecció, ja que aquesta operació es va fent de forma JustInTime. El quart terme dóna el cost de comunicació per enviar el resultat de l’operació de selecció al node que té la relació R. El darrer terme és el que dóna el cost de lectura de les tuples de la relació R per executar el join final. 4.- S’envien les relacions R i S a un tercer node i llavors s’executa el join en aquest. Primer s’envia la relació S i a continuació R, ja que així es pot anar executant el join a mesura que el node destí rep les tuples de la relació R. El seu cost és:

El primer terme és el cost del procés de lectura de la relació S. El segon terme és el cost d’enviar la relació S. El tercer terme és el cost de lectura de la relació R i el quart terme és el cost d’enviar la relació R. El darrer terme dóna el cost de lectura de les tuples de la relació S per executar el join final. Llavors, quan s’ha d’executar un join de dues relacions ( R join S ), es decideix la millor estratègia entre les quatre que s’han descrit. D’aquesta forma també es coneix el seu cost i per tant es pot escollir la millor estratègia d’execució entre tot el conjunt d’estratègies equivalents. A partir del que hem vist, es veu que l’algorisme anterior fa una cerca entre totes les possibles alternatives d’estratègia d’execució. Mitjançant la simplificació de les peticions equivalents s'aconsegueix minimitzar l’espai de cerca i així es va simplificant l’arbre amb les possibles estratègies d’execució.

Problema d’optimització estàtic basat en l’ordenació de joins

En aquest apartat es presenta un problema d’optimització estàtic basat en l’ordenació de joins per a sistemes gestors distribuïts. Es demana l’obtenció de l’estratègia d’execució d’un sistema que utilitza un mètode d’optimització estàtic basat en l’ordenació de joins. A continuació hi ha el join graf de la petició. Els diferents costos són:LCR=LCW=COM=1. La relació R té un índex per a l’atribut a, T per l’atribut b i S un índex per a l’atribut a i un altre índex per a l’atribut b. El valor d’s per a totes les operacions de join és d’1.

172

R

S

T

long(S)=200card(S)=1000

a

long(a)=long(b)=5

long(R)=100card(R)=500

b

long( T )=40card( T )=1000

A partir de la figura anterior es construeix l’arbre d’execució que hi ha a continuació.


R S T

(R join_a S) (S join_a R) (S join_b T ) (T join_b S) Llavors cal simplificar les peticions equivalents però primer cal decidir quina estratègia es millor per a cada petició de join. El cost de cada alternativa d’un join ( R join S ) és:

A continuació es calcula el cost de cada una de les diferents alternatives.

173

A partir dels models de cost anteriors, l’arbre resultant és:


R T

(R join_a S) (T join_b S) El cost d’execució de és de 42K. Els factors de selectivitat de les operacions de join es poden calcular a partir del valor d’s.

174

A continuació cal calcular la grandària de les relacions resultants que són:

A continuació es completa l’arbre quedant dues estratègies finals d’execució que són:

Si ara s'ajunten les diferents estratègies, el seu cost total és:

En aquest cas, la solució millor és la primera, encara que no hi ha molta diferència de cost respecte l’altra estratègia.

[Tamer1999] p259-p263

RESUM En aquesta sessió s’ha estudiat una tècnica de generació d’estratègies per a sistemes gestors distribuïts. Aquesta és estàtica i utilitza tècniques d’ordenació de joins.

175

SESSIÓ 27 Nom: Optimitzador dinàmic basat en ordenació de joins. Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:


PRECEDENTS A les sessions anteriors s’han estudiat les tècniques emprades tant pels optimitzadors estàtics com els dinàmics per la generació de les estratègies d’execució.

OBJECTIUS En aquesta sessió s’estudia un algorisme d’optimització dinàmic basat en ordenació de joins per a sistemes gestors distribuïts.

CONTINGUTS En aquesta sessió es presenta un algorisme genèric d’optimització dinàmic basat en ordenació de joins per a sistemes gestors distribuïts. En aquest apartat es presenta un algorisme d’optimització dinàmic basat en l’ordenació de joins per a sistemes gestors distribuïts.

Algorisme d’optimització dinàmic basat en l’ordenació de joins

El funcionament de l’algorisme d’optimització dinàmic en els sistemes gestors de base de dades distribuïdes segueix el mateix principi de funcionament que el dels sistemes gestors centralitzats. També va generant l’estratègia d’execució a partir de l’ordenació de les relacions en funció de la seva grandària, sempre començant per les relacions més petites fins les més grans. En aquest algorisme els fragments s’identifiquen com a Rij on Ri és el fragment i j és el node on està ubicat. L’algorisme també contempla el seu funcionament en una xarxa sense broadcast i amb una xarxa amb broadcast. Tot això tenint en compte que les relacions poden estar fragmentades ja que així és minimitza el seu cost d’execució. Per facilitar el procés sempre es pressuposa que els nodes estan ordenats en funció de la grandària de la relació. Aquest ordre sempre és de més gran a més petit i es dóna de forma:

A continuació es detalla el seu funcionament amb una xarxa amb broadcast i després amb una xarxa sense broadcast quan es vol executar una operació de (R join S).

176

Xarxa amb broadcast

En el primer terme s’obté un node j que sigui el que té el màxim d’informació tenint en compte les dues relacions, o sigui amb els fragments de les dues relacions R i S. El segon terme busca la relació més gran entre R i S. Llavors si el node que té més informació en té més que la grandària de la relació més gran, s’executa de forma centralitzada en aquest node. En cas contrari s’executa de forma distribuïda.

Xarxa sense broadcast

Per aquesta situació es poden donar dues situacions; quan almenys hi ha una relació no està fragmentada i quan les dues relacions estan fragmentades. Una relació sense fragments. En aquest cas la relació que no està fragmentada és S.

Si no Enviar S a la resta de nodes i execució distribuïda FiSi Si el cost d’enviar S a tots els nodes que tenen un fragment d’R és més gran que la informació que li falta al node 1 d’R, llavors la millor estratègia és una execució centralitzada en el Site 1. Les dues relacions estan fragmentades. En aquest cas la relació Rp és la relació més gran i Ri és la relació més petita.

Si la grandària d’informació que li falta al primer node és més petita que els fragments que ha d’enviar el primer node a la resta de nodes, llavors és millor una execució centralitzada en el primer node. En cas contrari surt a compte una execució distribuïda. Fins ara s’ha vist una possible estratègia per executar una operació de join de dues relacions (R join S) quan hi ha fragments. A continuació hi ha uns exemples on s’indica l’estratègia d’execució per a diferents situacions de fragmentació i amb condicions amb broadcast i sense broadcast.

177

D’aquesta forma es veu com el sistema executa una petició de join quan alguna de les relacions està fragmentada. Quan les dues relacions no estan fragmentades i estan ubicades a nodes diferents sempre s’envia la relació més petita al node que té la relació més gran i llavors ja es pot executar en aquest node destí l’operació de join. El principi de funcionament de l’optimitzador dinàmic en sistemes distribuïts és el mateix que en els sistemes centralitzats. Inicialment es converteix la petició original multivariable a un conjunt sèrie de peticions monovariable on només s’accedeix amb una sola relació. D’aquesta forma inicialment s’executen les operacions unàries d’àlgebra relacional i a continuació s’executa la petició resultant mitjançant la utilització de tècniques de separació o substitució. O sigui, que ho fa igual que en els sistemes centralitzats però minimitzant sempre el tràfic de xarxa. Per això, l’execució de la petició resultant es fa de forma dinàmica de dues en dues relacions i guardant sempre el resultat en una relació temporal. Aquest procés sempre es fa a partir de l’ordenació de les relacions en funció de la seva grandària (de més petita a més gran) fins que s’arriba al resultat final del join.

Problema d’optimització dinàmic basat en l’ordenació de joins

En aquest apartat es resol un exercici d’optimitzador dinàmic basat en l’ordenació de joins que ha de permetre completar els coneixements adquirits a l’apartat teòric anterior.

Problema d’optimització dinàmic basat en l’ordenació de joins

Disposem d'un sistema gestor distribuït que ha d'executar la petició següent:

178

El cost de comunicació COM del sistema és igual a 1, i es pot menysprear el cost LCR i LCW. Es demana obtenir una estratègia d'execució en què cal optimitzar el seu cost a partir d’un optimitzador dinàmic basat en l’ordenació de joins. Cal donar també el cost d’execució de l’estratègia. Es disposa de les estadístiques del sistema que ens permetran la generació de l’estratègia. Les estadístiques de les relacions són:

També sabem que long(a)=long(b)=10. Les estadístiques dels SF dels joins són:

Les ubicacions de les relacions són: R està en el Node 1. S està en el node 2 i T està en el node 3. Cal remarcar que cap relació està fragmentada. SOLUCIÓ Inicialment s’ordenen les relacions en funció de la seva grandària. Aquest ordre és:

Per tant l’execució comença amb el join de la relació T amb la relació S. Com s’ha d’enviar per la xarxa la relació més petita, la primera operació de l’estratègia és:

1) Site 3: Enviar la relació T al Site 2, ja que aquest node és el que té la relació S. El cost d’aquesta operació és igual a

2) Execució en el Site 2 l’operació de join

En aquest cas, la cardinalitat i grandària de la relació ST és:

Per decidir l’ordre que cal seguir a l’execució del join següent, s’ordenen les relacions de forma:

179

Per tant, a continuació s’ha d’executar el join d’R amb ST. Com que R és la relació més petita aquesta s’ha d’enviar al Site 2 que té la relació ST. Això es veu a continuació de forma: 3) Site 1: Enviar la relació R al Site 2, ja que aquest node és el que té la relació ST. El cost d’aquesta operació és igual a:

4) Execució en el Site 2 l’operació de join i ja es disposa de la relació resultant. Finalment, el cost total de l’estratègia

.

[Tamer1999] p254-p259

RESUM En aquesta sessió s’han estudiat una tècnica de generació d’estratègies per a sistemes gestors distribuïts. Aquesta és dinàmica i utilitza tècniques d’ordenació de joins. Els continguts s’han completat amb un problema senzill.

181

SESSIÓ 28 Nom: Problemes d’optimitzadors. Tipus: Problemes Format: No presencial Durada: 2 hores Dedicació: 3 hores Treball a lliurar: No Material:


PRECEDENTS A les sessions anteriors s’han estudiat tant els conceptes teòrics dels optimitzadors de peticions com alguns algorismes en detall.

OBJECTIUS En aquesta sessió es completen els coneixements teòrics adquirits a les sessions anteriors mitjançant la realització de problemes.

CONTINGUTS En aquesta sessió es resolen dos exercicis sobre optimitzadors basats en l’ordenació de joins.

4.7. Exercicis En aquest apartat es realitza un problema d’optimització estàtic.

Problema d’optimitzador estàtic

Disposem d'un gestor distribuït basat en un model d’optimització amb ordenació de joins que ha d'executar la petició següent:

La relació Clients està ubicada en el node 1, Factures en el node 2 i LiniesFactures en el node 3. Les estadístiques de les relacions són:

182

La relació Clients no té cap índex, la relació Factures té un índex per NumCli i un altre per NumFact i la relació LiniesFactures no té cap índex. Podem suposar que l’optimitzador estàtic només contempla dues possibles estratègies, i que els seus models de cost aproximats són:

Cal especificar:

1) Estratègia d'execució. 2) Cost d’execució de l’estratègia final.

SOLUCIÓ Inicialment s’obté l’arbre amb les operacions de join de dues relacions. Aquest és:

Per tal de simplificar l’arbre cal calcular el cost de totes les estratègies equivalents i seleccionar aquelles que tenen el cost més petit.

183

Com que les operacions i són equivalents, s’agafa la que té un cost més petit. Aquesta és l’estratègia 1 de amb un cost de 1M6. Com que les operacions i són equivalents, s’agafa l’estratègia 2 de amb un cost de 31M. Llavors cal completar l’arbre de forma:

La cardinalitat i grandària de les relacions CF i LFF són:

184

A continuació cal avaluar el cost de les estratègies finals. El seu cost és: Llavors si es compara el cost total de les dues possibles estratègies, es veu que la que té un cost més econòmic és:

I el cost d’execució de l’estratègia anterior és:

Problema d’optimitzador estàtic i dinàmic

En aquest apartat es realitza un problema d’optimització d’una petició i es compara el cost d’una estratègia estàtica amb el d’una estratègia dinàmica. A partir del Query graf següent, cal veure quina estratègia d’execució basada en l’ordenació de joins és millor. Es demana detallar l’estratègia estàtica i la dinàmica donada pels optimitzadors així com el seu cost.

A continuació es detalla la informació coneguda del sistema.

185

L’optimitzador pot utilitzar les dues primeres estratègies ja estudiades. El seu model de cost, es pot simplificar de forma:

Resolució del problema amb model d’optimització dinàmic

Inicialment s’executen les operacions unàries de selecció i projecció. En aquest cas, cal executar l’operació de selecció que hi ha sobre la relació U. Com que la relació U’ té un índex per l’atribut nom, aquest índex es fa servir per a l’execució de l’operació de selecció i per tant el seu cost és:

Pas 2) S’ordenen les relacions per la seva grandària i s’executa una operació de join. El seu cost és igual a 600K Aquest ordre és:

Com que la relació més petita és la relació S, l’operació que s’executa és:

El cost d’execució de l’operació de join és:

Com que les dues relacions tenen un índex per l’atribut de join, podem suposar que es fa un accés per índex i que el cost de procés és igual a:

Per tant, el cost d’aquest segon pas de l’estratègia és igual a 600K.

186

Pas 3) S’ordenen les relacions per la seva grandària i s’executa una operació de join. El seu cost és igual a 603K Les relacions resultants són:

L’ordre de les relacions és: En aquest cas el join que s’executa és:

El cost d’execució de l’operació de join és:

Si suposem que U’ té un índex per l’atribut c i com que sabem que la relació T també té un índex per l’atribut c, el cost de procés del join és:

Per tant, el cost d’aquest tercer pas de l’estratègia és igual a 603K Pas 4) Com que només queden dues relacions, s’executa el join que falta. El seu cost és igual a 100M2. Les dades de les relacions que queden són:

En aquest cas el join que s’executa és:

Com que la relació més petita de les dues és UT, és aquesta la que s’envia. El cost de comunicació

Si llavors suposem que els factors de selectivitat de les relacions no s’han modificat, podem afirmar que:

187

El cost de procés del Resultat és:

Aquest cost és molt gran, ja que cap de les relacions UT i SR tenen un índex per l’atribut b de join.

Per tant, el cost total d’aquest quart pas de l’estratègia és igual a

Llavors el cost total de l’estratègia d’execució és la suma del tots els costos, i aquest és igual a:

Per tant, COST D’EXECUCIÓ ESTRATÈGIA DINÀMICA = 100M3

Resolució del problema amb model d’optimització estàtic

Inicialment es construeix l’arbre amb totes les possibles operacions de join de dues relacions. Aquest és:

A continuació cal simplificar l’arbre anterior mitjançant el càlcul del cost d’execució de les diferents estratègies. En aquestes, els models de cost per l’operació R join S són:

188

De les dues operacions de join, la millor és

De les dues operacions de join, la millor és

A partir dels costos calculats, es poden eliminar de l’arbre les operacions

. En aquest cas, amb les operacions restants s’afegeixen les noves operacions de join amb una relació més i queda l’arbre següent.

189

Ara cal calcular el cost de les diferents peticions. Primer es calcula la cardinalitat i la grandària de les relacions que s’han obtingut en la fase anterior i després ja es pot calcular el cost d’execució de les peticions noves El cost d’execució de les peticions és:

Les operacions resultants són:

A continuació cal completar les operacions anteriors. Les estratègies finals són:

190

El cost de les estratègies és:

El cost total de les dues estratègies finals és: En aquest cas hi ha molt poca diferència entre les dues estratègies d’execució, encara que la segona és la millor.

RESUM En aquesta sessió s’han resolt dos exercicis sobre optimitzadors basats en l’ordenació de joins. S’han fet dos exercicis on s’ha estudiat la generació i càlcul del cost d’estratègies amb models estàtics i dinàmics.

191

SESSIÓ 29 Nom: Introducció al control de concurrència Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la primera sessió del capítol de control de concurrència. Un cop ja es coneix el funcionament bàsic d’un sistema gestor distribuït cal analitzar els mecanismes que aquest fa servir per tal de garantir la consistència de la informació.

OBJECTIUS En aquesta sessió s’introdueixen els conceptes bàsics referents al control de concurrència i la gestió de les transaccions distribuïdes.

CONTINGUTS En aquesta sessió es tracta la problemàtica de la gestió de les transaccions distribuïdes. Per fer-ho es comença amb l’estudi dels conceptes associats a la gestió de les transaccions i llavors s’estudien els conceptes de control de concurrència.

5. Control de concurrència

5.1. Introducció En aquest tema es fa una introducció a la gestió de les transaccions i el control de concurrència justificant la seva utilització.

Introducció a la gestió de transaccions

Tal com ja hem vist a les darreres sessions, els sistemes gestors executen peticions donades amb càlcul relacional mitjançant l'obtenció d'estratègies. Ara bé, aquestes operacions es poden executar dintre de transaccions, cosa que dificulta la seva resolució. Llavors, les transaccions sempre han de contemplar les propietats ACID, tal com s'exposa a continuació.

192

Atomicitat

Un conjunt d'operacions són atòmiques si s'executen totes o cap d'elles. Per tant, la propietat d'atomicitat indica que les operacions que formen una transacció s'han de tractar com una única operació. Això requereix que si l'execució d'una transacció s'atura per qualsevol motiu, el sistema gestor s'encarrega de decidir què fer amb la transacció quan pugui seguir funcionant. En aquest cas hi ha dues alternatives: Acabar la transacció amb les operacions que falten o bé desfer les modificacions ja fetes durant l'execució de la transacció. Hi ha dos tipus d'errors que poden aturar l'execució d'una transacció. Aquests són: a) De la mateixa transacció. Estan provocats per errors d'entrada de dades, bloqueig o esperes per a garantir la consistència de la informació. La tècnica per a mantenir l'atomicitat de la transacció durant aquest tipus d'error és la recuperació de transaccions o Transaction Recovery (TR). b) Del sistema. Són els errors que es presenten per la caiguda del sistema, CPU o problemes en les comunicacions. Per mantenir l'atomicitat durant aquest tipus d'error s'utilitzen tècniques de recuperació de caigudes o Crash Recovery (CR).

Consistència

La consistència és la propietat que s'encarrega de portar la base de dades d'un estat consistent a un altre estat consistent. La consistència d'una base de dades pot tenir diferents nivells, que van del nivell 0 (menor consistència) al nivell 3 (màxima consistència). Les característiques de cada nivell de consistència són: Nivell 3. a) Una transacció no pot modificar Dirty Data d'altres transaccions. b) Una transacció no actualitza (commit) cap operació d'escriptura fins que no acaba amb totes les operacions d'escriptura. O sigui, que l'actualització de totes les operacions d'escriptura les fa al final de la transacció. c)Una transacció no pot llegir Dirty Data d'altres transaccions. d)Altres transaccions no produeixen cap Dirty Data llegit per la transacció abans que aquesta acabi. Nivell 2. Característiques a, b, c del nivell 3. Nivell 1. Característiques a i b del nivell 3. Nivell 0. Característica a del nivell 3.

Aïllament

L'aïllament és la propietat de les transaccions que requereix que cada transacció sempre vegi la base de dades en un estat consistent. Per aconseguir-ho, una transacció no pot actualitzar els seus canvis fins que arribi al seu final o commit.

193

D'aquesta forma, en assegurar l'aïllament s'aconsegueix que la informació llegida per qualsevol transició és correcta. Tanmateix amb l'aïllament s'eviten els avortaments en cascada, ja que si una transacció deixa veure a la resta de transaccions el resultat de les seves modificacions abans del seu commit, si aquesta acaba amb un avortament, la resta de transaccions també han de desfer els canvis fets a partir d'aquesta informació llegida (Dirty Data).

Durabilitat

La durabilitat és la propietat de les transaccions que assegura que un cop una transacció ha executat satisfactòriament una operació de commit, els seus resultats són permanents i no es perdran de la base de dades. A partir de les propietats ACID que han de garantir els sistemes transaccionals es garanteix que la informació memoritzada pel sistema gestor sigui sempre consistent. Les solucions habituals garanteixen aquestes propietats, però fan que els sistemes amb moltes transaccions actives i amb probabilitat de conflictes gran, el seu rendiment sigui dolent. Actualment s’intenta trobar alternatives per aquestes situacions que tinguin un rendiment millor. Hi ha propostes que relaxen la propietat de l'atomicitat per tal de millorar el seu rendiment. També hi ha alternatives amb transaccions d'operacions de només lectura. La problemàtica de la gestió de les transaccions està força relacionada amb el control de concurrència, tal com es veu en l'apartat següent.

Control de concurrència

En aquest tema es descriu la necessitat del control de concurrència per mantenir la consistència de la informació. S’analitza el problema del control de concurrència en entorns transaccionals i amb existència de replicació. Un dels principals problemes dels sistemes gestors centralitzats dels sistemes gestors distribuïts és el control de concurrència, sobretot en sistemes transaccionals i amb existència de replicació d'informació. Tal com s'ha vist a l'apartat anterior, el control de concurrència és un aspecte força crític a contemplar en els sistemes gestors. A continuació es detallen els seus principals objectius i es presenten les idees bàsiques per la seva solució. El control de concurrència apareix quan hi ha una dada o informació sobre la que diferents processos hi volen fer operacions de lectura i/o escriptura. Si tots els processos només llegeixen la dada, el funcionament sempre serà correcte. Ara bé, els problemes apareixen quan hi ha més d'un procés que vol modificar la dada. En aquest cas, es poden presentar inconsistències en el valor de la dada. Per exemple, si dos processos llegeixen alhora el valor de la dada i després la volen modificar de forma independent, es pot assegurar que les modificacions d'un procés no seran efectives, ja que l'altre procés actualitzarà els seus canvis. Per tant, cal un

194

mecanisme que asseguri que això no passi, essent aquest el control de concurrència. Aquest problema es complica amb l'existència de transaccions, i sobretot si es tracta d'un sistema distribuït i amb existència de replicació en les seves dades. Una solució inicial per tal d'assegurar l'exclusió mútua d'aquestes operacions de lectura/escriptura, és la utilització d'adquisicions de les dades. El principal problema d'aquesta solució rau en el fet que les adquisicions de les dades acostumen a incrementar la contenció del sistema, sobretot quan hi ha transaccions llargues i en sistemes amb un nivell de concurrència gran. Llavors els algorismes de control de concurrència intenten incrementar el nivell de concurrència, mantenint sempre la consistència de la informació. Hi ha tres tipus diferents d'algorismes de control de concurrència: basats en adquisicions, basats en l'ordenació temporal de les operacions i els optimistes. Els algorismes basats en adquisicions i ordenació temporal de les operacions acostumen a ser pessimistes i els optimistes utilitzen de forma mixta adquisicions i marques temporals TS en la seva implementació. Els algorismes pessimistes són els algorismes que sempre assumeixen que hi pot haver un conflicte, i validen la compatibilitat de les operacions per a cada petició d'operació. Els algorismes optimistes són els algorismes que no validen la compatibilitat de les operacions abans d'executar-les, però al final de la transacció si que validen totes les operacions. L’algorisme de control de concurrència més utilitzat en els sistemes comercials és el Strict Two Phase Locking S2PL. Aquest algorisme és pessimista i està basat en l'adquisició de la informació quan hi ha una petició d'operació sobre ella. Si una altra transacció vol adquirir llavors aquesta informació, abans ha que validar la seva compatibilitat d’adquisicions. Si l'operació no és possible, la transacció ha d'esperar fins que ho sigui i llavors adquirir el bloqueig i fer l'operació. En aquesta situació, apareixen esperes de transaccions, amb la qual cosa poden haver-hi bloquejos. Per aquest motiu, el sistema ha de detectar i resoldre els bloquejos, cosa que provoca una càrrega addicional del sistema que provoca una disminució del seu rendiment. Per tal d'evitar aquesta sobrecàrrega del sistema, hi ha variants de l'algorisme S2PL que eviten l'existència dels bloquejos. És el cas dels algorismes Wound Wait Two Phase Locking WW2PL i Distributed Time Ordering DTO, que aporten tècniques preventives dels bloquejos. Aquests algorismes fan servir Marques Temporals TS associades a les operacions de les transaccions, fent que les esperes del sistema sempre siguin acícliques. Tot això va força bé per a sistemes amb un nivell de contenció gran, però en sistemes amb menys probabilitat de conflictes els algorismes optimistes donen millors rendiments. Un d'aquests algorismes és el Optimistic Distributed Time Ordering ODTO. En aquest algorisme l'execució de qualsevol operació segueix quatre fases: lectura, procés, validació i actualització. Les fases de lectura, procés i validació es fan sense modificar la BD. En la fase de validació és verifica que totes les operacions mantenen la consistència del sistema. Llavors, si hi ha consistència, es modifica la BD, i en cas contrari s'avorta la transacció.

195

Ara bé, tots aquests algorismes mantenen sempre la consistència de la informació, ja que produeixen estratègies serialitzables. Tal com s'ha vist, el control de concurrència és un dels aspectes més importants que afecten el rendiment dels sistemes gestors. Per aquest motiu és una línia de recerca força activa en l'actualitat amb què es pretenen millorar els algorismes actuals o cercar nous algorismes que permetin un increment del rendiment del sistema.

RESUM En aquesta sessió s’han introduït els conceptes bàsics referents a la gestió de les transaccions distribuïdes. Inicialment s’han estudiat els conceptes associats a la gestió de les transaccions i llavors s’ha analitzat el control de concurrència.

197

SESSIÓ 30 Nom: Arquitectura Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la segona sessió del capítol de control de concurrència. Un cop ja es coneixen els conceptes bàsics del control de concurrència, s’analitza l’arquitectura bàsica que ha de suportar els algorismes de control de concurrència.

OBJECTIUS En aquesta sessió s’introdueix l’arquitectura bàsica de suport dels algorismes de control de concurrència.

CONTINGUTS En aquesta sessió es tracta la problemàtica de l’arquitectura dels algorismes que donen suport al control de concurrència.

5.2. Arquitectura En aquest tema es presenta una arquitectura bàsica dels sistemes gestors que ens permetrà l’estudi dels principals algorismes de control de concurrència. Inicialment s’analitzen els elements que formen el sistema i a continuació es detalla el comportament de cada un d'aquests així com l'estructura dels algorismes utilitzats per modelar el sistema.

Consideracions arquitectòniques

El model bàsic d’un sistema gestor està format per un conjunt de clients i servidors. Els clients s'encarreguen d'enviar les peticions als servidors. Llavors, els servidors s'encarreguen de l'execució de les peticions i retornen el resultat als clients que havien fet la petició. Com que el sistema disposa de transparència de xarxa, el client no coneix cap detall relatiu a l’estructura o implementació del sistema. Llavors, el sistema està format per dos tipus d'elements: Clients i Servidors.

198

Els clients envien les peticions a executar a qualsevol dels servidors del sistema i esperen la resposta de la seva execució. Els servidors s’encarreguen d'executar les operacions enviades pels clients i els hi retornen el resultat de la seva execució. Cada node del sistema gestor està dividit en tres subsistemes:

Gestor de Transaccions TM

Coordina l'execució de les operacions de les transaccions. Aquest accedeix al diccionari de dades del sistema que conté l’Esquema Global Conceptual GCS per tal de conèixer si les dades estan replicades i els nodes en què aquestes estan ubicades. Utilitza dues estructures de dades que són: Participants i Marques Temporals. L'estructura Participants es fa servir pel TM per guardar els nodes que participen en l'execució de les operacions d'una transacció. L'estructura Marques Temporals es fa servir pel TM per guardar els TSs dels diferents nodes i així poder generar un TS virtual global.

Gestor de Control de Concurrència CCM

Implementa els algorismes de control de concurrència. El CCM utilitza dues estructures: Adquisicions i LWFG. L’estructura Adquisicions s’utilitza per guardar la informació relativa a les adquisicions de les variables i dels darrers TSs de les operacions que han llegit o modificat les variables. L’estructura LWFG s’utilitza per guardar les esperes que hi ha entre les diferents transaccions i així poder aplicar mecanismes que detectin situacions de bloqueig locals al node i participar en la detecció de situacions de bloqueig distribuïts.

Processador de Dades DP

Accedeix i modifica la informació que està a l’estructura Information. Per tal de poder gestionar correctament les operacions d’acabament de les transaccions s’utilitza l’estructura Log.

199

A continuació es detalla el funcionament dels diferents sistemes mostrat a l’arquitectura del sistema gestor. 1.- Client. El client envia operacions a un node a través de la xarxa agrupades en transaccions. Per tal de simplificar l’estudi dels diferents algorismes, es pot suposar que cada client envia les operacions de la transacció a un sol node del sistema, el qual passa a ser el coordinador de la transacció. Cal tenir present que per poder començar una nova transacció, el Client sempre ha d'esperar que la transacció anterior que ha llençat finalitzi. Tanmateix, les operacions que hi ha en les transaccions estan ordenades, i abans de poder enviar una nova operació al servidor corresponent, s'ha d'esperar que l'operació anterior s'hagi executat satisfactòriament. Les operacions que envia el Client al Servidor que té assignat són:

• Begin. Indica un inici de transacció. • Read. Dóna una ordre d'operació de lectura sobre una variable. • Write. Dóna una ordre d'operació d'escriptura d'una variable. • Commit. Indica que la transacció s'ha acabat satisfactòriament. • Abort. Indica un acabament incorrecte de la transacció.

Les operacions de Read i Write sempre tenen associat un tipus d'adquisició, el qual indica el nivell de protecció a aplicar a la dada. Hi ha dos tipus diferents d'adquisició, que són: Read i Write. A la taula següent es mostra la utilització d'aquests tipus d'adquisició amb les operacions de lectura i escriptura.

A partir de la combinació de les operacions i adquisicions de la taula anterior es pot garantir un nivell de consistència màxim en un entorn transaccional. Les regles que aquesta consistència ha de garantir són:

• Una transacció no pot modificar ni llegir cap Dirty Data d'altres transaccions. • Cap transacció pot produir Dirty Data llegit per una altra transacció abans que

aquesta acabi. • Una transacció sempre ha d'actualitzar totes les operacions d'escriptura al final

de la transacció. Per tant, és el Client el que s'encarrega de decidir el tipus d'adquisició associada a les operacions en funció del tipus de tractament que ha de fer amb les variables. En el cas de les operacions d'escriptura, l'adquisició sempre és d'escriptura. És doncs en les operacions de lectura quan el Client ha de decidir el tipus d'adquisició que vol utilitzar. El Client pot rebre dos tipus de respostes: Acknowledge (Ack) o Not Acknowledge (Not\-Ack).

200

• Ack. Indica que l'operació s'ha acabat correctament i ja pot enviar l'operació següent.

• NotAck. Indica que s'ha produït algun problema i l'operació no s'ha executat correctament.

Una forma de modelar la càrrega del sistema és modificant el nombre de transaccions que cada client va enviant per unitat de temps. Per fer-ho es va variant el temps que hi ha entre que una transacció acaba i comença la següent. Com més petit sigui aquest temps, més es carrega el sistema. Si una transacció acaba satisfactòriament, aquest temps s'anomena THINKTIME i si la transacció acaba amb una operació d'Abort, aquest temps és RESTARTTIME. 2.- Gestor de transaccions. El TM és l'encarregat de coordinar l'execució de les operacions que hi ha en les transaccions. El model utilitzat per la coordinació de l'execució d'una operació és centralitzat, ja que aquesta la resol un sol TM. El TM s'encarrega de decidir en quin o quins nodes s'ha d'executar una operació, i per tant, de sincronitzar l'execució d'operacions que utilitzen les rèpliques de la informació. Les operacions que pot rebre el TM són: Begin, Read, Write, Commit i Abort. La gestió d'aquestes operacions per part del TM pot canviar en funció de l'algorisme de control de concurrència utilitzat. A continuació es descriu el procés habitual de gestió d'aquestes operacions. a) Quan el TM rep una operació de Begin només ha d'inicialitzar l'estructura dels nodes que han participat en l'execució de les operacions en la transacció i contestar al Client amb un missatge d'Ack indicant que l'operació s'ha executat satisfactòriament. b) Quan el TM rep una operació de lectura o escriptura, s'encarrega d'enviar l'operació al node o nodes involucrats en la seva execució. En funció del tipus d'operació, adquisició i nivell de replicació, es poden distingir tres escenaris diferents d'execució.

• Execució local. El TM envia la petició de forma local al seu CCM. En aquest cas l'execució es fa de forma totalment local i autònoma en el node coordinador. Un exemple d'aquest tipus es dóna quan el TM rep una petició de lectura amb adquisició de lectura d'una variable que té localment.

• Execució distribuïda d'una fase. El TM ha de fer una operació sobre una dada que no té localment. En aquest cas, envia l'operació a un altre node que té la dada per tal que aquest la resolgui. Un cop el TM rep la resposta de l'altre TM conforme l’operació ja s'ha executat, ho informa al Client.

• Execució distribuïda de dues fases. En aquest cas, el TM ha d'enviar l'operació a un conjunt de nodes. Ara bé, com que aquesta operació ha de ser atòmica, no es pot enviar directament. Llavors es segueix un protocol de dues fases. A la primera fase, el TM envia un missatge de Lock a tots els nodes que tenen la dada, i en el moment en què tots han contestat satisfactòriament, comença la segona fase enviant l’operació a tots ells. Un cop tots els nodes han executat l'operació enviada en la segona fase, el TM coordinador contesta al Client indicant que l'operació s'ha executat.

201

c) Quan el TM rep una operació de Commit o Abort, ha de propagar l'operació a tots els nodes que han participat en l'execució de les operacions de la transacció. En aquest cas, el TM envia un missatge a tots els nodes participants i a mesura que rep les respostes dels diferents participants va actualitzant l'estructura Participants, fins que ja han contestat tots ells, llavors envia un missatge d'Ack al Client. 3.- Gestor de control de concurrència. El CCM és el subsistema que coordina l'execució de les operacions rebudes des del TM d'acord amb l'algorisme de control de concurrència emprat. Quan el CCM rep una operació des del TM, primer valida si es pot realitzar o no. Si l'operació es pot executar, el CCM envia l'operació cap al processador de dades DP i espera una resposta d'aquest. Però si el CCM rep una operació que no es pot processar per culpa d'un problema de compatibilitat amb altres operacions d'altres transaccions, llavors produirà diferents tractaments o reaccions depenent de l'algorisme de control de concurrència utilitzat. Aquesta acció consistirà sempre en una espera o un Abort de la transacció, el que equival a enviar un missatge de NotAck al TM coordinador de l'execució de la transacció. Els criteris que fa servir el CCM estan basats en adquisicions de les variables o en la utilització de marques temporals TS associades a les operacions i variables. Per aquest motiu el CCM requereix d'una estructura de dades per guardar aquestes informacions. El CCM és doncs l'encarregat de decidir la compatibilitat de les operacions, i per tant, el seu funcionament és diferent entre els diferents algorismes de control de concurrència. 4.- Processador de dades. El DP s'encarrega d'executar les operacions provinents del CCM i que poden ser: Read, Write, Commit o Abort. Quan el DP rep una operació de lectura, llegeix la informació i envia el resultat al CCM amb un missatge d'Ack. Si el DP rep una operació d'escriptura, modifica la informació i contesta amb un missatge d'Ack. Quan el DP rep un Commit, actualitza a disc tota la informació modificada per la transacció. Si el que rep és una operació d'Abort, el DP desfà les modificacions fetes per la transacció i ho deixa tal com estava abans de l'inici de la transacció. Amb aquest model, el DP ha d'executar les operacions tal com les hi envia el DP, cosa que sempre permet garantir la consistència de la informació. El DP ha de gestionar l'estructura de log per tal de poder recular les operacions fetes quan rep una ordre d'execució d'un Abort. Un cop hem vist l’arquitectura i les principals funcionalitats dels diferents subsistemes, a continuació es descriu la notació emprada en els algorismes utilitzats per modelar el sistema. La comunicació entre els diferents subsistemes sempre es fa mitjançant missatges a partir de les funcions Send i Receive. 1.- Send. S'utilitza per enviar un missatge a un altre component. 2.- Receive. S'utilitza per rebre un missatge d'un altre component.

202

Els paràmetres utilitzats per les funcions Send i Receive són dos: Informació per indicar la informació que es vol enviar o rebre i Canal de Comunicació que és el canal emprat per enviar o rebre la informació detallada en el primer paràmetre. El Canal de Comunicació emprat per enviar dades entre dos components locals sempre està format per l'identificador del node destí. Així doncs, Send(Info, DP) vol dir que s'envia el contingut de l'estructura Info al processador de dades DP. De la mateixa forma, Receive(Info, DP) és la funció que es fa servir per rebre un missatge del DP i guardar el seu contingut a l'estructura Info. La comunicació entre dos components no locals segueix el mateix conveni i es fa de la forma següent: 1.- Des del Client. Amb Send(Info, Network.TM) per enviar el contingut de l'estructura Info del Client al TM. Amb Receive(Info, Network.C) quan el Client vol rebre una informació a traves de la xarxa. 2.- Des del Gestor de Transaccions. Amb Send(Info, Network.C) per enviar el contingut de l'estructura Info del TM al Client. Amb Send(Info, TM.Site) per enviar el contingut de l'estructura Info del TM al TM del node Site. Amb Receive(Info, Network.C) quan el TM rep un missatge del Client i amb Receive(Info, TM.Site) quan el TM rep un missatge d'un altre TM del node Site. Per tal de simplificar els algorismes, també es fa servir una funció de comunicació de més alt nivell. Aquesta és la funció SendCCM(Info, Site). En aquest cas, si el node local és el node que es dóna com a segon paràmetre, s'envia Info al CCM local mitjançant la funció Send(Info, CCM). Ara bé, si el Site donat no és el node local, la informació s'envia al TM del node indicat per Site amb la funció Send(Info, TM.Site). D'aquesta forma es pot expressar qualsevol comunicació entre els Clients, TM's, CCM's i DP's.

[Tamer1999] p274-p297

RESUM En aquesta sessió s’ha presentat l’arquitectura base i la notació que fan servir els algorismes de control de concurrència.

203

SESSIÓ 31 Nom: Transaccions i serialització Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la tercera sessió del capítol de control de concurrència. A les sessions anteriors s’han estudiat els conceptes bàsics relatius a les transaccions, control de concurrència i arquitectura.

OBJECTIUS En aquesta sessió es defineixen i caracteritzen les transaccions per finalitzar amb la justificació de la teoria de la serialització com a criteri que garanteix la consistència de la informació en entorns transaccionals i amb existència de replicació

CONTINGUTS En aquesta sessió es defineixen les transaccions. Es segueix amb la seva caracterització i a continuació s’estudia la teoria de la serialització. En aquest tema es defineixen i caracteritzen les transaccions.

Transaccions

Hi ha situacions, tant en els sistemes gestors centralitzats com en els sistemes gestors distribuïts, en què per garantir la consistència de la informació, han d'existir transaccions. Una situació habitual és quan una sola petició SQL modifica un conjunt de tuples d'una relació. Si durant el procés de modificació hi ha alguna tupla que no es pot modificar o senzillament hi ha algun problema en el sistema, cal que es garanteixi que es modifiquin totes les tuples afectades o cap d'elles. En aquest cas es tracta d'una situació en la qual apareix el concepte de transacció. Aquest tipus de transaccions estan sempre associades a les peticions SQL, podent afirmar que una petició SQL sempre s'ha de tractar com una transacció, i que sempre ha de garantir les propietats ACID. Hi ha situacions en què interessa que una transacció inclogui més d'una petició SQL, ja que per garantir la consistència d'una operació, cal modificar més d'una relació del sistema. En aquest cas, cal modificar totes les relacions involucrades en l'operació o cap d'elles. En els SGBDD amb existència de replicació aquest problema encara és més crític, ja que si una dada està replicada entre els diferents nodes del sistema, el valor de totes les còpies sempre ha de ser el mateix, per la qual cosa cal tractar les

204

operacions de modificació de totes les repliques com una operació indivisible o atòmica. Tal com es pot observar a la figura següent, una base de dades sempre evoluciona entre estats consistents (Ei i Ek), però per fer-ho es pot donar el cas que passi per estats inconsistents (Ej). Ara bé, els mecanismes de control del sistema gestor han de garantir que quan el sistema estigui en un estat inconsistent (Ej), aquesta situació no es vegi per la resta de transaccions. Per tant, els mecanismes de control del sistema gestor han de garantir que encara que el sistema estigui momentàniament en un estat inconsistent, sempre vagi a un estat destí consistent. Una transacció es pot definir com una unitat de computació consistent i fiable que s'ha de dur a terme atòmicament respecte les altres transaccions. Llavors, els estats de la BD a l'inici i a la fi d'una transacció sempre han de ser consistents.

L'inici de les transaccions es defineix mitjançant la sentència BeginTransaction o BeginWork (Estat Ei), i el final amb la sentència Commit o Abort. El significat de BeginTransaction i BeginWork és el mateix i indica el punt de sincronisme inicial on comença la transacció. Aquesta operació es pot indicar amb la sentència Begin. El significat de la sentència de finalització d'una transacció és diferent i pot ser: 1.- Commit. Indica que la transacció ha acabat satisfactòriament i cal actualitzar totes les modificacions fetes durant l'execució de la transacció. 2.- Abort. Indica que la transacció no ha acabat satisfactòriament i cal desfer totes les modificacions fetes durant l'execució de la transacció. Aquesta sentència d’Abort pot estar provocada pel mateix usuari perquè desitja cancel·lar la transacció o bé pel propi sistema com a resultat d'un error o problema detectat. Al procés de deixar el sistema en l'estat inicial consistent abans de l'inici de la transacció (Ei) s'acostuma a definir com a procés de Rollback. Les operacions bàsiques que fan les transaccions són de lectura i escriptura. Aquestes operacions es fan sobre un conjunt de variables que es defineixen de forma: RS. Read Set que és el conjunt de variables llegides per la transacció. WS. Write Set que és el conjunt de variables modificades per la transacció. BS. Base Set que és el conjunt de totes les variables llegides i/o modificades per la transacció, o sigui que

205

El conjunt OSi es defineix com el conjunt de totes les operacions de lectura i escriptura d'una transacció i es dóna a partir de l'expressió OSi= Uj Oij, on Oij és l'operació j de la transacció i, i les operacions Oij són operacions de lectura o escriptura. Utilitzant aquesta notació, una operació de lectura sobre la variable x de la transacció i s'indica amb ri(x), on la variable de l'operació es dóna de forma x=var(ri(x)) o de forma més genèrica var(Oij) és la variable emprada per l'operació Oij. L'operació d'escriptura s'indica amb wi(x) i l'operació d'acabament d'una transacció, Commit(ci) o Abort(ai) es defineix com Ni. L'operació d'inici de la transacció sempre és una operació de begin o bi. Seguint aquesta notació, una transacció es caracteritza a partir d'un ordre parcial sobre les seves operacions, l'operació d'inici de transacció i la condició d'acabament. Aquest és:

Llavors es poden caracteritzar els requeriments de l'estructura interna d'una transacció com:

Caracterització interna d'una transacció

a) Al conjunt de totes les operacions cal incloure les operacions d'acabament.

b) Per qualsevol operació cal definir l'ordre d'execució de les operacions de forma que c) L'operació d'acabament de la transacció sempre és la darrera operació. Per totes les operacions Oij que estan al conjunt d) L’operació d’inici de la transacció sempre és la primera operació. Per totes les operacions Oij que estan al conjunt . Una altra forma més simple d'expressar una transacció és ordenant les operacions. Per exemple:

En aquest cas, el principi de la transacció s'indica amb l'operació Begin o bi, ja que pertany a la transacció i. En el cas d'un sistema gestor s'executen transaccions de forma concurrent. Per donar l'ordre d'execució de totes les operacions de les transaccions es segueix la notació anterior. Llavors poden aparèixer operacions conflictives, que es defineixen com:

206

Dues operacions Oij, Okl que estan al conjunt ∑ són conflictives si al menys una d'elles és una operació d'escriptura i són de diferents transaccions (i≠k). Llavors, a partir de l'ordre i tipus d'operacions es pot definir un pla com: Un Pla o Schedule S es defineix com el conjunt de totes les operacions i el seu ordre de forma:

1.- Les operacions del pla són la unió de les operacions de totes les transaccions.

2.- Es mantenen els ordres d'execució de les operacions de cada transacció.

3.- Cal definir sempre l'ordre d'execució de les operacions conflictives. Per totes les operacions conflictives

Segons això, també es pot donar un Pla de forma:

Al pla S anterior hi ha dues transaccions Ti i Tj, i es pot observar que les seves operacions s'executen de forma concurrent. En aquest cas, com les dues transaccions treballen amb variables diferents, no hi ha cap conflicte. Seguidament es presenten les dues situacions habituals en què l'execució del pla S provoca una inconsistència. 1.- Dirty Read.

La transacció Tj llegeix un valor modificat de la variable x per part de la transacció Ti. Com la transacció Ti acaba amb ai, el valor llegit per Tj és un valor incorrecte o Dirty Read. Per evitar aquest problema, una transacció no pot llegir un valor modificat d'una variable per un altra transacció abans que aquesta acabi. 2.- Repeteable Read.

Segons l'ordre d'execució de les dues transaccions, la variable x es llegida de forma consecutiva per les transaccions per modificar-la a continuació. Per tant, com que la transacció que executa el darrer Commit és la Ti, es perdrà el valor modificat per Tj amb la qual cosa es produeix una inconsistència en la informació. Aquest problema s'anomena Non-Repeteable Read, ja que si la transacció Ti torna a llegir el valor d’x

207

abans d'executar ci, el valor llegit seria diferent que el llegit al principi del pla. Per evitar aquest problema, una transacció no pot modificar un valor llegit per una altra transacció. Per garantir la consistència de la informació s'han d'evitar les situacions de Dirty Read i Non-Repeteable Read. Ara bé, per tal que el sistema tingui un bon rendiment, s'ha d'intentar augmentar el seu nivell de concurrència, ja que hi ha solucions que ofereixen consistència però amb un nivell de concurrència dolent. Un algorisme de control de concurrència és l'algorisme que s'encarrega de donar una estratègia d'execució que garanteixi la consistència de la informació a partir de qualsevol ordre d'entrada. Ara bé, si es disposa d'algun tipus d'informació del tipus de transaccions, l'algorisme pot generar l'estratègia d'una forma més òptima. Seguidament hi ha una classificació en funció de l'ordre de les operacions en les transaccions. • General. No hi ha cap ordre predeterminat entre les operacions de les

transaccions. Ti = { bi, ri(x), wi(x), ri(z), wi(y), wi(z), ci}

• Dues Fases. Quan totes les operacions de lectura es fan abans de les operacions

d'escriptura. Ti = { bi, ri(x), ri(z), wi(x), wi(y), wi(z), ci} • Restringides. Quan sempre que s'ha de modificar una variable aquesta s'ha

d'haver llegit. Ti = { bi, ri(x), ri(z), wi(x), ri(y), wi(y), wi(z), ci} • Restringides Dues Fases. Quan sempre es llegeixen primer totes les variables

que després s'han de modificar i totes les operacions de lectura es fan abans que les d'escriptura. Ti = { bi, ri(x), ri(z), ri(y), wi(x), wi(y), wi(z), ci}

• Atòmiques. Segueix el model restringit, però les operacions de lectura i

d'escriptura d'una variable són consecutives. Ti = { bi, ri(x), wi(x), ri(z), wi(z), ri(y), wi(y), ci}

Un altra forma de classificar les transaccions és segons la seva durada. Segons això n'hi ha de dos tipus: OnLine si el seu temps d'execució de la transacció és curt i LongLife per a temps de resposta grans. Un altra classificació depèn de com s'estructuren les transaccions: Planes o Aniuades. 1.- Les transaccions planes són aquelles transaccions que tenen un punt d'inici Begin i un sol punt d'acabament Commit o Abort. 2.- Les transaccions aniuades són aquelles que permeten incloure altres transaccions dintre d'elles. En els apartats i temes que es presenten a continuació sempre es suposa que les transaccions són OnLine, Generals i Planes.

208

5.3. Teoria de la serialització En aquest tema es presenta la teoria de la serialització. Aquesta defineix els criteris que han de seguir els algorismes de control de concurrència per tal de generar estratègies d’execució que garanteixin la consistència de la informació. Tal com s'ha vist a l'apartat anterior, cal aïllar l'execució de les transaccions per tal d'evitar conflictes. Una manera de fer-ho es executant primer les operacions d'una transacció, i després les d'un altra transacció. D'aquesta forma s'assegura que no hi ha conflictes, però el rendiment del sistema és dolent, ja que no hi ha cap concurrència. Cal dons trobar un mètode que permeti obtenir un pla en el que s'augmenti el nivell de concurrència però sempre mantenint la consistència de la informació. Una forma d'assegurar que un pla no provoca cap inconsistència és que el pla sigui serialitzable. A continuació es defineix aquest concepte de serialització i es justifica que sempre dóna un pla que no provoca inconsistències.

Pla Sèrie

Un pla és sèrie si les operacions de les transaccions no s'executen entrellaçades, o sigui, que primer s'executen les d'una transacció, després les d'un altra transacció i així fins executar les operacions de totes les transaccions. Un pla és sèrie i es representa de forma Ss. Exemple de pla sèrie:

En aquest exemple hi ha tres transaccions que són Ti, Tj i Tk. Primer s'executen les operacions de la transacció Ti, després les operacions de la transacció Tj i després les de la transacció Tk. Es pot observar que l'ordre d'execució de les operacions de begin és irrellevant. Per aquest motiu normalment no cal indicar les operacions de begin en un pla. Ara bé, les operacions d'acabament si que han d'estar agrupades amb les operacions de lectura i escriptura de cada transacció. Una altra forma simplificada d'indicar aquesta execució sèrie de les operacions és:

En el cas d'executar un pla sèrie, es pot assegurar que sempre es manté la consistència de la informació, ja que no hi ha concurrència entre les operacions de les diferents transaccions, i per tant, no hi ha cap tipus de problema. Ara bé, cal tenir present que donada una estratègia, els diferents plans sèrie no tenen perquè deixar la base de dades en la mateixa situació final, encara que tots ells siguin correctes. En aquest exemple es pot observar que al executar dos plans sèrie correctes (Ss1 i Ss2) el valor final de la variable x no és el mateix.

209

L'operació de computació de la Ti sobre la variable x és x=x+5 i la de la Tj és x=x*10. Si suposem que el valor inicial d’x és 1, el resultat d'execució dels dos possibles plans sèrie és:

El resultat d'execució de les dues estratègies és diferent, però les dues execucions donen un resultat consistent.

Plans equivalents de conflictes

Al executar operacions de diferents transaccions hi ha operacions que són compatibles i operacions que no són compatibles, tal com es pot veure a la taula següent.

Les operacions no compatibles són les que provoquen les inconsistències en la informació, i per tant caldrà vigilar en la seva execució. Segons la taula anterior podem definir que: - Dues operacions són incompatibles si al menys una d'elles és una operació d'escriptura, sempre i quan les dues operacions es refereixen a la mateixa variable. - Dos plans són equivalents en conflictes si totes les operacions conflictives s'executen en ells en el mateix ordre.

Pla serialitzable

Un pla és serialitzable Sse si totes les operacions conflictives de Sse s'executen en el mateix ordre que un pla sèrie Ss. Això vol dir que és equivalent en conflictes en un pla sèrie. O sigui, que sempre es pot afirmar que Sse econf Ss. Exemple de pla no serialitzable:

S1 no és un pla serialitzable. Si s'analitza l'ordre d'execució de les operacions conflictives es veu que no totes les operacions conflictives s'executen en el mateix ordre que un pla sèrie, de manera que S1 no és serialitzable.

210

Analitzant amb detall l'exemple anterior s'observa que l'operació que provoca que S1 no sigui serialitzable és ri(x). Si aquesta s'executa després de l'operació cj el pla és serialitzable. De fet, això és trivial, ja que llavors S1 és un pla sèrie, i evidentment un pla sèrie és equivalent en conflictes amb ell mateix. Si s'analitza el pla següent S2 s'observa que aquest tampoc és serialitzable, ja que no totes les operacions conflictives s'executen en el mateix ordre:

I les operacions conflictives són:

Segons aquest criteri de plans serialitzables s'intenta assegurar que si un pla és serialitzable, el resultat de la seva execució sempre porta a la base de dades a un nou estat consistent. Per tant, els CCA han de generar plans serialitzables a partir de qualsevol pla d'execució. Per tal de garantir la consistència de la informació no és suficient que els plans siguin serialitzables, ja que cal contemplar dues condicions addicionals.

Distribució

En el cas d'un sistema distribuït, l'ordre d'execució de les operacions conflictives ha de ser el mateix en tots els nodes. Per tant, cal que es compleixin dues condicions:

• El pla d'execució local a cada node sigui serialitzable. • Els plans d'execució locals siguin equivalents en conflictes en el mateix pla

sèrie, o sigui, que les operacions conflictives s'executin en el mateix ordre en els nodes locals.

Replicació

Cal garantir que el valor de totes les rèpliques d'una variable sigui el mateix. Les operacions de lectura es fan sobre una sola còpia i les d'escriptura cal fer-les sobre totes les còpies. Aquest és el model ReadOne-WriteAll ROWA.

211

Segons aquests criteris, a continuació es presenten les tècniques bàsiques d'algorismes de control de concurrència. La millor forma de classificar-les és mitjançant el tipus de sincronització que fan servir. N'hi ha de dos tipus: Pessimistes i Optimistes. 1.- Els algorismes pessimistes pressuposen que hi ha molts conflictes, i abans d'executar una operació sempre validen si aquesta és compatible. Dintre dels algorismes pessimistes en podem distingir tres tipus:

• Els basats en adquisicions de la informació. • Els basats en ordenació temporal. • Els híbrids, que fan servir adquisicions i marques temporals.

2.- Els algorismes optimistes pressuposen que hi ha pocs conflictes, i per tant, no fan cap validació abans d'executar una operació. En aquest cas, abans d'acabar la transacció validen si totes les operacions que s'han fet són compatibles. Els algorismes optimistes utilitzen tant adquisicions com marques temporals, amb la qual cosa la seva sincronització és híbrida.

[Tamer1999] p299-p306

RESUM En aquesta sessió s’han definit i caracteritzat les transaccions i s’ha estudiat la teoria de la serialització que dóna els criteris que han de seguir les estratègies d’execució per tal de garantir la consistència de la informació.

213

SESSIÓ 32 Nom: Algorismes pessimistes basats en adquisicions Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la quarta sessió del capítol de control de concurrència. A les sessions anteriors s’han presentat els conceptes bàsics relatius a les transaccions, control de concurrència i teoria de la serialització.

OBJECTIUS En aquesta sessió es presenten els principis de funcionament dels algorismes de control de concurrència basats en adquisicions.

CONTINGUTS En aquesta sessió s’estudien els algorismes pessimistes de control de concurrència que utilitzen adquisicions.

5.4. Algorismes pessimistes basats en adquisicions

Aquest tema descriu el comportament bàsic dels algorismes de control de concurrència basats en adquisicions.

Algorismes pessimistes basats en adquisicions

El seu principi de funcionament és que asseguren que la informació que es comparteix per diferents transaccions per operacions conflictives s'accedeix només per una operació alhora. Per fer-ho es fan servir adquisicions associades a cada variable. Llavors, quan una transacció vol fer una operació sobre una variable, abans l'ha d'adquirir. Si l'adquisició és compatible, l'operació es pot executar. Ara bé, si l'adquisició no és possible, l'operació no es pot executar i aquesta s'espera a que sigui possible. Els criteris que es fan servir per decidir si una operació és compatible, són els de la matriu de compatibilitat d'adquisicions, tal com s'han exposat a la sessió anterior. A la

214

figura següent es veu els passos que segueix el sistema per tal d'adquirir una dada i després fer l'operació sobre ella. Inicialment el TM fa la petició al CCM que gestiona les adquisicions de les dades. Si el CCM veu que l'operació és compatible contesta al TM amb un reconeixement. Llavors el TM sap que l'operació és compatible i ordena l'execució de l'operació. Ara bé, si el CCM detecta que l'operació no és compatible, l'afegeix com a petició pendent i quan sigui compatible contesta al TM i aquest segueix amb el procés. Segons aquest protocol, abans de fer una operació sobre una dada aquesta s'ha d'adquirir, i un cop s'ha fet, el TM ha d'enviar un missatge al CCM per tal que tregui l'adquisició sobre la variable deixant la variable disponible per altres processos. Segons el protocol basat en adquisicions ha d'haver-hi un control sobre les adquisicions de cada variable. En funció del node que gestiona les adquisicions hi ha tres tipus d'algorismes, que són: 1.- Centralitzat. Hi ha un dels nodes que guarda la informació relativa a les adquisicions de totes les variables, i per tant, qualsevol petició s'ha d'adreçar a aquest node. 2.- Còpia primària. Hi ha més d'un node que guarda la informació de les adquisicions. La informació relativa a les adquisicions de una variable està associada a un node, independentment si aquesta està replicada. 3.- Distribuït. Cada CCM s'encarrega de guardar la informació relativa a totes les variables i rèpliques locals, i per tant, si s'ha d'adquirir una variable replicada, caldrà emprar un protocol de dues fases per tal de fer la petició a tots els CCM que tenen una còpia de la variable.

215

Si es fa una anàlisi sobre els diferents models de gestió de les adquisicions, es veu que el model centralitzat és el que presenta més problemes de rendiment, ja que en passar totes les peticions per un sol node, aquest pot penalitzar el rendiment de tot el conjunt. Un altre inconvenient d'aquest model és que en cas de caiguda del node que gestiona les adquisicions, el sistema no pot seguir funcionant. L'opció de còpia primària evita aquest problema, però en gestionar les adquisicions de les variables replicades, ho fa a partir d'un sol node, que és el que es defineix com el que té la còpia primària de la variable. Això simplifica la gestió de les adquisicions, però també pot presentar problemes de rendiment quan hi ha un nivell de concurrència elevat. Tots els algorismes que s’estudien en aquest capítol segueixen el model de gestió d'adquisicions distribuït, ja que és el que presenta un nivell de rendiment millor i des del punt de vista de la fiabilitat és la solució més segura. Exemple d’estratègia Si s'aplica el protocol de dues fases al pla següent, es pot veure que el pla obtingut és el mateix i aquest no és serialitzable.

El problema rau en el fet que després de fer una operació, les adquisicions es desfan i cal una sincronització global a nivell de transacció. Per resoldre el problema que es presenta a l'exemple anterior, a l'algorisme S2PL es defineixen dues regles de comportament:

1. Una transacció no pot demanar una adquisició després de desfer una adquisició.

2. Una transacció no pot desfer una adquisició fins que pugui assegurar que més endavant no en demanarà cap més.

A l'algorisme que utilitza aquestes regles s'anomena Strict Two Phase Locking S2PL. El pla obtingut és sèrie i per tant serialitzable Ss= (Ti < Tj). En sol·licitar l'adquisició, l'operació wj(x), com que aquesta està adquirida per la transacció Ti, l'operació s'espera fins que l'adquisició sigui possible. Llavors la transacció Ti segueix i en acabar amb l’operació ci, es desfan les adquisicions, amb la qual cosa l'operació que

216

estava en espera ara és compatible i segueix endavant amb la Tj fins que aquesta finalitza. Per tant, una transacció ha d'anar agafant les adquisicions durant l'execució de les seves operacions, però no les allibera fins que arriba el seu Commit o Abort. D'aquesta forma, com que sempre que es modifica una dada, cal que aquesta estigui adquirida, i segons les condicions de compatibilitat de les operacions, cap altra transacció podrà agafar una adquisició de lectura o escriptura, s'evita el problema de Dirty Read. A continuació hi ha un pla on hi havia una situació de Dirty Read, i que a l'aplicar l'algorisme S2PL s'evita. En aquest cas, les operacions de la transacció Ti no estan en el pla final, ja que en executar l'operació ai s'han desfet totes les operacions d'aquesta transacció. I el que és important, inicialment l'operació de rj(x) s'ha esperat, ja que l’adquisició era incompatible respecte wi(x). Ara bé, en acabar la transacció Ti, aquesta operació que estava en espera, pot executar-se, ja que la seva adquisició ja és compatible. L'algorisme S2PL també evita el problema del Non-Repeteable Read, tal com es pot veure a l’exemple que hi ha a continuació. Segons l'algorisme S2PL, l'operació wi(x) no es pot fer, ja que la seva adquisició és incompatible amb rj(x). Llavors la transacció Ti no pot seguir i queda aturada fins que aquesta adquisició sigui compatible. Ara bé, seguidament l'operació wj(x) tampoc és compatible, donada l'adquisició de ri(x) de forma que aquesta transacció també queda aturada. Per tant, el pla queda bloquejat, ja que les dues transaccions que intervenen estan aturades. És doncs una situació de bloqueig. Aquestes situacions es poden produir en sistemes en què hi ha esperes, tal com està passant en les esperes associades al protocol S2PL. Per resoldre aquesta situació de bloqueig, el sistema ha d'avortar una de les dues transaccions. Per exemple la Tj i llavors la Ti pot seguir i acabar la seva execució. A l'apartat següent s'analitza aquesta situació amb detall. Resumint, si s'aplica l'algorisme S2PL, el procés es divideix en dues fases, tal com es veu a la figura següent.

217

1.- Primera fase La primera fase és la de creixement, ja que el sistema va agafant les adquisicions fins el punt de sincronisme, que és el punt a partir del qual ja no es demanen més adquisicions. A partir d'aquest punt de sincronisme, el sistema ja pot executar totes les operacions. 2.- Segona fase Un cop s'han executat totes les operacions comença la segona fase de decreixement. En aquesta fase les adquisicions són alliberades un cop les modificacions s'han actualitzat a la base de dades i s'arriba a l'operació d'acabament de la transacció. Si es segueix aquest criteri, el pla obtingut sempre és serialitzable i per tant es garanteix la consistència de la informació. Per aquest motiu l'algorisme S2PL és l'algorisme més utilitzat en els sistemes comercials, tant centralitzats com distribuïts, ja que sempre dóna estratègies serialitzables i amb un nivell de concurrència bastant acceptable. Ara bé, un dels problemes d'aquest algorisme és que en sistemes amb un nivell de concurrència elevat, hi ha força esperes, cosa que penalitza força el rendiment del sistema. Tanmateix, aquestes esperes poden provocar bloquejos, i per tant, cal implementar algorismes que els detectin. Aquests algorismes de detecció de bloquejos provoquen un increment de missatges per la xarxa, amb la qual cosa penalitzen el rendiment del sistema. Hi ha alternatives a l'algorisme S2PL que intenten minimitzar el nombre de bloquejos, però no garanteixen que el sistema sempre vagi millor. Un exemple d’aquest tipus d’algorisme és l’algorisme WW2PL.

Algorismes pessimistes híbrids

Ara bé, una variant dels algorismes de control de concurrència són els algorismes pessimistes híbrids, ja que fan servir adquisicions i marques temporals per la gestió de la compatibilitat de les operacions. La gestió de la compatibilitat de les operacions es fa a partir d'adquisicions, i per decidir si cal avortar una transacció a partir del TS de les operacions.

218

Com ja hem vist, el principal problema de l’algorisme S2PL és que pot provocar situacions de bloqueig del sistema, i per tant, cal aplicar tècniques de resolució d'aquestes situacions de bloqueig, amb la qual cosa es penalitza el rendiment del sistema. Una alternativa a l'algorisme S2PL, és l'algorisme Wound Wait Two Phase Locking WW\-2PL, que és un CCA pessimista híbrid. El seu funcionament és similar al S2PL, però en lloc d'aplicar tècniques de detecció de bloqueig, el que fa és evitar-les. La principal diferència d'aquest algorisme rau en el seu comportament quan detecta una incompatibilitat de les adquisicions. El criteri emprat per detectar les incompatibilitats és el mateix que utilitza el S2PL. Es disposa de les següents informacions que es requereixen per tal de decidir si una operació s'ha d'esperar o bé si s'ha d'avortar una transacció. Ti és la transacció que vol fer l'operació Oik. Tj és la transacció que té l'adquisició de la variable var(Oik).

Llavors, el tractament d'una operació per l'algorisme depèn si aquesta és compatible o incompatible.

• Operació compatible Si l'operació que es vol executar és compatible, s'executa.

• Operació incompatible Si l'operació no és compatible, en funció del seu TS farà una operació diferent. Si el TS de l'operació Oik és més gran que el TS de la variable que té l’adquisició s'espera a que l’operació sigui compatible, igual que l'algorisme S2PL. En cas contrari s'avorta la transacció més jove i s'executa la vella.

Segons aquests criteris aplicats, es pot veure que les esperes que hi ha són totes de transaccions joves a velles. Per tant, el graf d'esperes mai serà cíclic, de forma que no hi ha situacions de bloqueig i els plans obtinguts sempre són serialitzables. Seguidament hi ha alguns exemples i en tots ells podem suposar que TS(Ti)<TS(Tj).

219

Inicialment s'executa l'operació ri(x), ja que la variable x no està adquirida per cap transacció. L'operació wj(x) és incompatible però com que té un TS més gran que el de la transacció Ti, s'espera. Seguidament s'executa l'operació wi(x) i ci. En acabar l'operació ci s'executa l'operació wj(x), ja que ara és compatible, per seguir amb cj. El pla generat Sse1 és serialitzable i sèrie. En aquest pla S2 l'operació wi(x) és incompatible amb l'operació rj(x). Com que la Ti és la transacció més vella, s'avorta la Tj i seguidament s'acaba la Ti. L'algorisme WW2PL és doncs un algorisme que fa servir adquisicions i TS per a donar plans serialitzables. El principal avantatge d'aquest algorisme és que encara que hi hagi esperes, no hi pot haver bloquejos, amb la qual cosa el sistema no té cap sobrecàrrega per la seva detecció. És doncs una bona alternativa al S2PL, però cal veure si les operacions d'Abort qui hi ha per tal d'evitar els bloquejos realment no afecten al rendiment del sistema.

[Tamer1999] p308-p331

RESUM En aquesta sessió s’ha explicat el principi de funcionament dels algorismes pessimistes basats en adquisicions.

221

SESSIÓ 33 Nom: Detecció i resolució de bloqueig Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la cinquena sessió del capítol de control de concurrència. A les sessions anteriors s’ha estudiat el principi de funcionament dels algorismes de control de concurrència i s’ha vist que es poden donar situacions de bloqueig, tema que s’estudia en aquesta sessió.

OBJECTIUS En aquesta sessió s’estudien les tècniques de detecció de bloqueig en sistemes gestors de bases de dades.

CONTINGUTS En aquest tema s’identifica el procés de bloqueig de transaccions i s’analitzen les tècniques que hi ha per la seva detecció i resolució.

5.5. Detecció i resolució del bloqueig En aquest tema s’exposa la problemàtica del bloqueig i s’expliquen les principals tècniques pel seu tractament.

Bloqueig

Tal com hem vist a les sessions anteriors, un dels problemes de l'algorisme S2PL és que en provocar esperes en les operacions que no són compatibles, el sistema pot arribar a una situació de bloqueig. En aquest cas, poden quedar bloquejades un conjunt de transaccions, de tal forma que si no es fa res, es mantindran en aquesta situació de forma indefinida. Per resoldre aquesta problemàtica es pot fer segons dos enfocaments diferents:

222

• Detecció de bloqueig Cal dissenyar un mecanisme que periòdicament validi si hi ha o no bloqueig. I en el cas que es detecti bloqueig, llavors cal avortar alguna transacció per tal que el sistema pugui avançar.

• Prevenció de bloqueig

Si les esperes de les transaccions segueixen un ordre preestablert, s'aconsegueix que no hi hagi bloquejos, amb la qual cosa no caldrà detectar-los. Ara bé, per aconseguir aquesta situació, caldrà avortar més transaccions que en les tècniques de detecció.

Detecció de bloqueig

La millor forma de detectar un bloqueig és mitjançant la construcció d'un Wait For Graph WFG. Un Wait For Graph WFG és un graf en què els arcs representen les esperes entre les transaccions i en els nodes del graf hi ha la transacció amb l'operació que està en espera. Per tant, mitjançant un WFG es representen les esperes que hi ha entre les transaccions. Per exemple: En el pla S hi ha una situació de bloqueig en utilitzar l'algorisme S2PL. S= bi, bj, bk, ri(x), rj(y), wj(y), wi(x), ri(y), wk(z), rj(z), rk(x), wk(x), ck, ci, cj Durant l'execució d'aquest pla el sistema queda bloquejat. A la figura següent hi ha el graf d'aquesta situació. Una forma de detectar les situacions de bloqueig és cercant els cicles que hi ha al WFG cada cop que s'afegeix una operació d'espera. Així, cada cop que un CCM afegeix un node en el WFG es busquen tots els possible cicles que hi ha. Per cada cicle trobat vol dir que hi ha un bloqueig, i per tant cal escollir una de les transaccions que hi ha en ell per tal de cancel·lar-la i trencar el bloqueig. Ara bé, de totes les transaccions que hi ha al cicle cal escollir-ne una. Hi ha diferents criteris per decidir quina transacció cal avortar. Aquestes són:

1. En funció de les operacions o tasques fetes que ha fet cada transacció, ja que aquest es perd en avortar la transacció. Per tant, pot ser interessant avortar aquella transacció que menys feina hagi fet.

Tiri(y)

Tjrj(z)

Tkrk(x)

223

2. En funció del cost que representi avortar la transacció. Per tant, s'avorta la transacció que menys costi fer-ho. Normalment acostuma a ser la transacció que menys modificacions ha fet.

3. En funció del que falta per acabar de les transaccions. Segons aquest criteri,

s'escull per avortar la transacció que menys feina li quedi per acabar.

4. En funció del seu temps d'inici. Segons això, s'avorta la transacció més jove. A l'algorisme S2PL el criteri escollit per avortar una transacció és que avorta la transacció més jove, ja que així s'intenta avortar també la transacció que menys ha avançat en la seva execució. En el cas dels SGBDC es poden detectar les situacions de bloqueig tal com s'ha comentat. Ara bé, en el cas dels SGBDD la detecció de bloqueig no és tant simple. El principal problema en els sistemes distribuïts rau en el fet que en una transacció hi pot participar més d'un node, per la qual cosa, cada node ha de disposar del seu Local Wait For Graph LWFG i cal obtenir un Global Wait For Graph GWFG que sigui la unió de tots els LWFG. D'aquesta forma es poden detectar els interbloquejos globals. A la figura següent hi ha un exemple on es pot veure que hi ha dos LWFG sense cap bloqueig local, però si que hi ha un bloqueig global com a resultat de la seva unió.

Una forma d'obtenir el GWFG és mitjançant la utilització d'un model distribuït, on la responsabilitat de detectar el bloqueig global ho fan els nodes de forma individual. Com que tots els nodes tenen un TS local, i aquest tendeix entre tots ells a un TS global, segons aquest temps és fàcil determinar quan li toca a cada node obtenir el GWFG. En aquest instant, el node encarregat demana als diferents nodes el seu

Tiri(y)

TjLWFG del Node 1

Tjrj(z)

Tkrk(x)

LWFG del Node 2

Ti

No hi ha DeadLock local al Node 1

No hi ha DeadLock local al Node 2

Tiri(y)

Tjrj(z)

Tkrk(x)

GWFG

Hi ha DeadLock Global

224

LWFG, construeix el GWFG i si hi ha algun bloqueig global, s'encarrega d'enviar els missatges d'Abort als nodes involucrats. Amb aquesta tècnica, com que les peticions dels bloqueig es fan sobre un sistema distribuït, es pot donar el cas, que es detecti un bloqueig no existent, o bé que no és detecti una situació de bloqueig. En el primer cas, s'avorta una transacció que no caldria fer-ho, i això provoca una disminució del rendiment del sistema. La segona situació no és problemàtica, ja que el bloqueig no detectat, segur que es detecta més endavant. Les dues situacions penalitzen el rendiment del sistema, però sempre es pot assegurar que un bloqueig és detectat. Hi ha altres alternatives per la detecció del bloqueig global. Es pot seguir un model centralitzat, en què hi ha un sol node que s'encarrega de detectar el bloqueig. El principal problema d'aquesta solució és la dependència de tot el conjunt d'aquest node. Un altra alternativa és adoptar un model jeràrquic que està entre el centralitzat i el distribuït.

Prevenció de bloqueig

Per tal d'evitar les situacions de bloqueig, cal evitar que hi hagi cicles tancats d'esperes en el Wait For Graph WFG. Una forma d'aconseguir aquesta situació és ordenant les esperes a partir del seu Time Stamp TS, de tal forma que només esperin les transaccions més joves a les transaccions més velles. D'aquesta forma, si una transacció jove sempre n'espera una de més vella, mai pot haver-hi un cicle tancat d'esperes,amb la qual cosa no hi ha situacions de bloqueig. Per aconseguir l'ordenació de les esperes, quan el CCM detecta una incompatibilitat de les adquisicions, només permet que hi hagi esperes de les transaccions joves a les velles o de les velles a les joves. Per aconseguir-ho hi ha dues alternatives que són: Wait Die Si TS(Ti) < TS(Tj) Llavors Ti s'espera Sino Abort(Ti) Si la transacció que vol adquirir la variable és Ti, és més vella que la que té l'adquisició Tj, llavors s'espera. Ara bé, si la que vol fer l’adquisició és la més jove, s'avorta. D'aquesta forma, les úniques esperes que hi ha són de les transaccions velles a les joves. Wound Wait Si TS(Ti) < TS(Tj) Llavors Abort(Tj) Sino Espera Ti Si la transacció que vol adquirir la variable és Ti, és més vella que la que té l'adquisició, llavors s'avorta la jove Tj. Ara bé, si Ti és la jove, llavors aquesta s'espera. D'aquesta forma, les transaccions joves sempre esperen a les velles. En els dos models anteriors sempre s'avorten les transaccions joves. En el Wait Die les transaccions que s'esperen són les velles i en el Wound Wait s'esperen les joves.

225

RESUM En aquesta sessió s’ha explicat la problemàtica del bloqueig en els sistemes gestors distribuïts així com el procés que cal seguir per la seva detecció i resolució.

227

SESSIÓ 34 Nom: Algorismes s2pl i ww2pl Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:

o Bibliografia bàsica: [Clim2003]

PRECEDENTS Aquesta és la quarta sessió del capítol de control de concurrència distribuïda. A les sessions anteriors s’ha estudiat el principi de funcionament dels algorismes de control de concurrència.

OBJECTIUS En aquesta sessió s’estudien amb detall dos algorismes pessimistes de control de concurrència.

CONTINGUTS En aquesta sessió s’estudia amb detall el funcionament dels algorismes s2pl i ww2pl. Els dos algorismes són pessimistes. L’algorisme s2pl està basat en adquisicions i ha de detectar les situacions d’interbloqueig i l’algorisme ww2pl preveu les situacions d’interbloqueig.

5.6. Algorismes s2pl i ww2pl En aquest apartat es fa una descripció detallada de l’algorisme Strict Two Phase Locking (s2pl). Aquest és un algorisme pessimista basat en adquisicions.

Algorisme s2pl

L'algorisme S2PL és un algorisme pessimista basat en adquisicions. Cal recalcar que els criteris que segueix per garantir la compatibilitat de les operacions estan a la taula de compatibilitat d’adquisicions que ja sa vist en aquest capítol, ja que així es garanteix que l'algorisme S2PL produeixi plans serialitzables. A continuació es detalla el funcionament de l’algorisme s2pl en cinc apartats que són: Gestor de Transaccions, Gestor de Control de Concurrència, Processador de Dades, Gestió del rellotge distribuït i Resolució del bloqueig.

228

Gestor de Transaccions

El Gestor de Transaccions rep operacions del Client per tal de coordinar la seva execució. També rep operacions del seu CCM local i de la resta de TMs. Els missatges que rep del seu CCM local són les respostes de les operacions executades de forma local. Els missatges que rep d'altres TMs indiquen la resposta d'una operació que ja s'ha executat en un altre node o que un altre node que coordina una transacció li ha enviat amb ell perquè l'executi. Per tant, el TM pot rebre missatges d'un Client, d'altres TM i del seu CCM. Les estructures de dades utilitzades són:

Participant: Set of (Transaction, Set of Sites). ROWA: Set of (Transaction, Set of (Site, Granted)) Deadlock: Set of Transaction.

L'estructura Participant es fa servir per guardar els nodes que han participat o executat alguna operació en una transacció, l'estructura ROWA s'utilitza per guardar els nodes que participen en una operació distribuïda, i l'estructura DeadLock es fa servir per guardar l'identificador de les transaccions que s'han avortat com a resultat de la detecció d'una situació de bloqueig. Les operacions associades a l’estructura Participant són:

1. InitAreaParticipants. Donada una transacció, afegeix un conjunt buit de participants per la transacció. Per tant, inicialitza el seu atribut Transacció amb l'identificador de la transacció.

2. AddParticipant. Donada una transacció i un node, afegeix aquest node al

conjunt de participants de la transacció.

3. DelParticipant. Donada una transacció i un node, esborra aquest node del conjunt de participants de la transacció.

4. DeleteAreaParticipants. Donada una transacció, esborra el seu conjunt de

participants de l'estructura.

5. Participants. Donada una transacció, retorna el conjunt de nodes que han participat durant l'execució de la transacció.

6. EmptyParticipants. Donada una transacció, retorna True si el conjunt associat

a la transacció està buit.

229

Les operacions associades a l’estructura ROWA són:

1. InitAreaROWA. Donada una operació, afegeix un conjunt buit de participants a l'estructura. Per tant, inicialitza l'atribut Transaction amb l'identificador de la transacció que fa l'operació associant-hi un conjunt buit.

2. AddROWA. Donada una operació i un node, afegeix aquest node al conjunt de

l'operació i actualitza l'estat de l'operació com a pendent.

3. AddLockGr. Donada una operació i un node, actualitza l'estat de l'operació com a feta.

4. DeleteROWA. Donada una operació i un node, s'esborra aquest node del

conjunt de l'operació.

5. DeleteAreaROWA. Donada una operació, s'esborra el conjunt de nodes associats a l'operació.

6. Rowa. Donada una operació, retorna el conjunt de nodes participants.

7. EmptyROWA. Donada una operació, retorna True si el conjunt associat a

l'operació és buit.

8. GrantedROWA. Donada una operació, retorna True si tots els nodes que estan en el conjunt de l'operació ja han fet l'operació.

Les funcions associades a l'estructura DeadLock són:

1. AddDeadLockManaged. Donada una transacció, s'afegeix a l'estructura com a transacció que s'avorta com a resultat de la detecció i resolució d'una situació d’interbloqueig

2. DeadLockNotManaged. Donada una transacció, retorna True si aquesta no

s'ha avortat com a resultat d'una situació d’interbloqueig. Aquesta estructura (DeadLock) es necessita atès que diferents nodes poden decidir de forma independent avortar la mateixa transacció per tal de resoldre una situació d’interbloqueig. Llavors, el node que està coordinant l'execució de la transacció pot rebre un missatge d'Abort, quan ja ho ha gestionat. Per tant, per cada Abort gestionat cal apuntar-ho a l’estructura DeadLock, ja que així, abans d'enviar els missatges d' Abort a tots els participants de la transacció ha de consultar si això ja ho ha fet amb anterioritat. Si ja ho ha fet, ha d'ignorar el missatge d'Abort. El comportament del TM quan rep un missatge del Client és: Les operacions que pot rebre són: Begin, Read, Write, Commit i Abort.

1. Begin. Si el TM rep una operació de Begin, inicialitza la seva àrea de nodes participants i contesta amb un Ack al Client.

230

2. Commit o Abort. Si l'operació que rep el TM és un Commit o Abort, l'envia a tots els nodes que han participat en l'execució de la transacció. Llavors el TM espera resposta de tots els nodes indicant que el Commit o Abort s'ha executat. En aquest cas, el TM envia un missatge al Client informant que el Commit o Abort de la transacció ja s'ha fet.

3. Read. Quan el TM rep una operació Read, el procés que segueix depèn del

tipus de bloqueig de l'operació i de si la variable associada a l'operació està replicada o no.

a. Adquisició d'escriptura amb replicació. Si l'adquisició és d'escriptura i

la dada està replicada, el TM no pot enviar directament l'operació per la seva execució. En aquest cas, segueix un protocol de dues fases. En aquest protocol, inicialment el TM (TM coordinador) envia una operació de Lock a tots els nodes que tenen una rèplica de la variable (participants) i espera la seva resposta. Si un node contesta amb Ack, indica que ja ha adquirit la variable i per tant que està llest per executar l'operació. Si un node no pot garantir l'operació de Lock, no contesta i afegeix la petició com a pendent. Llavors quan pugui fer l'adquisició contestarà amb un Ack al TM coordinador. Per tant, el TM coordinador ha d'esperar la resposta de tots els participants. Quan tots contesten amb un Ack, llavors el TM coordinador ja pot enviar l'operació a tots ells per tal que l’executin. Un cop ho hagin fet, ho notifiquen al TM coordinar i llavors aquest contesta al Client informat que l'operació ja s'ha executat.

b. Adquisició de lectura o d'escriptura sense replicació. Si l'adquisició és de lectura o si l'adquisició és d'escriptura però la variable no està replicada, el TM envia la petició d'execució a un sol node. En aquest cas, el TM sempre s'apunta a l'estructura Participant el node a què envia l'operació.

4. Write. Quan el TM rep una operació d'escriptura, el procés que segueix només

depèn de si la variable associada a l'operació està replicada o no. Això és així perquè les operacions d'escriptura sempre tenen l'adquisició del tipus Write.

a. Sense replicació. Si la variable no està replicada, s'envia l'operació al

node primari que té la dada. b. Amb replicació. Si la variable està replicada, s'envia la petició a tots els

nodes que tenen la variable, però sempre se segueix el protocol de dues fases.

Cal remarcar, que en tot aquest procés el TM sempre s'apunta els nodes que participen en l'execució de l'operació a l'estructura Participant, i també fa servir l'estructura ROWA per conèixer quan es pot donar per feta una operació. També s’observa que sempre que s'envia una petició de Lock, el valor de l'atribut Info.Op es guarda a l'atribut temporal Info.RelOp, ja que més endavant en la segona fase del protocol que s'utilitza, caldrà recuperar el valor original de l'operació. A la figura següent es pot veure el funcionament del protocol de dues fases.

231

El comportament del Tm quan rep un missatge d’un altre TM és: En aquest cas pot rebre les respostes Null, NotAck i resposta correcta.

1. Resposta Null. Si el valor de l'atribut Info.Resp és Null indica que es tracta d'una petició a executar en aquest node. Per això, el TM envia la petició al seu CCM local perquè l'executi.

2. Resposta NotAck. Si el valor de Info.Resp és NotAck, vol dir que cal avortar la

transacció per tal de resoldre una situació d’interbloqueig que s'ha detectat. La detecció de l’interbloqueig l'ha fet un CCM d'un altre node. Aquest CCM ha enviat un missatge al seu TM i aquest ha enviat el missatge al TM que ha de coordinar la seva execució. Aquest procés és el que es detalla a l'algorisme s2pl-4 (s2pl.TM_Deadlock).

3. Resposta correcta. Si Info.Resp no és Null i tampoc és NotAck, vol dir que

l'operació associada al missatge ja s'ha executat i per tant el TM rep el resultat d'una operació que havia sol·licitat. El procés associat amb aquesta situació està detallat a continuació.

El comportament del TM quan rep un missatge del seu CCM local és: El procés a resoldre es fa en funció del node destí.

1. Node destí local. Si el node destí és local i Info.Resp és igual a NotAck, vol dir que rep una petició local per coordinar l'execució d'un Abort per tal de resoldre una situació d’interbloqueig. Ara bé, si la petició és local i Info.Resp no val NotAck, el missatge que rep el TM és el resultat d'una petició feta anteriorment i ja executada de forma local. En aquest cas, el procés seguit pel TM és el mateix que el que segueix el TM quan rep el resultat d'una execució feta en un altre node.

2. Node destí remot. En el cas que el node destí no és local, el TM envia el

missatge al node destí. Llavors el TM receptor tractarà el missatge tal com ja s’ha vist.

232

El comportament del TM quan rep una petició d' Abort d'una transacció per tal de resoldre una situació d’interbloqueig és: El TM consulta si la petició d'Abort ja s'ha fet anteriorment.

1. Abort ja gestionat. Si l'operació d' Abort ja s'ha gestionat el TM ignora el missatge.

2. Abort no gestionat. Però si l'Abort no s'ha gestionat, el TM s'apunta a

l'estructura deadlock l'identificador de la transacció i a continuació envia un missatge d'Abort a tots els nodes que han participat en la transacció.

El comportament del TM quan rep una resposta d'execució ja feta d'una operació que ell havia sol·licitat és: Aquestes operacions poden ser: Read, Write, Lock, Commit i Abort.

1. Read fet. Si l'operació executada és un Read, cal contestar directament al Client, ja que es segueix un model ROWA, i com que l'operació de lectura només s'ha enviat a un node, és aquest node el que està contestant, i per tant, ja es pot enviar el missatge directament al Client.

Si s'observa l'algorisme s2pl-1 l'operació de lectura només s'envia a un sol node. Ara bé, si la informació està replicada i l'adquisició és un Write, llavors s'involucren tots els nodes que tenen una rèplica, però el missatge enviat és un Lock.

En aquest cas, quan el TM rep resposta de tots els nodes involucrats, només envia l'operació de lectura a un sol node. Per tant, quan el TM rep un missatge indicant que l'operació de lectura ja s'ha fet, contesta directament al Client.

2. Write fet. Si l'operació executada és un Write, s'actualitza l'estructura ROWA i

es consulta si ja han contestat tots els nodes participants en l'operació d'escriptura. Si és així s'envia un missatge al Client informant que ja s'ha executat l'operació d'escriptura.

Però si encara falta algun node per contestar, no es fa res esperant el missatge dels nodes que encara no han executat l'operació. Aquest cas d'operació d'escriptura és més simple, ja que independentment que la variable estigui replicada o no, el model presentat sempre fa servir una estructura del tipus ROWA.

3. Lock fet. Quan el TM rep una operació de Lock, aquest sempre és d'escriptura

i pot ser tant d'una operació de lectura com d'escriptura. Si l'operació és un Write, el TM verifica si tots els nodes han contestat, i els envia l'operació. En aquest cas, no cal actualitzar l'estructura Participant, ja que això ja s'ha fet en el moment d'enviar els missatges Lock. Tanmateix, s'aprofita l'estructura ROWA que ja està actualitzada, per enviar la petició als nodes involucrats. Si l'operació associada al Lock és un Read, es mira si han contestat tots els nodes. Si és així, s'envia la petició de lectura a un sol node.

4. Commit o Abort fet. Es treu de l'estructura Participant el node que contesta. Si

ja han contestat tots els nodes, s'envia un missatge al Client indicant que

233

l'operació de Commit o Abort ja s'ha executat. En cas contrari, el TM no fa res i espera més missatges.

Un dels principals problemes de l'algorisme S2PL és que es poden produir situacions de bloqueig. Llavors, i tal com es veu més endavant, el CCM s'encarrega de detectar aquestes situacions de bloqueig i decidir quina transacció s'ha d'avortar. El criteri que fa servir el CCM per decidir la transacció que s'avorta depèn del TS de les transaccions.

Gestor de Control de Concurrència

El Gestor de Control de Concurrència rep peticions d'execució del TM local i s'encarrega de decidir si aquestes es poden executar. Per tal de decidir si dues operacions són compatibles fa servir la matriu de compatibilitat d'adquisicions de la figura següent.

El criteri emprat depèn del tipus d'adquisició de l'operació que es vol executar i de les adquisicions que ja té la variable. A partir de la matriu que hi ha a la figura anterior es pot observar que les úniques operacions que són compatibles sobre una mateixa variable per dues transaccions són les que tenen una adquisició de lectura, ja que si una operació té una adquisició d'escriptura no pot ser compatible amb qualsevol altra adquisició. Quan el CCM rep una operació del TM, primer ha de consultar a la matriu de compatibilitat d'adquisicions si aquesta és compatible. Si ho és, agafa l'adquisició i pren una acció, que en funció de l'operació pot ser la seva execució o simplement una resposta al TM que li ha fet la petició. Si la petició no és compatible, el CCM la memoritza com a operació pendent. Aquestes operacions pendents es guarden a l'estructura LWFG que té cada node. Com que aquesta incompatibilitat es dóna perquè hi ha una altra transacció que ja ha fet una adquisició sobre la variable, sempre que una transacció acaba, el CCM consulta en el seu LWFG si hi ha alguna operació pendent que en aquest instant ja és compatible. Si és així, fa la petició d'execució o resposta al TM, i en cas contrari la deixa a l'estructura LWFG fins que sigui compatible. Com ja hem vist, en afegir operacions no compatibles a l'estructura LWFG, sempre cal validar si hi ha situacions de bloqueig. Segons aquest comportament, el CCM utilitza tres estructures de dades, que són:

LWFG: Set of (OpOr, TranOr, Set of (TranDest, OpDest)) Locks: Set of (Var, Set of (Transaction, Lock, TimeStamp)) TranDeadLock: Set of (Tran, Site)

234

L'estructura LWFG guarda les operacions locals al node pendents d'execució. OpOr és l'operació pendent, i TranOr és l'identificador de la transacció d'aquesta operació. Llavors, per cada operació pendent es guarda el conjunt d'operacions i transaccions que han provocat aquesta espera. Si l'adquisició que té una variable és del tipus Write, aquest conjunt només conté una operació i transacció. Ara bé, es pot donar el cas que una variable tingui moltes adquisicions del tipus Read i si una altra transacció fa una petició d'adquisició del tipus Write, llavors hi ha un conjut d'operacions i transaccions que provoquen l'espera. Les funcions associades amb aquesta estructura són:

1. AddOpLWFG. Donada una operació i transacció no compatible, i el conjunt d'operacions i transaccions que provoquen la incompatibilitat, afegeix aquesta informació a l'estructura LWFG.

2. DeleteOpLWFG. Donada una transacció i variable, borra de l'estructura LWFG

aquesta espera.

3. DeleteLWFG. Donada una transacció, borra totes les esperes d'aquesta transacció que hi ha a l'estructura LWFG.

4. d) GetDeadLock. Retorna un conjunt de transaccions amb el seu node coordinador que cal avortar per tal de resoldre els diferents cicles d’interbloqueig que hi ha al LWFG.

5. PendingOp. Retorna una operació compatible del LWFG, que pot ser Read,

Write o Lock a l'estructura Info. Si no hi ha cap operació pendent que sigui compatible, omple l'estructura Info amb valors Null.

L'estructura Locks conté les adquisicions de les variables. La informació que cal guardar per gestionar les adquisicions és l'identificador de la transacció que ha fet l'adquisició, el tipus d'adquisició, que pot ser Read o Write i el TimeStamp TS de la transacció. El TS es fa servir per decidir quina transacció s'ha d'avortar quan es detecta un cicle en el LWFG. Les funcions associades amb aquesta estructura són:

1. AddLock. Donada una transacció, adquisició, variable i TS, afegeix la informació a l'estructura Locks.

2. DeleteLock. Donada una transacció, borra totes les adquisicions de la

transacció que hi ha a l'estructura.

3. IsLockComp. Donada una transacció, adquisició i variable, retorna True si és compatible, i False si no és compatible.

Finalment, l'estructura TranDeadLock s'utilitza per guardar el conjunt de transaccions que provoquen situacions d’interbloqueig. Cal doncs guardar l'identificador de la transacció i el node que coordina la seva execució, ja que cal enviar a aquest node l'operació NotAck, indicant que cal avortar la transacció. El comportament del CCM quan rep un missatge del TM és:

1. Commit o Abort. L’envia directament al processador de dades.

235

2. Read o Write. Inicialment consulta si l'operació és compatible. Si és compatible, la posa a l'estructura Locks i envia la petició al DP. Si l'operació no és compatible, l'afegeix a l'estructura d'esperes LWFG i seguidament mira si hi ha situacions d’interbloqueig. En aquest cas, per cada interbloqueig detectat, cerca la transacció més jove involucrada i li envia un missatge de NotAck al TM per tal que l'avorti. Un problema d'aquesta solució, i degut principalment al comportament distribuït del sistema, és que un CCM pot detectar una situació d’interbloqueig inexistent. En aquest cas, s'avorta una transacció sense cap necessitat, cosa que pot arribar a penalitzar el rendiment del sistema.

3. Lock. En aquest cas el tractament del missatge és el mateix que en el cas d'una operació de lectura o escriptura. Ara bé, si l'operació és compatible, el CCM ha de contestar al TM amb un missatge, ja que aquest espera el missatge per tal de decidir si fa l'operació o no.

El comportament del CCM quan rep un missatge del DP és: Aquest procés només ha de gestionar dos tipus diferents d'operacions: Read/Write i Commit/Abort.

1. Read/Write. Si el CCM rep una operació de lectura o escriptura del DP, vol dir que aquesta ja s'ha executat, i per tant l'envia al TM.

2. Commit/Abort. Si l'operació que rep el CCM és un Commit o Abort del DP, el

CCM envia un Ack al TM, indicant que el Commit o Abort s'ha executat pel DP. En aquest cas, com que s'acaba l'execució d'una transacció, cal desfer totes les adquisicions fetes per la transacció i consultar si de les operacions pendents que hi ha al LWFG, n'hi ha algunes que com a resultat d'eliminar les adquisicions de la transacció que acaba, ja són compatibles. Llavors, per totes les operacions que són compatibles, el CCM ha de prendre les accions necessàries per la seva execució.

Processador de Dades

El DP s'encarrega d'executar les operacions que li envia el gestor de control de concurrència. Per tal de gestionar els valors de les variables i el de les Before Image BI, cada node disposa de l'estructura Information. La seva estructura és:

Information: Set of (Variable, Value, BeforeImage, Transaction). Aquesta estructura guarda el contingut de totes les variables del node. Per cada variable guarda el seu valor a Information.Value, la seva BI a Information.BeforeImage, que és el valor anterior de la modificació de la variable i l'identificador de la transacció que ha fet la modificació a Information.Transaction. Les funcions associades amb aquesta estructura són:

1. GetVar. Donada una variable, retorna el seu valor. Aquest valor està a l'atribut Information.Value, ja que en el procés de modificació del contingut d'una variable sempre es guarda el nou valor en aquest atribut.

236

El valor antic es guarda en l'atribut Information.BeforeImage, sempre i quan aquest sigui Null. Si el valor de Information.BeforeImage no és Null vol dir que la mateixa transacció ja ha modificat la variable, de forma que s'ha de mantenir el valor del BeforeImage inicial.

2. PutVar. Donada una variable, el seu valor nou i l'identificador de la transacció,

modifica el seu contingut. El nou valor s'actualitza a Information.Value i la seva BI a l'atribut Information.BeforeImage. Tanmateix cal actualitzar el valor de la transacció que fa la modificació a l'atribut Information.Transaction.

3. UpdateData. Donada una transacció, actualitza totes les variables que aquesta

ha modificat durant la seva execució inicialitzant els valors dels atributs Information.BeforeImage i Information.Transaction a Null.

4. UndoData. Donada una transacció desfà totes les modificacions de les

variables fetes per la transacció a partir dels valors guardats en les BI i inicialitza a Null el contingut dels atributs Information.BeforeImage i Information.Transaction d'aquestes variables.

El tractament dels missatges per part del DP és:

1. Read. Si rep una operació de Read, accedeix a la informació i retorna el resultat de l'operació al CCM.

2. Write. Si el DP rep l'operació Write, modifica la informació i retorna un Ack al

seu CCM.

3. Commit. Actualitza al disc totes les variables modificades per la transacció durant la seva execució.

4. Abort. Desfa totes les modificacions fetes durant la seva execució, a partir de

la seva Before Image BI. En el model utilitzat pel DP, el contingut d'Information.Value és el valor real de la variable que hi ha al disc. Llavors, quan el DP rep una operació d'escriptura fa l'actualització directament al disc, guardant el seu valor anterior a Information.BeforeImage. D'aquesta forma si cal desfer una operació, només cal actualitzar Information.Value a partir del valor de Information.BeforeImage de la variable.

Gestió del Rellotge distribuït

En aquest apartat s'explica la solució adoptada per l'obtenció d'un rellotge global. Aquest rellotge es fa servir quan es detecta una situació de bloqueig i s'ha de decidir quina transacció s'avorta. Tal com ja hem vist, aquest procés el resol la funció GetDeadLock. El criteri emprat a l'algorisme S2PL es basa amb marques temporals TS, i per tant, cal disposar d'un mecanisme que generi els TSs a partir d'un rellotge global o distribuït. Aquest rellotge global ha d'estar format per un conjunt de rellotges locals independents, de tal forma que els valors dels diferents rellotges locals sempre tendeixin a un mateix valor.

237

La solució adoptada és que cada node disposa d'un rellotge local que està format per la concatenació d'un comptador i de l'identificador del node. Llavors, el TM va incrementant el valor del seu comptador de forma periòdica. Ara bé, pot succeir que hi hagi desviacions entre els valors dels comptadors locals dels nodes. Això és un problema, ja que interessa que tots els comptadors locals tendeixin a adoptar el mateix valor, aconseguint així un rellotge global. La solució adoptada per obtenir aquest valor de rellotge global és que cada TM conegui el valor dels comptadors de la resta de nodes. Això és factible, ja que quan un TM rep una trama, en aquesta sempre hi ha el valor del TS de l'operació associada a la trama. Per tant, quan un TM rep un missatge d'un altre TM, ha de guardar el valor del TimeStampOp del node que ha originat el missatge, que és el valor de l'atribut Aplication. L'estructura que té cada node i que permet guardar el valor màxim conegut dels rellotges de la resta de nodes és:

GlobalClock: Set of (Site, LocalClock) Les funcions associades amb aquesta estructura són:

1. GetMaxClock. A partir del valor de l'atribut Info.TimeStampMax de la trama i del contingut dels rellotges locals de tots els nodes que hi ha a l'estructura GlobalClock, dóna el rellotge més gran de tots ells. El rellotge retornat sempre acaba amb l'identificador del node local, ja que aquest el fa servir per actualitzar el seu comptador local.

2. UpdateClock. A partir del valor dels atributs Info.TimeStampOp, Info.Aplication

i el valor del comptador local, actualitza a l'estructura GlobalClock el valor local del comptador i el valor del comptador que és Info.TimeStampOp del node Info.Aplication. Aquesta actualització sempre s'afegeix amb el valor més gran conegut del rellotge.

Per obtenir els rellotges locals de cada node, es parteix del valor de la variable Counter. Al principi del procés, mitjançant el número del node NumSite, s’inicialitza la variable per tal que no hi hagi dos rellotges locals amb el mateix valor, ja que es pot assegurar que TimeConstant >> NumSite. Cada cop que s'incrementa el valor d'un rellotge local es fa amb el valor de TimeConstant. El temps que es tarda en incrementar el valor de Counter es dóna a partir de l'obtenció d'un valor aleatori Random mitjançant la funció UnifDist. Per a obtindre el rellotge global, s’executa un procés cada cop que el Gestor de Transaccions rep un missatge del Client. Com que el Client no assigna cap valor de TS als atributs de TS de la trama, ho fa el TM en rebre el missatge. El TM sempre actualitza el valor del TS de l'operació i quan rep una operació de Begin llavors també actualitza el valor de l'atribut TimeStampBegin. Seguidament consulta a l'estructura GlobalClock el valor del rellotge més gran, i si aquest és més gran que el seu rellotge local, l'assigna com a nou valor de rellotge.

238

Finalment, i per totes les operacions que rep el TM del Client, actualitza l'estructura GlobalClock i el valor de l'atribut Info.TimeStampMax de la trama. Fins aquest punt, s'actualitzen els rellotges de la trama i els valors de l'estructura GlobalClock cada cop que el TM rep un missatge del Client. Ara bé, quan el TM rep un missatge d'un altre TM o del seu propi CCM, també ha d'actualitzar aquests valors. Per tant, globalment es pot assegurar que l'atribut Info.TimeStampMax va agafant el valor màxim de tots els TS que tenen tots els nodes del sistema pels que passa la trama. Per tant, aquest valor és al que ha de tendir el conjunt de rellotges locals. Quan el Client inicia la primera transacció, el valor del seu atribut Info.TimeStampMax val zero. Però, a partir d'aquest instant, en passar la trama pels diferents nodes, va adoptant el valor més gran de tots els TS guardats a les estructures GlobalClock. Això succeeix fins que finalitza l'execució de la transacció. Llavors en iniciar l'execució de la transacció següent, quan el TM rep l'operació de Begin, actualitza el valor del seu rellotge local segons el valor més gran entre Info.TimeStampMax i la resta de rellotges coneguts. Aquest procés es fa per tots els nodes del sistema, per tal que els rellotges de tots els nodes tendeixen sempre al mateix valor. Ara bé, si hi ha un node poc actiu, que no és el nostre cas, el sistema segueix funcionant, ja que si s'ha dissenyat correctament la distribució de les dades del sistema, podem assegurar que aquest rebrà alguna petició d'un altre node. És doncs en aquest instant quan actualitzarà la seva estructura GlobalClock, i si més endavant el seu Client inicia una transacció, el valor del seu rellotge local s'actualitzarà correctament, com a resultat de la crida de la funció GetMaxClock, tendint al valor del rellotge global. Tanmateix, encara que un node sigui poc actiu, quan aquest enviï un missatge a un altre node, li retornarà el valor de Info.TimeStampMax actualitzat, pel que de forma independent de com acabi la transacció, quan comenci de nou un altra transacció, el seu valor ja tendirà al rellotge global. Amb aquesta estratègia adoptada, es millora la solució habitual d'anar enviant missatges nulls només per actualitzar el rellotge global, ja que no s'afegeixen trames addicionals a la xarxa del sistema.

Resolució del bloqueig

Un dels problemes de l'algorisme S2PL és que en provocar esperes entre les transaccions, el sistema pot arribar a una situació d’interbloqueig. Aquesta situació d’interbloqueig pot ser local a un node o global com a resultat de les esperes de diferents nodes. Cada cop que el CCM afegeix una operació a l'estructura d'esperes LWFG, seguidament verifica si hi ha situacions d’interbloqueig. Si és així, el CCM envia al TM un missatge per tal que avorti una transacció i així es resolgui la situació d’interbloqueig.

239

Ara bé, també cal detectar les situacions d’interbloqueig global. Una alternativa per detectar i resoldre les situacions d’interbloqueig global rau en l'assignació d'un node que coordini aquest procés de detecció. En aquest cas es tractaria d'una solució centralitzada, amb tots els problemes de rendiment i fiabilitat que això comporta. Una solució millor està basada en un model distribuït, tal que es va assignant de forma repartida un node coordinador per la detecció i resolució de les situacions d’interbloqueig. El node coordinador demana els diferents Local Wait For Graph LWFG a tots els nodes del sistema, i mitjançant la seva unió construeix un Global Wait For Graph GWFG d'esperes globals del sistema. És dons en aquest GWFG on el node coordinador ha de detectar i conseqüentment resoldre les situacions d’interbloqueig. El CCM del node coordinador del procés de detecció ja disposa de les estructures de dades LWFG, Locks i TranDeadLock, però necessita dues estructures addicionals GWFG i SitesGWFG per poder gestionar les situacions d’interbloqueig global. A continuació hi ha la definició de les estructures GWFG i SitesGWFG:

GWFG: Set of (OpOr, TranOr, Set of (TranDest, OpDest)) SitesGWFG: Set of Site

L'estructura GWFG s'utilitza per guardar el conjunt de LWFG de tots els nodes del sistema. OpOr és l'operació pendent, i TranOr és l'identificador de la transacció d'aquesta operació. Per cada operació pendent es guarda el conjunt d'operacions i transaccions que han provocat la seva espera. Les funcions associades amb aquesta estructura són:

1. InitGWFG. Inicialitza l’estructura GWFG.

2. AddLWFG. Donat un LWFG, l’afegeix a l’estructura GWFG.

3. GetGlobalDeadLock. Retorna el conjunt de transaccions amb el seu node coordinador que cal avortar per tal de resoldre els diferents cicles d’interbloqueig que hi ha en el GWFG.

L'estructura SitesGWFG s'utilitza per guardar els nodes que ja han donat el seu LWFG per tal d'actualitzar el GWFG. Així el CCM sap quan tots els nodes han enviat el LWFG i llavors ja pot detectar l'existència de situacions d’interbloqueig, ja que l'estructura GWFG està completa. Les funcions associades amb aquesta estructura són:

1. InitSitesGWFG. Inicialitza l’estructura SitesGWFG.

2. AddSiteGWFG. Donat un node l’afegeix a l’estructura SitesGWFG.

3. AllSitesGWFG. Retorna cert si a l’estructura SitesGWF s’han actualitzat tots els nodes del sistema.

A la figura següent es veu el procés seguit pel sistema en la construcció del GWFG. Inicialment el TM coordinador envia el missatge QueryLWFG al seu CCM i a la resta de TMs del sistema. Llavors, el CCM inicialitza totes les estructures de dades necessàries per aquest procés (SitesGWFG i GWFG) i afegeix el seu LWFG a l'estructura GWFG.

240

Quan la resta de TMs reben el missatge de QueryLWFG, redrecen la petició als seus CCMs locals amb un missatge de SendLWFG. Llavors, quan un CCM rep la petició de SendLWFG, retorna al TM local l'estructura LWFG amb un missatge de AckLWFG. En aquest cas, el TM retorna el missatge al TM coordinador, el qual ho envia al CCM local per tal que ho integri a l'estructura GWFG. Quan el CCM rep el missatge d'AckLWFG integra el LWFG que rep al GWFG i consulta a l'estructura SitesGWFG si ja han contestat tots els nodes del sistema. Quan això és així, cerca a l'estructura GWFG els cicles d’interbloqueig per tal de resoldre aquestes situacions. Ara bé, tal com ja s'ha comentat, el procés de coordinació és fa de forma distribuïda entre els nodes del sistema. A la figura següent es pot observar que un TM inicia el procés mitjançant un missatge de Timer. Aquest Timer es dispara en funció del valor del rellotge local del TM ja que hi ha un procés de generació d’intervals necessaris per la detecció de les situacions d’interbloqueig global. Els intervals del comptador pels que cada node s'encarrega de coordinar la detecció de les situacions d’interbloqueig són de WAITCHECKDD unitats de rellotge. Un cop el TM ha de coordinar el procés, prepara la trama amb la funció InitInfoDeadLock, la qual inicialitza els camps de la trama necessaris pel seu funcionament. Seguidament assigna a l'atribut Info.Op el codi d'operació QueryLWFG i envia la petició a tots els nodes del sistema. Durant tot aquest procés també s’actualitza l’estructura GlobalClock i el valor de l'atribut TimeStampMax. De fet, per qualsevol missatge que tracta el TM sempre s'actualitzen els valors relatius al rellotge global. Tal com s'ha vist a la figura anterior, el TM pot rebre dos tipus de missatges diferents d'un altre TM: QueryLWFG i AckLWFG. A continuació s'analitza el procés que ha de seguir el TM quan rep aquests missatges d’un altre TM, que són QueryLWFG o AckLWFG.

241

1. QueryLWFG. Si el TM rep una operació de QueryLWFG, ha d'enviar la petició al seu CCM local amb el codi d'operació SendLWFG, per tal que li retorni el LWFG del node.

2. AckLWFG. Si el TM rep un missatge amb Info.Op igual a AckLWFG, vol dir

que un altre TM li està enviant el seu LWFG. En aquest cas, el TM receptor del missatge ha d'enviar aquest LWFG al CCM local per tal que l'afegeixi al GWFG. A l'algorisme s2pl-13 està descrit aquest comportament del TM.

El comportament del TM quan rep un missatge del CCM local és:

1. AckLWFG. Només es pot tractar d'un missatge d'AckLWFG. Llavors, el TM ha d'enviar la informació al TM que coordina la detecció de les situacions d’interbloqueig.

El comportament del CCM quan rep un missatge del seu TM local és: En aquest cas pot rebre tres codis d'operació diferents per part del seu Gestor de Transaccions: QueryLWFG, AckLWFG i SendLWFG.:

1. QueryLWFG. Aquest missatge indica al CCM que ha d'inicialitzar totes les estructures de dades relacionades amb la construcció del GWFG, que són: GWFG i SitesGWFG. Seguidament, el CCM ha d'actualitzar el GWFG amb el seu LWFG.

2. AckLWFG. Quan el TM envia un missatge al CCM local amb el codi AckLWFG

indica que li envia el LWFG d'un altre node i el seu identificador (que està a l'atribut Info.SiteBegin). En aquest cas, el LM ha d'incorporar el LWFG que rep a l'estructura GWFG, i actualitzar l'identificador del node que li envia a l'estructura SitesGWFG.

Un cop s'han actualitzat aquestes informacions, el CCM verifica si ja té els LWFG de tots els nodes del sistema. Si és així, mitjançant la funció GetGlobalDeadLock busca les possibles situacions d’interbloqueig globals. Si n'hi ha alguna, envia un missatge al TM coordinador, per tal que provoqui un Abort de les transaccions culpables. A partir d'aquest instant, el procés de gestió de les situacions d’interbloqueig és idèntic al que s'utilitza en les situacions d’interbloqueig local.

3. SendLWFG. Aquest missatge indica que el TM demana al CCM local el seu

LWFG, ja que un altre TM li ha sol·licitat. Llavors, el CCM ha de retornar el LWFG al TM local amb el codi d'operació amb valor AckLWFG.

El principal problema de la solució adoptada per la detecció de les situacions d’interbloqueig és l'increment del tràfic de xarxa quan el sistema està agrupant els diferents LWFG per tal de construir el GWFG. Ara bé, tot depèn de la periodicitat d'execució d'aquest procés. Tal com ja s'ha vist, ajustant el valor de la constant WAITCHECKDD s'aconsegueix pujar o baixar aquest temps. És evident que amb un valor petit d'aquest paràmetre la càrrega de la xarxa és important, però llavors es pot assegurar que es detecten les situacions d’interbloqueig ràpidament, amb la qual cosa el sistema tendirà a donar millor resultats.

242

En canvi, si el valor de WAITCHECKDD és gran, la sobrecàrrega de la xarxa és menor, però llavors no es detectaran tant ràpidament les situacions d’interbloqueig, de manera que el rendiment del sistema potser no és tant bo. Com a conclusió, podem intuir que cal ajustar correctament el valor del paràmetre WAITCHECKDD, ja que en funció del seu valor el rendiment del sistema pot variar. Amb la solució adoptada a l'hora de construir el GWFG, com que no s'han sincronitzat els rellotges dels diferents nodes que intervenen en la seva construcció, cosa que penalitzaria molt el rendiment del sistema, pot succeir que apareguin dos fets poc desitjats, que són:

1. Detecció de situacions d’interbloqueig no existents. 2. No detecció de situacions d’interbloqueig que si que existeixen.

Aquests problemes, no són crítics, ja que si en un cicle de detecció no es detecten situacions d’interbloqueig reals, segur que més endavant (en un altre cicle de detecció) si que es detectaran, amb la qual cosa l'efecte en el seu rendiment és mínim. L'altra situació, també provoca una disminució en el rendiment del sistema, però el seu efecte queda més que compensat pel fet de definir punts de sincronisme del sistema que si que disminueixen força el seu rendiment.

Algorisme ww2pl

En aquest apartat es fa una descripció detallada de l’algorisme Wound Wait Two Phase Locking (ww2pl). Aquest és un algorisme pessimista híbrid que utilitza tècniques preventives de bloqueig. L'algorisme WW2PL és un algorisme pessimista híbrid. El seu principi de funcionament es detalla a l'apartat \ref{pesihibrid. Es pot observar que la principal diferència de l'algorisme WW2PL respecte el S2PL rau en el tractament de les operacions incompatibles. Es tracta d'un algorisme híbrid ja que fa servir tant adquisicions com TS per la gestió de la compatibilitat de les operacions. Les adquisicions s'utilitzen per decidir si les operacions són compatibles, i els TS per decidir quina transacció cal avortar quan hi ha una incompatibilitat. A l'hora d'assignar els TS a les operacions i transaccions, es fan servir les mateixes tècniques que les emprades a la resta d'algorismes. Amb tot això, l'algorisme WW2PL pretén millorar el comportament de l'algorisme S2PL, evitant l'existència de situacions d’interbloqueig. Si l'operació que es vol executar és compatible, s'executa. Ara bé, si l'operació no és compatible, en funció del seu TS segueix un tractament diferent. Si el TS de l'operació que es vol executar és més gran que el TS de la variable que té l'adquisició, s'espera a que l'operació sigui compatible, igual que l'algorisme S2PL. En cas contrari s'avorta la transacció més jove.

243

Segons aquests criteris, les esperes d'operacions que hi ha en el sistema són totes de transaccions joves a velles, i per tant, el graf d'esperes mai és cíclic, amb la qual cosa no hi ha situacions d’interbloqueig. L'algorisme WW2PL és doncs un algorisme que fa servir adquisicions i TS per obtenir sempre plans serialitzables. El principal avantatge d'aquest algorisme és que no provoca situacions d’interbloqueig. Amb això s'elimina tota la sobrecàrrega del sistema per la detecció de les situacions d’interbloqueig i s'eliminen força esperes. Encara que és una bona alternativa a l'algorisme S2PL, cal veure si l'increment en el nombre d'operacions d' Abort que hi ha, realment no afecta al rendiment del sistema. A continuació es detalla el funcionament de l'algorisme WW2PL.

Gestor de Transaccions

El Gestor de Transaccions rep operacions del Client i d'altres TMs per tal de coordinar la seva execució. Les estructures de dades i funcions d'accés que utilitza el TM són:

Participant: Set of (Transaction, Set of Sites) ROWA: Set of /Transaction, Set of (Site, Granted) AbortTran: Set of Transaction

L'estructura Participant s'utilitza per memoritzar el conjut de nodes que participen en l'execució d'operacions de cada transacció. L'estructura ROWA s'utilitza per guardar els nodes que participen en les operacions distribuïdes i les operacions que s'han executat per cada node. L'estructura AbortTran s'utilitza per memoritzar les transaccions que ja s'han avortat. El TM pot rebre del Client les operacions Begin, Read, Write, Commit i Abort. El comportament del TM quan rep un missatge del Client és:

1. Begin. Quan el TM rep una operació de Begin inicialitza l'estructura dels nodes participants i envia un missatge al Client indicant que ha executat l'operació.

2. Read. Si rep una operació de lectura amb una adquisició de lectura, intenta

executar localment l'operació, però si el node no té la informació, llavors l'envia al node primari que té la variable.

Si l'adquisició és d'escriptura i la informació no està replicada, s'envia l'operació directament al node primari que té la informació. Ara bé, si l'adquisició és d'escriptura i aquesta està replicada, fa servir un protocol de dues fases. Si en aquest procés el CCM decideix que cal avortar una transacció, contesta al TM amb un NotAck, i llavors aquest TM gestiona el procés d'Abort de la transacció.

244

3. Write. Quan el TM rep una operació d'escriptura i la variable no està replicada, envia l'operació al node primari que té la dada. En canvi, si la variable està replicada, s'envia la petició a tots els nodes que tenen la variable utilitzant un protocol de dues fases.

4. Commit o Abort. Si el TM rep del Client les operacions d'acabament de la

transacció (Commit o Abort), les propaga a tots els nodes que han participat durant l'execució de les operacions de la transacció.

El comportament del TM quan rep un missatge d’un altre TM és: Quan el TM rep un missatge d'un altre TM decideix el procés destí de l'operació. Si el missatge no conté cap resposta, vol dir que es tracta d'una petició, i per tant, el TM l'envia al CCM local. Ara bé, si es tracta d'una resposta del tipus NotAck, vol dir que s'ha d'avortar la transacció, i si rep una resposta però no és un NotAck, vol dir que un altre TM li retorna el resultat d'una petició feta amb anterioritat. El comportament del TM quan rep un missatge del CCM local és: Quan el TM rep una operació del CCM local, es pot assegurar que aquest conté sempre un resultat d'execució i ho gestiona igual que en el cas anterior.

Gestor de Control de Concurrència

El Gestor de Control de Concurrència rep peticions d'execució del TM i s'encarrega de decidir si aquestes es poden executar. Els criteris que fa servir per decidir si una operació és compatible són els mateixos que els de l'algorisme S2PL. Segons aquest comportament, les úniques operacions que són compatibles sobre una mateixa variable per dues transaccions són les que tenen una adquisició de lectura, ja que si una operació té una adquisició d'escriptura no és compatible amb qualsevol altra adquisició. Per tant, quan el CCM rep una operació del TM, ha de validar si aquesta és compatible. Si és compatible, l'envia al DP perquè s'executi. Però si l'operació no és compatible, en funció del seu TS i el de les transaccions que han provocat la incompatibilitat, el CCM pren una acció diferent. Si el TS de l'operació Oij és més gran que el TS de la variable que té l'adquisició, s'espera a que l'operació sigui compatible, i en cas contrari s'avorta la transacció més jove i s'executa la més vella. Segons aquest criteri, totes les esperes que hi ha en el sistema són de transaccions joves a velles, i per tant, el graf d'esperes mai és cíclic, per tal d'evitar situacions d’interbloqueig. El CCM també ha de contemplar les situacions en què una variable està adquirida per més d'una transacció alhora. Aquesta situació es pot donar si totes les adquisicions són de lectura. En aquest cas, si una operació no és compatible i és més vella que totes les que tenen l'adquisició, s'executa i s'avorten tota la resta de transaccions que tenen l'adquisició. Ara bé, si només hi ha una transacció més vella que tingui una adquisició, la transacció s'ha d'esperar a que aquesta acabi per tal d'analitzar si l'operació és compatible i es pot executar.

245

Segons aquest comportament, el CCM utilitza dos estructures de dades, que són:

LWFG: Set of (OpOr, TranOr, ApliOr, Set of (TranDest, ApliDest, OpDest)). Locks: Set of (Var, Set of (Transaction, Aplication, Lock, TimeStamp)).

L'estructura LWFG s'utilitza per guardar les operacions pendents d'execució. OpOr és l'operació pendent. TranOr i ApliOr són els identificadors de la transacció i aplicació de l'operació que s'està esperant. Llavors, per cada operació pendent es guarda el conjunt d'operacions que han provocat l'espera. Per poder identificar aquestes transaccions, també es guarda la transacció i aplicació a la que pertanyen. Les funcions associades amb aquesta estructura són:

1. AddOpLWFG. Donada una operació no compatible i el conjunt d'operacions que provoquen la incompatibilitat, afegeix l'espera a l'estructura LWFG.

2. DeleteOpLWFG. Donada una operació i transacció, esborra de l'estructura

LWFG aquesta espera.

3. DeleteLWFG. Donada una transacció, esborra totes les esperes d'aquesta transacció que hi ha a l'estructura LWFG.

4. PendingOp. Retorna una operació que cal tractar posteriorment pel CCM.

Aquestes operacions són les operacions compatibles o incompatibles que ja es poden executar. Les operacions incompatibles que es poden executar són aquelles que són més velles que totes les operacions que estan provocant l’espera. En aquest cas, encara que siguin incompatibles, s'executen i s'avorten les que provoquen l'espera, seguint així el principi de funcionament de l'algorisme WW2PL. Segons això, aquesta funció retorna l'operació a executar, el seu estat de compatibilitat i el conjunt de transaccions que provoquen la incompatibilitat.

L'estructura Locks conté les adquisicions de les variables i guarda les informacions necessàries per la seva gestió, que són: l'identificador de la transacció i aplicació que ha fet l'adquisició i el tipus d'adquisició i el TS de la transacció. Aquest TS es fa servir per decidir si es pot executar una operació incompatible. Les funcions de l'estructura Locks són:

1. AddLock. Donada una aplicació, transacció, adquisició, variable, tipus d'adquisició i TS, afegeix la informació a l'estructura Locks.

2. DeleteLock. Donada una transacció, borra totes les adquisicions de la transacció que hi ha a l'estructura Locks.

3. IsLockComp. Donada una operació, informa si és compatible o incompatible. Si l'operació és incompatible informa si el TS de l'operació és més gran que tots els TS de les adquisicions que provoquen la incompatibilitat.

Una operació incompatible es pot executar si és més vella que totes les operacions que estan provocant la incompatibilitat. En aquest cas, s'executa l'operació i s'avorten

246

les transaccions que estan provocant la incompatibilitat. En canvi, si la transacció no és la més vella, no es pot executar. Per tant, la funció IsLockComp retorna el seu estat de compatibilitat, si és la més vella i el conjunt de transaccions que provoquen la incompatibilitat. El comportament del CCM quan rep un missatge del TM local és:

1. Commit o Abort. Quan el CCM rep una operació de Commit o Abort, l'envia directament al processador de dades, ja que el TM coordinador de l'execució del Commit o Abort ha enviat l'operació a tots els nodes que han participat en l'execució de les operacions de la transacció.

2. Read o Write. El tractament de les operacions de Read o Write per part del

CCM sempre és el mateix, ja que aquest depèn del tipus d'adquisició associat a l'operació.

Inicialment consulta mitjançant la funció IsLockComp si l'operació és compatible o si és incompatible però es pot executar. Si és compatible, s'afegeix l'adquisició a l'estructura Locks i seguidament s'envia l'operació al DP per la seva execució.

Ara bé, si l'operació és incompatible però és més vella que totes les transaccions que provoquen la incompatibilitat, l'operació s'ha d'executar i cal avortar les transaccions que provoquen la incompatibilitat. Per fer-ho s'afegeix l'operació a l'estructura LWFG i s'avorten les transaccions culpables. D'aquesta forma, quan el sistema hagi resolt les operacions d' Abort, detectarà l'operació com a compatible i l'executarà. Seguint aquest procediment, s'assegura que quan s'executa l'operació ja s'han avortat les transaccions més joves.

En canvi, si l'operació no és la més vella, s'afegeix com a pendent a l'estructura LWFG esperant que sigui possible la seva execució.

3. Lock. Quan el CCM rep una operació de Lock, segueix el mateix tractament

que en el cas d'una operació de lectura o escriptura, encara que en lloc d'enviar la petició al DP contesta al TM indicant que l'operació es pot satisfer.

Si la petició de Lock no és compatible i és més vella que totes les que provoquen les incompatibilitats, cal avortar les transaccions que provoquen la incompatibilitat i contestar al TM. En cas contrari, s'afegeix l'operació de Lock a l'estructura LWFG.

El comportament del CCM quan rep un missatge del DP local és:

1. Read o Write. Els missatges que rep sempre són el resultat d'execució d'una operació. Si rep el resultat d'una operació de lectura o escriptura, l'envia al TM local.

2. Commit o Abort. Si l'operació que rep és una operació de Commit o Abort,

vol dir que ja s'ha executat pel DP. Llavors el CCM treu les adquisicions de l'estructura Locks i les esperes de la transacció que hi ha a l'estructura LWFG. Seguidament el CCM envia un missatge al TM indicant que l'operació ja s'ha executat.

247

Un cop el CCM ha enviat el missatge al TM, ha de buscar totes les operacions que estan a l'estructura LWFG que es poden resoldre. Aquestes poden ser tant les operacions compatibles com les incompatibles velles.

Processador de Dades

El DP rep peticions d'execució d'operacions de Commit, Abort, Read o Write del CCM local. Per les operacions de Commit o Abort deixa el contingut de les variables de forma consistent. Quan rep una operació de lectura ha de retornar el valor actual d'aquesta i per les operacions d'escriptura ha de modificar el valor de les variables. Per gestionar els continguts de les variables el DP disposa de l'estructura Information.

Information: Set of (Variable, Value, Set of (ValuePreWrite, TransactionPreWrite, AplicationPreWrite)).

Per cada variable es guarda el seu valor actual i els valors modificats per les transaccions a l'atribut ValuePreWrite, així com la transacció i aplicació que ha fet la modificació. Quan el DP rep una operació d'escriptura, modifica el contingut de l'atribut PreWrite de la variable. Si rep una operació de lectura, retorna el valor actual de la variable. Si l'operació que ha d'executar el DP és un Commit, ha d'actualitzar els valors de totes les variables modificades per la transacció que estan a l'atribut ValuePreWrite a l'atribut Information.Value. En canvi, si l'operació a executar és un Abort, el DP inicialitza tots els valors PreWrite actualitzats per la transacció. Les funcions associades a l'estructura Information són:

1. GetVar. Donada una variable i l'identificador de la transacció, retorna el valor de la variable. Si la transacció no ha modificat la variable, aquest valor està a l'atribut Information.Value. Si la transacció ha modificat la variable, el seu valor està a l'atribut ValuePreWrite.

2. PutVar. Donada una variable, el seu valor nou, l'identificador de la transacció i

l'identificador de l'aplicació, modifica el seu contingut. El nou valor s'actualitza a l'atribut PreWrite.

3. UpdateData. Donada una transacció, actualitza totes les variables que aquesta

ha modificant durant la seva execució als atributs Information.Value i inicialitza els valors PreWrite.

4. UndoData. Donada una transacció, desfà totes les modificacions de les

variables fetes per la transacció inicialitzant el contingut dels atributs PreWrite. A continuació es descriu el tractament que fa el DP en rebre les operacions de Read, Write, Commit o Abort del CCM local.

1. Read. Si el DP rep una operació de lectura, retorna el valor de la variable. Aquest valor està a l'atribut Information.Value si la transacció no ha modificat el seu contingut i si l'ha modificat, el seu valor està a l'atribut Information.ValuePreWrite.

248

2. Write. Quan el DP rep una operació d'escriptura, modifica el contingut de la

variable a l'atribut ValuePreWrite, ja que així manté el valor inicial de la variable a Information.Value i el valor modificat a Information.ValuePreWrite.

3. Commit o Abort. Si el DP rep una operació de Commit, actualitza els

continguts de totes les variables modificades per la transacció, i si rep una operació d' Abort desfà tots els canvis fets per la transacció.

RESUM En aquesta sessió s’ha detallat el funcionament dels algorismes s2pl i ww2pl.

249

SESSIÓ 35 Nom: Exercicis Tipus: Teòrica Format: No presencial Durada: 2 hores Dedicació: 2 hores Treball a lliurar: No Material:


PRECEDENTS Aquesta és la darrera sessió del capítol de control de concurrència. A la resta de sessions del capítol s’han estudiat els conceptes teòrics relatius a la gestió de transaccions i algorismes de control de concurrència.

OBJECTIUS En aquesta sessió es resolen exercicis de control de concurrència.

CONTINGUTS En aquesta sessió es resolen exercicis d’anàlisi de plans d’execució que gestionen els algorismes de control de concurrència s2pl i ww2pl.

5.7. Exercicis A continuació es resol un exercici on a partir d’un pla d’entrada s’aplica l’algorisme de control de concurrència ww2pl per tal d’obtindre el pla de sortida serialitzable.

Algorisme Wound-Wait Two Phase Locking

A partir del pla d’execució que hi ha a continuació, cal donar el pla de sortida que genera l’algorisme ww2pl detallant totes les operacions que es fan i justificant si el pla de sortida és serie o serialitzable. Pla = {b1, r1(x)rl, b2, r2(x)rl, r2(y)wl, r2(x)wl, w1(z)wl, b3, r3(w)rl, r2(z)rl, r3(x)rl, w1(x)wl, w1(y)wl, r3(z)wl, w1(z)wl, w3(x)wl, r1(w)rl, c1, c2, b4, r4(w)rl, w4(z)wl, w3(x)wl, c3, w4(w)wl, c4 }

250

SOLUCIÓ El Pla de sortida obtingut és: Pla = {b1, r1(x)rl, b2, r2(x)rl, r2(y)wl, (r2(x)wl s'espera T2 → T1), w1(z)wl, b3, r3(w)rl, r3(x)rl, w1(x)wl (provoca un abort de T2 i T3), a2, a3, w1(y)wl, w1(z)wl, r1(w)rl, c1, b4, r4(w)rl, w4(z)wl, w4(w)wl, c4 llavors segueixen les transaccions T2 i T3 b2, r2(x)rl, r2(y)wl, r2(x)wl, b3, r3(w)rl, r2(z)rl, (r3(x)rl s'espera $T3 → T2), c2, r3(x)rl, r3(z)wl, w3(x)wl, w3(x)wl, c3} Per tant, l'ordre d'execució és: ( c1< c4 < c2 < c3 ) El pla de sortida no és sèrie, ja que hi ha operacions intercalades de diferents transaccions. Per validar que el pla és serialitzable, aquest s'analitza a partir de l'ordre d'execució de les operacions conflictives. Segons això si que és serialitzable, ja que es compleixen les condicions:

1) Les úniques transaccions que executen operacions de forma concurrent són T2 i T3.

2) Per tal que el pla sigui serialitzable, les operacions que són conflictives s'han d'executar sempre en el mateix ordre que en un pla sèrie. En aquest cas les úniques operacions que hi ha conflictives entre T2 i T3 són les que accedeixen a la variable x i aquestes sempre són amb l'ordre T2 < T3.

A continuació es resol un exercici on a partir d’un pla d’entrada s’aplica l’algorisme de control de concurrència s2pl per tal d’obtindre el pla de sortida serialitzable.

Algorisme Strict Two Phase Locking

Disposem d’un sistema gestor de base de dades centralitzat que ha d'executar un pla S. Aquest pla és: S = { b2, b4, b3, b1, r2(z)rl, r2(w)rl, r1(x)rl, r3(z)rl, r1(w)rl, r2(z)rl, r2(y)wl, r3(w)wl, r3(w)rl, w3(z)wl, r3(x)rl, r4(y)rl, w1(z)wl, r3(y)rl, c2, w3(w)wl, c3, w4(y)wl, r4(x)rl, w1(z)wl, c4, w1(x)wl, c1 } En aquest sistema es pot suposar que ThinkTime >>RestartTime>>Temps que hi ha entre que finalitza una operació i comença la següent de la mateixa transacció. Ens demanen el pla serialitzable final que executa el sistema tenint en compte que fa servir un algorisme de control de concurrència Strict Two-Phase-Locking. En el pla serialitzable final cal detallar totes les operacions fetes.

251

SOLUCIÓ El Pla de sortida obtingut és: Pla = {b2, b4, b3, b1, r2(z)rl, r2(w)rl, r1(x)rl, r3(z)rl, r1(w)rl, r2(z)rl, r2(y)wl, r3(w)wl (T3 espera a T1 i T2), r4(y)rl (T4 espera a T2), w1(z)wl (T1 espera a T2 i T3), En aquest instant hi ha un cicle d’interbloqueig (T3, T1). Com la transacció més jove és T1, llavors es fa un abort sobre la transacció T1 amb (a1) i es mira si alguna de les operacions que hi ha en espera és compatible. Les operacions que estan en espera són: r3(w)wl i r4(y)rl. Aquestes operacions encara no es poden executar i per tant es segueix amb la resta d'operacions. c2, (ara si que son compatibles les operacions que estan en espera) r3(w)wl, r4(y)rl, r3(w)rl, w3(z)wl, r3(x)rl, r4(y)rl, r3(y)rl, w3(w)wl, c3, w4(y)wl, r4(x)rl, c4, b1, ... , c1} Per tant, l'ordre d'execució és: ( T2 < T3 < T4 < T1 ). Es resol un exercici on a partir d’un pla d’entrada s’apliquen els algorismes de control de concurrència s2pl i ww2pl.

Algorisme Strict Two Phase Locking i Wound-Wait Two Phase Locking

Disposem d'un sistema gestor distribuït que ha d'executar el pla S que hi ha a continuació. S = (r1(x)rl, r1(y)wl, r2(z)rl, r2(x)rl, r4(y)rl, r4(x)rl, r4(z)rl, r3(x)rl, w2(z)wl, r2(w)wl, r3(w)rl, r3(y)rl, r4(x)rl, w1(x)wl, w1(y)wl, w4(y)wl, c4,w3(x)wl, w3(w)wl, c3, w2(z)wl, w2(w)wl, c2, w1(y)wl, c1) Sabem que la informació no està replicada i ens demanen el pla generat per l’algorisme s2pl i per l'algorisme ww2pl. SOLUCIÓ 1) Strict Two Phase Locking Pla = {r1(x)rl, r1(y)wl, r2(z)rl, r2(x)rl, r4(y)rl (s'espera), r3(x)rl, w2(z)wl, r2(w)wl, r3(w)rl (s'espera), w1(x)wl (s'espera), w2(z)wl, w2(w)wl, c2 Es miren les operacions que estan en espera i que són compatibles. r4(y)rl no és compatible. r3(w)rl si és compatible. w1(x)wl no és compatible. r3(w)rl, r3(y)rl (s'espera i provoca interbloqueig)

252

El cicle d’interbloqueig inclou les transaccions T3 i T1. Com que la transacció més jove és T3, aquesta s'avorta. Llavors es miren les operacions compatibles que estan en espera. r4(y)rl no és compatible. w1(x)wl si que és compatible. a3, w1(x)wl, w1(y)wl, w1(y)wl, c1 Llavors, l’operació que està en espera r4(y)rl és compatible i s'executa. r4(y)rl, r4(x)rl, r4(z)rl, r4(x)rl, w4(y)wl, c4 Seguidament s'executen totes les operacions de la transacció T3. r3(x)rl, r3(w)rl, r3(y)rl, w3(x)wl, w3(w)wl, c3 L'ordre d'execució és: ( T2 < T1 < T4 < T3 ) 2) Wound-Wait Two Phase Locking Pla = r1(x)rl, r1(y)wl, r2(z)rl, r2(x)rl, r4(y)rl (com que hi ha un conflicte entre T4 i T1 i la transacció més vella és T1, la transacció T4 s'espera a la T1. r3(x)rl, w2(z)wl, r2(w)wl, r3(w)rl (hi ha un conflicte amb la transacció T2. Com que T3 és més jove que T2, s'espera. w1(x)wl (hi ha un conflicte amb T2 i T3). Com que la T1 és més vella, s'avorten les transaccions T2 i T3. l’operació r4(y)rl no és compatible. w1(y)wl, w1(y)wl, c1 Llavors, s'executen les operacions de la transacció T4 r4(y)rl, r4(x)rl, r4(z)rl, r4(x)rl, w4(y)wl, c4 Seguidament es tornen a executar les operacions del pla de les transaccions T2 i T3. r2(z)rl, r2(x)rl, r3(x)rl, w2(z)wl, r2(w)wl, r3(w)rl (és incompatible i com que és més jove que la T2, s'espera). w2(z)wl, w2(w)wl, c2, r3(w)rl, r3(y)rl, w3(x)wl, w3(w)wl, c3} L'ordre d'execució és: ( T1 < T4 < T2 < T3 )

RESUM En aquesta sessió s’han resolt tres exercicis de control de concurrència dels algorismes s2pl i ww2pl.

253

BIBLIOGRAFIA

LLIBRES

Principles of Distributed Database Systems Özsu, M.Tamer; Valduriez, Patrick Prentice Hall New Jersey, 1999 [Tamer1999]

Sistemes Gestors de bases de dades Climent Ferrer, August Enginyeria i Arquitectura La Salle Barcelona, 2008 [Climent2008]

Database System Implementation Garcia-Molina, Hector; Ullman, Jeffrey D.; Widom, Jennifer Prentice Hall New Jersey, 2000 [Garcia2000]

Distributed Database Systems Bell, David; Grimson, Jane Addison-Wesley 1992 [Bell1992]

Parallel Database Techniques Abdelguerfi, Mahdi; Wong, Kam-Fai IEEE Computer Society Press Los Alamitos, California, 1998 [Abdelguerfi1998]

Query Processing in Parallel Relational Database Systems Lu, Hongjun; Ooi, Beng-Chin; Tan, Kian-Lee IEEE Computer Society Press Los Alamitos, California, 1994 [Lu1994]

A First Course In Database Systems Ullman, Jeffrey D.; Widom, Jennifer Prentice Hall New Jersey, 1997 [Ullman1997]

254

Using SQL Groff, James R.; Weinberg, Paul N. Osborne McGraw-Hill Berkeley, California, 1990 [Groff1990]

The Practical SQL Handbook Bowman, Judith S.; Emerson, Sandra L.; Darnovsky, Marcy Addison-Wesley 1996 [Bowman1996]

Modern Database Systems, The Object Model, Interoperability, and Beyond Kim, Won ACM Press New York, 1995 [Kim1995]

Multidatabase Systems: An Advanced Solution for Global Information Sharing A.R.Hurson, M.W.Bright, S.Pakzad IEEE Computer Society Press Los Alamitos, California, 1994 [Hur1994]

Multimedia Database Systems V.S.Subrahmanian, Sushil Jajodia Springer, New York, 1996 [Sub1996]

Sistemas de bases de datos. Conceptos fundamentales Ramez Elmasri, Shamkant B.Navathe Addison-Wesley Iberoamericana Wilmington, 1997 [Elm1997]

255

GLOSSARI

ANSI American National Standards Institute.

AR Àlgebra relacional.

BD Base de dades.

BDD Base de dades distribuïda.

BI Imatge anterior.

BS Conjunt de variables de base.

CC Control de concurrència.

CCA Algorisme de control de concurrència.

CCM Gestor de control de concurrència.

CIS Control d'integritat semàntica.

CLM Matriu de compatibilitat d'adquisicions.

CPU Unitat central de procés.

CR Càlcul relacional.

CTO Algorisme de control de concurrència amb ordenació temporal conservatiu.

256

DBTG Database task group.

DBM Gestor de la memòria intermèdia (buffer) de la base de dades.

DD Diccionari de dades.

DTO Algorisme de control de concurrència amb ordenació temporal distribuïda.

FIFO Model cua, el primer que entra és el primer que surt.

FK Clau forània.

GCS Esquema global conceptual.

GES Esquema global extern.

GP Processador global.

GWFG Graf d'esperes global.

LCS Esquema local conceptual.

LES Esquema local extern.

LIS Esquema local intern.

LP Processador local.

LRM Gestor de recuperació local.

257

LWFG Graf d'esperes local.

MDB Multidatabase.

MU Unitat de memòria.

ODTO Algorisme de control de concurrència optimista.

PADD Disseny dimensional amb paral·lelisme explícit.

PK Clau primària.

RALE Entorn de desenvolupament Ramon Llull.

ROWA Lectura d'un i escriptura de tots.

RP Protocol de recuperació.

RS Conjunt de variables de lectura.

RTS Marca temporal de lectura.

S2PL Algorisme de control de concurrència amb adquisicions en dues fases.

SGBD Sistema gestor de base de dades.

SGBDC Sistema gestor de base de dades centralitzades.

SGBDD Sistema gestor de base de dades distribuïdes.

258

SGBDF Sistema gestor de base de dades federat.

SQL Structured query language.

SPARC Standards planning and requirements commitee.

TM Gestor de transaccions.

TP Protocols d'acabament.

TS Marques temporals.

WFG Graf d'esperes.

WS Conjunt de variables d'escriptura.

WTS Marca temporal d'escriptura.

WW2PL Algorisme de control de concurrència d'esperes en dues fases.

Creative Commons License Deed - Salle-URL · Creative Commons License Deed Reconeixement-No...

Documents

Transcript of Creative Commons License Deed - Salle-URL · Creative Commons License Deed Reconeixement-No...