Du temps réel sous PostgreSql Implémentation de EDF (Earliest Deadline First) Tirse Abdelghani Hidouci Walid Khaled Loudini Malik Doctorant ESI (ex INI) Alger Maître de conférences ESI (ex INI) Alger Maître de conférences ESI (ex INI) Alger Résumé: Les SGBDTR 1 gagnent de plus en plus d'importance ces dernières années. Plusieurs SGBDTR ont vu le jour, mais la plupart sont des solutions propriétaires comme STRIP (STranford Real-time Information Processor) [2], EagleSpeed [12], Polyhedra [14], et TimesTen [17]. Dans cet article, on présente notre extension temps réel de PostgreSql, un SGBD traditionnel open source, par l'implémentation de EDF 2 , une méthode d'ordonnancement en ligne utilisée sur la plupart des SGBDTR. Les performances de cette extension temps réel seront évaluées par notre simulateur réalisé à cet effet. Mots-clés: Systèmes de Gestion de Bases de Données, Temps Réel, Earliest Deadline First, PostgreSql. I. INTRODUCTION En plus des contraintes temporelles qu’elles doivent satisfaire, les applications temps réel actuelles doivent gérer, dans les temps, une quantité de données de plus en plus importante. Les STR 3 sur lesquels elles tournent, sont bien adaptés pour la gestion des contraintes temporelles, mais sont beaucoup moins efficaces pour manipuler des quantités importantes de données. Les SGBD sont mieux indiqués pour une gestion efficace d’une masse importante de données. Malheureusement, les temps d’exécution des transactions individuelles, dans un SGBD classique, sont indéterminés car l’objectif principal de ces SGBD est de minimiser le temps de réponse moyen des transactions [6], [9]. Donc, avoir des transactions qui s’exécuteraient durant une durée très longue n’est pas à écarter, ce qui est inacceptable dans beaucoup d’applications temps réel. C’est dans ce contexte que sont nées les recherches sur les SGBD temps réel, des systèmes qui doivent gérer de grands volumes de données tout en considérant les échéances individuelles et des transactions et celles des données. Par conséquent, l’objectif n’est plus de minimiser le temps de réponse des transactions comme c’est le cas des SGBD traditionnels, mais de minimiser le nombre de transactions qui ratent leurs échéances. Alors tous les ordonnancements sérialisables ne sont pas acceptables : ceux qui ne respectent pas les contraintes temporelles des transactions sont rejetés. Ceci implique la nécessité d’autres méthodes de gestion de transactions. Dans les SGBDTR, 1 2 3 Système de Gestion de Bases de Données Temps Réel Earliest Deadline First Système Temps Réel l’ordonnancement des transactions est guidé par des considérations de priorité que par des considérations d’équité. Dans cet article, on présente notre extension temps réel de PostgreSql avec la stratégie la plus utilisée pour l’ordonnancement des transactions dans un SGBDTR qui est EDF ou Earliest Deadline First, où la transaction avec l’échéance la plus proche se verra attribuer la priorité la plus haute. La suite de cet article est organisée comme suit. La section 2 présente les définitions de base d' un SGBDTR . La technique EDF est décrite dans la section 3. La section 4 présente PostgreSql, le SGBD open source objet de l' extension. Les résultats de nos tests et simulations seront discutés dans la section 5. La section 6 conclue notre papier et présentera nos travaux futurs. II. SGBD TEMPS RÉEL A. Introduction Les Systèmes de Gestion de Bases de Données Temps Réel (SGBDTR) sont le résultat d’un croisement de chemins entre les systèmes de gestion de bases de données (SGBD) [3], [8], [9] et les systèmes temps réel (STR) traditionnels [9], [7]. Le coup d’envoi des recherches était donné en 1988 avec l’article de Abbot et Garcia-Molina [1]. Depuis, le domaine ne cesse de drainer de plus en plus de chercheurs des deux communautés SGBD et STR avec des publications de haut niveau. Parmi les solutions proposées, on peut citer STRIP (STranford Real-time Information Processor) [2], EagleSpeed [12], Polyhedra [14], et TimesTen [17]. B. Caractéristiques des SGBDTR 1) Les données temps réel Les données temps réel représentent la capture de l’état du monde réel. On distingue entre donnée de base et donnée dérivée. 2) Donnée de base Correspond à une entité concrète de l’environnement (température, pression, etc.). 3) Donnée dérivée Se calcule à partir de valeurs d’autres données. 4) Échéances4 des transactions Respecter l’échéance d’une transaction est souvent un critère plus important que celui de la précision des résultats, c’est-à-dire qu’une réponse partielle qui arrive avant échéance peut être plus utile pour l’application qu’une réponse précise (ou complète) fournie en retard. 5) Classification des transactions sous les SGBDTR En plus de la cohérence logique de la base, les transactions dans un SGBDTR doivent respecter leurs échéances. Dans [10], [15], [16] on trouve une classification des transactions dans les SGBDTR. Cette classification est faite sur la base des conséquences que peut avoir le manquement des échéances transactions sur l’application et sur son environnement. a) Transactions à échéances strictes et critiques («hard deadline transactions») Une transaction qui rate son échéance peut avoir des conséquences graves sur le système ou sur l’environnement contrôlé. Par exemple, dans un système d’interception de missiles, les transactions qui permettent de contrer des missiles adverses sont à échéances strictes et critiques [13]. b) Transactions à échéances strictes et non critiques («firm deadline transactions») Si une transaction rate son échéance, elle devient inutile pour le système. Ses effets sont nuls. Elle est donc abandonnée (terminée avec échec) dès qu’elle rate son échéance. c) Transactions à échéances non strictes («soft deadline transactions») Si une transaction rate son échéance, le système ne l’abandonne pas immédiatement. En effet, elle peut avoir une certaine utilité pendant un certain temps encore après l’expiration de son échéance, mais la qualité de service qu’elle offre est moindre. Les principaux travaux actuels sur les SGBDTR portent sur les systèmes où les transactions possèdent des échéances strictes et non critiques (firm) ou des échéances non strictes (soft). Ces travaux concernent particulièrement des techniques de contrôle de concurrence des transactions et leur ordonnancement. Pour les transactions à échéances strictes et critiques, il n’existe pas à notre connaissance d’algorithmes d’ordonnancement des transactions qui garantissent leur terminaison avant l’échéance. La principale raison provient de l’indéterminisme de ces transactions et du manque de méthodes permettant d’estimer avec précision le temps d’exécution des transactions. Il existe cependant quelques tentatives de modélisation des ordonnanceurs de transactions à échéances strictes et critiques [4], [5], [18]. Ils sont généralement basés sur un surdimensionnement des ressources du système. Une autre classification des transactions est faite suivant le type des données manipulées: 4 Deadline A) Transactions déclenchées de mise à jour ou update transactions Ce sont des transactions déclenchées par les mises à jour des objets de base. Elles mettent à jour les objets dérivés. Ce sont donc des transactions en lecture/écriture. B) Transactions utilisateur ou user transactions Ce sont celles exécutées par l’utilisateur, avec des échéances. Elles effectuent des opérations de lecture/écriture de données non temps réel et/ou des lectures de données temps réel. III. ORDONNANCER SUIVANT EDF Dans une base de données temps réel il est nécessaire de maintenir, en plus de la cohérence logique des données, leur cohérence temporelle. Par conséquent, l’objectif n’est plus de minimiser le temps de réponse des transactions comme c’est le cas des SGBD traditionnels, mais de minimiser le nombre de transactions qui ratent leurs échéances. Alors tous les ordonnancements sérialisables ne sont pas acceptables : ceux qui ne respectent pas les contraintes temporelles des transactions sont rejetés. Ceci implique la nécessité d’autres méthodes de gestion de transaction. Dans les SGBDTR, l’ordonnancement des transactions est guidé par des considérations de priorité que par des considérations d’équité. Partant de ces différences, plusieurs recherches ont été consacrées à la conception d’algorithmes d' ordonnancement de transaction pour les SGBDTR et à l’évaluation de leurs performances. Ces recherches s' appuient sur les techniques d’ordonnancement des tâches dans les STR. La plus utilisée de ces techniques est EDF ou Earliest Deadline First. À un instant t, une transaction T se ferra attribuer une priorité suivant son échéance. Soit T une transaction, D son échéance, alors sa priorité P à un instant t est calculée ainsi: P(T,t)=D(T,t) , avec Zéro comme priorité la plus élevée. IV. POSTGRESQL A. Introduction D' après la documentation postgresql 8.3.5, PostgreSQL™ est un système de gestion de bases de données relationnelles objet fondé sur POSTGRES, Version 4.2™. Ce dernier a été développé à l' université de Californie au département des sciences informatiques de Berkeley. PostgreSql™ est un descendant OpenSource du code original de Berkeley. Il supporte une grande partie du standard SQL tout en offrant de nombreuses fonctionnalités modernes : requêtes complexes, triggers, contrôle des accès concurrents (MVCC ou multiversion concurrency control). De plus, PostgreSqL™ est extensible par l' utilisateur de plusieurs façons. En ajoutant, par exemple de nouveaux types de données, de nouvelles fonctions, de nouveaux opérateurs,... Et grâce à sa licence libérale, PostgreSqL™ peut être utilisé, modifié et distribué librement, quelque soit le but visé, qu' il soit privé, commercial ou académique. PostgreSql est un système client-serveur. Le schéma suivant (Figure 2) donne une vue simplifié sur l' architecture de ce système. Figure 1. Schéma de base de PostgreSql nombre de transactions. Chaque transaction sera affectée d' une échéance et d' une période. En dernière étape avant le lancement de la simulation, il pourra choisir de lancer sa simulation avec un PostgreSql classique ou avec un PostgreSql temps réel, c' est à dire avec EDF. Les résultats de la simulation seront récupérés dans un graphe avec deux courbes qui indiqueront les transactions ayant respectées (respectivement dépassées) leurs échéances. Les données sur lesquelles on a travaillé sont celles fournies par PostgreSql pour le benchmarking. (C' est une base avec 3 tables. La première avec 1000 enregistrements, les deux autres avec 10000 enregistrements chacune). B. Résultats et analyse Durant la phase de simulation, plusieurs séries de tests ont été effectués pour comparer les performances de PostgreSql sans EDF et PostgreSql avec EDF. Les tests varient en termes de nombre de clients, nombre de transactions soumises, de leurs échéances et de leurs périodes. Les résultats obtenus montrent une amélioration: nombre de transactions réussies (respectivement échouées) augmentent (respectivement diminuent). B. Cheminement d'une requête Une requête soumise pour exécution passe par les étapes suivantes: Parser : vérification de syntaxe, transformation en arbre de requête. Rewriter : réécriture de la requête. Planner/Optimizer : choix du meilleur plan d' exécution. Executor: traitement de l’arbre de requête établi (plan tree). Pour la réalisation de notre travail, notre intervention s' est faite au niveau de l' étape 1, c' est à dire le Parser. En effet, on a changé la syntaxe d' une transaction de telle sorte qu' on puisse indiquer l' échéance d' une transaction. (une transaction n' est qu' une requête limité par un bloc Start-Commit/Rollback). La transaction avec l' échéance la plus proche se verra attribuée la priorité la plus haute (zéro est la priorité la plus haute). Notre deuxième changement s' est opéré au niveau de l' étape 4, Executor. Ainsi, une transaction soumise pour exécution ne sera lancée que s' il n' existe pas une transaction plus prioritaire qu' elle, c' est à dire une transaction avec une échéance plus proche. V. SIMULATION ET RÉSULTATS A. Le simulateur L' évaluation des performances de notre implémentation est faite au travers d' un simulateur réalisé à cet effet. Avec une interface graphique intuitive et conviviale, l' utilisateur peut saisir les différents paramètres d' une simulation (Figure 3). Ainsi, l' utilisateur pourra fixer le nombre de clients (par ajout/suppression) et pour chaque client il pourra fixer le Figure 2. Paramétrage d' une simulation. VI. CONCLUSION ET PERSPECTIVES Les SGBDTR actuellement disponibles sont des prototypes ou des solutions propriétaires. Dans cet article nous avons proposé notre extension temps réel d' un SGBD, par l' implémentation de l' algorithme EDF sous PostgreSql, un SGBD open source. Avec la stratégie EDF, qui est utilisée par la plupart des SGBDTR, la transaction avec l’échéance la plus proche se verra attribuer la priorité la plus haute. Nous avons testé les performances de notre solution à travers un simulateur réalisé a cet effet. Avec EDF, seule l' échéance est prise en considération pour l' affectation d' une priorité à une transaction: les transactions qui réussissent ne sont pas nécessairement les plus importantes. Dans nos travaux futurs, on envisage d' ajouter une information indiquant l' importance d' une transaction et de l' utiliser dans le calcul de sa priorité tout en optimisant l' implémenation pour que l' amélioration des performances soit encore plus importante. RÉFÉRENCES [1] Abbot R. and Garcia-Molina H., « Scheduling real-time transactions: a performance evaluation », 14th Int. Conf. on VLDB, p. 1-12, 1988. [2] B. Adelberg, H. Garcia-Molina, and B. Kao. Applying Update Streams in a Soft Real-Time Database System. In ACM SIGMOD, 1995. [3] Bernstein P., Hadzilacos V. and Goodman N., Concurrency control and recovery in database systems, Addison-Wesley, 1987. [4] Bzstavros A. and Braoudakis S., « Timeliness via speculation for realtime database », 14th IEEE RTS Symposium, 1994. [5] Branding B. and Bushmann A., « On providing soft and hard real-time capabilities in an active DBMS », Int. Workshop on ARTDB, p. 158-169, 1995. [6] Dewitt D., Benchmarking Database Systems. Past Effords and Future Directions. IEEE Database Eng. Bull., 8(1) :2–9, 1985. [7] Elloy, J., Groupe de réflexion temps réel du CNRS : Le temps réel. Technique et Science Informatiques (TSI), 7(5) :493–500, 1988. [8] Gardarin G., Bases de Données Objet et Relationnelles. Eyrolles, 2000. [9] Gray J., The Benchmarks HandBook for DataBases and Transaction Processing Systems. Morgan Kaufmann, 1993. [10] Harista J.R., Carey M.J. and Livny M., « Data access scheduling in firm real-time database systems », J. of RTS, vol.4, n° 3, p. 203-241, 1992. [11] Liu C. and Leyland J., Scheduling Algorithms for Multiprogramming in Hard Real-Time Environment. Journal of the ACM, 1(20) :46–61, 1973. [12] Lockheed Martin. EagleSpeed Real-Time Database Manager. [13] Mammeri Z., « Expression et dérivation des contraintes temporelles dans les applications temps réel », APII-JESA, vol. 32, n° 5-6, p. 609-644, 1998. [14] Polyhedra Plc. Polyhedra White Papers, 2002. [15] Purimetla B., Sivasankaran R.M., Ramamritham K. and Stankovic J.A., « Realtime databases: issues and applications », Principles of RTS, ed. Printice Hill, 1994. [16] Ramamritham K., « Real-time databases », J. of Distributed and Parallel Databases, vol. 1, n° 2, p. 199-226, 1993. [17] The TimesTen Team. In-Memory Data Management for Consumer Transactions The TimesTen Approach. In ACM SIGMOD, 1999. [18] Son S.H., Geotge D.W. and Kim Y-K., « Developing a database system for timecritical applications », IEEE Int. Conf. on Database and Expert System Applications (DEXA’93), Prague, Czech, p. 313-324, 1993. [19] Stankovic J., Misconceptions about Real-Time Transactions : A Serious Problem for Next Generation Systems. IEEE Computer, 21(10) :10–19, 1988.