FR2718870A1

FR2718870A1 - Dispositif et procédé de calibration des modèles de coût.

Info

Publication number: FR2718870A1
Application number: FR9404330A
Authority: FR
Inventors: Andres Frederic; Kwakkel Fred; Kerssten Martin
Original assignee: Bull SA
Current assignee: Bull SA
Priority date: 1994-04-13
Filing date: 1994-04-13
Publication date: 1995-10-20
Anticipated expiration: 2014-04-13
Also published as: FR2718870B1

Abstract

Les systèmes de gestion de base de données relationnels (SGBDR) modernes font appel à des optimiseurs de requêtes. Ceux-ci sont chargés d'établir un plan d'exécution efficace des opérations successives nécessaires pour accomplir la requête. Pour cela, ils font appel à des modèles de coût afin d'explorer les divers plans d'exécution possibles et leurs coûs associés. La précision des modèles de coût est un facteur déterminant pour les performances de la base de donnée. Un des problèmes des modèles de coût est leur dépendance vis-à-vis de l'environnement matériel. Cela signifie que lorsque le SGBDR est transporté sur une autre plate-forme matérielle, il faut recalibrer les modèles de coût. La demande concerne un moyen d'effectuer cette recalibration de manière automatique grâce à des expériences générées et exécutées sans l'aide de l'opérateur. Grâce au programme expérimentateur (test pilot), des expériences pouvant infirmer ou confirmer rapidement des hypothèses sur les modèles de coût sont générées automatiquement. La forme analytique des modèles de coût dans le nouvel environnement est obtenue d'après les résultats des expériences.

Description

DISPOSITIF ET PROCEDE DE CALIBRATION DES MODELES DE COUT
La présente invention concerne un procédé et dispositif de calibration des modèles de coût utilisées dans un évaluateur de performances afin de les adapter de manière automatique à un système informatique particulier doté d'un système de gestion de base de données.

Les systèmes de gestion de bases de données relationnels modernes (couramment désignés par l'acronyme SGBDR) utilisent souvent des optimiseurs de requêtes afin de déduire un plan d'exécution efficace. Quand une requête est faite, le SGBDR choisit un chemin d'accès optimal pour l'exécution de la requête. Pour optimiser les performances, il est nécessaire d'analyser les requêtes émises et de décider de l'action à prendre. L'action peut être de changer la forme de la requête par exemple. Changer la forme de la requête signifie modifier le plan d'enchaînement des opérations exécutées par le serveur de bases de données pour traiter la requête. Les optimiseurs de requêtes font appel à des modèles de coût sophistiqués afin d'explorer l'espace des plans d'exécution possibles et leurs coûts associés. Les modèles de coût expriment analytiquement le coût des diverses requêtes sur le SGBDR. Le coût est généralement défini comme: coût = (consommation de ressources) + W * (temps de réponse) où W est un paramètre qui dépend du système. D'autres modèles de coût ont aussi été établi qui font encore intervenir par exemple le coût monétaire d'une requête. De manière générale, le coût d'une requête sur le SGBDR est une fonction que l'on souhaite minimiser de plusieurs résultats de la requête.

Un exemple de dispositif d'optimiseur de requêtes utilisant des modèles de coût est décrit par exemple dans le brevet W092/17843.

Le modèle de coût représente une indication nécessairement imprécise du coût réel d'une opération sur un SGBDR. Une des raisons de cette imprécision est la dépendance du modèle envers le système informatique utilisé et envers le type de domaine d'application du SGBDR. II est donc nécessaire de calibrer les modèles de coût lorsque le système de gestion de base de données est installé sur une autre plate-forme matérielle ou lorsque le domaine d'application change.

Dans l'état de l'art, cette calibration se fait de manière manuelle. L'utilisateur effectue une série de requêtes sur le SGBDR, mesure les coûts associés (par exemple les temps de réponse) et ajuste les modèles de coût en conséquence.

Cette calibration manuelle est un processus extrêmement lent et fastidieux. En effet, sur un SGBDR moderne, il y a un très grand nombre de requêtes possibles pour lesquelles il faut trouver un modèle de coût adapté en effectuant à chaque fois un grand nombre d'expériences. Entre chaque expérience, il est en outre nécessaire de modifier l'état des tables dans le SGBDR. II y a donc une très grande demande pour un système capable de calibrer les modèles de coût de manière entièrement automatique.

Un dispositif de calibration semi-automatique est proposé dans un document de
L. Mackert et G. Lohman intitulé "R+ optimizer validation and performance evaluation for local queries", ACM (Association for Computing Machinery)
SIGMOD International Conference on Management of Data, 1986, pp 84-95.

Pour diverses requêtes, le dispositif décrit dans ce document génère un ensemble d'expériences de manière automatique. Ces expériences menées systématiquement explorent à chaque fois tous les plans possibles d'exécution d'une requête sur le SGBDR, en variant la taille des tables du SGBDR ou d'autres caractéristiques du SGBDR. Par exemple, elles mesurent le coût de tous les plans d'exécution possibles d'une requête donnée sur un SGBDR avec des tailles de tables de 100 à 10000 tuples. Par conséquent, elles sont très longues à mener. L'information obtenue par de nombreuses expériences est redondante, alors que peut-être d'autres expériences avec des caractéristiques du SGBDR très différentes seraient nécessaires. II est très difficile avec la méthode de ce document de juger les effets de la variation simultanée de plusieurs paramètres du SGBDR. En outre, elles fournissent des tables du coût de diverses requêtes sur le SGBDR avec différentes configurations du SGBDR, en indiquant à chaque fois le meilleur plan d'exécution possible. En aucune façon ce document n'est concerné avec l'interprétation et la généralisation automatique de ces résultats d'expérience pour obtenir un modèle analytique de coût. Le coût de diverses requêtes est simplement reporté dans des graphes en fonction de la caractéristique variable du SGBDR (par exemple la taille de la table). Ce document ne suggère aucune méthode permettant d'interpréter automatiquement un ensemble de résultats d'expériences pour déterminer un modèle analytique de coût sans intervention humaine.

Un des buts de l'invention est de palier cet inconvénient, ce but est atteint par le fait que la méthode d'élaboration d'un modèle de coût utilisé dans un optimiseur de requête par un SGBD est caractérisée en ce que la méthode comporte une première étape de définition automatique d'un modèle de coût analytique, et une seconde étape de calibration automatique du modèle de coût, grâce à des expériences successives générées automatiquement et grâce à un nombre réduit de vérification du modèle
Selon une autre particularité, ledit modèle de coût analytique utilise des formules de coût génériques applicables à différents systèmes de base de données, et les caractéristiques d'un système spécifique sont décrites par des valeurs particulières des coefficients dans les formules de coût.

Selon une autre particularité, lesdits coefficients des formules de coût sont ajustés à l'aide des résultats des expériences successives.

Selon une autre particularité, les résultats des expériences successives comprennent au moins le temps d'exécution d'une opération sur la base de donnée.

Selon une autre particularité, les expériences successives utilisent des valeurs successives de facteurs dans les formules de coût, et ces valeurs successives sont choisies automatiquement de manière à confirmer ou à infirmer les hypothèses utilisées pour définir le modèle de coût analytique.

Selon une autre particularité, lorsque suffisamment d'expériences ont été effectuées pour obtenir un niveau de fiabilité donné au préalable à la mise en oeuvre du procédé, les coefficients des formules de coût qui correspondent le mieux aux résultats sont calculés à l'aide d'un algorithme de décomposition de valeurs singulières.

Selon une autre particularité, les expériences successives utilisent un point de répère à probabilité ("probabilistic benchmark").

Selon une autre particularité, les expériences succeLsives utilisent une base de données typique par type d'application avec un ensemble de requêtes caractéristiques par ce type d'application
Selon une autre particularité, le système de gestion de base de données est soit un système parallèle, soit un système séquentiel.

Un effet technique de l'invention est donc de rendre des SGBDR plus performants en terme de vitesse d'exécution notamment en les adaptant automatiquement à un système informatique particulier.

Pour cela, I'invention propose un dispositif utilisant un système de gestion de bases de données relationnel et comprenant un module de calibration des modèles analytiques de coût utilisés par ledit système de gestion de bases de données relationnel, ledit module de calibration effectuant un ensemble d'expériences de vérification desdits modèles analytiques de coût pour les adapter à un système informatique particulier, pour chaque modèle analytique de coût ledit ensemble d'expériences de vérification étant choisi de manière automatique dans un espace d'expériences et un modèle analytique initial de coût étant ajusté automatiquement à partir des résultats desdites expériences de vérification.

Selon une autre particularité de l'invention, ledit module de calibration des modèles analytiques de coût utilise le programme expérimentateur (test pilot) pour choisir de manière automatique ledit ensemble d'expériences et pour ajuster automatiquement ledit modèle analytique initial de coût.

Selon une autre particularité, L'espace d'expériences est transmis au module de calibration automatique par le module principal.

Selon une autre particularité, l'espace d'expériences indique au moins un facteur dans les formules de coût qui varie au cours des expériences successives.

Selon une autre particularité, au moins une partie des facteurs dans les formules de coût variant au cours des expériences successives caractérisent l'état d'une ou des tables du système de gestion de bases de données sur lesquelles ont lieu les expériences.

Selon une autre particularité, au moins un des facteurs dans les formules de coût qui varient au cours des expériences successives est proportionnel au nombre de tuples dans les tables sur lesquelles ont lieu les expériences.

Selon une autre particularité, L'espace d'expériences comporte en outre un taux de confiance à obtenir pour les formules de coût ajustées.

Selon une autre particularité, L'espace d'expériences comporte en outre l'intervalle de valeurs que peuvent prendre les facteurs dans les formules de coût au cours des expériences successives.

Selon une autre particularité, le module de calibration automatique effectue des mesures pour calibrer les modèles de coût à l'aide d'un étalon d'évaluation de performances composé de tables et d'un ensemble de requêtes associées.

Selon une autre particularité, les tables et l'ensemble de requêtes associées utilisés dans l'étalon d'évaluation de performances sont caractéristiques pour une application du monde réel.

Selon une autre particularité, L'étalon d'évaluation de performances est de type probabilistique.

Selon une autre particularité, le module de calibration automatique choisit des points de mesure successifs au cours des expériences, correspondants à des valeurs successives des facteurs dans les formules de coût, qui ont une haute probabilité de confirmer ou d'infirmer les hypothèses sur les formules utilisées par le modèle analytique de coût.

Selon une autre particularité, le dit modèle de coût utilise des formules de coût dont les coefficients propres à un système particulier sont ajustés par le module de calibration automatique au cours des expériences successives.

Selon une autre particularité, le dit modèle de coût utilise des formules de coût dont la forme générale analytique est déterminée par le module de calibration automatique au cours des expériences successives.

Selon une autre particularité, les coefficients des formules de coût et/ou l'allure générale analytique des formules de coût sont déterminés par le module de calibration automatique de manière à ce que l'erreur relative entre les prévisions du modèle de coût et les résultats des expériences successives n'excèdent pas un seuil déterminé correspondant au taux de confiance de l'espace d'expérience.

Selon une autre particularité, si un simple ajustement des coefficients des formules de coût ne permet pas d'obtenir une erreur relative en-dessous du seuil déterminé, alors la forme générale analytique des formules de coût est modifiée et les coefficients correspondants sont ajustés par le module de calibration automatique, et cela jusqu'à ce qu'une forme générale analytique et des coefficients ajustés correspondants soient trouvés qui permettent d'obtenir une erreur relative en-dessous du seuil déterminé.

Selon une autre particularité, la succession du ou des facteurs dans les formules de coût au cours des expériences est déterminée par le module de calibration automatique de manière à minimiser le temps nécessaire à la succession des expériences, en choisissant un ordre de succession qui réduise les modifications à apporter aux tables pour chaque expérience.

Selon une autre particularité, les résultats des expériences comprennent au moins le temps d'exécution d'une des requêtes de l'évaluateur de performances par le système informatique auquel on veut ajuster le modèle de coût.

Selon une autre particularité, le module principal et le module de calibration automatique communiquent au cours des expériences par l'intermédiaire d'un objet -les valeurs des facteurs pour mener l'expérience -le résultat de l'expérience -le type de requête à tester pour cette expérience.

D'autres caractéristiques et avantages de la présente invention ressortiront de la description qui suit, donnée à titre d'exemple et illustrée dans les figures annexées.

La figure 1 est un schéma-bloc simplifié de l'invention montrant les divers composants et leurs relations.

La figure 2 représente le format des données définissant l'espace d'expériences du module de calibration automatique.

La figure 3 représente le format des données d'hypothèses transmises au module de calibration automatique.

La figure 4 représente le format des données d'actions effectuées par le module de calibration automatique.

A titre de rappel pour le lecteur que l'on supposera familier avec les systèmes de gestion de bases de données, précisons tout d'abord quelques termes utilisés tout au long de la description.

Une base de données relationnelle se présente comme un ensemble de relations, aussi appelées tables. Une table est identifiée par un nom et correspond à un ensemble de valeurs à deux dimensions (tuple, attribut). La notion de base de données proprement dite n'existe pas dans les SGBDR. La traditionnelle notion d'enregistrement est remplacée par celle de tuple.

Dans les SGBDR modernes, I'optimiseur de requêtes est fondamental pour obtenir des performances élevées. Son rôle est de déduire un plan d'exécution des opérations sur le SGBDR efficace. Ce plan spécifie par exemple l'ordre optimal des opérations pour effectuer la requête. Pour choisir le plan à exécuter pour une requête, I'optimiseur de requêtes a besoin d'évaluer plusieurs possibilités de plan d'exécution à l'aide d'un programme d'évaluation des performances, ci-après définies comme des coûts. L'évaluation des coûts est basée sur un modèle de coût qui prend en compte les spécificités du calculateur et du type de données utilisées pour estimer le coût d'une requête.

Un problème des modèles de coût est la dépendance vis-à-vis du type de données utilisée. Les modèles de coût sont souvent établis à partir de tables et d'un ensemble de requêtes caractéristiques pour un exemple de la vie réelle dans un domaine d'application. Lorsque le domaine d'application change, c'est-à-dire lorsque les tables contiennent un type de données différent ou lorsque ses caractéristiques statistiques changent, il faut recalibrer les modèles de coût si l'on veut assurer des performances optimales. Cette opération est, comme mentionné, extrêmement lente et fastidieuse. Ce mode de faire convient toutefois lorsque les caractéristiques statistiques des données varient peu.

C. Turbyfill et al, dans "AS3AP- An ANSI Sequel Standard Scalable and Portable
Benchmark for Relational Database Systems", (publié en septembre 1989 par DB
Software Corporation, 220 California Avenue, Suite 201, Palo Alto, CA94306,
USA), proposent un étalon d'évaluation de performances (benchmark) probabilistique appelé AS3AP composé de diverses tables et d'un ensemble de requêtes associé, représentatif pour un vaste spectre de domaines d'utilisation.

Cet étalon permet donc de s'affranchir dans une large mesure du problème mentionné.

Un autre problème des modèles de coût plus spécifiquement résolu par l'invention est la dépendance vis-à-vis du calculateur utilisé. Cela signifie que toutes les fois que le SGBDR est transportée sur une autre plate-forme matérielle, ou qu'un nouveau système d'exploitation est installé, il est nécessaire pour obtenir des performances optimales de recalibrer les modèles de coût. Dans l'art antérieur, cette opération est effectuée manuellement, c'est-à-dire qu'un opérateur effectue pour chaque type de requêtes sur le SGBDR une série de mesures du coût sur le nouvel environnement et tente d'obtenir à partir de ces mesures un modèle analytique du coût de la requête dans le nouvel environnement.

Un modèle de coût différent est nécessaire pour chaque requête possible sur le
SGBDR. Par exemple, le coût d'une opération d'échantillonnage séquentiel avec prédicat de sélection peut s'exprimer par une relation du type:
COST = INIT + COSTrscan + COSTpred avec:
COSTrscan = NEXT*SIZE et:
COSTpred = BALANCE4eval(Pred > *SIZE
La table 1 résume les diverses fonctions et variables utilisées dans ces relations:

<tb> <SEP> VARIABLE <SEP> DESCRIPTION <SEP> TYPE
<tb> COST <SEP> Coût <SEP> pour <SEP> échantillonner <SEP> une <SEP> table <SEP> fonction <SEP> de <SEP> coût
<tb> NEXT <SEP> Coût <SEP> pour <SEP> procéder <SEP> au <SEP> prochain <SEP> paramètre
<tb> <SEP> tuple <SEP> dans <SEP> la <SEP> table
<tb> SIZE <SEP> Taille <SEP> de <SEP> la <SEP> table <SEP> fonction
<tb> COST <SEP> i <SEP> Coût <SEP> pour <SEP> échantillonner <SEP> fonction <SEP> de <SEP> coût
<tb> <SEP> séquenttiellement <SEP> une <SEP> table
<tb> <SEP> avec <SEP> un <SEP> prédicat <SEP> de <SEP> sélection
<tb> INIT <SEP> Coût <SEP> de <SEP> préparation <SEP> paramètre
<tb> <SEP> d'échantillonage <SEP>
<tb> BALANCE <SEP> Composante <SEP> de <SEP> coût <SEP> pour <SEP> paramètre
<tb> <SEP> pondérer <SEP> la <SEP> fonction <SEP> eval <SEP> (P)
<tb> eval(P) <SEP> Nombre <SEP> estimé <SEP> de <SEP> termes <SEP> évalués <SEP> fonction
<tb> <SEP> avec <SEP> le <SEP> prédicat <SEP> P
<tb>
Le lecteur averti comprendra qu'il ne s'agit ici que d'un exemple de modèle de coût pour une seule requête particulière sur un SGBDR. Pour d'autres tvpes de requêtes, d'autres modèles de coût s'appliqueront de manière similaire. Pour de plus amples informations, I'homme de l'art pour.s se référer par exemple au rapport EP2025 DD11b3501, mai 1990 de F.ANDRES intitulé "Study of some typical algorithms for a cost model definition" et au rapport EP2025 DD11b3901 intitulé "Cost model for a database system in a distributed memory architecture" .

Les paramètres INIT, BALANCE et NEXT dans le modèle ci-dessus dépendent du système informatique utilisé, par exemple du matériel ou du système d'exploitation. Ils doivent être déterminés lors de la calibration des modèles de coût. II se peut aussi que la forme générale analytique de ce modèle de coût ne s'applique pas à un système informatique particulier; par exemple, que COSTrscan ne dépende pas linéairement de la taille SIZE de la table. II s'agit donc pour obtenir des performances optimales d'adapter, de corriger et de calibrer ce modèle de coût.

Un schéma-bloc simplifié d'un dispositif de calibration automatique de modèle de coût est représenté sur la figure 1. Lorsqu'il s'avère nécessaire de recalibrer les modèles de coût utilisés par un module principal 1 chargé notamment de gérer un SGBDR avec optimiseur de requêtes, celui-ci communique avec le module de calibration automatique 2. En entrée, il lui communique des données 3 définissant un espace d'expériences. L'espace d'expérience définit un ensemble d'expériences limité pour tester un modèle de coût. Le module de calibration automatique établit à partir de ces données des hypothèses 4 sur les modèles de coût, puis génère et exécute automatiquement une succession d'expériences prises dans l'ensemble d'expériences sur le SGBDR, afin d'améliorer les modèles des hypothèses. Pour réaliser ces expériences, le module de calibration place le
SGBDR dans un état requis grâce à des actions 6. Le module de calibration utilise ensuite les résultats des expériences pour calculer des modèles de coût calibrés 5 transmises en sortie au module principal 1.

Dans une réalisation préférentielle du module principal 1 et du module de calibration automatique 2 par logiciel en programmation orientée objet, les données définissant l'espace d'expérience, les hypothèses et les actions sont implémentées sous la forme d'objets, c'est-à-dire d'entités informatiques contenant des variables et/ou des fonctions de manipulation de ces variables.

Le format des données définissant un espace d'expériences 3 est représenté sur la figure 2 pour les expériences de calibration du modèle de coût de la requête "échantillonnage séquentiel avec prédicat de sélection" mentionnée ci-dessus.

Ces données sont transmises par le programme de SGBDR dans le module principal 1 au module de calibration automatique 2. Les facteurs sont les variables d'expérience. Ici, les deux facteurs sont la taille du ou des tables et le type du prédicat de sélection. Le module de calibration automatique sélectionne des couples de valeurs successives des facteurs au cours des expériences de manière à confirmer ou à infirmer les hypothèses sur la forme analytique du modèle de coût. Au cours des expériences, les valeurs des facteurs sont choisies à l'intérieur d'un intervalle défini dans l'espace d'expériences. Les paramètres sont les coefficients des modèles de coût que le module de calibration automatique s'efforce de déterminer. Le résultat des expériences est ici un entier représentant le temps d'exécution en millisecondes de la requête sur le SGBDR avec les facteurs d'expérience choisis. Dans une variante, L'espace d'expérience peut encore contenir une variable de type entier ou nombre réel non représentée sur la figure indiquant un taux de confiance. Ce taux de confiance indique l'erreur relative maximale ou, dans une variante, moyenne que le modèle de coût ajusté doit présenter par rapport aux expériences.

Le format des données d'hypothèses est représenté sur la figure 3. L'hypothèse donnée sur la figure 2 correspond au coût pour un échantillonnage séquentiel avec prédicat de sélection. Les hypothèses sont utilisées par le module de calibration automatique et utilisent directement les données transmises dans l'espace d'expérience. Une hypothèse comprend la liste des facteurs qui pourront varier aux cours des expériences. Ces facteurs comprennent pour cet exemple la taille de la ou des tables et le prédicat de sélection. En outre, elle comprend la réponse du système. Cette réponse constitue ici le temps pour échantillonner séquentiellement la table avec un prédicat de sélection. En outre, elle comprend la liste des paramètres. Ces paramètres sont les coefficients des modèles de coût que l'on souhaite adapter. Finalement, elle comprend un modèle analytique de coût. Ce modèle est adapté par le module de calibration automatique à l'aide des résultats des expériences. Initialement, ce modèle peut soit être transmis par le module principal et correspondre par exemp., au modèle utilisé dans un environnement matériel antérieur, soit être un modèle initial quelconque de relation analytique entre les facteurs, les paramètres et les résultats établi par le module de calibration automatique.

Le module de calibration automatique manipule le SGBDR au cours des expériences au moyen des données d'actions représentées sur la figure 4. Par exemple, il fait varier à l'aide des actions la taille d'une ou de plusieurs tables, ou il modifie le prédicat de sélection utilisé pour l'échantillonnage séquentiel. II demande ensuite d'effectuer la requête à tester sur le SGBDR, et mesure le coût de cette requête (ici le temps nécessaire à l'échantillonnage séquentiel avec prédicat de sélection). En programmation orientée objet, une action se présente comme un objet portant un nom (ici SCAN~SELECT~RELATION). Cet objet défini les valeurs des facteurs nécessaire pour la prochaine expérience. Ici, les 2 facteurs sont la taille de la table à tester et le prédicat de sélection pour l'opération d'échantillonnage séquentiel. L'objet contient une variable pour le résultat de l'expérience, ici le temps d'échantillonnage. Enfin l'objet contient une fonction agissant sur au moins une des tables du SGBDR qui est la requête testée. Cet objet définit donc toute l'interface entre les deux modules de l'invention au cours des expériences.

Le fonctionnement de l'invention selon la réalisation préférentielle va maintenant être décrit plus en détail.

Le module principal 1 communique au module de calibration automatique, à tour de rôle pour chaque modèle de coût à établir, un espace d'expérience selon le format de la figure 2. Cet espace d'expériences définit un ensemble d'expériences permettant de tester le coût d'une requête particulière sur le
SGBD, parmi lesquelles le module de calibration automatique choisira automatiquement les expériences les plus appropriées. Le module de calibration automatique convertit ces données pour établir des hypothèses sur les modèles de coût selon le format de la figure 3. Le module de calibration automatique envoie en retour au module principal lors des expériences pour chaque modèle à tester une succession d'actions. A chaque hypothèse correspond un type d'action. Le format des données d'action est illustré sur la figure 4. Ces actions entraînent des modifications de l'état du SGBDR, par exemple des modifications du nombre de tuples contenus, correspondant aux valeurs des facteurs actuellement testés. Ces actions définissent aussi une opération à effectuer sur le SGBDR, par exemple un échantillonnage séquentiel avec prédicat de sélection.

Le temps consommé par la requête est mesuré, et le module de calibration automatique sélectionne d'autres facteurs correspondant à un nouvel état du
SGBDR pour la prochaine mesure. II continue ainsi jusqu'à ce que le modèle de coût défini dans les hypothèses soit adapté avec une précision suffisante.

Le module de calibration automatique travaille dans une réalisation préférentielle avec un algorithme de décomposition de valeurs singulières (dénoté algorithme
SVD, un acronyme de l'anglais "singular value decomposition", dans la littérature). Lorsque suffisamment de mesures ont été effectuées, il obtient les paramètres des modèles de coût les mieux adaptés grâce à cet algorithme connu de l'art antérieur. L'algorithme localise les valeurs de paramètres en utilisant une minimisation de X2. II accepte une fonction qui est une combinaison linéaire des fonctions partielles et des paramètres, ainsi qu'un ensemble de données.

Analytiquement, il détermine les valeurs des paramètres (P1...PN). L'équation pour le modèle de coût doit être exprimée sous la forme générale d'un système linéaire comme suit: F(x;P1 ,P2...Pn) = P1 *G1 (x) + P2*G2(x) + ... + PnGn(x) où
F(x;P1,P2...Pn) équation du modèle de coût (solution)
x facteur dans le modèle de coût
Pi paramètre dans le modèle de coût
Gi sous-fonction du modèle de coût pour le paramètre Pi
Les mesures sont enregistrées dans un ensemble de données: [(xi,yi) ! (1 < =i < =m)] où xi représente la i-ème valeur choisie du facteur, yi le i-ème résultat de mesure et m le nombre d'expériences.

Comme le modèle de coût choisi dans l'exemple pour un échantillonnage séquentiel avec prédicat de sélection ne correspond pas à un système linéaire, les modèles de coût initiaux ont été partagés en deux parts. La première partie décrit le comportement attendu d'un SGBDR avec un prédicat de sélection fixé et calibre les paramètres INIT et NEXT. La seconde partie calibre le paramètre
BALANCE au moyen de requêtes utilisant des requêtes avec des prédicats de sélection variables. Pour la première partie, nous utilisons les sous-fonctions de l'algorithme SVD: GINIT(SIZE) = 1 et GNEXT(SIZE) = SIZE. Pour la seconde partie, la sous-fonction utilisée est GBALANCE(SlZE,PREDlCAT) = eval(PREDlCAT) *SIZE.

Les autres termes INIT et NEXT*SIZE sont choisis constants.

De manière préférentiel, le module de calibration automatique sera constitué par une version adaptée du programme expérimentateur (test pilot) (Software
Testpilot en anglais) décrit dans M.L. KERSTEN et al, "Design and
Implementation of a DBMS Performance Assessment Tool", CWl Technical
Report, CS-9263, Amsterdam, Dec. 1992. Il s'agit d'un outil général de mesure de performances, qui permet de décrire des aspects d'un système et un modèle de performances analytique à l'aide d'une déclaration. Le programme expérimentateur (test pilot) aide ensuite à calibrer automatiquement les coefficients dans le modèle de performance en choisissant et en exécutant des expériences jugées hautement probables de confirmer ou d'infirmer le modèle. Si l'algorithme de décomposition de valeurs singulières utilisé dans le programme expérimentateur (test pilot) ne permet pas avec le modèle de coût en hypothèse de trouver des coefficients garantissant une adéquation suffisante du modèle, le programme expérimentateur (test pilot) modifie automatiquement la forme générale analytique du modèle. Par exemple, si un modèle de performances supposant

L'homme de l'art pourra se référer à la documentation du programme expérimentateur (test pilot) mentionné ci-dessus pour les détails de l'implémentation du module de calibration automatique.

Un des mérites de l'invention est d'utiliser cet outil général pour une application spécifique de calibration de modèles de coût dans un SGBDR.

Considérons une série d'expériences pour trouver un modèle de coût pour la requête "sélection d'un tuple" dans une table d'une taille de O à 100 tuples, en fonction de la taille de la table. Pour confirmer ou infirmer rapidement une hypothèse de dépendance linéaire, le programme expérimentateur (test pilot) générera par exemple automatiquement une série d'expériences avec des tailles de table valant successivement: 0, 100, 50, 25, 75, 13, 38, etc...

Cette succession a pourtant un inconvénient. Pour chaque expérience, il est nécessaire d'apporter des grandes modifications aux tables. Après la première sélection, 100 tuples sont insérés. Un tuple est sélectionné et à nouveau 50 tuples sont effacés, etc... Cette manière de faire peut s'avérer inacceptablement lente.

Pour cette raison, un autre ordre est préférable qui minimise le temps d'exécution en minimisant les modifications des tables. Pour cela, dans une réalisation avantageuse, le programme expérimentateur (test pilot) est modifié de manière à traiter ensemble des groupes de points de test successifs qui sont ensuite exécutés dans un ordre qui minimise le temps d'exécution. Par exemple, si trois points successifs sont traités ensemble, L'ordre des mesures deviendra par exemple: 0, 50, 100, 75, 25, 13 etc... Un compromis sera trouvé pour la taille des groupes de points. En effet, si les groupes de point de test contenaient dans cet exemple 100 points, L'ordre des mesures deviendrait 0,1,2,3 etc..., ce qui est en contradiction avec la nécessité d'infirmer ou de confirmer rapidement les modèles.

Le module de calibration automatique cesse d'exécuter de nouvelles expériences lorsque l'utilisateur intervient. L'utilisateur peut ainsi suivre sur un écran l'évolution d'un paramètre représentant la fiabilité du nouveau modèle de coût calibré, et interrompre les expériences lorsque ce paramètre atteint une valeur satisfaisante.

De manière préférable pourtant, le module de calibration automatique interrompt automatiquement les expériences dès que l'erreur relative entre les prévisions du modèle de coût calibré et les résultats des expériences est au-dessous d'un seuil déterminé. Le programme de SGBDR communique ce seuil dénommé taux de confiance au module de calibration automatique avec les données définissant l'espace d'expérience. De manière connue, le taux de confiance est défini par la relation:
T=!E-M!/M dans laquelle T désigne le taux de confiance, E la valeur estimée par le modèle ajusté et M la valeur mesurée lors des expériences.

Le module de calibration automatique interrompt par exemple les expériences dès que la valeur maximale du taux de confiance pour toutes les mesures se trouve en-dessous d'un seuil transmis par le programme de SGBDR. Dans une variante, il interrompt les expériences dès que la valeur moyenne du taux de confiance pour toutes les mesures se trouve en-dessous d'un seuil.

Dans une réalisation préférable de l'invention, les tables et l'ensemble de requêtes associé utilisés pendant la calibration des modèles de coût constituent un étalon d'évaluation de performances probabilistique de type AS3AP (voir document de Turbyfill cité plus haut). Ce type d'étalon autorise une relative indépendance des modèles de coût vis-à-vis du domaine d'application du
SGBDR.

Dans une autre réalisation, les tables et l'ensemble de requêtes associé utilisés pendant la calibration des modèles de coût sont caractéristiques pour une application réelle. Ce type d'étalon permet d'établir des modèles de performance parfaitement optimisés pour un domaine d'application particulier du SGBDR.

Ce dispositif de calibration automatique des modèles de coût a été testé avec succès pour calibrer les modèles de coût d'un système de gestion de bases de données relationnel parallèle de type DBS3 implémenté sur une architecture multiprocesseur en mode dit "tout-partagé".

Claims

Revendications

1. Méthode d'élaboration d'un modèle de coût utilisé dans un optimiseur de requête par un SGBD, caractérisée en ce que la méthode comporte une première étape de S4finition automatique d'un modèle de coût analytique, et une seconde étape de calibration automatique du modèle de coût, grâce à des expériences successives et en nombre réduit de vérification du modèle générées automatiquement.

2. Méthode selon la revendication précédente, caractérisée en ce que ledit modèle de coût analytique utilise des formules de coût génériques applicables à différents systèmes de base de données, et que les caractéristiques d'un système spécifique sont décrites par des valeurs particulières des coefficients dans les formules de coût.

3. Méthode selon la revendication 2, caractérisée en ce que lesdits coefficients des formules de coût sont ajustés à l'aide des résultats des expériences successives.

4. Méthode selon la revendication 3, caractérisée en ce que les résultats des expériences successives comprennent au moins le temps d'exécution d'une opération sur la base de donnée.

5. Méthode selon une des revendications précédentes, caractérisée en ce que les expériences successives utilisent des valeurs successives de facteurs dans les formules de coût, et en ce que ces valeurs successives sont choisies automatiquement de manière à confirmer ou à infirmer les hypothèses utilisées pour définir le modèle de coût analytique.

6. Méthode selon la revendication 5, caractérisée en ce que lorsque suffisamment d'expériences ont été effectuées pour obtenir un niveau de fiabilité donné au préalable, les coefficients des formules de coût qui correspondent le mieux aux résultats sont calculées à l'aide d'un algorithme de décomposition de valeurs singulières.

7. Méthode selon l'une des revendications précédentes, caractérisée en ce que les expériences successives utilisent un point de ré père à probabilité ("probabilistic benchmark").

8. Méthode selon l'une des revendications précédentes, caractérisée en ce que les expériences successives utilisent une base de données typique par un type d'application avec un ensemble de requêtes caractéristiques par ce type d'application 9. Méthode selon l'une des revendications précédentes, caractérisée en ce que le système de gestion de base de données est soit un système parallèle, soit un système séquentiel.

10. Dispositif pour implémenter le procédé de la revendication 1, caractérisé en ce qu'il comporte: -un module principal de gestion de bases de données comprenant un optimiseur de requêtes utilisant au moins un modèle analytique de coût -et un module de calibration automatique du ou des modèles analytiques de coût qui génère et exécute automatiquement une succession d'expériences de vérification du ou des modèles de coût afin d'adapter les formules de coût utilisées dans le ou les modèles de coût à l'environnement informatique particulier dans lequel le système de gestion de bases de données relationnel est implémenté, les expériences successives étant choisies automatiquement par le module de calibration automatique dans un espace d'expériences.

11. Dispositif selon la revendication 10, caractérisé en ce que le module de calibration automatique est réalisé à partir du programme expérimentateur (test pilot).

12. Dispositif selon la revendication 10 ou 11, caractérisé en ce que l'espace d'expériences est transmis au module de calibration automatique par le module principal.

13. Dispositif selon l'une c0s revendications 10 à 12, caractérisé en ce que l'espace d'expériences indique au moins un facteur dans les formules de coût qui varie au cours des expériences successives.

14. Dispositif selon la revendication précédente, caractérisé en ce que au moins une partie des facteurs dans les formules de coût variant au cours des expériences successives caractérisent l'état d'une ou des tables du système de gestion de bases de données sur lesquelles ont lieu les expériences.

1 5. Dispositif selon la revendication précédente, caractérisé en ce que au moins un des facteurs dans les formules de coût qui varient au cours des expériences successives est proportionnel au nombre de tuples dans les tables sur lesquelles ont lieu les expériences.

16. Dispositif selon l'une des revendications 10, 11 ou 13, caractérisé en ce que l'espace d'expériences comporte en outre un taux de confiance à obtenir pour les formules de coût ajustées.

17. Dispositif selon l'une des revendications 10, 1 1 ou 13, caractérisé en ce que l'espace d'expériences comporte en outre l'intervalle de valeurs que peuvent prendre les facteurs dans les formules de coût au cours des expériences successives.

18. Dispositif selon l'une des revendications 10 à 12, caractérisé en ce que le module de calibration automatique effectue des mesures pour calibrer les modèles de coût à l'aide d'un étalon d'évaluation de performances composé de tables et d'un ensemble de requêtes associées.

19. Dispositif selon la revendication précédente, caractérisé en ce que les tables et l'ensemble de requêtes associées utilisés dans l'étalon d'évaluation de performances sont caractéristiques pour une application du monde réel.

20. Dispositif selon la revendication 17, caractérisé en ce que l'étalon d'évaluation de performances est de type probabilistique.

21. Dispositif selon la revendication 13 ou 14, caractérisé en ce que le module de calibration automatique choisit des points de mesure successifs au cours des expériences, correspondants à des valeurs successives des facteurs dans les formules de coût, qui ont une haute probabilité de confirmer ou d'infirmer les hypothèses sur les formules utilisées par le modèle analytique de coût.

22. Dispositif selon l'une des revendications 10 à 20, caractérisé en ce que le dit modèle de coût utilise des formules de coût dont les coefficients propres à un système particulier sont ajustés par le module de calibration automatique au cours des expériences successives.

23. Dispositif selon l'une des revendications 10 à 21, caractérisé en ce que le dit modèle de coût utilise des formules de coût dont la forme générale analytique est déterminée par le module de calibration automatique au cours des expériences successives.

24. Dispositif selon l'une des revendications 16, 21 ou 22, caractérisé en ce que les coefficients des formules de coût et/ou l'allure générale analytique des formules de coût sont déterminés par le module de calibration automatique de manière à ce que l'erreur relative entre les prévisions du modèle de coût et les résultats des expériences successives n'excèdent pas un seuil déterminé correspondant au taux de confiance de l'espace d'expérience.

25. Dispositif selon la revendication précédente, caractérisé en ce que si un simple ajustement des coefficients des formules de coût ne permet pas d'obtenir une erreur relative en-dessous du seuil déterminé, alors la forme générale analytique des formules de coût est modifiée et les coefficients correspondants sont ajustés par le module de calibration automatique, et cela jusqu'à ce qu'une forme générale analytique et des coefficients ajustés correspondants soient trouvés qui permettent d'obtenir une erreur relative en-dessous du seuil déterminé.

26. Dispositif selon l'une des revendications 13, 20 ou 23, caractérisé en ce que la succession du ou des facteurs dans les formules de coût aii cours des expériences est déterminée par le module de calibration automatique de manière à minimiser le temps nécessaire à la succession des expériences, en choisissant un ordre de succession qui réduise les modifications à apporter aux tables pour chaque expérience.

27. Dispositif selon l'une des revendications précédentes, caractérisé en ce que les résultats des expériences comprennent au moins le temps d'exécution d'une des requêtes de l'évaluateur de performances par le système informatique auquel on veut ajuster le modèle de coût.

28. Dispositif selon l'une des revendication 10 à 13, caractérisé en ce que le module principal et le module de calibration automatique communiquent au cours des expériences par l'intermédiaire d'un objet -les valeurs des facteurs pour mener l'expérience -le résultat de l'expérience -le type de requête à tester pour cette expérience.

29 Utilisation du dispositif selon l'une des revendications précédentes pour calibrer les modèles de coût utilisés par l'optimiseur de requêtes dans un système de gestion de bases de données relationnel parallèle.