2.3 Approche e-commerce
C'est une approche pour l'optimisation des requêtes
distribuées [3], inspirée du e-commerce, elle considère
les requêtes et leurs réponses comme des marchandises, les pairs
voulant exécuter des requêtes comme des acheteurs, et ceux qui en
répondent comme des vendeurs.
La marchandise (la réponse) a un prix (coût), ce
dernier prend en compte plusieurs facteurs, à savoir, la fraîcheur
ou la complétude des données, le temps total d'exécution,
ou bien le nombre d'octet de la réponse.... Le prix de la marchandise
varie au cours du temps en fonction de l'offre / demande. Si une marchandise
est trop demandée, son coût augmente, et l'inverse est vrai.
Dans un tel environnement, trouver la réponse d'une
requête nécessite parfois que la requête soit
éclatée en plusieurs sous parties, récupérer les
sous réponses des pairs distants (vendeurs), avec le prix le moins cher,
et les fusionner pour construire la réponse à la requête
initiale.
Pour mieux comprendre cette approche, prenons un exemple d'une
société de télécommunication, qui dispose de
plusieurs bureaux en France. Chacun des ces bureau possède un SGBD
local. Le schéma de la base comprend la relation CLIENT (IDClient,
NomClient, Bureau) qui stocke les informations du client comme son nom, son
identifiant ..., ainsi qu'une autre relation FACTURE (FID, NuméroTel,
IDClient, Montant) détenant l'historique des communications du
client.
Supposant que le manager du bureau de paris, demande le
montant total des factures émises par les bureaux de Lyon et
Metz :
SELECT SUM(Montant) FROM FACTURE F, CLIENT C
WHERE F.IDClient=C.IDClient AND Bureau in (`Lyon',`Metz');
Le bureau de paris va interroger tous les bureaux qu'ils aient
ou non la réponse à la (sous partie) requête. Supposant
que, entre autre, les bureaux Lyon et Metz ont répondu positivement aux
parties de la requête concernant leurs propres clients avec un prix
à 30 et 40 secondes respectivement.
Supposant aussi que les offres de Metz et Lyon soient les
meilleures, et que le prix ici représente le temps d'exécution de
la (sous partie) requête.
Le bureau de paris va comparer ces offres, et il va constater
que la meilleure offre est celle faite par les bureaux Lyonnais et Messins.
On dit ici que le pair parisien (acheteur) a acheté les
réponses (marchandises) des pairs (vendeurs) lyonnais et Messins
à un prix de 30 et 40 secondes respectivement, mais ensuite, il peut
négocier le prix. La négociation sera exposée par la
suite.
2.3.1 Query Trading ou Commerce de requêtes (QT)
Dans QT, la procédure d'optimisation des requêtes
est considérée comme un commerce des réponses entre les
pairs vendeurs, possédant les données relevantes aux
requêtes. Les pairs acheteurs sont les pairs qui ne peuvent pas
répondre à certaines requêtes, soit parce qu'ils manquent
de ressources (CPU, mémoire...), ou bien ils n'ont pas les
données relevantes à la requête localement.
Chaque pair peut jouer le rôle d'acheteur ou de vendeur,
ça dépend de la requête qu'on veut optimiser et des
données que chaque pair détient localement.
Le pair acheteur demande des services aux pairs vendeurs, pour
le calcul de la réponse à la requête, et les pairs vendeurs
répondent en faisant des offres qui contiennent l'estimation du
coût de la réponse à la requête. Cette estimation
pourra être le temps requis pour l'exécution et la transmission
des résultats au pair acheteur, le temps nécessaire pour trouver
la première ligne du résultat, le temps moyen pour
récupérer les lignes du résultat, le nombre total des
lignes du résultat, la fraicheur ou la complétude du
résultat.
L'acheteur classe les offres reçues, et choisit celles
qui minimisent le prix (coût) relatif à la requête.
| 
