Chapter 6 – Conclusion and Research Perspectives
5 Perspectives de Recherche
5.1 Calibrage de la Quantité de Mémoire Volatile
notables. Enfin, considérer à la fois XML et de nouvelles technologies mémoires est un problème intéressant.
5.1 Calibrage de la Quantité de Mémoire Volatile
Le calibrage des ressources est crucial dans le contexte de la carte à puce, et plus généralement dans celui des petits objets intelligents (capteurs météorologiques ou de trafic routier, composant embarquées dans les appareils domestiques, etc.) subissant des contraintes techniques et/ou économiques. En effet, l'exiguïté de l'environnement cible (dispositif embarqué dans le corps), la puissance d'alimentation limitée et la résistance aux attaques (prévient l'observation directe des composants) entraînent la minimisation des ressources matérielles du composant intelligent. De plus, lorsque ces composants sont produits à grande échelle (c'est le cas des cartes à puce), la diminution des coûts de production impose la réduction de la taille du chip (le coût est directement lié à la taille du support de silicium) et réduisant ainsi les ressources embarquées. Dans ce contexte, la RAM est une ressource particulièrement cruciale vue sa faible densité comparée aux autres composants (une cellule de RAM est 16 fois plus volumineuse qu'une cellule de ROM); elle représente dans une puce près du tiers du prix (matériel) de la puce. Elle doit donc être soigneusement calibrée, et minimisée selon les besoins de l'application. L'étude [ABP03] réalise un premier pas dans cette direction, en considérant (i) des données relationnelles
stockées à plat et sans index49, (ii) un dispositif autonome (on s'interdit de se reposer sur des
ressources distantes et/ou du swap externe à la puce), (iii) des droits d'accès basés sur des requêtes plates (non imbriquées) comme dans le contexte PicoDBMS, et (iv) de la mémoire persistante électronique (accès rapide en lecture) comme c'est le cas dans les puces.
Cette étude est conduite en 3 étapes, que nous résumons dans cette section. La première étape détermine la quantité minimale de RAM nécessaire à l'évaluation de requête, sans se soucier des performances. La deuxième étape consiste à améliorer/optimiser les performances de ce modèle d'exécution à consommation mémoire minimale. La troisième étape s'attache à étudier l'impact sur le modèle précédent de l'ajout incrémental de RAM.
5.1.1 Modèle d'Exécution à Consommation Minimale
La consommation RAM d’un plan d’exécution correspond à la taille cumulée des structures de données internes des opérateurs et des résultats intermédiaires traversant l’arbre d’opérateurs. Le modèle d’exécution doit suivre deux règles pour consommer le minimum de
49 Les index ne sont pas considérés dans l'étude. La raison principale est de rendre le problème analysable, et de voir jusqu'où on peut aller sans index. D'autres raisons peuvent aussi justifier notre analyse sans index : (i) ils augmentent le coût des mises à jour et compliquent l'atomicité, (ii) ils sont nécessairement absents dans certains contextes évaluant des requêtes sur des flots de données, (iii) ils sont difficiles à maintenir sur certaines technologies de mémoire comme la FLASH gros grain considérée dans [BSS+03], (iv) ils rivalisent avec les données embarquées en terme d'espace de stockage, (v) vu que tous les attributs ne sont pas nécessairement indexés, certaines requêtes doivent être évaluées sans disposer d'index.
Database on Chip Résumé en Français – French Summary
-178-
mémoire : (R1) la règle d’invariabilité proscrit toute structure de donnée dont la taille est fonction du volume de données interrogées et (R2) la règle de minimalisme interdit le stockage de toute information qui peut être recalculée. Ces deux règles régissent la synchronisation des opérateurs et minimisent le stockage interne, conduisant à une exécution pipeline stricte, représentée Figure 76.
Structure DFlo w scan scan scan R S T Group by R.a, S.b Agrégat Ptr S
Ptr R Ptr TClé de grpcouranteT Clé de grpsuivanteT Agrég at
GBY.Open ChildOp.Open();Split.Val ue←+∞ // Scan the whole inp ut in
repeat // order to find the smallest groupin g valu e (GV) in Split
ChildOp.Next()
if DflowÎGrpLst < Split.Value then Sp lit←DFlo w.GrpLst
until DFlow.Chil d = EOF // Split converges to the small est GV at EOF
GBY.Next
if Split.Value ≠+∞then // there is a next GV to compute
Current←Split; DFlow.AggLst←0 // Initialize the computati on of the current GV
Split.Value←+∞; Chil dOp.Open() // Initialize Spl it for computing the n ext GV
repeat // scan the whole inp ut
ChildOp.Next()
if DflowÎGrpLst = Current.Value then // the current tuple shar es the GV
compute DFlowÎAgg Lst
elseif DFlowÎGrpLst∈] Curre nt.Value,Sp lit.Valu e [ then // Split converges
Split←DFlow.GrpLst until DFlow.Ch ild = EOF
DFlow.GrpLst←Current // Output an aggregate
Figure 76 Requête exemple et Dflow. Figure 77 Algorithme GroupBy.
L’algorithme des différents opérateurs du modèle d’exécution à consommation minimale découle de ces règles. Nous les représentons dans [ABP03] selon le modèle
itérateur [Gra93] disposant de l'interface Open, Next, Close, où Open initialise les structures
de données internes, Close les libère et Next produit le tuple suivant de l'opérateur.
L'algorithme de groupement (GroupBy) est détaillé Figure 77. Lors de l'Open, les valeurs des
clés de groupement courantes et suivantes sont fixées respectivement à –∞ et à +∞, et
l'opérateur consomme entièrement son entrée à la recherche de la clé de groupement
minimale qu'il stocke dans l'attribut de Dflow Clé de grpT courante. Sur appel à Next,
l'opérateur parcourt le flot d'entrée jusqu'à rencontrer un tuple partageant la clé courante qu'il délivre alors en résultat; chaque tuple consommé par l'opérateur fait éventuellement évoluer
la clé de groupement suivante stockée dans Clé de grpT suivante lorsque la clé rencontrée en
entrée est strictement comprise entre les valeurs courantes et suivantes stockées dans Dflow. Lorsque l'opérateur rencontre la fin du flot d'entrée, il stocke remplace la clé courante par la suivante, ouvre à nouveau son flot d'entrée et répète le processus.
Ce modèle d’exécution, consommant le minimum de RAM, offre de faibles performances dues aux re-itérations successives sur les données engendrées par les opérateurs de groupement (décrit précédemment) et de jointure, qui ne peut être réalisé que par boucle imbriquée. La conséquence dramatique sur le nombre de réitérations (nombre de
Open) réalisées est présentée Figure 78. Avec k clés de groupement distinctes à l’entrée du
Database on Chip Résumé en Français – French Summary -179- scan R S T Group by R.a, S.b k ×| | R S| | itérations k ×| | R|| itérations k itérations scan scan Agrégat R S T Group by R.a, S.b Clé courante = a1,b1 Clé suivante = a3,b5
R.a ≥a1 & R.a ≤a3 (R.a, S.b) ≥(a1,b1) & R.a,S.b <(a3, b5) R.a,S.b <(a3, b5)
scan scan scan Agrégat
Figure 78 Itérations nécessaires à l’évaluation à consommation minimale.
Figure 79 Filtres d'itération de l'algorithme de groupement.
5.1.2 Optimisation du Modèle : les Filtres d'Itération
Des solutions diverses et complémentaires peuvent être envisagées pour réduire le coût de ces itérations sans consommer de RAM supplémentaire. Des techniques traditionnelles d’optimisation globale minimisent le nombre d’itérations total par réorganisation de l’arbre d’exécution, par exemple en opérant les sélections le plus tôt possible et en ordonnant les jointures de façon optimale (envisagées dans [ABP03]).
En outre, nous avons imaginé une technique d’optimisation locale50 originale réduisant
le nombre de tuples considérés au sein de chaque itération. Le flot de tuples entrant de
chaque opérateur peut être séparé en trois ensembles distincts: les tuples Nécessaires sont
ceux qui participent au résultat produit lors de l’itération en cours (pour le groupement, ceux
qui partagent la clé courante), les tuples Indispensables sont ceux qui modifient l’état interne
des opérateurs sans participer au résultat de l’itération courante (pour le groupement, ceux qui partagent une clé de groupement située entre les clés courante et suivante), et les tuples
Inutiles qui ne sont ni Nécessaires ni Indispensables. Du filtrage doit être mis en place pour éviter de traiter et d’acheminer ces tuples dans l’arbre d’exécution jusqu’à l’opérateur. La
distinction des tuples Nécessaires, Indispensables et donc Inutiles dépend de chaque
opérateur. Une fois cette distinction faite, le filtrage des tuples Inutiles peut être mis en
œuvre (l'étude de minimisation du nombre de tuples Nécessaires, conduisant à choisir un
algorithme plutôt qu'un autre, est réalisée dans [ABP03]). Chaque opérateur souhaitant
éliminer les tuples Inutiles de son flot d’entrée exprime un prédicat, appelé filtre d’itération,
qui sélectionne uniquement les tuples Nécessaires et Indispensables pour une itération
donnée. Ce prédicat est ensuite vérifié par les opérateurs du sous-arbre, produisant ce flot d’entrée. Conceptuellement, un filtre d’itération est similaire à un prédicat de sélection qui serait appliqué le plus tôt possible dans l’arbre d’exécution. Toutefois, les filtres d’itération peuvent impliquer plusieurs attributs de plusieurs relations de base. Ils sont donc plus
50 Notons que le terme d’optimisation locale a un sens différent de son utilisation classique, puisqu’il s’applique à une itération plutôt qu’à un opérateur.
Database on Chip Résumé en Français – French Summary
-180-
complexes que des restrictions classiques, ce qui impose de s’attacher à la manière de les vérifier pour éviter des opérations redondantes. La Figure 79 montre les filtres d'itérations réduisant le flot d'entrée de l'opérateur de groupement. La clé de groupement correspondante
à l'agrégat en cours de calcul est (a1, b1), et la valeur immédiatement supérieure parvenue à
l'opérateur de groupement dans l'état actuel de l'exécution est (a3, b5). Les opérateurs du
sous arbre peuvent donc éliminer les instances du produit cartésien partageant une clé strictement inférieure à (a1, b1) ou supérieure à égale à (a3, b5).
Le modèle d'exécution proposé en RAM minimale s’adapte naturellement à une quantité de RAM bornée additionnelle disponible lors de l’exécution par ajout d'autres
instances du produit cartésien (au lieu d'une seule) dans Dflow. Chaque itération produit ainsi
plusieurs résultats. Cependant, cette utilisation de la RAM complique la vérification des filtres d'itération, vu que celle-ci s'opère sur des ensembles. On peut cependant facilement balancer l'efficacité des filtres avec le coût de vérification.