Skip to content

Commit

Permalink
Update bloom.xml
Browse files Browse the repository at this point in the history
  • Loading branch information
@Krysztophe
Krysztophe committed Nov 28, 2016
1 parent 63265e0 commit e6b9646
Showing 1 changed file with 38 additions and 39 deletions.
77 changes: 38 additions & 39 deletions postgresql/bloom.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -22,22 +22,23 @@
</para>

<para>
Une signature est une représentation à perte des colonnes indexées et, de ce
Une signature est une représentation avec perte des attributs indexé(s) et, de ce
fait, est sujet à renvoyer des faux positifs&nbsp;; c'est-à-dire qu'il peut
indiquer qu'un élément fait partie d'un ensemble alors que ce n'est pas
vrai. De ce fait, les résultats d'une recherche doivent toujours être
vérifiés en utilisant les valeurs réelles des colonnes à partir de la ligne
dans la table. Les signatures plus larges réduisent le risque de faux
positif et, de ce fait, réduisent le nombre de visites inutiles à la table.
Cependant, l'index est plus volumineux et de ce fait plus lent à parcourir.
indiquer à tort qu'un élément fait partie d'un ensemble. De ce fait,
les résultats d'une recherche doivent toujours être
vérifiés en utilisant les valeurs réelles des attributs de la ligne
dans la table. Des signatures plus larges réduisent les risques de faux
positifs et réduisent donc le nombre de visites inutiles à la table.
Bien sûr, l'index est plus volumineux et donc plus lent à parcourir.
</para>

<para>
Ce type d'index est principalement utile quand une table a de nombreuses
colonnes et que les requêtes testent des combinaisons arbitraires de ces
colonnes. Un index btree traditionnel est plus rapide qu'un index bloom mais
Ce type d'index est principalement utile quand une table a de nombreux
attributs et que les requêtes en testent des combinaisons arbitraires.
Un index btree traditionnel est plus rapide qu'un index bloom mais
il en faut généralement plusieurs pour supporter toutes les requêtes que
gèrerait un seul index bloom. Il est à noter que les index peuvent aussi
gèrerait un seul index bloom. Noter que les index bloom ne supportent que les
recherches par égalité, là où les index btree peuvent aussi
réaliser des recherches d'inégalité et d'intervalles.
</para>

Expand All @@ -46,7 +47,7 @@

<para>
Un index <literal>bloom</literal> accepte les paramètres suivants dans
la clause <literal>WITH</literal>.
sa clause <literal>WITH</literal> :
</para>

<variablelist>
Expand All @@ -68,9 +69,8 @@
<para>
Nombre de bits générés pour chaque colonne d'index. Le nom de chaque
paramètre fait référence au numéro de la colonne d'index qu'il contrôle.
La valeur par défaut est de <literal>2</literal> et le maximum est de
<literal>4095</literal>. Les paramètres pour les colonnes d'index qui ne
sont pas encore utilisés sont ignorés.
La valeur par défaut est <literal>2</literal> bits et le maximum
<literal>4095</literal>. Les paramètres pour les colonnes d'index non utilisées sont ignorés.
</para>
</listitem>
</varlistentry>
Expand All @@ -91,16 +91,16 @@ CREATE INDEX bloomidx ON tbloom USING bloom (i1,i2,i3)

<para>
L'index est créé avec une longueur de signature de 80 bits, avec les
colonnes i1 et i2 correspondant à 2 bits, et la colonne i3 correspondant à
attributs i1 et i2 correspondant à 2 bits, et la colonne i3 à
4 bits. Nous pourrions avoir omis les informations
<literal>length</literal>, <literal>col1</literal>, et
<literal>col2</literal> étant données qu'elles ont la valeur par défaut.
<literal>col2</literal> car elles ont les valeurs par défaut.
</para>

<para>
Voici un exemple plus complet de définition et d'utilisation d'un index
bloom, ainsi qu'une comparaison avec les index btree équivalents. L'index
bloom est fortement plus petit que l'index btree et propose de meilleures
bloom est considérablement plus petit que l'index btree et offre de meilleures
performances.
</para>

Expand Down Expand Up @@ -133,8 +133,7 @@ CREATE INDEX
</programlisting>

<para>
Un parcours séquentiel prend beaucoup de temps sur cette table
volumineuse&nbsp;:
Un parcours séquentiel sur cette grande table prend beaucoup de temps&nbsp;:
<programlisting>
=# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
QUERY PLAN
Expand All @@ -149,8 +148,8 @@ CREATE INDEX
</para>

<para>
Donc l'optimiser sélectionnera habituellement un parcours d'index si
possible. Avec un index btree, nous obtenons ce résultat&nbsp;:
En général l'optimiseur sélectionnera un parcours d'index si c'est
possible. Avec un index btree, nous obtenons ceci&nbsp;:
<programlisting>
=# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
QUERY PLAN
Expand All @@ -165,7 +164,7 @@ CREATE INDEX
</para>

<para>
Bloom est meilleur que btree pour la gestion de ce type de recherche&nbsp;:
Bloom est meilleur que btree pour gérer ce type de recherche&nbsp;:
<programlisting>
=# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 = 123451;
QUERY PLAN
Expand All @@ -180,19 +179,19 @@ CREATE INDEX
Execution time: 76.778 ms
(8 rows)
</programlisting>
Notez le nombre relativement important de faux positifs&nbsp;: 2349 lignes
ont été sélectionnées pour être vérifiées dans la table, amaus aucune n'a
réellement correspondu au filtre de la requête. Nous pouvons réduire ça en
précisant une longueur de signature plus importante. Dans cet exemple,
Noter le nombre relativement important de faux positifs&nbsp;: 2349 lignes
ont été sélectionnées pour vérification dans la table, mais aucune ne correspondait
au filtre de la requête. Nous pouvons réduire cela en
spécifiant une longueur de signature plus importante. Dans cet exemple,
créer l'index avec <literal>length=200</literal> a réduit le nombre de faux
positifs à 55. Par contre, il a doublé la taille de l'index (306 Mo) et
s'est révélé plus lent pour cette requête (125 ms globalement).
positifs à 55 mais doublé la taille de l'index (306 Mo) et
s'est révélé plus lent pour cette requête (125 ms en tout).
</para>

<para>
Maintenant, le problème principal avec la recherche btree est que btree
n'est pas efficace quand les conditions de recherche ne contraignent pas
les premières colonnes de l'index. Une meilleure stratégie pour le btree
Le problème principal avec la recherche btree est que btree
est inefficace quand les critères de recherche ne portent pas
sur la ou les premières colonne(s) de l'index. Une meilleure stratégie avec les btree
est de créer un index séparé pour chaque colonne. À ce moment-là,
l'optimiseur pourra choisir quelque chose comme&nbsp;:
<programlisting>
Expand All @@ -210,20 +209,20 @@ CREATE INDEX
Execution time: 0.280 ms
(9 rows)
</programlisting>
Bien que cette requête s'exécute plus rapidement qu'avec des index seuls,
nous payons une large pénalité à cause de la taille de l'index. Chacun des
index btree simple colonne occupe 214 Mo, soit un espace total de plus de
1,2 Go, autrement dit huit fois la place utilisée par l'index bloom.
Bien que cette requête soit bien plus rapide qu'avec n’importe lequel des index à une colonne,
nous payons une large pénalité en taille d'index. Chacun des
index btree mono-colonne occupe 214 Mo, soit un espace total de plus de
1,2 Go, autrement dit 8 fois la place utilisée par l'index bloom.
</para>
</sect2>

<sect2>
<title>Interface de la classe d'opérateur</title>

<para>
Une classe d'opérateur pour les index bloom requiert une fonction de
Une classe d'opérateur pour les index bloom ne requiert qu'une fonction de
hachage pour le type de données indexé et un opérateur d'égalité pour la
recherche. Cet exemple montre la définition de la classe d'opérateur pour
recherche. Cet exemple définit de la classe d'opérateur pour
le type de données <type>text</type>&nbsp;:
</para>

Expand All @@ -243,7 +242,7 @@ DEFAULT FOR TYPE text USING bloom AS
<listitem>
<para>
Seules les classes d'opérateur pour <type>int4</type> et
<type>text</type> sont inclus avec le module.
<type>text</type> sont incluses avec le module.
</para>
</listitem>

Expand Down

0 comments on commit e6b9646

Please sign in to comment.