Persistance des résumés

L’interrogation a posteriori des résumés nécessite leur conservation sur disque. Le choix de l’approche adoptée pour le stockage du résumé doit tenir compte des coûts d’E/S sur disque. Nous détaillons dans ce qui suit les avantages et inconvénients de deux systèmes pouvant gérer la persistance des données : système de fichiers et système de gestion de base de données.

Système de fichiers. Dans cette modélisation, chaque échantillon est représenté par un

fichier contenant les différents événements du flux. Pour accélérer l’opération de recherche des échantillons les plus anciens d’un ordre, chaque fichier est nommé selon la date de début de constitution de l’échantillon. Chaque dossier représente un ordre et contient ainsi

L fichiers. Lors d’une opération de ré-échantillonnage, on peut facilement accéder au dos-

sier de l’ordre concerné. Cependant, pour extraire les échantillons les plus anciens d’un ordre, il faut trier tous les fichiers du dossier selon leur nom. Suite à cette opération, on extrait aléatoirement T/2 événements de chaque fichier. Les évènements extraits sont ainsi enregistrés dans un nouveau fichier et les deux anciens fichiers sont supprimés.

Système de gestion de base de données. Une deuxième approche permet de conser-

ver le résumé dans une base de données. Les événements du flux sont insérés dans des relations indexées afin de faciliter leur accès. Les échantillons sont triés en fonction de

leur date de début de constitution. Nous proposons dans ce qui suit un schéma relationnel possible.

Le schéma relationnel. La modélisation proposée permet de distinguer le flux de

départ, le résumé conçu et, les paramètres utilisés pour la conception du résumé. Le schéma relationnel, illustré dans la Figure 4.6 a été conçu de façon à prendre en considération le traitement de plusieurs flux. Pour représenter cela, une relation "Flux" permet de conserver les informations relatives aux flux en entrée telles que son identifiant et son nom. A chacun des flux traités par StreamSamp correspond un enregistrement dans cette relation. La relation "Paramètres" contient les différents paramètres utilisés par l’algorithme pour résumer les flux à savoir le taux d’échantillonnage (α), la taille des échantillons (T ) et le nombre d’échantillons par ordre (L). Le résumé constitué pour un flux donné en fonction d’un lot de paramètres est accessible à travers la relation "Résumé".

La relation "Échantillon" maintient les informations relatives aux échantillons conservés par l’algorithme. Chaque échantillon est caractérisé par son identifiant, son poids (2Ordre₎

ainsi que sa date début et fin de constitution qui représentent les dates de la période échantillonnée. Chaque échantillon contient un ensemble d’évènements mémorisés dans la relation "Évènement". Cette relation comporte l’identifiant de l’échantillon ainsi que les valeurs de ses attributs.

EvènementID Attribut1 Attributn EchantillonID Evènement EchantillonID RésuméID TempsDébut TempsFin Poids Echantillon RésuméID FluxID ParamID Résumé FluxID Nom Flux ParamID α T L Paramètres

Figure 4.6 – Modèle relationnel du résumé conçu par StreamSamp.

Les avantages de cette représentation sont doubles : le premier consiste à permettre de séparer l’univers des flux de données de celui des résumés conçus et, le second consiste à permettre le résumé de plusieurs flux. Un même flux peut participer à l’élaboration de différents résumés ; différents résumés peuvent avoir les mêmes paramètres, etc.

Indexation des données. Un index est un élément de redondance que l’on va spéci-

fier pour permettre au système de gestion de base de données (SGBD) d’optimiser certaines requêtes. Il est placé sur une relation, il permet un accès très rapide aux enregistrements, selon la valeur d’un ou plusieurs champs. Les index jouent un rôle discret mais important dans la gestion des bases de données. La décision de créer un index résulte de l’examen des avantages et inconvénients de cette opération. L’index ralentit les mises à jour et consomme un peu de place, mais il rend les tris et les recherches d’information plus rapides.

L’algorithme StreamSamp est basé sur un échantillonnage récursif. L’opération de ré- échantillonnage s’effectue entre les échantillons les plus anciens d’un même ordre. Ainsi, avant toute opération de fusion, les échantillons d’un même ordre doivent être ordonnés de façon à extraire les deux plus anciens échantillons. Pour ce faire, nous appliquons des index à la table "Résumé" afin d’assurer un accès direct aux échantillons. Deux possibilités d’indexation s’offrent à nous : (i) assurer que l’attribut "EchantillonID" soit incrémental, (ii) créer un index sur l’attribut "TempsDebut".

Dans le premier cas de figure, il suffit de conserver un identifiant incrémental pour les échantillons de façon à ce que chaque nouvelle entrée prend l’identifiant qui suit. L’utili- sation d’un index groupant (appellé aussi cluster index) sur l’ensemble des attributs ("Ré- suméID, Poids"), permet d’extraire tous les échantillons d’un ordre donné et les deux plus anciens échantillons de l’ordre sont par la suite extraits en utilisant l’attribut "Echantillo- nID". L’utilisation des index groupants permet de spécifier que l’index créé correspond à un arrangement physique particulier où les enregistrements voisins sont stockés dans des blocs voisins.

Dans la deuxième approche, un index groupant sur l’attribut ("RésuméID, TempsDe- but") permet d’extraire les deux plus anciens échantillons. Le résultat du ré-échantillonnage prendra par la suite la place de l’un des échantillons à supprimer de façon à conserver un ordre croissant dans les estampilles temporelles. Par ailleurs, afin d’accéder rapidement et extraire tous les évènements d’un même échantillon, on place un index groupant sur l’attri- but "EchantillonID" de la relation "Évènement". Dans l’implantation de StreamSamp, nous avons opté pour cette approche étant donné qu’elle nous permet d’accéder rapidement aux échantillons les plus anciens d’un ordre.

Avantages et inconvénients. Nous discutons dans ce paragraphe les avantages et in-

convénients des deux modélisations présentées précédemment.

– Utilisation générale : l’avantage d’une modélisation orientée système de fichiers est qu’elle est simple et facile à utiliser. De plus elle ne nécessite pas de pré-requis logiciels. Tandis qu’une solution orientée base de données, nécessite la mise en place d’un SGBD, création des index, etc.

– Identification des plus anciens échantillons d’un ordre : dans un système de fichiers, une opération de tri des fichiers est réalisée avant chaque fusion afin de localiser les deux échantillons les plus anciens. Cependant, en utilisant un SGBD, les

n-uplets représentant les échantillons sont déjà triés en fonction de la date de début des échantillons, ce qui facilite l’accès aux données des échantillons concernés. – Gestion de données : les SGBD sont connus pour leur capacité à gérer les données,

gérer les accès concurrents, etc. Ceci présente un avantage majeur lorsque le résumé doit être exploité par plusieurs entités (programmes, utilisateurs, etc).

– Exploitation du résumé : contrairement aux SGBD, les systèmes de fichiers n’ont pas de langage d’interrogation puissant tel que SQL. Ceci va nécessiter beaucoup plus d’effort dans l’implantation tels que le développement de méthodes pour parcourir les échantillons, accéder aux attributs, etc.

L’utilisation d’un SGBD offre plus d’avantages dans la construction et l’exploitation des résumés qu’un système de fichiers (e.g. indexation des données dans la base, optimisation des requêtes, etc). Plusieurs schémas relationnels peuvent être envisagés afin de modéli- ser le résumé de StreamSamp. Nous avons adopté un schéma permettant de séparer les informations sur les différents flux en entrée et les informations sur les résumés.