Calcul des estimations

Nous présentons dans cette section notre démarche pour déterminer les estimations nécessaires à la prise en compte des contraintes de temps réel. Plus précisément, nous apportons des éléments de réponse à la question suivante : quelles sont les estimations nécessaires et comment les obtenir ?

Pour qu’une requête respecte son échéance, il faut que son temps de réponse (TR) soit inférieur au délai précisé (D). Le temps de réponse est la durée séparant l’instant d’envoi de la

requête et la réception de tous les résultats. Rappelons qu’on le calcule en faisant la somme du temps d’envoi de la requête (Tqs), l’intervalle de temps entre l’instant de réception de la requête par le serveur et l’instant de début de transfert (Tserv), ainsi que le temps de transfert des résultats (Ttr).

TR= Tqs + Tserv + Ttr.

Tserv inclut le temps entre la réception de la requête et le début de son traitement par le

SGBD (TpreTrait) (e.g. temps de transformation de la requête), le temps de traitement de la requête par le SGBD (TtraiBD) (i.e. le temps écoulé entre la soumission de la requête au SGBD sous-jacent et celui de la réception de tous les résultats) et le temps de vérification des validités spatiale et temporelle des résultats (TpostTrait).

Tserv = TpreTrait + TtraitBD + TpostTrait

En principe, les temps les plus prédominants sont : le temps de traitement de la requête par le SGBD et le temps de transfert des résultats. Effectivement, lors du traitement d’une requête par le SGBD, de grands volumes de données sont manipulés et plusieurs accès disque peuvent être nécessaires. De même, le transfert des résultats peut être important, surtout pour des réseaux à faibles débits et fortes latences comme les réseaux sans fil. Ainsi, nous effectuons le premier test d’admission et l’ordonnancement juste avant la soumission des requêtes au SGBD. Par conséquent, il est nécessaire de calculer une estimation du temps de traitement par le SGBD (ETtraitBD) et une estimation du temps de transfert des résultats (ETtr). Pour simplifier nos explications, nous supposons que les temps de vérifications sont négligeables. Dans l’architecture proposée, nous avons dédié le module Estimations des coûts à cette finalité. Rappelons que ce module prend comme entrée une requête Q et s’appuie sur l’évaluateur de coûts du SGBD et sur le module Estimation du temps de transfert, pour obtenir les estimations

ETtraitBD, ETtr.

3.1.1. Estimation des temps de traitement de la requête par le SGBD sous-jacent

Pour estimer avec précision le temps de traitement d’une requête par le SGBD, les valeurs de plusieurs paramètres doivent être connues, parmi lesquelles les caractéristiques du système (e.g. temps pour effectuer une opération simple par le processeur CPU, temps pour lire ou écrire une page disque E/S), les caractéristiques des données manipulées (e.g. taille des relations, nombre et types d’attributs impliqués), l’ordre d’exécution des opérations d’une requête et les détails des algorithmes implémentant ces opérations (e.g. jointure par hachage simple ou hybride, jointure par tri-fusion, algorithme de recherche des plus proches voisins du type « meilleur d’abord » ou « par séparation et évaluation »). Tous ces facteurs ont une influence sur le temps de traitement d’une requête. Rappelons que pour une requête donnée, plusieurs plans d’exécution ayant des coûts radicalement différents peuvent être envisagés [DKS 92]. En principe, l’optimiseur du SGBD choisit celui qui a le moindre coût (e.g. celui qui minimise le temps de réponse). Le coût de chaque plan est calculé grâce à un évaluateur de coûts. En fait, l’évaluateur de coûts est constitué de statistiques sur les données et sur le système et de formules de coûts. Afin d’estimer le coût d’un plan, l’évaluateur de coûts utilise les statistiques sur les données manipulées et les formules de coûts associées à chaque opération. Dans la littérature, plusieurs travaux décrivent des évaluateurs de coûts permettant d’estimer les coûts des requêtes [DSK 92, GST 96, Naa 99, ZMS 03]. Certains travaux se sont particulièrement concentrés sur les évaluateurs de coûts pour des requêtes spatiales de zone ou

de recherche des plus proches voisins [TS 96, PM 96, TSS 00]. Nous n’allons pas détailler ici ces formules de coûts. Nous retenons néanmoins qu’à l’issue de l’étape d’optimisation, un plan d’exécution optimisé annoté par ses coûts est déterminé. Il est à notre avis judicieux de s’appuyer sur les estimations calculées par l’évaluateur de coûts du SGBD lors des prises de décisions effectuées par les tests d’admission. Pour obtenir ces estimations, nous proposons d’invoquer au niveau du sous-module Estimations des coûts une procédure appelée

Estimate_Query_Cost(Q,ETtratBD,EDs). Cette procédure accepte comme paramètre d’entrée une

requête Q et renvoie une estimation du temps de traitement par le SGBD associé à Q ainsi qu’une estimation du nombre EDs de tuples résultats. C’est en s’appuyant sur l’évaluateur de coûts du SGBD sous-jacent que les valeurs de ces estimations sont déduites.

3.1.2. Estimation du temps de transfert

Les difficultés posées par l’estimation du temps de transfert des résultats sont liées à la mobilité des clients et à la dynamique du réseau. En effet, la localisation du client à l’envoi de la requête et à la réception des résultats n’est pas forcément la même. Or, les paramètres réseaux peuvent changer d’un endroit à un autre (e.g. délais, bande passante). D’un autre côté, les réseaux sans fil se caractérisent par une grande instabilité avec un taux élevé de pertes de paquets et une grande variabilité de la bande passante et des délais [GUR 04]. Pourtant, dans notre cas, des garanties sur les valeurs des paramètres réseaux sont nécessaires afin d’obtenir des estimations réalistes du temps de transfert des résultats. Dans ce contexte, beaucoup d’efforts ont été déployés visant à fournir des prédictions sur l’état futur des ressources du réseau [LAN 97, CB 99, OKS 98, SND 05]. Ces travaux exploitent les informations sur le mouvement des clients mobiles et sur l’état du réseau afin de garantir la qualité de service exigée par les applications. Dans les réseaux cellulaires (e.g. GSM), des mécanismes de contrôle d’admission permettant d’allouer la bande passante dans la cellule où est situé l’utilisateur et de réserver la bande passante dans toutes les cellules voisines, ont été proposés dans [CB 99, OKS 98]. Nous ne détaillons pas ces techniques qui relèvent du domaine des télécommunications alors que nous nous intéressons plutôt au traitement des requêtes mobiles avec des contraintes de temps réel. Dans ce travail, nous supposons que les opérateurs réseaux offrent à leurs clients des garanties sur les bandes passantes et les délais des réseaux sous- jacents.

Dans notre architecture, c’est le sous-module Estimation du temps de transfert qui estime le temps de transfert des résultats (ETtr) en prenant comme entrée l’estimation EDs du volume des résultats calculée par l’évaluateur de coûts. Nous supposons que ce module dispose des connaissances sur les valeurs des paramètres réseaux permettant de calculer le temps de transfert (e.g. débit, latence). Précisons, en outre, que dans le cas des requêtes retournant des résultats partiels, c’est seulement une estimation du temps de transfert d’une partie des résultats qui est déterminée (i.e. une estimation du temps de transfert du nombre minimum de tuples résultats attendus). En effet, le test d’admission doit tenir compte du fait que le client peut accepter un résultat incomplet.