Changeset 1132

Show
Ignore:
Timestamp:
09/08/08 19:24:50 (2 months ago)
Author:
sas
Message:

On continue...

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved

  • traduc/trunk/postgresql/geqo.xml

    r973 r1132  
    5252    optimiser est la jointure (<firstterm>join</firstterm>). Le nombre de plans 
    5353    de requêtes possibles croît exponentiellement avec le nombre de jointures 
    54     de la requête. Un effort supplémentaire d'optimisation est dû 
    55     au support d'une variété de <firstterm>méthodes de jointure</firstterm> 
     54    de la requête. Un effort supplémentaire d'optimisation est nécessité par 
     55    le support de différentes <firstterm>méthodes de jointure</firstterm> 
    5656    (boucles imbriquées, jointures de hachage, jointures de fusion...) pour 
    57     exécuter des jointures individuelles et une diversité 
    58     d'<firstterm>index</firstterm> (B-tree, hash, GiST et GIN...) pour accéder 
     57    exécuter des jointures individuelles et différents 
     58    <firstterm>index</firstterm> (B-tree, hash, GiST et GIN...) pour accéder 
    5959    aux relations. 
    6060   </para> 
    …… 
    277277    engendrés par combinaison de gènes de candidats à forte valeur 
    278278    d'adaptation &mdash; par l'utilisation de portions aléatoires de plans 
    279     peu-coûteux pour créer de nouvelles séquences. Ce processus est répété 
    280     jusqu'à ce qu'un nombre prédéterminé de séquences ait été considéré&nbsp;; 
     279    peu coûteux pour créer de nouvelles séquences. Ce processus est répété 
     280    jusqu'à ce qu'un nombre prédéterminé de séquences aient été considérées&nbsp;; 
    281281    la meilleure séquence rencontrée pendant la recherche est utilisée pour 
    282     produire le paln final. 
     282    produire le plan final. 
    283283   </para> 
    284284 
    …… 
    335335      À un niveau plus basique, il n'est pas certain qu'optimiser 
    336336      une requête avec un algorithme génétique conçu pour le problème du 
    337       voyageur de commerce approprié. Dans le cas du voyageur de commerce, le 
     337      voyageur de commerce soit approprié. Dans le cas du voyageur de commerce, le 
    338338      coût associé à une sous-chaîne quelconque (tour partiel) est 
    339339      indépendant du reste du tour, mais cela n'est certainement plus vrai dans 

  • traduc/trunk/postgresql/gin.xml

    r973 r1132  
    44     par      $Author$ 
    55     révision $Revision$ --> 
    6 <!-- SAS : 20080228, PG83 --> 
    76 
    87<chapter id="GIN"> 
    …… 
    6968   et les relations entre clés, valeurs indexées et requêtes 
    7069   indexables. En résumé, <acronym>GIN</acronym> combine extensibilité, 
    71    généralisation, ré-utilisation du code et une interface 
     70   généralisation, ré-utilisation du code à une interface 
    7271   claire. 
    7372 </para> 
    …… 
    139138       c'est-à-dire que si (check[i] == TRUE), la i-ème clé du tableau résultant 
    140139       d'<function>extractQuery</function> est présente dans la valeur indexée. 
    141        Le datum <literal>query</literal> d'origine (pas le tableau de clé 
     140       Le datum <literal>query</literal> d'origine (pas le tableau de clés 
    142141       extrait&nbsp;!) est passé au cas où la méthode 
    143142       <function>consistent</function> a besoin de le consulter. 
    …… 
    156155  En interne, un index <acronym>GIN</acronym> contient un index B-tree construit 
    157156  sur des clés, où chaque clé est un élément de la valeur indexée (un membre d'un 
    158   tableau par exemple) et où chaque ligne d'une page feuille est soit un pointeur 
    159   vers un B-tree sur des pointeurs heap (PT, posting tree) soit une liste de 
     157  tableau par exemple) et où chaque ligne d'une page feuille est, soit un pointeur 
     158  vers un B-tree de pointeurs heap (PT, posting tree), soit une liste de 
    160159  pointeurs heap (PL, posting list) si la liste est suffisamment petite. 
    161160 </para> 
    …… 
    187186     Le temps de construction d'un index <acronym>GIN</acronym> dépend 
    188187     grandement du paramètre <varname>maintenance_work_mem</varname>&nbsp;; 
    189      la mesquinerie au regard de la mémoire de travail ne paie pas lors de la création d'un index. 
     188     il est contre-productif de limiter la mémoire de travail lors de la création d'un index. 
    190189    </para> 
    191190   </listitem> 
    …… 
    217216        <para> 
    218217         <quote>Souple</quote> signifie 
    219          que le nombre réel des résultats renvoyés peut différer légèrement 
     218         que le nombre réel de résultats renvoyés peut différer légèrement 
    220219         de la limite indiquée, en fonction de la requête et de la qualité du 
    221220         générateur de nombres aléatoires du système. 

  • traduc/trunk/postgresql/gist.xml

    r973 r1132  
    44     par      $Author$ 
    55     révision $Revision$ --> 
    6 <!-- SAS : 20080306, PG830 --> 
    76 
    87<chapter id="gist"> 
    …… 
    7069   autres arbres de recherche standard en termes de données gérées. Par 
    7170   exemple, <productname>PostgreSQL</productname> supporte les B-trees et les 
    72    index hash extensibles. Cela signifie qu'il est possible d'utiliser 
     71   index de hachage extensibles. Cela signifie qu'il est possible d'utiliser 
    7372   <productname>PostgreSQL</productname> pour construire un B-tree ou un hachage 
    7473   sur tout type de données. Mais, les B-trees ne supportent 
    7574   que les prédicats d'échelle (<literal>&lt;</literal>, 
    76    <literal>=</literal>, <literal>&gt;</literal>), les index hash ne supportent 
     75   <literal>=</literal>, <literal>&gt;</literal>), les index de hachage 
    7776   que les requêtes d'égalité. 
    7877 </para> 
    …… 
    8483   <quote>est-ce que imagex est plus petite que imagey</quote> et <quote>est-ce 
    8584   que imagex est plus grande que imagey</quote>. En fonction de la définition 
    86    donnée à <quote>égal à</quote>, <quote>inférieur à</quote> ou 
    87    <quote>supérieur à</quote>, cela peut être utile. 
     85   donnée à <quote>égale à</quote>, <quote>inférieure à</quote> ou 
     86   <quote>supérieure à</quote>, cela peut avoir une utilité. 
    8887   Néanmoins, l'utilisation d'un index basé sur <acronym>GiST</acronym> permet 
    8988   de créer de nombreuses possibilités de poser des questions spécifiques au domaine, 

  • traduc/trunk/postgresql/high-availability.xml

    r973 r1132  
    1515 <indexterm><primary>partitionnement de données</primary></indexterm> 
    1616 
    17  <para> 
    18   Les serveurs de bases de données peuvent travailler ensemble pour permettre 
    19   à un second serveur de prendre rapidement la main si le serveur principal 
    20   échoue (haute disponibilité, <foreignphrase>high availability</foreignphrase>), 
     17<!-- seamlessly ? --> 
     18 <para> 
     19  Des serveurs de bases de données peuvent travailler ensemble pour permettre 
     20  à un serveur secondaire de prendre rapidement la main si le serveur principal 
     21  échoue (haute disponibilité, ou <foreignphrase>high availability</foreignphrase>), 
    2122  ou pour permettre à plusieurs serveurs de servir les mêmes données (répartition 
    22   de charge <foreignphrase>load balancing</foreignphrase>). Idéalement, les 
    23   serveurs de bases de données peuvent travailler ensemble sans jointure. Les 
    24   serveurs web traitant des pages web statiques peuvent travailler ensemble 
    25   assez facilement en répartissant la charge des requêtes web sur plusieurs 
    26   machines. De même, les serveurs de bases de données en lecture seule peuvent 
    27   aussi travailler ensemble assez facilement. Malheureusement, la plupart des 
    28   serveurs de bases de données ont des requêtes de lecture/écriture et ce type 
    29   de serveurs sont bien plus difficile à faire travailler ensemble. Ceci est dû 
    30   au fait qu'il faut placer une seule fois sur chaque serveur les données en 
    31   lecture seule et qu'une écriture sur un serveur doit être propagée à tous les 
    32   serveurs pour que les futures lectures sur ces serveurs renvoient des résulats 
     23  de charge, ou <foreignphrase>load balancing</foreignphrase>). Idéalement, les 
     24  serveurs de bases de données peuvent travailler ensemble sans jointure. 
     25  </para> 
     26  <para> 
     27  Il est aisé de faire coopérer des serveurs web qui traitent des pages web statiques 
     28  en répartissant la charge des requêtes web sur plusieurs 
     29  machines. Dans les faits, les serveurs de bases de données en lecture seule peuvent 
     30  également coopérer facilement. Malheureusement, la plupart des 
     31  serveurs de bases de données traitent des requêtes de lecture/écriture et, 
     32  de ce fait, collaborent plus difficilement. En effet, alors qu'il suffit de 
     33  placer une seule fois les données en lecture seule sur chaque serveur, une 
     34  écriture sur n'importe quel serveur doit, elle, être propagée à tous les 
     35  serveurs afin que les lectures suivantes sur ces serveurs renvoient des résulats 
    3336  cohérents. 
    3437 </para> 
    3538 
    3639 <para> 
    37   Ce problème de synchronisation est la difficulté fondamentale pour les 
    38   serveurs travaillant ensemble. Comme il n'existe pas qu'une seule 
    39   solution qui élimine l'impact du problème de synchronisation pour tous 
    40   les cas pratiques, il existe plusieurs solutions. Chaque solution répond à 
    41   ce problème d'une façon différente et minimise cet impact pour une charge 
    42   spécifique. 
     40  Ce problème de synchronisation représente la difficulté fondamentale à la 
     41  collaboration entre serveurs. Comme la solution au problème de 
     42  synchronisation n'est pas unique pour tous les cas pratiques, plusieurs 
     43  solutions co-existent. Chacune répond de façon différente et minimise 
     44  cet impact au regard d'une charge spécifique. 
    4345 </para> 
    4446 
    …… 
    4648  Certaines solutions gèrent la synchronisation en autorisant les modifications 
    4749  des données sur un seul serveur. Les serveurs qui peuvent modifier les données 
    48   sont appelés serveurs lecture/écriture ou serveurs maîtres. Les serveurs qui 
    49   peuvent répondre aux requêtes en lecture seule sont appelés des serveurs 
     50  sont appelés serveurs en lecture/écriture ou serveurs maîtres. Les serveurs qui 
     51  peuvent répondre aux requêtes en lecture seule sont appelés serveurs 
    5052  esclaves. Les serveurs qui ne sont pas accessibles tant qu'ils ne se sont pas 
    51   transformés en serveurs maîtres sont appelées des serveurs en attente 
     53  promus en serveurs maîtres sont appelées serveurs en attente 
    5254  (<foreignphrase>standby servers</foreignphrase>). 
    5355 </para> 
    5456 
    5557 <para> 
    56   Certaines solutions sont synchrones, signifiant qu'une transaction de 
    57   modification de données n'est pas considérée validée tant que tous les 
    58   serveurs n'ont pas validés la transaction. Ceci garantit qu'un 
    59   <foreignphrase>failover</foreignphrase> ne perdra pas de données et que tous 
    60   les serveurs en répartition de charge renverront des résultats cohérents quel 
    61   que soit le serveur interrogé. En contraste, les solutions asynchrones 
    62   autorisent un délai entre le moment de la validation et sa propagation aux 
    63   autres serveurs, ceci qui comporte le risque que certaines transactions soient 
    64   perdues dans le basculement à un serveur de sauvegarde et que les serveurs en 
    65   répartition de charge pourraient renvoyer des données obsolètes. La 
    66   communication asynchrone est utilisée quand la version synchrone est trop 
    67   lente. 
     58  Certaines solutions sont synchrones, ce qui signifie qu'une transaction de 
     59  modification de données n'est pas considérée valide tant que tous les 
     60  serveurs n'ont pas validé la transaction. Ceci garantit qu'un 
     61  <foreignphrase>failover</foreignphrase> ne perd pas de données et que tous 
     62  les serveurs en répartition de charge retournent des résultats cohérents, quel 
     63  que soit le serveur interrogé. Au contraire, les solutions asynchrones 
     64  autorisent un délai entre la validation et sa propagation aux 
     65  autres serveurs. Cette solution implique une éventuelle perte de transactions 
     66  lors de la bascule sur un serveur de sauvegarde, ou l'envoi de données 
     67  obsolètes par les serveurs à charge répartie. La communication asynchrone est 
     68  utilisée lorsque la version synchrone est trop lente. 
    6869 </para> 
    6970 
    7071 <para> 
    7172  Les solutions peuvent aussi être catégorisées par leur granularité. Certaines 
    72   solutions peuvent seulement gérer un serveur de bases entier alors que 
     73  ne gèrent que la totalité d'un serveur de bases alors que 
    7374  d'autres autorisent un contrôle par table ou par base. 
    7475 </para> 
    7576 
    7677 <para> 
    77   Les performances doivent être considérées dans tout choix. Il y 
     78  Il importe de considérer les performances dans tout choix. Il y 
    7879  a généralement un compromis à trouver entre les fonctionnalités et les 
    7980  performances. Par exemple, une solution complètement synchrone sur un réseau 
    80   lent pourrait diviser les performances par plus que deux alors qu'une 
    81   solution asynchrone pourrait avoir un impact minimal sur les performances. 
     81  lent peut diviser les performances par plus de deux, alors qu'une 
     82  solution asynchrone peut n'avoir qu'un impact minimal sur les performances. 
    8283 </para> 
    8384 
    …… 
    9798 
    9899   <para> 
    99     Le <foreignphrase>failover</foreignphrase> sur disque partagé évite la 
    100     surcharge dûe à la synchronisation en ayant seulement une copie de la 
    101     base de données. Cela utilise un seul ensemble de disques partagé entre 
    102     plusieurs serveurs. Si le serveur principal échoue, le serveur en attente 
    103     est capable de monter et lancer la base comme s'il récupérait après un 
    104     d'un arrêt brutal. Ceci permet un <foreignphrase>failover</foreignphrase> 
     100    Le <foreignphrase>failover</foreignphrase> (ou bascule sur incident) 
     101    sur disque partagé élimine la surcharge de synchronisation par 
     102    l'existence d'une seule copie de la base de données. Il utilise un 
     103    seul ensemble de disques partagé par plusieurs serveurs. Si le serveur 
     104    principal échoue, le serveur en attente 
     105    est capable de monter et démarrer la base comme s'il récupérait d'un 
     106    arrêt brutal. Cela permet un <foreignphrase>failover</foreignphrase> 
    105107    rapide sans perte de données. 
    106108   </para> 
    107109 
    108    <para> 
    109     Cette fonctionnalité de matériel partagé est commune aux périphériques de 
    110     stockage en réseau. Utiliser un système de fichiers réseau est aussi 
    111     possible bien qu'une grande attention doit être portée au système de 
     110<!-- SAS::ICI --> 
     111   <para> 
     112    La fonctionnalité de matériel partagé est commune aux périphériques de 
     113    stockage en réseau. Il est également possible d'utiliser un système de 
     114    fichiers réseau bien qu'il faille porter une grande attention au système de 
    112115    fichiers pour s'assurer qu'il a un comportement <acronym>POSIX</acronym> 
    113116    complet (voir <xref linkend="creating-cluster-nfs"/>). Une