Transcript Systèmes de gestion de bases de données NFP 107

Préambule
Systèmes de gestion de bases de données
NFP 107
Introduction à la concurrence d’accès
Philippe Rigaux
[email protected]
http://idf.pleiad.net/index.php
Vertigo
NFP 107
1
Préambule
1. Généralités
Vertigo
NFP 107
2
Préambule
Objectifs de ce cours
• Comprendre les mécanismes d’accès
concurrents à une base de données
• Connaître les risques liés à une gestion laxiste
de la concurrence
▫ Connaître aussi les inconvénients d’une gestion
trop stricte
• S’initier au concept de transaction, et interpréter
dans ce contexte le comportement d’un SGBD
transactionnel
• Comprendre les modes de gestion de la
concurrence offerts au niveau « logique »
Vertigo
NFP 107
3
Préambule
Pour accompagner ce cours
• Le polycopié (Introduction à la concurrence
d’accès, Philippe Rigaux, Cnam)
▫ Dispo à http://sys.bdpedia.fr en HTML
▫ (PDF) http://www.bdpedia.fr/systemes-relationnels
• Disposer d’un SGBD comme PostgreSQL ou
MySQL pour effectuer quelques manipulations
chez vous
• Et bien entendu, faire les exercices du polycopié
et autres
Vertigo
NFP 107
4
Préambule
De quoi s’agit-il?
• Deux hypothèses à reconsidérer
▫ Un programme SQL s’exécute indépendamment
des autres (« en isolation »)
 -> de grandes bases de données peuvent gérer des
centaines, voire des milliers d’accès concurrents
▫ Un programme s’exécute sans erreur et
intégralement
 Raisons innombrables: plantage, pb réseau, pb du
serveur, panne électrique, etc.
 L’interruption peut laisser la base dans un état
incohérent
Vertigo
NFP 107
5
Préambule
SGBD et concurrence d’accès
• Les SGBD assurent le contrôle de la
concurrence (CC)
▫ Les programmes concurrents sont contrôlés et
surveillés
▫ Certaines séquences d’opérations sont interdites,
▫ A l’extrême, le CC assure que l’hypothèse 1 est
vérifiée: les programmes s’exécutent en isolation
• Un composant complémentaire est la reprise sur
panne
▫ CC et reprise sur panne sont liées par la notion de
transaction.
Vertigo
NFP 107
6
Préambule
Ce que nous devons savoir
• Sans même comprendre les techniques utilisées
(objet du prochain cours), il faut
▫ Maîtriser la notion, centrale, de transaction
 La spécification d’une transaction nous revient
▫ Réaliser l’impact du CC sur les autres utilisateurs
 Une transaction mal conçue peut faire perdre
inutilement beaucoup de temps
▫ Choisir un niveau d’isolation approprié
 Difficile, mais potentiellement extrêmement
important
Vertigo
NFP 107
7
Préambule
2. Notions de base
Vertigo
NFP 107
8
Préambule
Transaction
• Définition: une transaction est une séquence
d’opérations de lecture ou d’écriture, se
terminant par commit ou rollback
▫ Le commit est une instruction qui valide toutes les
mises à jour
▫ Le rollback est une instruction qui annule toutes
les mises à jour.
▫ Les opérations d’une transaction sont solidaires:
elles sont toutes validées, ou pas du tout.
Vertigo
NFP 107
9
Préambule
Quelques précisions
• On parle de transaction plutôt que de
programme : plus précis
• Une transaction s’exécute dans le cadre d’un
processus client connecté au serveur SGBD.
• On peut effectuer une ou plusieurs transactions
dans un même processus: elles sont sérielles.
• En revanche, deux processus distincts
engendrent des transactions concurrentes.
Vertigo
NFP 107
10
Préambule
Notre exemple de base
• Notre base de données:
▫ Des clients qui réservent des places pour des
spectacles
 Client (id_client, nb_places_réservées)
▫ Des spectacles qui proposent des places à des
clients.
 Spectacle (id_spectacle,
nb_places_offertes, nb_places_prises)
▫ NB: cette base est cohérente si le nombre de places
prises est égal à la somme des places réservées
Vertigo
NFP 107
11
Préambule
Notre procédure Réservation
• Ecrite en PL/SQL
▫ mais équivalente, du point de vue transactionnel,
à la même fonction écrite en n’importe quel autre
langage.
• Effectue des lectures et des mises à jour
▫ Et notamment des mises à jour des données lues
précédemment
▫ Représentative des procédures qui posent le plus
de problème
▫ (ici: explication de la procédure à partir du code)
Vertigo
NFP 107
12
Préambule
Architecture
• La procédure précédente engendre des transactions
Les deux espaces communiquent
par message.
Ils ne partagent rien.
Processus Client
(exécute Réservation)
LeLe
serveur
envoie
client envoie
des
données
des
requêtes
Le Client gère
- des données
- des calculs
Invisibles pour le serveur
(ou les autres clients)
Vertigo
Processus Server
(reçoit, exécute des
requêtes)
Le serveur accède à la base
et effectue ses propres
calculs
Invisible pour tous les
clients
NFP 107
13
Préambule
Représentation des transactions
• Pour comprendre les mécanismes de
concurrence, on va se limiter à l’essentiel
▫ Les requêtes transmises par chaque processus
(T1, T2, … Tn) au serveur
▫ L’ordre dans lequel ces requêtes sont reçues
• On va les représenter (modéliser) très
simplement de la manière suivante:
▫ ri[x]: Ti demande la lecture (read) de la donnée x.
▫ wi[x]: Ti demande la mise à jour (write) de la
donnée x.
▫ Ci et Ri représentent le commit et le rollback.
Vertigo
NFP 107
14
Préambule
Qu’est-ce qu’une « donnée »
• C’est l’unité d’information affectée par la
requête. Cela peut être:
▫
▫
▫
▫
Toute la base
Toute une table
Une ligne dans une table
Une cellule (valeur) dans une ligne.
• En théorie on peut tout considérer. En pratique:
▫ Dans les SGBD relationnels, l’unité
transactionnelle est la ligne dans une table
Vertigo
NFP 107
15
Préambule
Exemples de transactions
• En s’exécutant, la procédure Réservation
engendre des transactions
▫ r[s1]r[c1]w[s1]w[c1]C: on lit le spectacle s1, le
client c1, puis on les met à jour tous les deux
▫ r[s1]r[c2]w[s1]w[c2]C: un autre client réserve pour
le même spectacle
▫ r[s1] : on lit le spectacle s1, et on s’arrête là (plus
assez de places disponibles?)
• Un même processus peut effectuer des
transactions en série:
r[s1]r[c1]w[s1]w[c1] r[s1]r[c2]w[s1]w[c2] r[s1]
Vertigo
NFP 107
16
Préambule
Exécutions concurrentes
• Quand plusieurs programmes clients sont actifs
simultanément, les transactions engendrées
s’effectuent en concurrence.
• On obtient potentiellement un entrelacement
des requêtes
Serveur
r1[s1] r1[c1] r2[s1] r2[c2] w1[s1] Etc.
continuent
metetàP2
jour
P1 lit le P1 litP2
le lit leP2 lit le P1 P1
s’exécuter
spectacle
s1 …
spectacle
s1Client
Client c2Le À
Client
c1 c1
• Fait: les exécutions concurrentes non
contrôlées sont source d’anomalies.
Vertigo
NFP 107
17
Préambule
Propriétés des transactions
• Un système relationnel garantit un ensemble de
propriétés rassemblées sous l’acronyme ACID.
▫ A = Atomicité. Une transaction est validée
complètement ou pas du tout.
▫ C = Cohérence. Une transaction mène d’un état
cohérent à un autre état cohérent.
▫ I = Isolation. Une transaction s’exécute comme si
elle était seule.
▫ D = Durabilité. Quand le commit s’exécute, ses
résultats sont définitifs.
• Essentiel à retenir: l’isolation peut n’être que
partielle, pour des raisons de performance.
Vertigo
NFP 107
18
Préambule
Pause …
• J’effectue un commit, puis je m’aperçois d’une erreur: est-il encore
temps de faire un rollback?
• La transaction r[s1]r[c1]w[s2]w[c1]C peut-elle être engendrée par la
procédure Réservation?
• J’exécute la commande:
 DELETE * FROM MesClients; WHERE id=1;
▫ Réponse: 100 000 lignes détruites. Pourquoi et que faire?
• Exécution de Réservation: je lis un spectacle: il reste 10 places
libres; je veux en réserver 5: on me répond qu’une autre transaction
a tout pris. Est-ce possible dans un système transactionnel?
Vertigo
NFP 107
19