Jointure sur un agrégat historique

Dans cette seconde expérimentation, nous exécutons la requête HistAvgCPU vu

dans la section 8.2.3. Pour rappel, cette requête joint une relation temporelle avec un

agrégat effectué sur historique. Voici les paramètres de notre expérience :

– L’historique est mis à jour dès que possible par un processus extérieur (une

re-quête dans Astronef par exemple).

– Il existeDidentifiants d’équipement etMvaleurs historiques par identifiants.

– Il y a un index surHistCPU(monitorableId).

La requêteSQLgénérée et donnée en paramètre àdbjoinetdbsourceest la suivante :

1 SELECT monitorableId, AVG(cpu) as avg FROM HistCPU GROUP BY monitorableId

(a) Performance globale (b) Performance de l’agrégat avec sélection sur identifiant

F

IGURE

9.4 – Performance de la jointure avec agrégat en utilisant la sélection ou non

Résultats: Dans cette expérience, nous avons pu remarquer que les performances

de la requêteSQL dedbsourcene dépend que de la taille de l’historique (M.D).

Tou-tefois, ce n’est pas le cas pour un agrégat utilisant une sélection sur l’identifiant avec

dbjoin, qui ne dépend principalement que de M. La figure 9.4(a) représente

l’évolu-tion de la latence de la requête d’agrégat avec et sans la jointure faite pardbjoin

²

. La

figure9.4(b) représente l’évolution de la latence en variant Mpour l’agrégat avec

sé-lection.

La performance dépend des caractéristiques de l’historique. Plus nous avons un M

petit, plus nous avons une petite latence pour le planP2. La latence deP2est bornée

entre les deux courbes de la figure9.4(a)comme le cas M=10 représente le minimum

de latence etD =1 (équivalent à aucune sélection) est le pire cas. Le choix du plan est

clairement en faveur du plan P2 car son pire cas a des performances similaires à P1.

Dans l’expérience précédente, nous avions supposé pouvoir absorber le coût de mise

à jour. Ce n’est pas le cas ici, car l’historique est régulièrement mis à jour.

2. La perte de performance massive observée après 4Mn-uplets est due aubufferingqui ne peut être fait en mémoire et le disque est utilisé. Ce fait a été confirmé par les développeurs d’H2.

Stratégies alternatives

Si le résultat de la requête peut être dégradé, il est possible d’utiliser dbsource en

mode périodique. Dans ce cas, nous pouvons évaluer la condition limite pour passer

d’un plan à l’autre en regardant les coûts mesurés dans la figure9.4.

Nous pouvons toutefois trouver une autre réécriture fournissant un

résul-tat exact. Lorsque la requête est déployée, il y a une distinction entre le passé

(CPU MemHistory

^t0

) et le futur représenté par le flux CPU Mem. En supposant que

l’agrégat est séparable par les moyens décrits dans la section 3.4.2, alors nous

pou-vons séparer les calculs sur le passé et le futur. L’agrégat passé est un calcul instantané

effectué par dbsource est modeone-shot. L’agrégat futur est calculé par les opérateurs

id

G

_...

et [∞]. Or, ces opérateurs peuvent être regroupés en un seul macrobloc capable

de calculer l’agrégat avec un coût mémoire borné.

9.4 Conclusion

La performance est un élément clé pour la gestion des flux de données. En effet,

gérer des données temps réel implique les traiter le plus rapidement possible pour ne

pas risquer des blocages. Nous avons vu dans ce chapitre que notre approche nous

permet de générer des plans de requêtes efficaces autant pour la gestion de flux de

données que pour la jointure avec un SGBD.

Nous avons tout de même perçu la limite de notre approche. En effet, nous avons

opté pour un système de règle. Cela nous permet d’avoir des résultats rapides et une

intégration très efficace. Toutefois, pour la spécification de l’algorithmePane

(macro-bloc fenêtre-agrégat) par exemple, nous avons dû prévoir le cas où une projection se

serait glissée entre la fenêtre et l’agrégat lors de l’optimisation logique. Ce cas-là n’est

pas grave, car la sémantique reste identique avec ou sans. Mais dans le cas d’une

sé-lection, ou éventuellement un autre opérateur, nous ne pouvons peut-être plus former

notre macrobloc, nous privant d’un gain certain de performance.

Nous avons présenté nos contributions et validé leurs résultats. Nous avons ainsi

un système d’observation efficace capable d’interroger tout type de données. Le

cha-pitre suivant présente une extension de ces travaux pour personnaliser les résultats en

fonction de l’utilisateur.

Partie V

Personnalisation des

résultats

Notre approche permet d’observer un système hétérogène et dynamique. Nous

avons montré que notre intergiciel est adaptable aux différentes situations. Lors de

nos expérimentations, il nous a paru intéressant de pouvoir adapter aussi les données

en fonction des utilisateurs. Ce prochain chapitre présente une extension de notre

in-tergiciel pour effectuer une telle personnalisation des données.

« The shape’s fine, just make the whole thing... you know, cooler.

It needs to be about 20% cooler. »

Rainbow Dash

10

Gestion des préférences utilisateurs

10.1 Modélisation algébrique . . . . 169

10.2 Mise en œuvre . . . . 173

10.3 Intégration et Expérimentations . . . . 174

10.4 Conclusion . . . . 177

Grâce à la popularisation des technologies et des capacités de traitement de

don-nées, les systèmes sont de plus en plus complexes et fournissent de plus en plus de

données. Le spectre des utilisateurs étant plus large, il est important de pouvoir

adap-ter la masse d’informations récoltée à chaque personne. De nombreux efforts ont été

consacrés ces dernières années à la personnalisation des réponses lors de l’accès aux

bases de données. Dans ce chapitre, nous explorons une extension à notre approche

pour ajouter des opérateurs adaptant les résultats d’interrogations aux préférences

utilisateurs. Ainsi, l’utilisateur n’obtient que les données qui l’intéressent.

Dans la section10.1, nous détaillons les fondements théoriques à la gestion de

pré-férences contextuelles. Une fois les opérateurs décrits dans l’algèbre Astral, nous

pou-vons présenter les algorithmes utilisés pour les mettre en œuvre dans la section10.2.

Enfin, dans la section10.3nous présentons l’intégration faite dans Astronef pour que

l’utilisateur puisse personnaliser ses résultats d’interrogation. Cette intégration est

accompagnée d’une évaluation de performances pour sélectionner le meilleur

algo-rithme de calcul.

10.1 Modélisation algébrique

Dans cette section, nous introduisons dans le cadre d’Astral-Astronef les

opéra-teurs de CPref-SQL [de Amo 2009]. Tout d’abord, nous présentons les notions

riques nécessaires pour appréhender les préférences contextuelles. Puis, nous

présen-tons les deux opérateurs permettant de sélectionner les n-uplets préférés sur une

rela-tion temporelle. Ensuite, nous utilisons ceci à notre cadre applicatif. Enfin, nous

pré-sentons, comment l’intégration dans Astronef est réalisée.

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