geqo.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Dernière modification
     le       $Date$
     par      $Author$
     révision $Revision$ -->
<!-- SAS : 20071220, PG83b4 -->

 <chapter id="geqo">
  <chapterinfo>
   <author>
    <firstname>Martin</firstname>
    <surname>Utesch</surname>
    <affiliation>
     <orgname>
      University of Mining and Technology
     </orgname>
     <orgdiv>
      Institute of Automatic Control
     </orgdiv>
     <address>
      <city>
       Freiberg
      </city>
      <country>
       Germany
      </country>
     </address>
    </affiliation>
   </author>
   <date>1997-10-02</date>
  </chapterinfo>

  <title id="geqo-title">Optimiseur génétique de requêtes
    (<foreignphrase>Genetic Query Optimizer</foreignphrase>)</title>

  <para>
   <note>
    <title>Auteur</title>
    <para>
     Écrit par Martin Utesch (<email>utesch@aut.tu-freiberg.de</email>)
     de l'Institut de Contrôle Automatique à l'Université des Mines et de 
     Technologie de Freiberg, Allemagne.
    </para>
   </note>
  </para>

  <sect1 id="geqo-intro">
   <title>Gérer les requêtes, un problème d'optimisation complexe</title>

   <para>
    De tous les opérateurs relationnels, le plus difficile à exécuter et à
    optimiser est la jointure (<firstterm>join</firstterm>). Le nombre de plans
    de requêtes possibles croît exponentiellement avec le nombre de jointures
    de la requête. Un effort supplémentaire d'optimisation est nécessité par
    le support de différentes <firstterm>méthodes de jointure</firstterm>
    (boucles imbriquées, jointures de hachage, jointures de fusion...) pour
    exécuter des jointures individuelles et différents
    <firstterm>index</firstterm> (B-tree, hash, GiST et GIN...) pour accéder
    aux relations.
   </para>

   <para>
    L'optimiseur standard de requêtes pour <productname>PostgreSQL</productname>
    réalise une <firstterm>recherche quasi-exhaustive</firstterm> sur
    l'ensemble des stratégies alternatives. Cet algorithme,
    introduit à l'origine dans la base de données System R d'IBM, produit un ordre
    de jointure quasi-optimal mais peut occuper beaucoup de temps et de
    mémoire à mesure que le nombre de jointures d'une requête augmente.
    L'optimiseur ordinaire de requêtes de <productname>PostgreSQL</productname>
    devient donc inapproprié pour les requêtes qui joignent un grand nombre de tables.
   </para>

<!-- electrical power grid ? -->
   <para>
    L'Institut de Contrôle Automatique de l'Université des Mines et de 
    Technologie basé à Freiberg, Allemagne, a rencontré des difficultés
    lorsqu'il s'est agi d'utiliser <productname>PostgreSQL</productname>
    comme moteur d'un système d'aide à la décision reposant sur une base de
    connaissance utilisé pour la maintenance d'une grille
    de courant électrique. Le SGBD devait gérer des requêtes
    à nombreuses jointures pour la machine d'inférence de la base de
    connaissances. Le nombre de jointures de ces requêtes empêchait
    l'utilisation de l'optimiseur de requête standard.
   </para>

<!-- Supprimé dans la v83
   <para>
    Les difficultés en terme de performance pour l'exploration des plans de
    requêtes possibles ont créé la demande du développement d'une nouvelle
    technique d'optimisation.
   </para>
-->

   <para>
    La suite du document décrit le codage d'un <firstterm>algorithme
    génétique</firstterm> de résolution de l'ordonnancement des jointures
    qui soit efficace pour les requêtes à jointures nombreuses.
   </para>
  </sect1>

  <sect1 id="geqo-intro2">
   <title>Algorithmes génétiques</title>

<!-- fitness : ? Je doute qu'il s'agisse de forme physique :-/ 
     to fit : s'intégrer, entrer, s'encastrer... 
     adaptation me semble convenir -->
   <para>
    L'algorithme génétique (<acronym>GA</acronym>) est une méthode
    d'optimisation heuristique qui opère par recherches non déterministes,
    aléatoires. L'ensemble des solutions possibles au problème d'optimisation
    est considéré comme une <firstterm>population</firstterm>
    d'<firstterm>individus</firstterm>. Le degré d'adaptation d'un individu
    à son environnement est indiqué par sa <firstterm>valeur d'adaptation</firstterm>
    (<foreignphrase>fitness</foreignphrase>).
   </para>

   <para>
    Les coordonnées d'un individu dans l'espace de recherche sont représentées
    par des <firstterm>chromosomes</firstterm>, en fait un ensemble de chaînes
    de caractères. Un <firstterm>gène</firstterm> est une sous-section de
    chromosome qui code la valeur d'un paramètre simple en cours d'optimisation.
    Les codages habituels d'un gène sont
    <firstterm>binary</firstterm> ou <firstterm>integer</firstterm>.
   </para>

   <para>
    La simulation des opérations d'évolution
    (<firstterm>recombinaison</firstterm>, <firstterm>mutation</firstterm> et
    <firstterm>sélection</firstterm>) permet de trouver de nouvelles
    générations de points de recherche qui présentent une meilleure adaptation
    moyenne que leurs ancêtres.
   </para>

   <para>
    Selon la <acronym>FAQ</acronym> de <systemitem
    class="resource">comp.ai.genetic</systemitem>, on ne peut pas réellement
    affirmer qu'un <acronym>GA</acronym> n'est pas purement une recherche
    aléatoire. Un <acronym>GA</acronym> utilise des processus stochastiques, mais
    le résultat est assurément non-aléatoire (il est mieux qu'aléatoire). 
   </para>

   <figure id="geqo-diagram">
    <title>Diagramme structuré d'un algorithme génétique</title>

    <informaltable frame="none">
     <tgroup cols="2">
      <tbody>
       <row>
        <entry>P(t)</entry>
        <entry>génération des ancêtres au temps t</entry>
       </row>

       <row>
        <entry>P''(t)</entry>
        <entry>génération des descendants au temps t</entry>
       </row>
      </tbody>
     </tgroup>
    </informaltable>

<literallayout class="monospaced">
+=========================================+
|&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;  Algorithme GA  &lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;|
+=========================================+
| INITIALISE t := 0                       |
+=========================================+
| INITIALISE P(t)                         |
+=========================================+
| évalue ADAPTATION de P(t)               |
+=========================================+
| tant que pas CRITERE ARRET faire        |
|   +-------------------------------------+
|   | P'(t)  := RECOMBINAISON{P(t)}       |
|   +-------------------------------------+
|   | P''(t) := MUTATION{P'(t)}           |
|   +-------------------------------------+
|   | P(t+1) := SELECTION{P''(t) + P(t)}  |
|   +-------------------------------------+
|   | évalue ADAPTATION de P''(t)         |
|   +-------------------------------------+
|   | t := t + 1                          |
+===+=====================================+
</literallayout>
   </figure>
  </sect1>

  <sect1 id="geqo-pg-intro">
   <title>Optimisation génétique des requêtes (<acronym>GEQO</acronym>) dans
     PostgreSQL</title>

   <para>
    Le module <acronym>GEQO</acronym> utilise une approche du problème
    d'optimisation des requêtes similaire à celui du voyageur
    de commerce (<acronym>TSP</acronym>). Les plans de requêtes possibles sont
    codés comme des chaînes d'entiers. Chaque chaîne représente l'ordre de
    jointure d'une relation de la requête à une autre. Par exemple, l'arbre de
    jointure
<literallayout class="monospaced">
   /\
  /\ 2
 /\ 3
4  1
</literallayout>
    est codé avec la chaîne d'entiers '4-1-3-2', ce qui signifie&nbsp;:
    première jointure entre les relations '4' et '1', puis '3' et enfin
    '2', avec 1, 2, 3, 4 les identifiants des relations pour l'optimiseur de
    <productname>PostgreSQL</productname>.
   </para>

   <para>
    Les caractéristiques spécifiques de l'implantation du
    <acronym>GEQO</acronym> sont&nbsp;:

    <itemizedlist spacing="compact" mark="bullet">
     <listitem>
      <para>
      <!-- least fit : plus divergent ? -->
       l'utilisation d'un algorithme génétique monostable (ou à état stable)
       (remplacement des individus les moins ciblés au lieu d'un remplacement
       global de génération) permet une convergence rapide vers des plans de
       requêtes améliorés ; c'est indispensable au traitement des requêtes dans un
       temps raisonnable&nbsp;;
      </para>
     </listitem>

     <listitem>
      <para>
      <!-- Je me souviens maintenant pourquoi j'avais déjà buté sur cette
      relecture du temps de la 8.0... -->
      <!-- edge recombination crossover et edge losses ? -->
       l'utilisation de croisements (recombinaisons) aux limites est particulièrement
       adapté pour la restriction des pertes aux limites lors de la résolution
       du problème du voyageur de commerce par un algorithme génétique&nbsp;;
      </para>
     </listitem>

     <listitem>
      <para>
       la mutation en tant qu'opérateur génétique est rendue obsolète afin
       d'éviter la nécessité de mécanismes de réparation lors de la génération
       de tournées valides du problème du voyageur de commerce.
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    Diverses parties du module <acronym>GEQO</acronym> sont adaptées de l'algorithme
    Genitor de D. Whitley.
   </para>

   <para>
    Le module <acronym>GEQO</acronym> permet à l'optimiseur de requêtes de
    <productname>PostgreSQL</productname> de supporter les requêtes disposant
    de jointures importantes de manière efficace via une recherche non
    exhaustive.
   </para>

  <sect2>
   <title>Génération par le <acronym>GEQO</acronym> des plans envisageables</title>

   <para>
    Le processus de planification du <acronym>GEQO</acronym> utilise le code
    standard du planificateur pour créer les plans de parcours des relations
    individuelles. Les plans de jointure sont alors développés à l'aide de
    l'approche génétique. Comme décrit plus bas, chaque plan de jointure
    candidat est représenté par une séquence à laquelle joindre les relations
    de base. Lors de l'étape initiale, l'algorithme produit simplement quelques
    séquences de jointure aléatoirement. Pour chaque séquence considérée, le
    code du planificateur standard est invoqué pour estimer le coût de la
    requête à l'aide de cette séquence. (Pour chaque étape de la séquence, les
    trois stratégies de jointure sont considérées&nbsp;; et tous les plans de
    parcours initiaux sont disponibles. Le coût estimé est le moins coûteux.)
    Les séquences dont le coût est moindre sont considérées <quote>plus
    adaptée</quote> que celle de coût plus élevé. L'algorithme génétique
    élimine les candidats les moins adaptés. De nouveaux candidats sont alors
    engendrés par combinaison de gènes de candidats à forte valeur
    d'adaptation &mdash; par l'utilisation de portions aléatoires de plans
    peu coûteux pour créer de nouvelles séquences. Ce processus est répété
    jusqu'à ce qu'un nombre prédéterminé de séquences aient été considérées&nbsp;;
    la meilleure séquence rencontrée pendant la recherche est utilisée pour
    produire le plan final.
   </para>

   <para>
    Ce processus est intrinsèquement non-déterministe, du fait des choix
    aléatoires effectués lors de la sélection initiale de la population et lors des
    <quote>mutations</quote> des meilleurs candidats qui s'en suivent. De ce
    fait, des plans différents peuvent être choisis d'une exécution à l'autre,
    ce qui conduit à des temps d'exécution et des ordres de colonnes
    différents.
   </para>

  </sect2>

  <sect2 id="geqo-future">
   <title>Tâches à réaliser pour la future implantation du <acronym>GEQO</acronym>
    </title>

     <para>
      Un gros travail est toujours nécessaire pour améliorer les paramètres de
      l'algorithme génétique.
      Dans le fichier
      <filename>src/backend/optimizer/geqo/geqo_main.c</filename>,
      pour les routines <function>gimme_pool_size</function> et
      <function>gimme_number_generations</function>, il faut trouver un
      compromis pour que les paramètres satisfassent deux besoins
      concurrents&nbsp;:
      <itemizedlist spacing="compact">
       <listitem>
	<para>
	 l'optimisation du plan de requête&nbsp;;
	</para>
       </listitem>
       <listitem>
	<para>
	 le temps de calcul.
	</para>
       </listitem>
      </itemizedlist>
     </para>

     <para>
      Dans l'implantation courante, l'adaptation de chaque séquence de jointure
      candidate est estimée par l'exécution ab-initio du code standard de
      sélection de jointure et d'estimation de coût utilisé par le planificateur.
      Avec l'hypothèse que différents candidats utilisent des sous-séquences de
      jointure similaires, une grande partie du travail est répétée. Ce
      processus peut être grandement accéléré en retenant les estimations de
      coût des sous-jointures. Le problème consiste à éviter d'étendre
      inutilement la mémoire en mémorisant ces états.
     </para>

     <para>
      À un niveau plus basique, il n'est pas certain qu'optimiser
      une requête avec un algorithme génétique conçu pour le problème du
      voyageur de commerce soit approprié. Dans le cas du voyageur de commerce, le
      coût associé à une sous-chaîne quelconque (tour partiel) est
      indépendant du reste du tour, mais cela n'est certainement plus vrai dans
      le cas de l'optimisation de requêtes. Du coup, la question reste posée quant au fait
      que la recombinaison soit la procédure de mutation la plus efficace.
     </para>

   </sect2>
  </sect1>

 <sect1 id="geqo-biblio">
  <title>Lectures supplémentaires</title>

  <para>
   Les ressources suivantes contiennent des informations supplémentaires sur
   les algorithmes génétiques&nbsp;:

   <itemizedlist>
    <listitem>
     <para>
      <ulink url="http://www.aip.de/~ast/EvolCompFAQ/">The
      Hitch-Hiker's Guide to Evolutionary Computation</ulink> (FAQ de <ulink
      url="news://comp.ai.genetic"></ulink>)&nbsp;;
     </para>
    </listitem>
   
    <listitem>
     <para>
      <ulink url="http://www.red3d.com/cwr/evolve.html">Evolutionary
      Computation and its application to art and design</ulink>, par
      Craig Reynolds&nbsp;;
     </para>
    </listitem>

    <listitem>
     <para>
      <xref linkend="elma04"/>
     </para>
    </listitem>

    <listitem>
     <para>
      <xref linkend="fong"/>
     </para>
    </listitem>
   </itemizedlist>
  </para>

 </sect1>
</chapter>