Performance on Carnet de découvertes

Le partitionnement par hachage

Florent Jardin — Fri, 23 Apr 2021 00:00:00 +0000

Le partitionnement déclaratif a été une véritable révolution à la sortie de la version 10 de PostgreSQL en octobre 2017. La gestion des sous-tables devenait alors bien plus aisée au quotidien, simplifiant leur mise en place et leur maintenance.

Sans cesse amélioré au cours des dernières années, je me souviens encore de mon émerveillement devant la magie du partitionnement par hachage, apparu en version 11. Comment le déployer et que permet-il ? J’ai voulu m’en rendre compte dans une rapide démonstration sur le type UUID en étudiant les fonctions d’appui qui se cachent derrière le hachage des valeurs.

Un très bon choix de repli

Dès lors qu’une ou plusieurs tables dépasse le milliard de lignes, il y a fort à parier que les problèmes de performance ou de maintenance soient au rendez-vous : index volumineux, fragmentation importante, gel de l’activité pour cause de rebouclage des identifiants de transactions, difficultés à purger les données. L’apparition du partitionnement déclaratif dans PostgreSQL a permis d’y adresser des solutions avec un minimum de complexité.

La clé de partitionnement peut être définie par trois méthodes (range, list, hash) qui présentent chacunes des réponses appropriées aux besoins d’une table ou d’une fonctionnalité. Nous privilégierons une clé répartie sur un intervalle de temps pour l’archivage de données sur une date, ou bien une clé dont les valeurs sont régulées dans une liste lorsque l’on souhaite maîtriser la répartition et pouvoir la faire évoluer simplement.

La dernière méthode hash est intéressante à plusieurs égards par la confusion de la clé primaire avec la clé de partionnement et par une répartition équilibrée des données sur l’ensemble des sous-tables définies à l’avance. De manière générale, si vous n’avez pas idée de votre clé de partitionnement et que vous lisez principalement vos données sur leur clé primaire, la méthode par hachage peut être un très bon choix de repli.

Prenons une table très simple que nous découpons en cinq partitions à partir des valeurs de la clé primaire dont le type est uuid.

CREATE TABLE t1 (
 tid uuid PRIMARY KEY,
 tchar text,
 tdate timestamp without time zone
) PARTITION BY HASH (tid);

CREATE TABLE t1_0_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 0);

CREATE TABLE t1_1_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 1);

CREATE TABLE t1_2_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 2);

CREATE TABLE t1_3_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 3);

CREATE TABLE t1_4_5 PARTITION OF t1
 FOR VALUES WITH (modulus 5, remainder 4);

Avec cette configuration, l’identifiant de chaque ligne sera haché et réduit par l’opérateur modulo pour obtenir une valeur entière comprise entre 0 et 4. Insérons un petit million de lignes et observons leur répartition.

INSERT INTO t1
SELECT gen_random_uuid(), md5(g::varchar),
 current_timestamp - g * interval '1 hour'
 FROM generate_series(1, 1e6) g;

-- INSERT 0 1000000

À partir de la version 13 de PostgreSQL, la fonction gen_random_uuid() est intégrée dans le catalogue et il n’est plus nécessaire de passer par des extensions comme pgcrypto ou uuid-ossp pour générer un uuid aléatoire.

La vue pg_stat_user_tables nous indique bien un nombre de tuples équitablement insérés dans les partitions.

SELECT relname, SUM(n_live_tup) n_live_tup
 FROM pg_stat_user_tables
 GROUP BY cube(relname) ORDER BY relname;

 relname | n_live_tup
---------+------------
 t1_0_5 | 200148
 t1_1_5 | 200123
 t1_2_5 | 199964
 t1_3_5 | 200184
 t1_4_5 | 199581
 | 1000000

Le nombre de partitions est un choix crucial lors de l’initialisation de la table, ou lors de sa transformation en table partitionnée, car l’ajout de nouvelles partitions nécessite de remplacer une des sous-tables existantes par un nouvel ensemble de partitions dont le diviseur doit être un multiple du précédent.

Voyons comment scinder l’une des partitions en deux.

BEGIN;
ALTER TABLE t1 DETACH PARTITION t1_0_5;

CREATE TABLE t1_0_10 PARTITION OF t1
 FOR VALUES WITH (modulus 10, remainder 0);

CREATE TABLE t1_5_10 PARTITION OF t1
 FOR VALUES WITH (modulus 10, remainder 5);

INSERT INTO t1 SELECT * FROM t1_0_5;
-- INSERT 0 200148

DROP TABLE t1_0_5;
COMMIT;

Le contenu de l’ancienne partition t1_0_5 est déversé dans la table partitionnée et l’opérateur modulus 10 permet la redistribution des lignes dans les deux nouvelles partitions, respectivement celles dont les restes de la division sont 0 et 5. On garantit ainsi que les autres partitions ne deviennent pas leur nouvelle destination.

SELECT relname, SUM(n_live_tup) n_live_tup
 FROM pg_stat_user_tables WHERE relname like 't1%10'
 GROUP BY cube(relname) ORDER BY relname;

 relname | n_live_tup
---------+------------
 t1_0_10 | 99960
 t1_5_10 | 100188
 | 200148

Cette opération est lourde sur des données vivantes, avec des verrous de type Access Exclusive qui interdisent toutes consultations ou modifications de la table partitionnée. Les sous-tables non impliquées dans la transformation restent accessibles en lecture, pour peu qu’on puisse réaliser les SELECT sur leur nom exact de partition.

Les fonctions d’appui

La plupart des types de données sont supportés par la méthode hash à l’aide notamment des classes d’opérateur et des fonctions d’appui fournies par PostgreSQL. Par exemple, pour connaître la liste de types compatibles avec le partitionnement par hachage, il suffit de consulter le catalogue.

demo=# \dAc hash
 List of operator classes
 AM | Input type | Storage type | Operator class | Default?
------+-----------------------+--------------+---------------------+----------
 hash | aclitem | | aclitem_ops | yes
 hash | anyarray | | array_ops | yes
 hash | anyenum | | enum_ops | yes
 hash | anyrange | | range_ops | yes
 ...
 hash | uuid | | uuid_ops | yes
 hash | xid | | xid_ops | yes
 hash | xid8 | | xid8_ops | yes
(46 rows)

Lors de l’élaboration du partitionnement par hachage, la communauté a étendu les fonctions d’appui en proposant que la valeur hachée soit encodée sur 64 bits (bigint) et mélangée par salage. Dans le cas du type uuid, la fonction d’appui est uuid_hash_extended pour laquelle le deuxième argument vaut HASH_PARTITION_SEED en dur dans le code de PostgreSQL.

demo=# \dAp hash uuid*
 List of support functions of operator families
 AM | Operator family | Left type | Right type | Number | Function
------+-----------------+-----------+------------+--------+--------------------
 hash | uuid_ops | uuid | uuid | 1 | uuid_hash
 hash | uuid_ops | uuid | uuid | 2 | uuid_hash_extended

demo=# \df uuid_hash*
 List of functions
 Schema | Name | Result data type | Argument data types | Type
------------+--------------------+------------------+---------------------+------
 pg_catalog | uuid_hash | integer | uuid | func
 pg_catalog | uuid_hash_extended | bigint | uuid, bigint | func

Pour bien me rendre compte de la bonne utilisation d’une fonction d’appui pour le hachage d’une colonne particulière, j’ajoute à mon catalogue une nouvelle fonction uuid_hash_noseed qui repose sur la méthode classique uuid_hash sans salage.

CREATE OR REPLACE FUNCTION uuid_hash_noseed(value uuid, seed bigint)
 RETURNS bigint AS $$
SELECT abs(uuid_hash(value));
$$ LANGUAGE sql IMMUTABLE;

CREATE OPERATOR CLASS uuid_noseed_ops FOR TYPE uuid
 USING hash AS
 OPERATOR 1 =,
 FUNCTION 2 uuid_hash_noseed(uuid, bigint);

Le nouvel opérateur uuid_noseed_ops est défini pour utiliser la fonction créée précédemment en spécifiant le numéro d’appui 2, correspondant à la génération d’un hash encodé sur 64 bits (doc) requis pour le partitionnement. Pour valider mes hypothèses sur la distribution des lignes en fonction de leur reste de division, je crée une table t2 avec une clé primaire au format uuid dans laquelle je sépare les valeurs de hash paires et impaires.

CREATE TABLE t2 (
 tid uuid PRIMARY KEY
) PARTITION BY HASH (tid uuid_noseed_ops);

CREATE TABLE t2_0_2 PARTITION OF t2
 FOR VALUES WITH (modulus 2, remainder 0);

CREATE TABLE t2_1_2 PARTITION OF t2
 FOR VALUES WITH (modulus 2, remainder 1);

INSERT INTO t2
SELECT gen_random_uuid() FROM generate_series(1, 1e6) g;
-- INSERT 0 1000000

La suite de mon expérience m’a mené un peu plus loin que ce que j’imaginais à l’origine. Même en l’absence d’un salage avec la constante HASH_PARTITION_SEED, une autre opération au cœur de la méthode de hachage survient : hash_combine64().

/*
 * Combine two 64-bit hash values, resulting in another hash value, using the
 * same kind of technique as hash_combine(). Testing shows that this also
 * produces good bit mixing.
 */
static inline uint64
hash_combine64(uint64 a, uint64 b)
{
 /* 0x49a0f4dd15e5a8e3 is 64bit random data */
 a ^= b + UINT64CONST(0x49a0f4dd15e5a8e3) + (a << 54) + (a >> 7);
 return a;
}

Ce salage supplémentaire est fiable pour le sous-partitionnement, où l’on souhaite obtenir un hachage de plusieurs colonnes pour établir la distribution des lignes dans les partitions. Dans mon cas de test, puisque ma clé de partitionnement est seule, l’opération ne fait que commuter les bits du résultat. Ce constat avait été partagé entre deux développeurs, ce qui m’a donné la requête finale ci-dessous afin de retrouver le reste de division et de le comparer avec les noms de partitions de ma table t2.

SELECT tid, tableoid::regclass partname,
 (uuid_hash_noseed(tid, 0)::bit(64) # x'49a0f4dd15e5a8e3')::bigint % 2
 AS remainder
 FROM t2 ORDER BY tid LIMIT 10;

 tid | partname | remainder
--------------------------------------+----------+-----------
 000012e3-bf3e-4895-8dc4-adf25649680a | t2_0_2 | 0
 00003fd4-b941-4c49-afcb-6449f2ddd169 | t2_1_2 | 1
 000068b2-ce2d-4e13-9586-1ad986d31737 | t2_0_2 | 0
 00006999-696e-4c15-ac94-d1de23b89c73 | t2_1_2 | 1
 000085cb-e666-4ecb-a886-09ae86fc7d55 | t2_1_2 | 1
 00008675-2291-4c49-afd1-4b55ccbd50c1 | t2_0_2 | 0
 0000c8a1-a0fb-4e53-882d-ed9c11aba44c | t2_1_2 | 1
 0000d1fd-759a-47c5-8e87-284455b36478 | t2_0_2 | 0
 0000d3af-64da-427c-815d-b7d32f62d7a6 | t2_1_2 | 1
 0000f608-f4a2-43dd-8483-94bb317e0c95 | t2_0_2 | 0

Conclusion

Avec l’apparition du partitionnement par hachage, PostgreSQL s’est doté d’une nouvelle méthode permettant de bénéficier de tous les avantages du partitionnement déclaratif sans se soucier de la distribution logique des valeurs de la clé de partitionnement.

Bien que l’élagage de partition lors de la planification ne soit pas l’objectif de la manœuvre puisque la clé de partitionnement est par nature indexée, il devient très intéressant de bénéficier notamment d’une maintenance par VACUUM accélérée en subdivisant les données et les index sur le disque. La distribution des opérations de lecture et d’écriture sur plusieurs disques à l’aide des tablespaces est également possible depuis la version 12 et apporte son lot de solutions pour les tables très volumineuses.

Comprendre les requêtes préparées

Florent Jardin — Tue, 30 Mar 2021 00:00:00 +0000

Les requêtes ou instructions préparées sont un mécanisme proposé par la plupart des moteurs de bases de données afin de réexécuter un ordre SQL semblable au précédent. On parle d’un template de requête qu’il est nécessaire de préparer avant d’exécuter. Les principaux bénéfices que nous lui connaissons méritent un article afin de mieux comprendre leur implémentation.

Parse-Bind-Execute

Au cours de sa vie, tout bon artisan du Web finit par découvrir les ravages des attaques par injection SQL, soit par la sagesse de leurs mentors, soit par la douloureuse expérience du terrain. Bien que les nombreuses couches d’abstraction les rendent aujourd’hui inopérantes grâce aux échappements ou à la validation des données en entrée, ces attaques sont encore possibles dès que la requête est écrite en pur SQL.

Source : https://xkcd.com/327

L’une des meilleures approches pour éviter ces attaques, repose sur la séparation des requêtes et de leurs paramètres au moment de leur exécution. L’instruction, dite préparée, est ainsi intégralement analysée et le positionnement des valeurs est connu à l’avance. Toute tentative d’injection est réduite à néant.

PREPARE get_notation(text, text) AS
 SELECT id, exam, notation FROM students
 WHERE lastname = $1 AND firstname = $2;

EXECUTE get_notation('Pattinson', $$Robert' ; DROP TABLE students;--$$);
-- (0 rows)

L’exemple précédent utilise les ordres SQL PREPARE et EXECUTE mais ce n’est pas la seule façon de déclarer une instruction préparée. En effet, il existe à ce sujet le sous-protocole Extended Query décrit dans la documentation sur les flux de messages. La communication client-serveur se découpe en trois messages afin de garantir la prise en compte des paramètres à inclure dans une instruction préparée, sans risque d’injection.

Parse : l’instruction SQL et éventuellement un nom et un typage pour les paramètres ;
Bind : les valeurs à positionner dans l’instruction préparée donnée ;
Execute : déclenche la lecture du curseur ouvert sur le serveur.

Il est donc de la responsabilité du pilote ou du connecteur fourni avec le langage ou le framework de son choix, de proposer les méthodes de communication qui s’appuient sur le bon protocole étendu. En C et avec la libpq par exemple (doc), la déclaration d’une instruction préparée se réalise avec la méthode PQprepare et l’exécution avec PQexecPrepared.

Côté serveur, si l’on étend la verbosité des traces d’activité avec les paramètres log_parser_stats, log_planner_stats, log_executor_stats et log_min_duration_statement, il est possible d’identifier les étapes citées plus haut avec l’exécution d’une requête préparée par pgbench, nommée P0_1.

-- Message PARSE
LOG: PARSER STATISTICS
LOG: PARSE ANALYSIS STATISTICS
LOG: REWRITER STATISTICS
LOG: duration: 1.284 ms
 parse P0_1: SELECT abalance FROM pgbench_accounts WHERE aid = $1;

-- Message BIND
LOG: PLANNER STATISTICS
LOG: duration: 1.211 ms
 bind P0_1: SELECT abalance FROM pgbench_accounts WHERE aid = $1;
DETAIL: parameters: $1 = '1600439'

-- Message EXECUTE
LOG: EXECUTOR STATISTICS
LOG: duration: 4.170 ms
 execute P0_1: SELECT abalance FROM pgbench_accounts WHERE aid = $1;
DETAIL: parameters: $1 = '1600439'

Quand un plan générique se déroule sans accroc

Cependant, la sécurité contre les injections n’est pas mise en avant dans la documentation de PostgreSQL au sujet de PREPARE. Et pour cause, depuis son implémentation dans la version 7.3, cette méthode repose sur des mécanismes profonds pour optimiser les performances d’une requête lorsqu’elle est exécutée un certain nombre de fois.

Les instructions préparées sont principalement intéressantes quand une seule session est utilisée pour exécuter un grand nombre d’instructions similaires. La différence de performances est potentiellement significative si les instructions sont complexes à planifier ou à réécrire, par exemple, si la requête implique une jointure de plusieurs tables ou requiert l’application de différentes règles. Si l’instruction est relativement simple à planifier ou à réécrire mais assez coûteuse à exécuter, l’avantage de performance des instructions préparées est moins net.

Source : https://docs.postgresql.fr/13/sql-prepare.html

Avec PostgreSQL, chaque requête passe par une succession d’étapes pour obtenir le résultat final. Ce fonctionnement permet de qualifier la transformation d’une étape à une autre en s’assurant par ailleurs que la syntaxe est bonne ou qu’un chemin optimisé puisse être emprunté.

Le parser vérifie la syntaxe de l’instruction, ouvre une transaction pour réaliser l’analyse sémantique auprès des relations voulues ;
Le rewriter réalise les transformations nécessaires en fonction des règles telle que la définition d’une vue ou d’une fonction ;
Le planner (ou planificateur) sélectionne le plan d’exécution le moins coûteux en fonction des régles d’accès et des estimations connues ;
L’executor suit les consignes du plan d’exécution et consolide le résultat final à retourner au client.

Les étapes d’analyse d’une instruction lors des messages Parse et Bind ont un coût : il est nécessaire de valider la syntaxe, réécrire les jointures si besoin et surtout, construire le plan d’exécution. Par défaut, une série de plans sera construit avant que le moteur n’en retienne qu’un seul dont le coût est bon compromis avec la moyenne des cinq premiers. Ce plan devient le plan générique et sera réutilisé au sein de la même session pour toutes les exécutions de l’instruction préparée.

L’utilisation de ce plan d’exécution unique devient la clé pour économiser quelques précieuses millisecondes d’analyse à chaque nouveau message Execute. Si je reprends l’exemple de Bobby et de la table students, on observe un gain significatif au bout de la cinquième ou sixième exécution avec un temps de planification (Planning Time) quasi-nul.

EXPLAIN (ANALYZE)
EXECUTE get_notation('Pattinson', 'Robert');

-- QUERY PLAN
-- -------------------------------------------------------------------------------
-- Index Scan using students_lastname_firstname_idx on students
-- (cost=0.29..6.06 rows=1 width=13) (actual time=0.027..0.029 rows=1 loops=1)
-- Index Cond: ((lastname = 'Pattinson'::text) AND (firstname = 'Robert'::text))
-- Planning Time: 0.235 ms
-- Execution Time: 0.071 ms
-- ...
-- Planning Time: 0.225 ms
-- Execution Time: 0.090 ms
-- ...
-- Planning Time: 0.323 ms
-- Execution Time: 0.081 ms
-- ...
-- Planning Time: 0.249 ms
-- Execution Time: 0.074 ms
-- ...
-- Planning Time: 0.218 ms
-- Execution Time: 0.068 ms
-- ...
-- Planning Time: 0.232 ms
-- Execution Time: 0.068 ms
-- ...
-- Planning Time: 0.040 ms
-- Execution Time: 0.091 ms
-- ...
-- Planning Time: 0.036 ms
-- Execution Time: 0.089 ms

Depuis la version 12 de PostgreSQL, il est possible de changer le comportement du moteur avec le paramètre plan_cache_mode en forçant l’utilisation du plan générique dès la deuxième exécution (force_generic_plan) ou ne pas l’utiliser du tout (force_custom_plan).

Les dessous du temps de réponse

Pour se convaincre des bénéfices qu’engendre l’utilisation des instructions préparées, j’ai souhaité étudier le comportement d’une même requête SELECT sur la table pgbench_accounts. L’outil pgbench fourni avec le projet PostgreSQL permet de générer une variété de requêtes sur un modèle de données générique.

export PGDATABASE=pgbench
pgbench --initialize --scale=100

La table contient 10 millions de lignes et dispose d’une clé primaire sur laquelle nous estimerons qu’une grande partie des requêtes réalisera ses lectures. J’active également les paramètres pour tracer les statistiques de chacune des étapes citées plus haut, afin d’en savoir plus sur leur durée respective et la répartition du temps de travail entre elles.

PGOPTIONS="-c client_min_messages=log"
PGOPTIONS="$PGOPTIONS -c log_parser_stats=on"
PGOPTIONS="$PGOPTIONS -c log_planner_stats=on"
PGOPTIONS="$PGOPTIONS -c log_executor_stats=on"
export PGOPTIONS

Ces informations statistiques de l’ensemble des requêtes de pgbench sont redirigées de la sortie d’erreurs vers une routine awk qui agrège les temps de traitement. Dans cette démonstration, le paramètre plan_cache_mode est positionné sur auto, sa valeur par défaut.

Exécution sans préparation

pgbench --protocol=simple --select-only --transactions=10000 \
2>&1 >/dev/null | awk '
 /STATISTICS/ { $1="" ; k=$0 }
 /elapsed/ { stats[k]+=$8 ; count[k]+=1 ; total+=$8 }
 END { for (s in stats) printf "%s: %1.3f ms\n", s, stats[s]*1000 }
 END { printf " -- TOTAL: %1.3f ms\n", total*1000 }'

 EXECUTOR STATISTICS: 163.910 ms
 PARSE ANALYSIS STATISTICS: 57.493 ms
 PLANNER STATISTICS: 163.451 ms
 PARSER STATISTICS: 37.018 ms
 REWRITER STATISTICS: 13.753 ms
 -- TOTAL: 435.625 ms

Exécution avec préparation

pgbench --protocol=prepared --select-only --transactions=10000 \
2>&1 >/dev/null | awk '
 /STATISTICS/ { $1="" ; k=$0 }
 /elapsed/ { stats[k]+=$8 ; count[k]+=1 ; total+=$8 }
 END { for (s in stats) printf "%s: %1.3f ms\n", s, stats[s]*1000 }
 END { printf " -- TOTAL: %1.3f ms\n", total*1000 }'

 EXECUTOR STATISTICS: 157.778 ms
 PARSE ANALYSIS STATISTICS: 0.746 ms
 PLANNER STATISTICS: 1.146 ms
 PARSER STATISTICS: 0.129 ms
 REWRITER STATISTICS: 0.031 ms
 -- TOTAL: 159.830 ms

Rapporté à une exécution unitaire, la répartition des temps de traitement entre les phases de préparation et d’exécution est sans surprise. Alors que le temps de préparation (Parse, Rewrite, Plan) est supérieur au temps d’exécution pour des instructions non préparées, il s’annule intégralement sur un volume de plusieurs milliers de requêtes exécutées dans la même session avec l’utilisation d’un plan générique.

Le graphique ci-dessus reprend les temps moyens de chaque étape d’une requête unitaire à l’issue d’une vingtaine de traitements pgbench pour 10 000 transactions.

Pour aller plus loin

Que ce soit pour se protéger des injections ou pour atteindre de hautes performances, j’ai voulu montrer dans cet article qu’il pouvait être bénéfique de préparer ses requêtes, d’autant plus si votre librairie préférée le supporte. Si vous êtes à la recherche de temps de réponse les plus faibles possibles, posez-vous les questions suivantes :

Mes requêtes ont-elles fréquemment la même forme ?
Leurs plans d’exécution sont-ils relativement bien optimisés ?
Mon application gère-t-elle la persistance des connexions ?

Si vous rentrez dans ces cases, vous gagnerez de précieuses millisecondes avec un plan générique au sein d’une même session. Dans le cas où la persistance des connexions n’est pas votre fort, il est possible de coupler PgBouncer avec l’extension preprepare pour définir un ensemble d’instructions préparées dès l’ouverture de la session.

Tour d'horizon de PgBouncer

Florent Jardin — Fri, 21 Aug 2020 00:00:00 +0000

Les programmes de regroupement de connexions (pooling) vous permettent de réduire la surcharge liée à la base de données lorsque le nombre de connexions physiques réduit les performances. Ceci est particulièrement pertinent sous Windows, où les limitations du système empêchent un grand nombre de connexions. C’est également vital pour les applications Web où le nombre de connexions peut devenir très important.

(Source : https://wiki.postgresql.org)

Je n’ai pas trouvé meilleure approche que la traduction du wiki communautaire du projet PostgreSQL pour aborder l’outil PgBouncer, faisant partie avec Pgpool-II, des deux seuls poolers de connexions largement répandus. Le produit est déconcertant de facilité, sa documentation et la littérature qui gravitent sur Internet sont claires et unanimes : PgBouncer améliorera grandement les performances de votre instance PostgreSQL !

Dans cet article, je vous propose un rapide aperçu de PgBouncer avec quelques cas possibles d’utilisation. Nous parlerons aussi du récent support de l’authentification SCRAM et comment le configurer sans effort.

Théorie, ma vieille amie

Depuis ses origines, le fonctionnement de PostgreSQL repose sur le modèle client/serveur multi-processus, c’est-à-dire que chaque processus aura une tâche définie et une zone mémoire qui lui est propre. Ce modèle s’oppose à l’architecture multi-thread dans laquelle un processus peut être partagé par plusieurs instructions indépendantes et présenterait des risques de corruptions de mémoire.

Ainsi, pour chaque demande de connexion vers l’instance, le processus principal postgres se charge de l’authentification avant de créer un nouveau processus backend qui maintiendra le lien entre les deux parties et assurera l’aboutissement des commandes du processus client, appelé frontend. Le backend ne sera libéré qu’à la déconnexion de la session utilisateur, comme l’illustre le schéma ci-après.

Cependant, l’établissement de la connexion n’est pas une opération anodine. Les coûts des échanges à travers le réseau, de création d’un processus, de l’allocation de sa mémoire et du paramétrage de la session, représenteraient une poignée de millisecondes.

Comme indiqué en préambule, les applications critiques telles que celles du e-commerce requièrent des temps de réponses les plus faibles possibles, avec des exigences de l’ordre d’une centaine de millisecondes par appel de page, contenant elles-mêmes des centaines de requêtes… C’est à ce moment-là que PgBouncer entre en jeu.

Le schéma précédent évolue avec le pooler de connexions entre les connexions clientes et l’instance de base de données. Le processus pgbouncer est donc responsable des demandes entrantes et se comporte comme un proxy, qu’il soit sur le serveur hébergeant les données, sur les serveurs frontaux ou même sur un serveur tiers, dédié à ces redirections.

PgBouncer ne présente qu’une faible empreinte mémoire équivalente à 2 ko par connexion et repose sur un binaire et un fichier de configuration. L’outil gère des pools de connexions par bases de données ou par rôles (ou les deux) et maintient un certain nombre de connexions actives vers l’instance pour les recycler en cas d’arrivée de nouveaux frontends.

La configuration est extrêmement simple et épurée, et ne devrait rebuter personne. Par exemple, en supposant que l’instance PostgreSQL écoute localement sur le port 5433 et dispose d’une base data1, nous cherchons à définir un pool de 5 à 50 backends avec un délai de 30 secondes d’inactivité avant la déconnexion réelle au serveur. Le fichier de configuration suivant est alors parfaitement adapté :

[pgbouncer]
listen_addr = demo.priv
listen_port = 5432
auth_file = userlist.txt
server_idle_timeout = 30
min_pool_size = 5

[database]
data1 = host=localhost port=5433 dbname=data1 pool_size=50

Chérie, tu as les clés ?

Puisque PgBouncer fait office de proxy entre les applications et les bases de données en respectant le protocole de connexion, il lui revient d’assurer la validation des mots de passe de chaque nouvelle demande entrante. L’implémentation des différentes méthodes telles que md5 ou scram-sha-256 se trouve dans le fichier src/proto.c(source) et garantit qu’une demande de connexion réalisée sur l’interface de PgBouncer soit bien légitime et autorisée auprès de l’instance.

Fichier auth_file

À ce sujet, l’outil propose deux solutions pour vérifier un mot de passe. La plus basique consiste à renseigner un fichier (ou auth_file) avec les couples login/password qui seront consultés à chaque demande, et les comparer avec les éléments de l’utilisateur. Les données doivent être identiques aux informations stockées dans l’instance PostgreSQL, plus précisément dans la relation système pg_authid, ou historiquement pg_shadow.

SET password_encryption = 'scram-sha-256';
CREATE ROLE frontend PASSWORD 'pass' LOGIN;
SELECT rolpassword FROM pg_authid WHERE rolname = 'frontend' \gx

-- -[ RECORD 1 ]----------------------------------------------------
-- rolpassword | SCRAM-SHA-256$4096:e2iH7Tv/XJrD0bxiSNt4yA==$Pxhbz2…

L’ajout d’une nouvelle ligne dans le fichier userlist.txt nécessite uniquement de prendre soin d’entourer chaque mot par des guillemets doubles. PgBouncer surveillera alors son contenu afin de disposer des bonnes informations à tout moment.

# userlist.txt 
"frontend" "SCRAM-SHA-256$4096:e2iH7Tv/XJrD0bxiSNt4yA==$Pxhbz2…"

Délégation auth_user

Si la maintenance d’un tel fichier s’avère complexe pour quelque raison que ce soit, il est possible de déléguer un rôle à la consultation de la table pg_authid directement dans l’instance, en précisant le paramètre auth_user. Le paramètre auth_query définit la requête à exécuter pour ensuite comparer les résultats avec les identifiants de connexion. Cette requête repose sur la vue pg_shadow mais de nombreuses variantes sont possibles, comme une requête plus élaborée sur pg_authid ou une fonction qui dispose des bons droits de consultation avec la clause SECURITY DEFINER comme le suggère la documentation.

Le support de la méthode d’authentification par SCRAM est arrivé avec la version PgBouncer 1.14 en juin 2020. Le mot de passe chiffré avec SCRAM ne peut pas être utilisé pour de la délégation de connexion, tel que le propose le paramètre auth_user. L’un des contournements consiste à hacher le mot de passe en md5 pour le rôle de délégation.

SET password_encryption = 'md5';
CREATE ROLE admin SUPERUSER PASSWORD 'pass' LOGIN;
SELECT rolpassword FROM pg_authid WHERE rolname = 'admin' \gx

-- -[ RECORD 1 ]------------------------------------
-- rolpassword | md57a25b0bc04e77a2f7453dd021168cdc2

Le fichier userlist.txt ne contiendra donc qu’une seule ligne pour le rôle admin défini comme auth_user dans la configuration PgBouncer.

# userlist.txt 
"admin" "md57a25b0bc04e77a2f7453dd021168cdc2"

[pgbouncer]
listen_addr = demo.priv
listen_port = 5432

auth_type = scram-sha-256
auth_file = userlist.txt
auth_user = admin
;auth_query = SELECT usename, passwd FROM pg_shadow WHERE usename=$1

[database]
data1 = host=localhost port=5433 dbname=data1

Côté client, l’illusion est parfaite ! Le rôle frontend se connecte à l’instance sans besoin d’ajouter ses identifiants dans le fichier userlist.txt.

$ psql "host=priv.demo dbname=data1 user=frontend"
Password for user frontend:
psql (12.4)
Type "help" for help.

data1=> \conninfo
You are connected to database "data1"
 as user "frontend" on host "priv.demo" at port "5432".

Vers l’infini et au-delà

PgBouncer est un outil à connaître et à déployer sans modération pour la recherche de performance. Il se couple parfaitement bien avec une configuration HAProxy pour une architecture de haute-disponibilité si le besoin se fait sentir. Le support de l’authentification SCRAM est une excellente avancée, alors que la communauté se décide de la définir comme un standard pour les prochaines versions majeures de PostgreSQL.

D’autres fonctionnalités essentielles n’ont volontairement pas été abordées dans cet article, comme le pooling de transactions et le paramètre pool_mode, ou simplement la pseudo-base pgbouncer qui joue le rôle de console d’administration très fournie en informations sur les pools et sessions actives. Gageons que j’y passe plus de temps à l’avenir pour vous les présenter !

Les statistiques au service du plan d'exécution

Florent Jardin — Wed, 01 Jul 2020 20:30:00 +0200

La lecture d’un plan d’exécution fait partie des meilleures armes du développeur et de l’administrateur de bases de données pour identifier les problèmes de performances. Dans un précédent article, je présentais l’intérêt de positionner un index sur les colonnes d’une table pour faciliter les recherches, notamment avec l’aide de la commande EXPLAIN.

À cette époque, je ne m’étais pas attardé sur la notion des statistiques de données, que l’on retrouve dans la plupart des moteurs du marché. Voyons de plus près ce que propose PostgreSQL pour garantir les performances de vos requêtes.

Estimer ou ne pas estimer

Une statistique de données résulte d’un calcul en arrière plan sur tout ou partie des données d’une table. Il peut s’agir de la quantité de lignes, du nombre distinct de valeurs dans une colonne, ou bien encore de la distribution des valeurs sous forme d’histogramme. Ainsi, pour chaque table et chaque colonne, il existe des données supplémentaires qui permettent au moteur d’avoir une juste estimation des données qu’il s’apprête à manipuler.

Prenons la table pgbench_history sur laquelle j’ai ajouté un index pour la colonne aid. Quel plan nous propose le moteur pour récupérer toutes les lignes dont la valeur aid est inférieure à 1 000 ?

EXPLAIN SELECT * FROM pgbench_history WHERE aid < 1000;

 QUERY PLAN
--------------------------------------------------------
 Bitmap Heap Scan on pgbench_history
 (cost=4.34..11.79 rows=9 width=116)
 Recheck Cond: (aid < 1000)
 -> Bitmap Index Scan on pgbench_history_aid_idx
 (cost=0.00..4.34 rows=9 width=0)
 Index Cond: (aid < 1000)

Le résultat qui s’affiche correspond au meilleur plan connu et repose sur un système de coût d’accès aux lignes. Le plan présentant le coût le plus faible est considéré comme le meilleur plan ; l’ensemble des nœuds le composant sera donc respecté pour récupérer le résultat final. Dans le cas de notre requête, le moteur estime que les opérations Bitmap Index et Bitmap Heap sont les moins coûteuses en performance.

Comment le moteur peut-il être certain que ce plan est le moins coûteux ? Comparons son coût d’accès total (ici 11.79) avec un autre plan pour lequel nous interdisons l’usage de l’index.

SET enable_bitmapscan = off;
EXPLAIN SELECT * FROM pgbench_history WHERE aid < 1000;

 QUERY PLAN
------------------------------------------------------------------
 Seq Scan on pgbench_history (cost=0.00..19.50 rows=9 width=116)
 Filter: (aid < 1000)

Le coût de lecture complète de la table (nœud Seq Scan) vaut 19.50, ce qui est supérieur au plan précédent. Lorsque l’on exécute un requête SQL, une partie du moteur, appelé le planificateur consolide en arrière plan une petite quantité de plans avant de ne retourner que le meilleur. Plusieurs paramètres comme enable_bitmapscan, peuvent changer complètement le comportement du planificateur en réduisant le nombre de choix possibles dans l’élaboration de ses plans.

En complément du coût, la commande EXPLAIN indique également l’estimation du nombre de lignes que retourneront les nœuds. Dans le cas des deux plans, le planificateur estime qu’il existe 9 lignes répondant au critère de recherche. Cette statistique peut être déduite des vues système pg_class et pg_stats.

SELECT s.*, c.relpages, c.reltuples
 FROM pg_stats s JOIN pg_class c ON s.tablename = c.relname
 WHERE tablename = 'pgbench_history' AND attname = 'aid' \gx

-[ RECORD 1 ]----------+------------------------------------
schemaname | public
tablename | pgbench_history
attname | aid
inherited | f
null_frac | 0
avg_width | 4
n_distinct | -0.997
most_common_vals | {66403,80979,82766}
most_common_freqs | {0.002,0.002,0.002}
histogram_bounds | {75,973,1755,… ,98037,98999,99991}
correlation | 0.047431067
most_common_elems |
most_common_elem_freqs |
elem_count_histogram |
relpages | 7
reltuples | 1000

Sans même consulter le contenu de la table pgbench_history, nous sommes en possession d’informations intéressantes. Nous apprenons que la table contient exactement 1 000 lignes (reltuples) et que la colonne aid présente un nombre de valeurs distinctes (n_distinct) qui tend vers -1, c’est-à-dire autant de valeurs uniques que de lignes dans la table.

La distribution des valeurs de la colonne aid est représentée par le tableau histogram_bounds de 100 éléments. Ces bornes divisent approximativement les valeurs dans des groupes de même taille ; comprendre que 1 % des lignes ont une valeur de colonne aid comprise entre 75 et 972, 1 % des lignes, entre 973 et 1 754, etc. On peut dès lors supposer que les valeurs possibles de la colonne aid s’étendent de 75 à 99 991.

Si l’on revient à notre critère de recherche, les lignes dont la valeur aid est inférieure à 1 000 représenteraient un peu plus de 1 % des 1000 lignes de la table, soit environ 10 lignes si toutes les valeurs étaient distinctes. L’estimation de 9 lignes proposée par la commande EXPLAIN serait donc juste.

La documentation du projet détaille en profondeur le calcul de ces estimations avec de nombreux exemples : How the Planner Uses Statistics: Row Estimation Examples.

Tout l’intérêt des statistiques est donc d’apporter suffisamment d’éléments précalculés et économes en espace disque pour que le planificateur puisse faire des estimations les plus justes possibles. Dès lors qu’une estimation est calculée, le choix du plan d’exécution le moins coûteux devient évident. Retenons que le meilleur plan doit être le moins coûteux en ressources et donc, le plus optimisé pour la requête SQL.

Qu’advient-il de notre plan si, par erreur ou hasard, les statistiques étaient erronées ou venaient à disparaître pour la colonne aid ?

DELETE FROM pg_statistic s
 WHERE starelid = 'pgbench_history'::regclass AND staattnum = (
 SELECT attnum FROM pg_attribute
 WHERE attrelid = s.starelid AND attname = 'aid'
 );

RESET enable_bitmapscan;
EXPLAIN SELECT * FROM pgbench_history WHERE aid < 1000;

 QUERY PLAN
--------------------------------------------------------------------
 Seq Scan on pgbench_history (cost=0.00..19.50 rows=333 width=116)
 Filter: (aid < 1000)

On constate qu’en l’absence de statistiques sur le critère de sélection, le plan Bitmap n’est plus le moins coûteux et n’est donc plus proposé par le planificateur. Le moteur privilégera la lecture complète de la table (Seq Scan) dont le coût est invariant.

SET enable_seqscan = off;
EXPLAIN SELECT * FROM pgbench_history WHERE aid < 1000;

 QUERY PLAN
--------------------------------------------------------
 Bitmap Heap Scan on pgbench_history
 (cost=10.86..22.02 rows=333 width=116)
 Recheck Cond: (aid < 1000)
 -> Bitmap Index Scan on pgbench_history_aid_idx
 (cost=0.00..10.77 rows=333 width=0)
 Index Cond: (aid < 1000)

L’estimation de lignes retournées peut paraître surprenante ! Il s’agit d’un calcul arbitraire défini dans la classe selfuncs.h (source) avec notamment un facteur de sélectivité qui s’applique sur le nombre total de lignes présentes dans la table. Ainsi, pour un critère d’égalité, ce facteur vaudra 0.5 % (DEFAULT_EQ_SEL=0.005) alors qu’une comparaison de non-égalité comme celle de notre exemple, vaudra 33.33 % (DEFAULT_INEQ_SEL=0.3333333333333333).

Puisque le planificateur estime devoir parcourir 333 entrées dans l’index à défaut de meilleure estimation, le coût total de ce plan est surévalué à 22.02, au lieu de 11.79 auparavant.

Collecte automatique des statistiques

Bien entendu, supprimer des statistiques n’est pas une bonne pratique et ne devrait pas être envisagé pour « changer le comportement » du planificateur. Depuis la version 8.3 de PostgreSQL, il n’y a même plus trop de raison de s’inquiéter de l’absence ou de la fraîcheur des statistiques associées à chaque colonne de vos tables : le processus autovacuum (désactivé en 8.1 et 8.2) se charge, entre autres fonctions, de parcourir régulièrement les tables de vos bases pour collecter et consolider la table pg_statistic. Il se porte ainsi garant de la pertinence des plans d’exécution.

En réalité, ce processus observe les variations de volumétrie des tables avant de déclencher l’opération ANALYZE par un processus de maintenance pour cette table. Ce mécanisme est bien plus pertinent et optimisé qu’une exécution à intervale régulier pour calculer arbitrairement les statistiques de la base.

Le seuil de déclenchement de l’autoanalyze est obtenu à l’aide d’un calcul trivial impliquant deux paramètres globaux que l’on peut surcharger, autovacuum_analyze_threshold = 50 et autovacuum_analyze_scale_factor = 0.1.

analyze threshold = analyze base threshold +
 analyze scale factor * number of tuples

Prenons l’exemple de la table pgbench_accounts qui contient un million de lignes avec une contrainte de clé primaire sur la colonne aid. La vue système pg_stat_user_tables dispose d’informations complémentaires à celles des statistiques, notamment la colonne n_mod_since_analyze qui indique la quantité de tuples ayant été modifiés depuis la dernière opération de collecte ANALYZE. Voyons son contenu après la modification d’une portion de lignes.

UPDATE pgbench_accounts SET filler = '' WHERE aid <= 10000;
-- UPDATE 10000

SELECT relname, last_autoanalyze, n_live_tup, n_mod_since_analyze
 FROM pg_stat_user_tables u
 WHERE relname = 'pgbench_accounts' \gx

-[ RECORD 1 ]-------+------------------------------
relname | pgbench_accounts
last_autoanalyze | 2020-06-18 15:12:55.224493+02
n_live_tup | 1000000
n_mod_since_analyze | 10000

Ici, seul 1 % de la table a subi un changement et le mécanisme de collecte automatique des statistiques semble ne pas s’être déclenché. En effet, le seuil de déclenchement pour cette table serait plutôt de 100 050 lignes (50 + 0.1 * 1000000). Recommençons avec un plus large échantillon et observons les traces d’activité du processus autovacuum.

ALTER SYSTEM SET log_min_messages = debug2;
ALTER SYSTEM SET log_autovacuum_min_duration = 0;
SELECT pg_reload_conf();

UPDATE pgbench_accounts SET filler = '' WHERE aid <= 90051;
-- UPDATE 90051

SELECT relname, last_autoanalyze, n_live_tup, n_mod_since_analyze
 FROM pg_stat_user_tables u
 WHERE relname = 'pgbench_accounts' \gx

-[ RECORD 1 ]-------+------------------------------
relname | pgbench_accounts
last_autoanalyze | 2020-06-30 17:44:22.424363+02
n_live_tup | 1000000
n_mod_since_analyze | 0

Comme attendu, un traitement ANALYZE s’est exécuté et a mis à jour les données de la vue pg_stat_user_tables, mettant à zéro la colonne n_mod_since_analyze jusqu’au prochain déclenchement. Côté trace d’activité, le mode debug2 écrit une série d’événements tels que les seuils calculés de la table, le démarrage et la fin du traitement par le worker dédié.

DEBUG: autovacuum: processing database "demo"
DEBUG: pgbench_accounts: vac: 100051 (threshold 200050),
 anl: 100051 (threshold 100050)
DEBUG: analyzing "public.pgbench_accounts"
LOG: automatic analyze of table "demo.public.pgbench_accounts"
 system usage: CPU: user: 0.09 s, system: 0.00 s, elapsed: 0.25 s

Estimer la prochaine heure de la collecte

Dans la plupart des cas, les paramètres associés au mécanisme d’autovacuum sont adaptés à la plupart des tables et assurent une fréquence correcte du calcul des statistiques. Cependant, au-delà d’une certaine volumétrie, une table peut présenter des incohérences entre son contenu et ses statistiques.

La modification de 10 % de la table pgbench_accounts pourrait prendre des jours voire des semaines avant que ne survienne le traitement autoanalyze. Il est donc de la responsabilité du développeur ou du DBA de surveiller l’accroissement de l’indicateur n_mod_since_analyze pour éviter que les statistiques ne soient trop décorrélées du contenu.

Pour s’en assurer, je crée deux fonctions dans ma base pour récupérer respectivement les options de stockage d’une table (reloptions) ou à défaut, les paramètres d’instance, ainsi que le calcul du seuil de déclenchement sur la base de la formule précédente. La seconde fonction s’assure notamment que le mécanisme de collecte automatique n’est pas désactivé (autovacuum_enabled = off).

CREATE OR REPLACE FUNCTION get_reloption(reloptions text[], name text)
RETURNS text LANGUAGE sql
AS $$
 SELECT coalesce(min(option_value), current_setting(name))
 FROM pg_options_to_table(reloptions) WHERE option_name = name;
$$;

CREATE OR REPLACE FUNCTION get_anl_threshold(o oid)
RETURNS float LANGUAGE sql
AS $$
 SELECT get_reloption(reloptions, 'autovacuum_analyze_threshold')::int +
 get_reloption(reloptions, 'autovacuum_analyze_scale_factor')::float *
 c.reltuples
 FROM pg_class c
 WHERE oid = o AND NOT EXISTS (
 SELECT 1 FROM pg_options_to_table(c.reloptions)
 WHERE option_name = 'autovacuum_enabled' AND option_value = 'off'
 )
$$;

Avec les résultats de ces fonctions, je peux construire une requête plus évoluée qui estime l’heure du prochain déclenchement en fonction de nombre de modification et de la dernière collecte.

SELECT relname, n_live_tup, n_mod_since_analyze,
 get_anl_threshold(relid) threshold, last_autoanalyze,
 current_timestamp +
 (1 -
 CASE WHEN n_mod_since_analyze = 0 THEN null
 WHEN n_mod_since_analyze > get_anl_threshold(relid) THEN 1
 ELSE n_mod_since_analyze / get_anl_threshold(relid) END) *
 (current_timestamp - last_autoanalyze) next_autoanalyze
FROM pg_stat_user_tables WHERE relname = 'pgbench_accounts' \gx

-[ RECORD 1 ]--------+------------------------------
relname | pgbench_accounts
n_live_tup | 1000000
n_mod_since_analyze | 0
threshold | 100050
last_autoanalyze | 2020-07-01 15:07:40.134444+02
next_autoanalyze |

UPDATE pgbench_accounts SET filler = '' WHERE aid <= 25000;
-- UPDATE 25000

-[ RECORD 1 ]--------+------------------------------
relname | pgbench_accounts
n_live_tup | 1000000
n_mod_since_analyze | 25000
threshold | 100050
last_autoanalyze | 2020-07-01 15:07:40.134444+02
next_autoanalyze | 2020-07-01 18:16:43.734491+02

La commande ALTER TABLE suivante permet de modifier les options de stockage de la table, et d’ajuster le seuil du déclenchement automatique de la collecte. À vous de voir si l’activité sur votre table le justifie !

ALTER TABLE pgbench_accounts SET (
 autovacuum_analyze_scale_factor = 0.01,
 autovacuum_analyze_threshold = 0
);

-[ RECORD 1 ]--------+------------------------------
relname | pgbench_accounts
n_live_tup | 1000000
n_mod_since_analyze | 25000
threshold | 10000
last_autoanalyze | 2020-07-01 15:07:40.134444+02
next_autoanalyze | 2020-07-01 17:04:34.038917+02

-[ RECORD 1 ]--------+------------------------------
relname | pgbench_accounts
n_live_tup | 1000000
n_mod_since_analyze | 0
threshold | 10000
last_autoanalyze | 2020-07-01 17:04:41.987032+02
next_autoanalyze |

Conclusion

Les statistiques jouent un rôle essentiel dans les performances d’un moteur relationnel comme PostgreSQL. Réussir à les maintenir pertinentes est la clé dans la gestion au quotidien du système. Avec mon exposé, j’espère vous avoir démontré qu’il n’est pas nécessaire de rafraîchir toutes les statistiques, mais seulement celles dont le seuil n’est plus adapté.

Dans un genre similaire, un récent article de Hubert « depesz » Lubaczewski présente une série de requêtes permettant d’identifier les tables nécessitant une action de maintenance (vacuum ou analyze) dans le cas où la routine automatique ne fait pas correctement son travail. Ce genre de petites astuces peuvent sauver des vies… (euh) des plans d’exécution !

Index décomplexé

Florent Jardin — Fri, 27 Sep 2019 16:00:00 +0200

Index terminologique : permet au lecteur de localiser rapidement un élément dans l’ouvrage, sans être contraint de le lire intégralement. (Wikipédia)

Index de base de données : structure de données qui permet de retrouver rapidement les données. (Wikipédia)

L’usage du même mot n’est pas fortuit. Chacun de ces usages désigne la capacité d’identifier rapidement un mot, un terme (ou plus largement, une donnée) à l’aide d’une adresse, comme un numéro de page, ou l’emplacement de la donnée sur un disque ou un volume. D’une façon purement scolaire, prenons le mécanisme d’indexation le plus simple : celui basé sur le tri alphanumérique. Lorsque l’on parcoure l’index pour retrouver un concept dans un livre, les propositions sont classiquement dressées dans l’ordre alphanumérique de haut en bas, de la page de gauche à la page de droite (pour de la littérature occidentale).

Ainsi, le lecteur peut démarrer sa recherche à partir de la première lettre de son mot, le comparer aux termes triés, recommencer avec la deuxième lettre, etc. jusqu’à identifier le terme voulu ou la racine la plus proche. Le résultat est alors accompagné d’une liste de numéros de pages, dans lesquelles l’auteur du livre a reférencé de lui-même les concepts-clés nécessaires à la recherche par index.

Pour ce qui est d’une base de données dite relationnelle, les informations relatives à une entité (ou objet), seront réparties dans les colonnes d’une ou de plusieurs tables. L’accès aux données est similaire à la recherche d’un mot dans un livre : critère de sélection (un nom de famille, une époque, une jointure, etc.) et un chemin d’accès (le tri alphanumérique pour faire simple).

En SQL, pour obtenir une portion de données non indexées d’une table (la liste des pages mentionnant un mathématicien, par exemple), nous demandons au moteur de parcourir la totalité des lignes et de ne retourner que la sélection voulue. Cette recherche est aussi efficace que de feuilleter un livre intégralement avant de tomber sur l’information.

La méthode d’accès pour récupérer la liste des mathématiciens ayant fait partie de la famille Gauss peut être obtenue avec l’ordre EXPLAIN suivie de la requête SELECT :

EXPLAIN (ANALYZE,BUFFERS)
 SELECT firstname, lastname
 FROM mathematicians
 WHERE lastname = 'Gauss';

Le résultat correspond au plan d’exécution ou query plan, que le moteur construit à partir des statistiques mises à sa disposition, telles que le nombre de lignes connues dans la table, la présence d’index ou la ventilation des données selon leur valeur (aussi appelée histogramme). Durant cette première étape, le moteur peut établir plusieurs plans pour n’en conserver qu’un seul dont le coût d’exécution serait le moins élevé et garantir un temps global de traitement le plus rapide possible.

 QUERY PLAN
-------------------------------------------------
Seq Scan on mathematicians
 (cost=0.00..14.33 rows=1 width=18)
 (actual time=0.188..0.189 rows=0 loops=1)
 Filter: ((lastname)::text = 'Gauss'::text)
 Rows Removed by Filter: 666
 Buffers: shared hit=6
Planning Time: 0.229 ms
Execution Time: 0.219 ms

Le nœud Seq Scan nous confirme que la table a été lue de façon séquentielle et intégrale, bien qu’un filtre ait été appliqué. L’option ANALYZE enrichit le résultat, en contrepartie d’une véritable exécution de la requête sur les relations de la base (ici, la table mathematicians). On y retrouve dès lors le temps réel de recherche et le nombre de lignes retournées et ignorées. L’option BUFFERS indique le nombre de blocs parcourus en précisant s’ils sont lus à partir de la mémoire partagée (shared hit) ou du disque (read).

Observons à présent le comportement du moteur et le plan d’exécution qu’il propose lorsque ce dernier prend connaissance d’un index sur la colonne de recherche lastname :

 QUERY PLAN
--------------------------------------------------------------
Index Scan using mathematicians_lastname_idx on mathematicians
 (cost=0.28..8.29 rows=1 width=18)
 (actual time=0.043..0.046 rows=1 loops=1)
 Index Cond: ((lastname)::text = 'Gauss'::text)
 Buffers: shared hit=3
Planning Time: 0.176 ms
Execution Time: 0.081 ms

Cette fois-ci, le moteur estime un coût de 8,29 au lieu de 14,33 à l’aide de cet index sur la condition de recherche. On constate un changement dans le nœud envisagé par le moteur : un parcours par Index Scan identifie l’unique adresse pour la valeur « Gauss » et récupère les informations connexes dans la table mathematicians. Il en résulte une réduction du nombre de blocs parcourus de 3 au lieu de 6 dans l’exemple sans index. Le gain sur le temps d’exécution est non négligeable : la requête a mis 81 µs au lieu de 219.

Cependant, cette situation n’est pas immuable et selon la valeur de la recherche, le plan d’exécution sélectionné peut varier. Prenons l’exemple des mathématiciens de la famille Cartan.

 QUERY PLAN
--------------------------------------------------------------
Bitmap Heap Scan on mathematicians
 (cost=4.29..8.85 rows=2 width=18)
 (actual time=0.067..0.072 rows=2 loops=1)
 Recheck Cond: ((lastname)::text = 'Cartan'::text)
 Heap Blocks: exact=2
 Buffers: shared hit=4
 -> Bitmap Index Scan on mathematicians_lastname_idx
 (cost=0.00..4.29 rows=2 width=0)
 (actual time=0.051..0.051 rows=2 loops=1)
 Index Cond: ((lastname)::text = 'Cartan'::text)
 Buffers: shared read=2
Planning Time: 0.173 ms
Execution Time: 0.119 ms

Nous avons affaire à un autre nœud relatif à l’usage d’un index, le Bitmap Heap Scan et son Bitmap Index Scan. Le moteur a trouvé dans son parcours d’index, deux lignes (rows=2) dont il stocke les adresses dans un tableau en mémoire, aussi appelé bitmap. La récupération des lignes provoque des accès dits aléatoires et peut devenir coûteuse pour le moteur.

Pour les opérations de comparaison simple comme l’égalité, il est recommandé d’utiliser un index b-tree, par défaut avec l’ordre CREATE INDEX. Cet index s’appuie sur un algorithme du même nom qui assure le stockage des couples valeur/adresse au sein d’un arbre dit équilibré, dont la profondeur doit être la plus faible possible pour réduire les coûts de lecture.

Un index b-tree est composé :

d’un bloc méta ;
de blocs intermédiaires, dont le bloc racine (root) ;
de blocs feuilles.

Il est possible de les consulter à l’aide des fonctions mises à disposition par les extensions pgstattuple et pageinspect, et de démêler le parcours d’index que réalise le moteur à chaque exécution.

 SELECT bt_page_stats.blkno, type, live_items
 FROM generate_series(1,
 pg_relpages('mathematicians_lastname_idx')::integer-1
 ) blkno,
LATERAL bt_page_stats('mathematicians_lastname_idx', blkno);

-- blkno | type | live_items
-- -------+------+------------
-- 1 | l | 317
-- 2 | l | 319
-- 3 | r | 3
-- 4 | l | 32

Requête issue de « PostgreSQL Architecture et notions avancées » de Guillaume Lelarge, édition D-BookeR.

La méthode bt_page_stats associée au nom de l’index et le numéro du bloc, peut être couplée avec la fonction generate_series pour obtenir une ligne par bloc appartenant à l’index, à l’exception du bloc méta. On constate que le bloc n°3 est la racine (type=r) de notre b-tree, bloc à partir duquel le moteur pourra réaliser les comparaisons successives jusqu’à atteindre les valeurs de sa recherche.

SELECT ctid, data, convert_from(decode(
 substring(replace(data, ' 00', ''), 4),
 'hex'), 'utf8') as text
 FROM bt_page_items('mathematicians_lastname_idx', 3);

-- ctid | data | text
-- ---------+-------------------------------------------------+--------------
-- (1,0) | |
-- (2,38) | 0f 4b 6c 65 65 6e 65 00 | Kleene
-- (4,116) | 1b 5a 61 72 61 6e 6b 69 65 77 69 63 7a 00 00 00 | Zarankiewicz

Le bloc racine nous indique qu’il existe trois ramifications (comme l’indiquaient les statistiques précédentes avec la valeur live_items du bloc n°3) contenant les adresses physiques aussi appellées ctid. Le champs data varie selon le type de donnée indexée et s’il s’agit d’un bloc d’index ou d’un bloc de table ; dans cet exemple, la colonne text nous indique la borne basse (minus infinity) de chaque bloc. Il est possible d’obtenir les extrêmes de chaque bloc feuille avec la requête suivante :

SELECT blkno, min(text), max(text)
 FROM (
 SELECT blkno, convert_from(decode(
 substring(replace(data, ' 00', ''), 4),
 'hex'), 'utf8') as text
 FROM (
 SELECT bt_page_stats.blkno
 FROM generate_series(1,
 pg_relpages('mathematicians_lastname_idx')::integer-1
 ) blkno,
 LATERAL bt_page_stats('mathematicians_lastname_idx', blkno)
 WHERE type = 'l'
 ) blkno,
 LATERAL bt_page_items('mathematicians_lastname_idx', blkno)
 WHERE length(data) > 0
 ) t GROUP BY blkno ORDER BY blkno;

-- blkno | min | max
-- -------+--------------+--------------
-- 1 | Abbt | Kleene
-- 2 | Kleene | Zarankiewicz
-- 4 | Zarankiewicz | Zygmund

Pour nos exemples de recherche, les noms « Gauss » et « Cartan » sont tous deux classés entre les lettres A et K, soit dans le bloc n°1 de l’index mathematicians_lastname_idx. Le parcours se poursuit donc dans ce nouveau bloc feuille, où les adresses ctid correspondent à présent aux blocs physiques de la table mathematicians.

SELECT *
 FROM (
 SELECT ctid, data, convert_from(decode(
 substring(replace(data, ' 00', ''), 4),
 'hex'), 'utf8') as text
 FROM bt_page_items('mathematicians_lastname_idx', 1)
 ) t
 WHERE text IN ('Gauss', 'Cartan');

-- ctid | data | text
-- ---------+-------------------------+--------
-- (3,8) | 0f 43 61 72 74 61 6e 00 | Cartan
-- (4,8) | 0f 43 61 72 74 61 6e 00 | Cartan
-- (1,102) | 0d 47 61 75 73 73 00 00 | Gauss

Les résultats des plans d’exécution précédents s’expliquent ! Pour rappel, nous avions un nœud Index Scan pour la recherche « Gauss » et deux nœuds Bitmap Heap/Index Scan pour la recherche Cartan.

La première recherche effectue physiquement deux lectures dans l’index (blocs 3 puis 1) avant de lire le bloc de données (1,102), soit un total de trois blocs, cohérent avec le plan d’exécution (Buffers: shared hit=3).

La seconde recherche effectue également deux lectures dans l’index mais ira récupérer deux lignes distinctes à deux endroits différents de la table (adresses (3,8) et (4,8)), soit un total de quatre blocs, valeur également annoncée par le plan (Buffers: shared hit=4).

Bien évidemment, la consultation du contenu des index n’est pas nécessaire pour l’analyse de performances. Ces derniers vivent et s’équilibrent à chaque modification de données pour maintenir les adresses physiques et garantir un accès optimisé avec la profondeur de lecture la plus faible possible.

L’ajout d’un index ne doit pas être un réflexe systèmatique. Il faut tenir compte de la cardinalité des données d’une colonne, autrement dit, la faible proportion de données retournée à chaque filtre. Dans le cas de la table mathematicians, une recherche basée sur les conditions LIKE ou > pourrait très simplement parcourir l’ensemble des six blocs de la table (Seq Scan), car moins coûteux que le parcours de plusieurs blocs d’index supplémentaires.

Cet article s’est concentré sur le fonctionnement de l’index le plus courant b-tree mais il en existe encore d’autres, répondant à des contraintes variées de recherche et de stockage !

Si la démonstration vous a plu, le jeu de données fr-mathematicians.sql est disponible sur Github et provient de la page « Liste des mathématiciens » disponible sur Wikipédia.