[Trad] [svn:pgfr] r1132 - traduc/trunk/postgresql
admin at listes.postgresql.fr
admin at listes.postgresql.fr
Lun 8 Sep 19:24:51 CEST 2008
Author: sas
Date: 2008-09-08 19:24:50 +0200 (Mon, 08 Sep 2008)
New Revision: 1132
Modified:
traduc/trunk/postgresql/geqo.xml
traduc/trunk/postgresql/gin.xml
traduc/trunk/postgresql/gist.xml
traduc/trunk/postgresql/high-availability.xml
Log:
On continue...
Modified: traduc/trunk/postgresql/geqo.xml
===================================================================
--- traduc/trunk/postgresql/geqo.xml 2008-09-05 21:08:19 UTC (rev 1131)
+++ traduc/trunk/postgresql/geqo.xml 2008-09-08 17:24:50 UTC (rev 1132)
@@ -51,11 +51,11 @@
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 dû
- au support d'une variété de <firstterm>méthodes de jointure</firstterm>
+ 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 une diversité
- d'<firstterm>index</firstterm> (B-tree, hash, GiST et GIN...) pour accéder
+ exécuter des jointures individuelles et différents
+ <firstterm>index</firstterm> (B-tree, hash, GiST et GIN...) pour accéder
aux relations.
</para>
@@ -276,10 +276,10 @@
é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 — 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 ait été considéré ;
+ 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 ;
la meilleure séquence rencontrée pendant la recherche est utilisée pour
- produire le paln final.
+ produire le plan final.
</para>
<para>
@@ -334,7 +334,7 @@
<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 approprié. Dans le cas du voyageur de commerce, le
+ 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
Modified: traduc/trunk/postgresql/gin.xml
===================================================================
--- traduc/trunk/postgresql/gin.xml 2008-09-05 21:08:19 UTC (rev 1131)
+++ traduc/trunk/postgresql/gin.xml 2008-09-08 17:24:50 UTC (rev 1132)
@@ -3,7 +3,6 @@
le $Date$
par $Author$
révision $Revision$ -->
-<!-- SAS : 20080228, PG83 -->
<chapter id="GIN">
<title>Index GIN</title>
@@ -68,7 +67,7 @@
définissent le comportement des clés dans l'arbre
et les relations entre clés, valeurs indexées et requêtes
indexables. En résumé, <acronym>GIN</acronym> combine extensibilité,
- généralisation, ré-utilisation du code et une interface
+ généralisation, ré-utilisation du code à une interface
claire.
</para>
@@ -138,7 +137,7 @@
TRUE si la valeur indexée contient la clé correspondante de la requête,
c'est-à-dire que si (check[i] == TRUE), la i-ème clé du tableau résultant
d'<function>extractQuery</function> est présente dans la valeur indexée.
- Le datum <literal>query</literal> d'origine (pas le tableau de clé
+ Le datum <literal>query</literal> d'origine (pas le tableau de clés
extrait !) est passé au cas où la méthode
<function>consistent</function> a besoin de le consulter.
</para>
@@ -155,8 +154,8 @@
<para>
En interne, un index <acronym>GIN</acronym> contient un index B-tree construit
sur des clés, où chaque clé est un élément de la valeur indexée (un membre d'un
- tableau par exemple) et où chaque ligne d'une page feuille est soit un pointeur
- vers un B-tree sur des pointeurs heap (PT, posting tree) soit une liste de
+ tableau par exemple) et où chaque ligne d'une page feuille est, soit un pointeur
+ vers un B-tree de pointeurs heap (PT, posting tree), soit une liste de
pointeurs heap (PL, posting list) si la liste est suffisamment petite.
</para>
@@ -186,7 +185,7 @@
<para>
Le temps de construction d'un index <acronym>GIN</acronym> dépend
grandement du paramètre <varname>maintenance_work_mem</varname> ;
- la mesquinerie au regard de la mémoire de travail ne paie pas lors de la création d'un index.
+ il est contre-productif de limiter la mémoire de travail lors de la création d'un index.
</para>
</listitem>
</varlistentry>
@@ -216,7 +215,7 @@
</para>
<para>
<quote>Souple</quote> signifie
- que le nombre réel des résultats renvoyés peut différer légèrement
+ que le nombre réel de résultats renvoyés peut différer légèrement
de la limite indiquée, en fonction de la requête et de la qualité du
générateur de nombres aléatoires du système.
</para>
Modified: traduc/trunk/postgresql/gist.xml
===================================================================
--- traduc/trunk/postgresql/gist.xml 2008-09-05 21:08:19 UTC (rev 1131)
+++ traduc/trunk/postgresql/gist.xml 2008-09-08 17:24:50 UTC (rev 1132)
@@ -3,7 +3,6 @@
le $Date$
par $Author$
révision $Revision$ -->
-<!-- SAS : 20080306, PG830 -->
<chapter id="gist">
<title>Index GiST</title>
@@ -69,11 +68,11 @@
Cette extensibilité n'est pas comparable à celle des
autres arbres de recherche standard en termes de données gérées. Par
exemple, <productname>PostgreSQL</productname> supporte les B-trees et les
- index hash extensibles. Cela signifie qu'il est possible d'utiliser
+ index de hachage extensibles. Cela signifie qu'il est possible d'utiliser
<productname>PostgreSQL</productname> pour construire un B-tree ou un hachage
sur tout type de données. Mais, les B-trees ne supportent
que les prédicats d'échelle (<literal><</literal>,
- <literal>=</literal>, <literal>></literal>), les index hash ne supportent
+ <literal>=</literal>, <literal>></literal>), les index de hachage
que les requêtes d'égalité.
</para>
@@ -83,8 +82,8 @@
<quote>est-ce que imagex est égale à imagey</quote>,
<quote>est-ce que imagex est plus petite que imagey</quote> et <quote>est-ce
que imagex est plus grande que imagey</quote>. En fonction de la définition
- donnée à <quote>égal à</quote>, <quote>inférieur à</quote> ou
- <quote>supérieur à</quote>, cela peut être utile.
+ donnée à <quote>égale à</quote>, <quote>inférieure à</quote> ou
+ <quote>supérieure à</quote>, cela peut avoir une utilité.
Néanmoins, l'utilisation d'un index basé sur <acronym>GiST</acronym> permet
de créer de nombreuses possibilités de poser des questions spécifiques au domaine,
telles que <quote>trouver toutes les images de chevaux</quote> ou
Modified: traduc/trunk/postgresql/high-availability.xml
===================================================================
--- traduc/trunk/postgresql/high-availability.xml 2008-09-05 21:08:19 UTC (rev 1131)
+++ traduc/trunk/postgresql/high-availability.xml 2008-09-08 17:24:50 UTC (rev 1132)
@@ -14,71 +14,72 @@
<indexterm><primary>clustering</primary></indexterm>
<indexterm><primary>partitionnement de données</primary></indexterm>
+<!-- seamlessly ? -->
<para>
- Les serveurs de bases de données peuvent travailler ensemble pour permettre
- à un second serveur de prendre rapidement la main si le serveur principal
- échoue (haute disponibilité, <foreignphrase>high availability</foreignphrase>),
+ Des serveurs de bases de données peuvent travailler ensemble pour permettre
+ à un serveur secondaire de prendre rapidement la main si le serveur principal
+ échoue (haute disponibilité, ou <foreignphrase>high availability</foreignphrase>),
ou pour permettre à plusieurs serveurs de servir les mêmes données (répartition
- de charge <foreignphrase>load balancing</foreignphrase>). Idéalement, les
- serveurs de bases de données peuvent travailler ensemble sans jointure. Les
- serveurs web traitant des pages web statiques peuvent travailler ensemble
- assez facilement en répartissant la charge des requêtes web sur plusieurs
- machines. De même, les serveurs de bases de données en lecture seule peuvent
- aussi travailler ensemble assez facilement. Malheureusement, la plupart des
- serveurs de bases de données ont des requêtes de lecture/écriture et ce type
- de serveurs sont bien plus difficile à faire travailler ensemble. Ceci est dû
- au fait qu'il faut placer une seule fois sur chaque serveur les données en
- lecture seule et qu'une écriture sur un serveur doit être propagée à tous les
- serveurs pour que les futures lectures sur ces serveurs renvoient des résulats
+ de charge, ou <foreignphrase>load balancing</foreignphrase>). Idéalement, les
+ serveurs de bases de données peuvent travailler ensemble sans jointure.
+ </para>
+ <para>
+ Il est aisé de faire coopérer des serveurs web qui traitent des pages web statiques
+ en répartissant la charge des requêtes web sur plusieurs
+ machines. Dans les faits, les serveurs de bases de données en lecture seule peuvent
+ également coopérer facilement. Malheureusement, la plupart des
+ serveurs de bases de données traitent des requêtes de lecture/écriture et,
+ de ce fait, collaborent plus difficilement. En effet, alors qu'il suffit de
+ placer une seule fois les données en lecture seule sur chaque serveur, une
+ écriture sur n'importe quel serveur doit, elle, être propagée à tous les
+ serveurs afin que les lectures suivantes sur ces serveurs renvoient des résulats
cohérents.
</para>
<para>
- Ce problème de synchronisation est la difficulté fondamentale pour les
- serveurs travaillant ensemble. Comme il n'existe pas qu'une seule
- solution qui élimine l'impact du problème de synchronisation pour tous
- les cas pratiques, il existe plusieurs solutions. Chaque solution répond à
- ce problème d'une façon différente et minimise cet impact pour une charge
- spécifique.
+ Ce problème de synchronisation représente la difficulté fondamentale à la
+ collaboration entre serveurs. Comme la solution au problème de
+ synchronisation n'est pas unique pour tous les cas pratiques, plusieurs
+ solutions co-existent. Chacune répond de façon différente et minimise
+ cet impact au regard d'une charge spécifique.
</para>
<para>
Certaines solutions gèrent la synchronisation en autorisant les modifications
des données sur un seul serveur. Les serveurs qui peuvent modifier les données
- sont appelés serveurs lecture/écriture ou serveurs maîtres. Les serveurs qui
- peuvent répondre aux requêtes en lecture seule sont appelés des serveurs
+ sont appelés serveurs en lecture/écriture ou serveurs maîtres. Les serveurs qui
+ peuvent répondre aux requêtes en lecture seule sont appelés serveurs
esclaves. Les serveurs qui ne sont pas accessibles tant qu'ils ne se sont pas
- transformés en serveurs maîtres sont appelées des serveurs en attente
+ promus en serveurs maîtres sont appelées serveurs en attente
(<foreignphrase>standby servers</foreignphrase>).
</para>
<para>
- Certaines solutions sont synchrones, signifiant qu'une transaction de
- modification de données n'est pas considérée validée tant que tous les
- serveurs n'ont pas validés la transaction. Ceci garantit qu'un
- <foreignphrase>failover</foreignphrase> ne perdra pas de données et que tous
- les serveurs en répartition de charge renverront des résultats cohérents quel
- que soit le serveur interrogé. En contraste, les solutions asynchrones
- autorisent un délai entre le moment de la validation et sa propagation aux
- autres serveurs, ceci qui comporte le risque que certaines transactions soient
- perdues dans le basculement à un serveur de sauvegarde et que les serveurs en
- répartition de charge pourraient renvoyer des données obsolètes. La
- communication asynchrone est utilisée quand la version synchrone est trop
- lente.
+ Certaines solutions sont synchrones, ce qui signifie qu'une transaction de
+ modification de données n'est pas considérée valide tant que tous les
+ serveurs n'ont pas validé la transaction. Ceci garantit qu'un
+ <foreignphrase>failover</foreignphrase> ne perd pas de données et que tous
+ les serveurs en répartition de charge retournent des résultats cohérents, quel
+ que soit le serveur interrogé. Au contraire, les solutions asynchrones
+ autorisent un délai entre la validation et sa propagation aux
+ autres serveurs. Cette solution implique une éventuelle perte de transactions
+ lors de la bascule sur un serveur de sauvegarde, ou l'envoi de données
+ obsolètes par les serveurs à charge répartie. La communication asynchrone est
+ utilisée lorsque la version synchrone est trop lente.
</para>
<para>
Les solutions peuvent aussi être catégorisées par leur granularité. Certaines
- solutions peuvent seulement gérer un serveur de bases entier alors que
+ ne gèrent que la totalité d'un serveur de bases alors que
d'autres autorisent un contrôle par table ou par base.
</para>
<para>
- Les performances doivent être considérées dans tout choix. Il y
+ Il importe de considérer les performances dans tout choix. Il y
a généralement un compromis à trouver entre les fonctionnalités et les
performances. Par exemple, une solution complètement synchrone sur un réseau
- lent pourrait diviser les performances par plus que deux alors qu'une
- solution asynchrone pourrait avoir un impact minimal sur les performances.
+ lent peut diviser les performances par plus de deux, alors qu'une
+ solution asynchrone peut n'avoir qu'un impact minimal sur les performances.
</para>
<para>
@@ -96,19 +97,21 @@
<listitem>
<para>
- Le <foreignphrase>failover</foreignphrase> sur disque partagé évite la
- surcharge dûe à la synchronisation en ayant seulement une copie de la
- base de données. Cela utilise un seul ensemble de disques partagé entre
- plusieurs serveurs. Si le serveur principal échoue, le serveur en attente
- est capable de monter et lancer la base comme s'il récupérait après un
- d'un arrêt brutal. Ceci permet un <foreignphrase>failover</foreignphrase>
+ Le <foreignphrase>failover</foreignphrase> (ou bascule sur incident)
+ sur disque partagé élimine la surcharge de synchronisation par
+ l'existence d'une seule copie de la base de données. Il utilise un
+ seul ensemble de disques partagé par plusieurs serveurs. Si le serveur
+ principal échoue, le serveur en attente
+ est capable de monter et démarrer la base comme s'il récupérait d'un
+ arrêt brutal. Cela permet un <foreignphrase>failover</foreignphrase>
rapide sans perte de données.
</para>
+<!-- SAS::ICI -->
<para>
- Cette fonctionnalité de matériel partagé est commune aux périphériques de
- stockage en réseau. Utiliser un système de fichiers réseau est aussi
- possible bien qu'une grande attention doit être portée au système de
+ La fonctionnalité de matériel partagé est commune aux périphériques de
+ stockage en réseau. Il est également possible d'utiliser un système de
+ fichiers réseau bien qu'il faille porter une grande attention au système de
fichiers pour s'assurer qu'il a un comportement <acronym>POSIX</acronym>
complet (voir <xref linkend="creating-cluster-nfs"/>). Une
limitation significative de cette méthode est que si les disques ont un
More information about the Trad
mailing list