Cas de la jointure hybride SGFD-SGBD

Grâce à la flexibilité de dbsource, nous avons pu réécrire le plan de requête pour

placer au plus les opérateurs relationnels sur le SGBD. Toutefois, nous sommes aussi

en possession d’un composant opérateur que nous pouvons exploiter : dbjoin. Nous

avons défini la sémantique de l’opérateur comme capable de supporter toute requête

R

₁

R

₂

avec R

₁

relation temporelle quelconque et R

₂

exprimée en algèbre

relation-nelle sur les relations de la base de données. Ce composant est un macrobloc que nous

pouvons former grâce à une règle. Afin d’illustrer l’application successive des règles,

voici l’ensemble des résultats intermédiaires appliqués lors du raisonnement :

R

₁ c

R

2

=σ

c

R

₁

1D

^change_R 1

R

2

(viasugar)

= R

₁

1

c

D

^change_R 1

R

₂

(viapushselection)

= R

1

1

c

D

^change_R

1

dbsource

^Q_trigger

(viadboperator)

= R

₁

1

c

dbsource

^Q_{noti f y(R}

1)

(viadbsourcemode)

Enfin, l’application d’une dernière règle va nous permettre de transformer cette

jointure en :dbjoin

^Q_c

(R

1

). Cette règle est exprimée grâce au prédicatmacrobloc:

1 macrobloc(

2 [join,JoinConfig,[

3 [A,LeftConfig,C],

4 [dbsource,DBConfig,[]]

5 ]],

6 [dbjoin,NewConfig,[[A,LeftConfig,C]]]

7 ):- % Si...

8 map_get(DBConfig, "mode", "notify"), % Le mode de dbsource est notify

9 map_get(DBConfig, "dependentRId", RId), % Et notify pointe sur...

10 map_get(LeftConfig, "rid", RId), % ... l’entite de gauche,

11 !, % alors...

12 map_get(DBConfig, "query", Query), % Recuperation de la requete

13 map_get(JoinConfig, "attributes", Attr), % Recupere les attributs

14 map_get(JoinConfig, "condition", "1==1", Cond), % Condition (1=1 par defaut)

15 conditionsql(Cond, CondSQL), % Transformation en SQL

16 map_merge(JoinConfig, { % Ajout des nouveaux parametres de configuration

17 ’query’: Query,

18 ’condition’: CondSQL,

19 ’attributes’: Attr,

20 }, NewConfig).

Toutefois, l’utilisation de cette règle ne semble pas optimale dans tous les cas. Pour

effectuer l’opération de jointure (semi-sensible) entre une relation temporelle et un

SGBD, il existe deux plans de requête :

P1 Une jointure relationnelle usuelle (par exemple, jointure hachée) est appliquée

entre la relation temporelle et un nœuddbsourceconfiguré en modenotify.

P2 Undbjoinconfiguré avec la bonne requêteSQLest appliqué sur la relation

tem-porelle.

En effet, si les relations de la base de données ne sont pas mises à jours, alors il

devient raisonnable de dire que la création d’une vue matérialisée en mémoire du

ré-sultat intermédiaire peut améliorer les performances avec le planP1. Cette vue devient

un cache local. L’opérateur de jointure peut créer des accès plus optimisés comme des

tables de hachages pour minimiser son coût. Toutefois, le coût de construction de cette

vue est non négligeable, cardbjoinexécute une requête sur le SGBD ce qui peut prendre

beaucoup de temps.

A contrario, si nous appliquons undbjoinavec le planP2, la sélection des n-uplets

fait que la taille du résultat est minimisée comparé au plan P1. Les résultats

inter-médiaires peuvent être optimisés par le SGBD. Toutefois, cette requête est exécutée

pour chaque n-uplet ce qui peut avoir un coût important. Même avec des stratégies de

cache évoluées du côté du SGBD, il est possible d’avoir un état de la relation entrante

différent pour chaque requête ce qui le rend difficile d’exploiter des caches.

Notre analyse empirique nous indique que la fréquence des mises à jour est

déter-minante pour privilégier P1 (basse fréquence) ou P2 (haute fréquence). Ce point est

validé et affiné par les expérimentations que nous menons dans la section9.3.

7.4 Conclusion

Dans ce chapitre, nous avons présenté l’intégration d’un support persistant

rela-tionnel. Dans le cadre de l’observation de système, nous exploitons le support

persis-tant pour la gestion du catalogue du système ainsi que les historiques de flux.

L’ana-lyse des quatre dynamiques de données a mis en avant une méthode pour concevoir

le schéma physique de la base de données. Astral permet d’unifier les deux mondes

pourtant régis par des dynamiques, des modes d’interrogation et des concepts

diffé-rents. Ainsi, cette solution gère l’hétérogénéité en terme d’évolution des données que

nous nous sommes fixés lors de cette thèse.

La mise en œuvre de l’intégration du support persistant s’appuie fortement sur les

connaissances dont nous disposons avec Astral en terme de modélisation des sources

de données. Nous avons conçu plusieurs composants capables de refléter différentes

sémantiques pour les modes de collecte de données, comme en terme de persistance

de celles-ci. La flexibilité du moteur de règles développé dans Astronef a permis de

mettre en œuvre des optimisations non triviales du plan de requête.

Toutefois, notre approche est améliorable. En effet, dans le cadre de la persistance

des données du catalogue, des composants spécifiques doivent être mis en place.

L’ab-sence de gestion déclarative pour ce point rend cette tâche délicate.

Nous nous sommes basés sur des heuristiques et sur l’application itérative de

règles pour résoudre l’optimisation du plan de requête. Une généralisation de

l’ap-proche pourrait optimiser des plans plus complexes, notamment dus à l’ordre des

jointures. Par exemple, si nous souhaitons optimiser (R

1

1 R

2

) 1 R

3

avec R

2

et R

3

issus d’un même SGBD. Même en sachant qu’en Astral la jointure soit associative, il

est difficile de spécifier une règle permettantR

₁

1 (R

2

1 R

3

)avecR

2

1 R

3

poussé au

niveau SGBD. Le domaine des SGBD a rencontré le même problème ce qui a permis

l’introduction de la programmation dynamique dans l’optimisation de requêtes. Nous

pourrions améliorer nos performances en utilisant un tel procédé.

Nous avons désormais un système de gestion de données persistantes et temps

réel. Nous validons notre approche en déployant ce système pour l’observation du

réseau domestique.

Table des règles Astronef

143

1 Sucres syntaxiques . . . 119

2 Inférences des types . . . 120

3 Inférences des attributs . . . 120

4 Optimisation des projections . . . 122

5 Optimisation des sélections. . . 122

6 Optimisations logiques annexes . . . 123

7 Regroupement de macroblocs . . . 124

8 Déclaration d’opérateurs de n-uplets . . . 125

9 Sélection d’implémentations . . . 127

10 Modification de la requête de dbsource . . . 139

11 Modification du mode de dbsource . . . 140

Partie IV

Expérimentations

Nous avons désormais un langage capable d’interroger tout type de données et

nous avons aussi un intergiciel capable d’exécuter ces requêtes. Nous allons

mainte-nant mettre en pratique ces idées. Tout d’abord, nous consacrons un chapitre à

l’ob-servation du réseau domestique. Puis, afin d’évaluer les performances de notre

inter-giciel, nous présentons une évaluation des performances dans un second chapitre.

« What is this place

Filled with so many wonders? Casting its spell

That I am now under »

Fluttershy, So Many Wonders

8

DomVision : Application au réseau local

domestique

8.1 Adaptation au système observé . . . . 147

8.2 Expressivité du système d’observation . . . . 151

8.3 Conclusion . . . . 155

Nous avons présenté dans le chapitre d’introduction le domaine d’application

pri-vilégié sur lequel cette thèse s’appuie. Ce chapitre permet de mettre en pratique notre

solution d’observation. DomVision est l’instanciation d’Astronef-Asteroid sur le

ré-seau local domestique. Ainsi, nous mettons en œuvre un système d’observation par

l’écriture de quelques composants et de plusieurs requêtes.

Dans ce chapitre, nous présentons les différents points de mise en application qui

nous permettent de valider notre contribution en tant que système d’observation. En

premier lieu, dans la section 8.1, nous présentons l’adaptation au système observé.

Ensuite, en section8.2, nous détaillons les requêtes déployées qui tirent profit de

l’ex-pressivité d’Astral.

8.1 Adaptation au système observé

Dans cette section, nous analysons le système observé au sens où nous l’avons

dé-crit jusqu’ici dans Astronef et Asteroid. Nous devons modéliser le système observé

pour en extraire son schéma qui permet de représenter le catalogue dans la base

d’As-teroid. Puis nous nous intéressons aux données temps-réel. Enfin, nous présentons les

flux à notre disposition dans ce réseau.

Dans le document Gestion de flux de données pour l'observation de systèmes (Page 141-149)