Implémentation des SGBD Structure générale des applications Application utilisateur accédant à des données d'une base Les programmes sous-jacents contiennent du code SQL Exécution : pendant l'exécution Les requêtes sont transmises au SGBD Le SGBD vérifie le code, optimise, gère les accès concurrents, accède aux données, récupère les réponses, transmet à l'application
Implémentation en 3 couches Couche externe Interfaces avec les langages «hôtes» Définition des vues utilisateurs, de leurs droits,... Noyau du SGBD Langages le définition et de manipulation (SQL) Optimiseur de requêtes Gestion des index Gestionnaires de transactions et des journaux Couche interne Accès physique aux données
Implémentation en 3 couches Couche interne Noyau Couche externe Fichiers Gestionnaire de fichiers (système) Interface interne Fonctions internes du SGBD - SQL (DDL, DML) - optimisation - transactions - index -... Interface externe Utilsateurs - programmes - vues - droits d'accès -... SGBD
Indépendance des couches Couche interne/noyau (indépendance physique) Que faire si on change le gestionnaire de fichiers de la couche interne? Réécrire l'interface interne, mais aucun changement dans le noyau Noyau/couche externe (indépendance logique) Si on change le noyau, faut-il réécrire les applications utilisateurs? Non, si on change de SGBD relationnel Oui, si on change l'organisation d'une BD
Noyau + Interface externe 5 modules principaux Interface interactive/outils de développement Précompilateurs : prise en compte d'ordres SQL dans des programmes (C, JAVA, ) Analyseur de requêtes SQL Optimiseur de requêtes Outils d'administration et dictionnaire des données (info sur les utilisateurs et les objets qu'ils ont créés)
Noyau + Interface interne 5 modules principaux Le journal (contient toutes les opérations réalisées sur le SGBD) Le processeur de transactions Le gestionnaire d'index Le gestionnaire d'espace disque Le gestionnaire des buffers (communication entre le disque et le SGBD)
Architectures des SGBD Main frame Noyau et couche externe sur une même machine Client-serveur Client : couche externe + SQL + communication Serveur : Noyau (- SQL) + communication SGBD répartis Plusieurs main frames sur différents sites Données de la base stockées sur différents sites Architectures n-tiers : Intègrent les applications Web
Client-Serveur Le poste client contient les outils de l'interface externe sauf le dictionnaire des données Le serveur assure le stockage des données et des meta-données (dictionnaire de données) Donc le serveur contient Les outils de l'interface interne Plus le dictionnaire de données et les outils d'administration
Client-Serveur Deux types de serveurs : Serveur de transaction : le client envoie des transactions traitées par le serveur, puis traite les résultats Serveur de données : les transactions sont exécutées par le client, le serveur ne fait que "fournir" les données Donc le serveur de données "travaille moins" que le serveur de transactions
Transmissions client-serveurs Optimiser les transferts de données Soit envoyer n-uplet/n-uplet Soit envoyer bloc/bloc et stocker dans un cache optimise si on estime que la transaction va utiliser les autres n-uplets du bloc transmis Mais occasionne des problèmes de conflit d'accès un n-uplet transmis peut être modifié par une autre transaction
Transmissions client-serveurs Concurrence d'accès Lorsque deux transactions modifient une même donnée, il faut prendre un certain nombre de précautions. La solution la plus courante est de verrouiller les objets utilisés par une transaction donnée les verrous sont gérés par le serveur donc chaque verrou doit donner lieu à l'envoi d'un message aux clients
Architecture répartie Chaque site a une version complète du SGBD Données réparties sur les sites Découpage horizontal : les sites ont tous les mêmes relations avec différents contenus Découpage vertical : les sites ont des relations différentes, tous connaissent la structure de la BD Pas d'opérateur spécifique pour accéder à l'ensemble des données Découpage horizontal : union des données sur les différents sites Découpage vertical : jointure
Pourquoi des architectures n-tiers? Web Très répandu et permet de traiter différents types de données (textes, sons, images, ) SGBD Accès efficace et sécurisé à des données structurées (tables/n-uplets) La combinaison des deux est de plus en plus systématique
Architectures n-tiers Web : manipule des données statiques en lecture seule via HTML Les accès à une base de données supposent que : les données à stocker dans les pages ne sont pas connues a priori des requêtes de mise à jour sont indispensables Solution : générer les pages HTML à la volée
Architectures deux-tiers et trois-tiers Architectures à deux pôles (2-tiers) client avec un navigateur serveur pour les applications et le SGBD Architectures à trois pôles (3-tiers) client avec un navigateur serveur d applications (le plus souvent OO) serveur de données (SGBD)
Architecture deux-tiers Deux types de serveur d application Passerelle CGI (Common Gateway Interface) Un programme externe au serveur HTTP construit les pages HTML à partir des résultats des requêtes Serveur HTTP étendu Toutes les applications partagent les données grâce à un ensemble de fonctions (API ou Application Programming Interface) intégrées au serveur HTTP
Architecture deux-tiers réseau Serveur HTTP Appli. CGI Poste client (navigateur) réseau Serveur HTTP étendu API Appli. SGBD + données
Architecture deux-tiers Deux types d API ISAPI (Microsoft) : remplace les exécutables CGI par des DLL partagées par plusieurs applications NSAPI (Netscape) : extension du serveur HTTP. fonctions définies dans un fichier de configuration souplesse d utilisation
Architecture trois-tiers Poste client Charge et exécute du code Serveur d application Logiciel OO générant le code et assurant l interface avec le SGBD Serveur de base de données Exécute les requêtes et renvoie le résultat à l interface avec le SGBD
Architecture trois-tiers réseau Poste client (navigateur chargeur et exécuteur de code) Serveur de code (OO) - CORBA - ODBC - JDBC réseau Serveur HTTP Base de données Serveur d appli. et HTTP Serveur BD
Architectures n-tiers Architecture 3 tiers Niveau client Niveau serveur d'application : middleware Niveau serveur de données
Gestion de transactions 1.Objectifs et bases 2.Journaux et reprise 3.Cas des systèmes répartis 4.Concurrence d'accès
Problème de base Plusieurs traitements effectués en même temps Il faut garantir : Que tous les traitements sont exécutés correctement Qu'aucun n'attendra «trop longtemps» Qu'aucun ne sera «oublié» Que si une panne survient, ils pourront être repris
Problème de base Opérations typiques : Traitements OLTP (On Line Transaction Proc.) : Mises à jour ponctuelles de lignes par des écrans prédéfinis, souvent répétitives, sur les données les plus récentes Traitements OLAP (On Line Analytical Proc.) : Consultations longues et compliquées Cas typique : données bancaires Débit / crédit sur une base de données bancaire + moyenne des comptes par agence Mesure des performances du système nombre de transactions par seconde et temps moyen d'exécution
Exemple Agences 1 Comptes 100 000 Caissiers 100 Historique (Stocke les opérations)
Test de performance Begin-Transaction Update Compte Set Balance = Balance + Delta Where ComptetId = Aid ; Insert into Historique (Aid, Tid, Bid, Delta, TimeStamp) ; Update Caissier Set Balance = Balance + Delta Where CaissierId = Tid ; Update Agence Set Balance = Balance + Delta Where CaissierId = Tid ; End-Transaction Pour valider un débit/crédit, toutes les màj doivent être faites 90 % doivent avoir un temps de réponse < 2 secondes Chaque terminal génère une transaction toute les 10s Performance = Nombre de transactions validées / temps total
Exécution concurrente En plus de ces transactions, on suppose d'autres requêtes compliquées traitant un grand nombre de n-uplets en lecture Exemple : moyenne des comptes par agence SELECT A.AgenceId, AVG(C.Balance) FROM Agence A, Compte C WHERE A.AgenceId = C.AgenceId GROUP BY A.AgenceId
Les menaces Concurrence entre transactions Les effets d'une transaction sont «perdus» Des incohérences apparaissent Toutes les transactions sont bloquées Pannes Une transaction ne peut plus être continuée : défaire ce qui a été fait puis reprendre la transaction Une panne logicielle ou matérielle intervient : reprendre les transactions en cours
Propriétés des transactions Atomicité Soit toutes les mises à jour sont validées soit aucune Cohérence La base doit passer d'un état cohérent à un autre état cohérent Isolation Les résultats d'une transactionne ne sont visibles que lorsque cette transaction est validée Durabilité Les résultats d'une transaction validée ne peuvent être modifiés que par une autre transaction
Atomicité Introduction de deux instructions : Commit : validation des modifications (écriture sur disque) Abort : annulation des modifications (retour en arrière) (Rollback sous ORACLE) Une transaction peut donc : Avoir une «vie sans histoire» (son commit a été exécuté) Se suicider (son code contient un abort) Etre assassinée (le système a exécuté un abort)
En résumé... Update Update Mémoire de la transaction Commit Abort Bases de données Poubelle
Cohérence Perte de mise à jour lorsque deux transactions modifient le même objet Deux transactions T1 et T2 ajoutent Delta au même compte comme suit T1 : lire C.Balance T1 : C.Balance = C.Balance + Delta T2 : lire C.Balance T2 : C.Balance = C.Balance + Delta T2 : Ecrire C.Balance puis Commit T1 : Ecrire C.Balance puis Commit T2 est perdue
Isolation Lectures impropres : Une transaction modifie un objet lu par une autre transaction T1 ajoute Delta mais est annulée et T2 lit Balance T1 : lire C.Balance T1 : C.Balance = C.Balance + Delta T1 : Ecrire C.Balance T2 : lire C.Balance T1 : Abort T2 :... T2 lit une valeur fausse
Durabilité Une panne peut «annuler» les effets d'une transaction Exemple T1 : lire C.Balance T1 : C.Balance = C.Balance + Delta T1 : Ecrire C.Balance...PANNE... Commit T1 n'est pas sauvegardée
Journaux (avant/après) Journal «avant» : sauvegarde les valeurs lues avant modification Contient les débuts de transactions, les valeurs d'enregistrement avant mises à jour, les fins de transactions (commit ou abort) Permet de défaire les mises à jour effectuées par une transaction
Journal avant 2.Log Page lue Page modifiée 3.Update 1.Read 4.Write Base de données
Journaux (avant/après) Journal «après» : sauvegrade les valeurs après modifications Contient les débuts de transactions, les valeurs d'enregistrement après mises à jour, les fins de transactions (commit ou abort) Il permet de refaire les mises à jour effectuées par une transaction
Journal après 3.Log Page lue Page modifiée 2.Update 1.Read 4.Write Base de données
Gestion des journaux Structure d'un enregistrement Numéro de transaction (Trid) Type d'enregistrement {début, update, insert, commit, abort} TupleId [Attribut modifié, Ancienne valeur, Nouvelle valeur]... Ecrits dans un tampon en mémoire et vidés sur disque en début de Commit ou Abort
Sauvegrades Sauvegrades périodiques En parallèle aux mises à jour Ecrite dans les journaux ("savepoint") L'état sauvegardé doit être cohérent Points de reprise Permet de situer les transactions effectuées après la sauvegarde Pose d'un point de reprise Ecrire les buffers de journalisation (Log) Ecrire les buffers de pages (DB) Ecrire un record "checkpoint" dans le journal
En cas de panne... Panne logicielle : reprise «à chaud» Rechercher le dernier point de reprise Avec le journal après, rechercher les transactions en cours au moment de la panne Avec le journal avant, défaire les transactions non validées Avec le journal après, refaire ces transactions et terminer les transactions validées mais non complètement terminées (panne juste après Commit)
En cas de panne... Panne matérielle : reprise «à froid» Rechercher le dernier point de sauvegarde Restaurer l'état de la base sauvegardé Avec le journal après, reprendre les transactions en cours au moment de la panne
Concurrence Deux types d'action : lecture et écriture Types d'accès concurrents Lecture Lecture : ne pose pas de problème Ecriture Ecriture : perte de mise à jour Ecriture Lecture : lectures impropres Règles pour éviter ces problèmes 1.Toute transaction ne doit pas lire ou écrire un objet modifié par une autre transaction non terminée 2.Toute transaction ne doit pas modifier un objet lu par une autre transaction non terminée
Exemple : perte de mise à jour Deux transactions T1 et T2 ajoutent Delta au même compte comme suit T1 : lire C.Balance T1 : C.Balance = C.Balance + Delta T2 : lire C.Balance T2 : C.Balance = C.Balance + Delta T2 : Ecrire C.Balance puis Commit T1 : Ecrire C.Balance puis Commit Règle 1 non satisfaite
Exemple : lecture impropre T1 ajoute Delta mais est annulée et T2 lit Balance T1 : lire C.Balance T1 : C.Balance = C.Balance + Delta T1 : Ecrire C.Balance T2 : lire C.Balance T1 : Abort T2 :... Règle 1 non satisfaite
Exemple : lecture impropre T1 ajoute puis retire Delta et T2 lit Balance T1 : lire C.Balance T1 : C.Balance = C.Balance + Delta T1 : Ecrire C.Balance T2 : lire C.Balance T1 : C.Balance = C.Balance - Delta T1 : Ecrire C.Balance T1 : Commit Règle 2 non satisfaite
Terminologie Exécution concurrente de transactions : Séquence dans laquelle les instructions des transactions sont mélangées Exécution séquentielle : Séquence dans laquelle les instructions des transactions ne sont pas mélangées Exécution concurrente correcte : Son résultat est le même que celui produit par une exécution séquentielle
Détection des problèmes Graphe de précédence d'un exécution concurrente E Noeuds : transactions concurrentes Arcs : arc de T à T' si dans E, T lit ou écrit un objet puis T' écrit le même objet Exécution concurrente problématique si le graphe de précédence est cyclique
Exemples Reprendre les exemples donnés précédemment Tous les graphes contiennent Deux noeuds : T1 et T2 Deux arcs : de T1 à T2 et de T2 à T1
Verrous Permettent à une transaction de «réserver» en exclusion des autres un objet Deux actions élémentaires Demander un verrou sur O : lock(o) Libérer un verrou sur O : unlock(o) On ne peut lire ou écrire un objet O sans avoir obtenu un verrou sur O Deux types de verrou : écriture et lecture Tout verrou en écriture est exclusif Les verrous en lecture peuvent être partagés
Verrouillage en 2 phases Acquisition des verrous, puis libération des verrous Il est impossible d'obtenir un nouveau verrou après en avoir libéré un On garantit ainsi la correction des exécutions concurrentes Mais il reste un problème : interblocage
Exemple d'interblocage T1 : lock(o, W) T2 : lock(o', W) T1 : lock(o', R) T1 attend que T2 libère le verrou T2 : lock(o, W) T2 attend que T1 libère le verrou... T1 et T2 s'attendent mutuellement Comment résoudre ce problème? Quand il apparaît (on retrouve une problématique de cycle dans un graphe) En évitant (au mieux) qu'il n'apparaisse
Résolution des interblocages Maintenir le graphe des verrous Noeuds : transactions Arc de T à T' : T attend un verrou possédé par T' Tester régulièrement si le graphe est cyclique Par exemple dès qu'une transaction attend trop longtemps Si le graphe est cyclique Choisir une transaction du cycle Défaire cette transaction, puis la refaire plus tard
Prévention des interblocages Donner priorité aux transactions anciennes Ajouter une estampille de temps à chaque transaction Deux techniques Wait-Die : annuler une transaction T demandant des verrous tenus par des transactions anciennes. Lorsque T est reprise, elle garde son estampille Wound-Wait : si une transaction ancienne attend un verrou d'une transaction nouvelle T, T est blessée. Si T demande un verrou déjà pris, elle est défaite puis refaite
Cas des BD réparties La technique du verrouillage en 2 phases est utilisée Gestion centralisée : un site est désigné pour coordonner les demandes de verrous Sites impliqués par la transaction Site d'exécution de la transaction Site central 3 - exécution 4 - fin de transaction 1 - demande 2 - obtention 5 - libération
Gestion distribuée des verrous Plusieurs sites gèrent les verrous Chaque site s'occupe des verrous sur un ensemble donné d'objets Données répliquées : t sur différents sites t est lu sur un seul site (le plus souvent, le site où est exécutée la transaction) t est écrit sur tous les sites où il est stocké Donc t doit être verrouillé en écriture sur tous les sites où il est stocké Mais t doit aussi être verrouillé en lecture sur tous les sites où il est stocké
Gestion des interblocages Gestion centralisée : comme le cas standard Gestion distribuée Chaque site peut ne pas avoir de problème Mais, globalement, interblocage Résolution des interblocages dans une gestion distribuée : Chaque site teste si son sous graphe est cyclique et résout éventuellement un interblocage local Si nécessaire, on teste si le graphe global est cyclique (sur un site dédié)
Exemple 4 transactions et deux sites T1 et T2 exécutées sur le site 1 T3 et T4 exécutées sur le site 2 Ordonnancement global [T1 lock(a, W)] [T2 lock(a, W)] Site 1 T1 T2 [T3 lock(a, W)] [T4 lock(a, W)] [T4 lock(b, W)] [T1 lock(b, W)] Site 2 T3 T4
Conclusions On n'a présenté que les notions de base Beaucoup de recherches sur le sujet, mais peu d'implémentations Granularité des objets verrouillés (de la base complète au n-uplet) ou degrés d'isolation Gestion de transactions imbriquées pour améliorer le parallélisme Extension des opérations (pas seulement read/write) pour avoir des propriétés de commutativité...