Bases de données temps-réel

Transcription

1 Bases de données temps-réel Plan Applications temps réel et SGBD Les SGB traditionnels Modèles et approches pour le temps réel Produits existants Conclusion 1

2 Les applications temps-réel Gestion de systèmes dont les comportements doivent être prévisibles et opportuns Paramètres évoluant au cours du temps Actions à mener au moment voulu avant une date limite Familles de temps-réel : dur, ferme, mou dur ( état catastrophique en cas de non respect), ferme ( abandon en cas de non respect), mou ( terminaison de la transaction avec un intérêt moindre) Les SGBD Format des données indépendant des applications les utilisant Gestion, stockage, interrogation très efficaces de grands volumes de données Garanties d intégrité, de cohérence et de récupération des données en cas de panne.? Les applications temps-réel peuvent en avoir besoin 2

3 Exemples d applications Gestion de salles de marchés Contrôle du trafic aérien Applications militaires (gestion d un champ de bataille) Télécom : routeurs, commutateurs Gestion d une centrale nucléaire... Des objectifs différents SGBD : objectifs de performance globale, sans garantie pour une transaction particulière. Pas de notion de temps. Applications temps-réel : besoin d assurance de résultats pour des requêtes individuelles.? Aménagements nécessaires pour rendre les SGBD compatibles avec les applications temps-réel. 3

4 Les aménagements Spécifications des caractéristiques tempsréel pour les données et les transactions Suppression des aléas de temps de transaction : gestion des index, BD résidente en mémoire, relâchement de contraintes de cohérence Nouveaux algorithmes de contrôle de concurrence Caractéristiques temps-réel Sur les données : estampillage et durée de validité Sur les transactions : date limite, facteur critique, fonction de valeur? priorité Autres paramètres utiles : fréquence, ressources et données nécessaires, temps d exécution estimé? classification des transactions 4

5 Suppression des aléas Méthodes adaptées de gestion des index Base de données résidente en mémoire Relâchement de contraintes de cohérence Gestion des index Les index permettent un accès plus rapide aux données Idée : limitation du nombre de transactions concurrentes Problème des index : reconstruction? utilisation de B+-arbres relâchés, permet un rééquilibrage différé 5

6 BD résidente en mémoire Avantage : suppression des accès disque, meilleure prévision des temps de transactions Meilleure utilisation des ressources? nouveau contrôle de concurrence : utilisation de verrous à gros grain (niveau relation) Sinon, importance de l organisation de la hiérarchie mémoire : répartition entre données en mémoire et sur disque Relâchement de contraintes Propriétés ACID : Atomicité Cohérence Isolation Durabilité Contrôle de concurrence assure la sérialisabilité, parfois trop lourde à mettre en œuvre. 6

7 Ordonnancement et contrôle de concurrence Introduction des priorités pour ordonnancer les transactions et gérer les conflits Cas des SGBD traditionnels : Verrouillage à deux phases et estampillage Aménagements pour le temps réel: 2PL-HP et méthodes optimistes Cas des SGBD traditionnels Transaction : correspond à la vision d un programme d utilisateur du coté du SGBD, c-à-d une séquence de lectures/écritures. Exécution en série: une transaction après l autre. Si chaque transaction préserve la cohérence, toute exécution en série préserve la cohérence. Ordonnancement sérialisable: équivalent à une exécution en série. Équivalence : Quelque soit la BD, l effet de la première exécution est identique à l effet de la seconde exécution. Moyen de vérification : ordre des lectures et écritures conflictuels. 7

8 Exécution sérialisable Deux exécutions sont équivalentes si: Les mêmes actions (lecture, écriture) se retrouvent dans les mêmes transactions Chaque paire de d actions conflictuelles (lecture/écriture, écriture/lecture ou écriture/écriture) sont ordonnées de la même façon dans les deux exécutions Une exécution S est sérialisable si S est équivalente à une exécution en série des mêmes transactions Exemple Une exécution non sérialisable: T1: R(A), W(A), R(B), W(B) T2: R(A), W(A), R(B), W(B) T1 A T2 Graphe de précédence B Le cycle dans le graphe révèle le problème. L effet de T1 dépend de celui de T2, et vice-versa. Théorème : cycle dans le graphe de précédence non sérialisable. 8

9 Protocole 2PL: Protocole de verrouillage en 2 phases (2PL) Chaque transaction doit obtenir un verrou partagé S (shared) sur un granule avant de le lire, et un verrou exclusif X (exclusive) sur un granule avant d effectuer une écriture dessus. Tous les verrous émis par une transaction sont libérés à sa terminaison. Si une transaction émet un verrou X sur un granule, aucune transaction ne peut obtenir un verrou (S ou X) sur le même granule. Une transaction ne peut émettre de verrou dès qu elle commence à libérer ses verrous. Deadlocks Exemple: T1: S(A) S(B) T2: X(B) X(C) T3: S(C) X(A) T1 T2 T3 Deux manières de gérer les deadlocks: prévention des Deadlocks détection des Deadlocks 9

10 Prévention des Deadlocks Attribuer des priorités sous forme d estampilles temporelles (date de prise en compte). Supposons que Ti demande un verrou détenu par Tj. Deux cas de figure : Wait-Die: si Ti a une priorité supérieure, Ti attend Tj; autrement Ti abandonne Wound-wait: si Ti a une priorité supérieure, Tj abandonne; autrement Ti attend Détection des Deadlocks Création d un graphe d attente waits-for graph: Les nœuds représentent les transactions Il y a un lien de Ti vers Tj si Ti attend que Tj libère un verrou Périodiquement vérifier s il y a un cycle dans le graphe waits-for 10

11 Estampillage Idée: attribuer à chaque élément un readtimestamp (RTS) et un write-timestamp (WTS), donner à chaque nouvelle transaction une estampille (TS): Si l action a i de la transaction Ti est en conflit avec l action aj de Tj, et TS(Ti) < TS(Tj), alors a i doit être réalisée avant aj. Sinon, relancer la transaction. T veut lire un granule O Si TS(T) < WTS(O), T veut lire une valeur de O déjà recouverte. Alors, la lecture est refusée et T abandonnée et relancée avec une nouvelle estampille. Si TS(T) >= WTS(O): Permettre à T de lire O. M-à-J de RTS(O) à max(rts(o), TS(T)) Le changement de RTS(O) doit être écrit sur disque! 11

12 T veut écrire un granule O Si TS(T) < RTS(O), La valeur de O que T est en train de produire a été demandée antérieurement et supposée jamais produite. L écriture est refusée et T abandonnée et relancée par la suite. SINON T1 Si TS(T) < WTS(O), R(A) T tente d écrire une valeur périmée L écriture est rejetée et T abandonnée. Thomas-Write-Rule : ignore l écriture. Autrement, L écriture est acceptée et M-à-J de WTS(O) à max(wts(o), TS(T)) W(A) Commit T2 W(A) Commit Adaptation du contrôle de concurrence au temps réel Objet principal des travaux de recherche sur les SGBD temps-réel. Besoin : Ordonnancement en fonction des priorités affectées aux transactions En cas de conflit, priorité aux transactions les plus critiques. 12

13 Protocole 2PL High Priority Du V2P + gestion de priorités En cas de conflit, abandon de la transaction de priorité inférieure et remise en jeu de celle ci. Une transaction demandant un verrou en lecture ne peut l obtenir que si sa priorité est supérieure à celles de toutes les transactions en attente de verrou en écriture 2PL- Wait Promote V2P + gestion de priorités En cas de conflit, la transaction bloquante hérite de la priorité de la transaction bloquée si la priorité de cette dernière est supérieure à la priorité de la transaction bloquante. Problème : les simulations montrent des performances moindres que le 2PL- High priority. 13

14 Les OCC: concurrence optimiste OCC-FV (Forward Validation): Pas de verrouillage, phase de validation à la fin de la transaction. Les transactions en conflit avec la transaction arrivée à la validation sont abandonnées. OPT-SACRIFICE : Une transaction peut être abandonnée en phase de validation, en cas de conflit avec une transaction plus prioritaire. Problème : une transaction peut être abandonnée après avoir utilisé beaucoup de ressources qui seront gâchées. OPT-WAIT : Une transaction doit attendre la fin des transactions qui sont en conflit avec elle et qui possèdent une priorité supérieure à la sienne. Simulations des méthodes les plus efficaces (2PL-HP et OCC-FV) Temps réel mou léger avantage au 2PL-HP en cas de ressources finies OCC-FV plus performant dans tous les autres cas. Explication : Nombre d abandons accentué pour le 2PL-HP par le fait que les transactions abouties peuvent être abandonnées à leur tour car elles n ont pas terminé dans les temps. 14

15 Un prototype : StarBase Objectifs : gestion de contraintes temps-réel fermes, BD non répartie, sur disque, modèle relationnel Repose sur un OS temps-réel : RT-Mach Objectif de performance : maximiser le taux de transactions exécutées avant leur date limite Implémentation détaillée du SGBD StarBase : caractéristiques Limitation du nombre de transactions concurrentes Ordonnancement des transactions natif RT- Mach, fondé sur les priorités Contrôle de concurrence : WAIT-X(S) 15

16 Les autres produits Stades d avancement variés : peu sont aboutis Produits spécialisés et adaptés aux applications temps-réel associées La plupart utilisent des BD réparties Toutes les techniques développées ne sont pas utilisées Des produits commercialisés non encore approuvés (empress.com) Conclusion Axes de recherches privilégiés : contrôle de concurrence, relâchement des contraintes Pas de proposition de la part des principaux éditeurs de SGBD Sujet qui prend de l importance avec la multiplication des applications temps-réel utilisant des de gros volumes de données persistantes. 16

17 Bibliographie Ben Kao and Hector Garcia-Molina. An Overview of Real-Time database systems. In Advances in real-time systems. Printice Hall, april Azer Bestavros. Advances in real time Database systems research. In ACM-SIGMODSeries, 25(1), March Young-Kuk Kim and Sang H. Son. Starbase : Managing Contention and Timing constraints. In RTDBMS: issues and applications, chapter 1, Kluwer-Academic, C. Hermant, mémoire de fin d études, ENST