Du temps réel sous PostgreSql

Du temps réel sous PostgreSql
Implémentation de EDF (Earliest Deadline First)
Tirse Abdelghani
Doctorant
ESI (ex INI) Alger
Hidouci Walid Khaled
Maître de conférences
ESI (ex INI) Alger
Loudini Malik
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. I NTRODUCTION
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 Système de Gestion de Bases de Données Temps Réel
2 Earliest Deadline First
3 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 T EMPS 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éances
4
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. O RDONNANCER 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. P OSTGRESQL
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
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. S IMULATION 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
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).
Figure 2. Paramétrage d'une simulation.
VI. C ONCLUSION 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 real-
time 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.