Podcast Dataoops - Episode 48

Tue, 30 Apr 2024 12:00:00 +0100

Podcast Dataoops - Episode 47

Sat, 06 Apr 2024 12:00:00 +0100

De retour du pgDay Paris 2024.

Mon, 18 Mar 2024 10:39:28 +0100

Me voilà rentré du pgDay Paris. J’ai beaucoup aimé cette édition. J’étais déjà venu à celle de et je dois dire que je n’ai pas été déçu. Pour rappel, le pgDay Paris est une conférence internationale. Les présentations sont en anglais et permettent d’attirer des orateurs et un public plus anglophone.

Je vois souvent cette conférence comme un petit : on retrouve un contenu assez riche avec la dimension internationale.

On croise des têtes déjà connues : public, orateurs, bénévoles, contributeurs : Tout ce petit monde qui fait vivre la communauté Postgres.

Puis, c’est l’occasion de mettre des visages sur des noms que l’on croise en lisant des articles ou les mailing-list Postgres.

Voici un petit retour sur les conférences auxquelles j’ai assisté :

Elephant in a nutshell - Navigating the Postgres community 101

Avec , on a pensé que ce serait bien d’avoir cette conférence en introduction.

Je l’ai trouvé très complète. Elle parle de Postgres, mais aussi et surtout de sa communauté. C’est ce qui fait sa force.

Sustainable Database Performance profiling in PostgreSQL

Postgres dispose de nombreuses vues statistiques apportant des informations sur son fonctionnement.

Elles peuvent être natives (pg_stat_statements …) ou via des extensions pg_stat_kcache, pg_wait_sampling.

Cependant, et c’est ce que souligne cette conférence, elles apportent une vue à un instant T.

Pour les exploiter, il faut les historiser. L’orateur présente un outil basé sur ce qui se fait sur Oracle : .

En revanche, il le présente comme l’unique outil permettant d’exploiter ces informations. Une personne dans le public lui a fait remarquer qu’il existait un autre projet : .

Les deux outils ne fournissent pas les mêmes fonctions, pg_profile génère un rapport HTML. Il est plutôt facile à installer, il ne nécessite pas de librairies externe car il est écrit en pl/pgsql.

PoWA apporte des graphes, de la suggestion d’index… mais est plus lourd à installer.

PostgreSQL without permanent local data storage

Là, on rentre dans une conférence très technique. Matthias travaille sur le projet et il participe régulièrement sur les .

Neon est un fork opensource de Postgres visant à séparer le compute et le storage. C’est ce qu’a fait AWS avec le projet Aurora.

Heikki Linnakangas, un des co-fondateurs de Neon et committer de Postgres a fait plusieurs présentations :

Matthias a présenté les différents problèmes que cela posait de vouloir séparer le stockage du reste du moteur. C’est clairement un projet très ambitieux. Pour le moment, il est difficile de savoir si ce fork perdurera ou non.

Cependant, on peut souligner que les personnes travaillant dessus ont une très grande connaissance du moteur. On peut espérer que ça ait des implications positives dans le projet Postgres.

Affaire à suivre…

Lightning Talks!

Les Lightning Talks sont une bonne occasion de balayer certains sujets un peu plus légers. Ca passe plutôt bien après le repas. C’est assez divertissant. J’ai bien aimé la présentation de Léo Unbekandt sur l’architecture des instances Postgres à Scalingo. Pas de K8S, une architecture simple et éprouvée.

J’ai aussi aimé la présentation de Chris Ellis où il fabrique un objet décoratif lumineux avec de l’ESP32 dedans.

Multi-tenant database: the good, the bad, the ugly.

Après, les Lightning Talks, on retourne dans le vif du sujet avec cette présentation de Pierre Ducroquet.

Je connais bien Pierre, la première fois que je l’ai croisé, c’était au pgDay France 2016. Il avait fait une très bonne présentation sur . Ensuite, ça a été mon collègue de travail pendant quelques années où on a rencontré les problèmes que pouvaient poser les bases de données multi-tenant.

Il présente différentes façons de faire du multi-tenant avec les contraintes que cela implique. Il donne des chiffres assez impressionnants comme plus de 200 000 tables!

Beyond B-trees looking at Columnar Storage and LSM trees

Une autre conférence assez bas niveau sur le stockage colonne et les LSM Tree.

Ce type de stockage peut effectivement faire partie du futur de Postgres. Le moteur commence à être utilisé pour de plus en plus de projets analytiques où on manipule de gros volumes de données.

Il faut donc des méthodes de stockage capable d’encaisse des écritures rapides.

Postgres 16 highlight: Logical decoding on standby

Une nouveauté assez attendue sur Postgres 16 : La possibilité de faire du décodage logique sur un secondaire.

Qui mieux qu’un des auteurs de cette fonctionnalité pour en parler ?

Bertrand présente les difficultés pour faire un décodage logique sur un secondaire, et comment elles ont été résolues.

Il a aussi fait une démonstration. C’est vraiment impressionnant, car c’est un sujet assez compliqué.

Point bonus, il explique aussi une nouveauté de Postres 17 : la synchronisation des slots de réplication.

Actuellement, on peut difficilement “raccrocher” une réplication logique en cas de bascule. Il y a un risque de perte de transaction.

Postgres 17 devrait permettre de synchroniser un slot de réplication. En cas de bascule, on peut reprendre la réplication. On est chanceux, il vient tout juste d’écrire un article sur le sujet : .

Closing

C’était la dernière conférence de la journée. On a pu se retrouver pour le social event.

C’est un moment que j’affectionne particulièrement. Car au-delà des conférences, c’est surtout une occasion d’échanger entre passionnés. De retrouver des connaissances et amis de longue date.

J’ai réalisé que j’avais un peu délaissé les conférences, entre le covid, mon passage en freelance etc… A l’avenir, j’essaierai d’être plus présent sur ce genre d’évènement (si je peux prendre le train).

Merci

J’en profite aussi pour remercier les . On a du mal à réaliser l’investissement que ça demande. Un grand merci à eux pour cet évènement !

On se verra sûrement au pgDay 2025 !

Podcast Dataoops - Episode 46

Mon, 11 Mar 2024 12:00:00 +0100

Recommandations de lectures pour améliorer ses connaissances en base de données et PostgreSQL

Mon, 12 Feb 2024 09:00:00 +0100

Table des matières

Je ne vais lister que quelques livres, mais je pourrais en citer pleins d’autres 😃 . J’espère que ça permettra à plus de développeurs, DBA, DEVOPS, CTO … de mieux comprendre les bases de données et leurs enjeux.

Fondamentaux des bases de données

The Manga Guide to Databases

Niveau : Débutant

est celui que je recommande dans la plupart de mes rapports d’audit.

Il est vraiment génial, facile à lire et pour autant, il ne sacrifie pas le fond à la forme.

Il couvre un peu tous les aspects importants :

Modélisation
Écriture de requêtes simples
Grands principes des bases de données : transaction, isolation…

Database Design for Mere Mortals

Niveau : Intermédiaire

de Michael J. Hernandez est, comme son nom l’indique, orienté sur la modélisation.

C’est un gros pavé de plus de 600 pages, mais il ne faut pas se laisser impressionner. Il se lit très bien, c’est bien vulgarisé et l’auteur a fait attention à éviter de s’embarquer dans la théorie qui peut parfois être indigeste.

J’ai beaucoup aimé le processus d’interviews pour construire le modèle de données, l’accent mis sur la documentation du modèle. Il parle peu des formes normales, c’est un parti pris. Cependant, si on suit son processus, le modèle respecte bien les formes normales.

SQL Antipatterns

est un bon livre pour identifier les anti-patterns et apporte des solutions. Je m’en sers régulièrement quand j’ai besoin d’expliquer ce qui ne va pas dans un modèle ou une requête.

SQL for Smarties

Niveau : Avancé

Comment ne pas mentionner les livres de . Il a participé au standard SQL et écrit de .

fait partie des références en matière de SQL. La première édition date de 1995… oui… presque 30 ans quand j’écris ces lignes ! La cinquième édition date de 2015, malgré ces 10 ans, le contenu est toujours d’actualité. On trouve même des ordres assez récents comme LATERAL, les window functions, CTE.

On est aussi sur un gros pavé de plus de 800 pages, le livre est très complet, assez exhaustif. Je dirai réservé à ceux qui veulent vraiment approfondir leurs connaissances en SQL.

À noter qu’il existe une version en français basé sur la seconde édition qui date de 2000, elle accuse un peu l’age : . On peut le trouver .

The Art Of SQL

Niveau : Avancé

Avec de , on change de catégorie. Là, on est sur du SQL plus avancé. Le livre va être orienté performances, bonnes pratiques. Malgré ses 18 ans, son contenu est toujours d’actualité. C’est un livre très puissant, il vous faudra du temps pour le lire et assimiler chaque page.

Performance

SQL Performance Explained

Niveau : Intermédiaire

Impossible de ne pas mentionner l’excellent livre de , .

Comme son titre l’indique, on va parler performance, indexation, écriture de requêtes. À noter qu’il a également été traduit en plusieurs langues : Allemand, Espagnol, Japonais et Français grâce à Guillaume Lelarge .

Le contenu du livre est également disponible sur son site . Markus est aussi l’auteur d’un excellent site sur les fonctionnalités avancés du SQL : . Lors de l’émission , il a annoncé la volonté d’en faire un livre. J’ai hâte ! Il a aussi fait de nombreuses .

Indexing Beyond the Basics

Niveau : Débutant - Intermédiaire

est un e-book orienté sur les index. Un point intéressant est qu’il mentionne aussi pourquoi le moteur n’utilise pas un index.

PostgreSQL

Practical SQL

Niveau : Débutant - intermédiaire

est un super livre pour quelqu’un qui débute sur Postgres. Il parle d’un peu de tout, du SQL jusqu’aux types avancés. Comment utiliser le SQL pour analyser des données, faire du full text search, opération d’administration…

PostgreSQL - Architecture et notions avancées

Niveau : Intermédiaire - avancé

par Guillaume Lelarge et Julien Rouhaud est le livre que je recommande pour qui veut comprendre comment fonctionne Postgres. Mon seul regret est qu’il ne soit pas traduit en anglais pour en faire profiter plus de lecteurs.

À noter aussi qu’il est mis à jour tous les ans.

Learn PostgreSQL

par Lucas Ferrari et Enrico Pirozzi est un livre très complet sur l’administration de Postgres. Un must have pour un DBA.

Pour les francophones, vous pouvez vous orienter vers de Sébastien Lardière.

PostgreSQL 14 Internals

par Egor Rogov est un livre sur les entrailles de Postgres. Il est vraiment très complet. Un grand merci à lui de le mettre à disposition en accès libre.

Dans le même style, il existe un site par Hironobu SUZUKI.

Postgres à nouveau élu SGBD de l'année en 2023, mais je suis inquiet

Mon, 05 Feb 2024 09:00:00 +0100

Cette année encore, Postgres a été élu SGBD de l’année par . Même si ce n’est qu’un classement, cela donne une tendance. Cela fait aussi plusieurs années qu’il est reconnu selon les sondages de Stackoverflow : . C’est un SGBD très apprécié, tant par les développeurs, que par les DBA chevronnés… Mais aussi par les directeurs qui y trouvent une stabilité¹.

Postgres a tout pour séduire :

Année après année, de nouvelles fonctionnalités sont rajoutées. Je pense notamment à : la parallélisation, le partitionnement, la réplication logique…
Il a su, depuis toujours, garder sa fiabilité.
Sa communauté n’a fait que grandir. Les conférences dédiées à Postgres battent des records d’affluence tous les ans.²
C’est devenu un standard, même pour les autres logiciels : les éditeurs rajoutent même le support du protocole Postgres pour faciliter leur intégration : Aurora, AlloyDB, QuestDB…
C’est un des rares projets de cette envergure à être communautaire. On a pu voir qu’il ne suffit pas que le projet soit opensource, il faut aussi compter sur la communauté et son écosystème.
Il est supporté par les gros acteurs : les GAFAM emploient de nombreux committers et contributeurs. Ils sponsorisent également les conférences. Par exemple, le prochain .

Cependant, je suis un peu inquiet pour le futur. Non pas pour PostgreSQL. Bruce Momjian a fait plusieurs présentations sur ce sujet :

C’est même le sujet de la Keynote d’ouverture du dernier PGConf Europe :

Non, je suis plutôt inquiet sur la perte de connaissance du métier de DBA.

A quoi servira Postgres si on ne sait pas l’utiliser correctement ?

Table des matières

Un peu d’histoire

Par le passé, il y avait une spécialisation forte des compétences : développeurs, testeurs, DBA étude, DBA prod, ingénieur système, ingénieur stockage, ingénieur sauvegarde…

Chaque spécialité évoluait un peu dans sa bulle, ce qui compliquait la collaboration avec des cycles de développement longs.

Cette organisation a laissé place à une nouvelle façon de travailler : développeurs fullstack, DEVOPS/SRE, des data “quelque chose” (engineer, analyst, steward…).

Les compétences se sont diluées sur les différents métiers. Je croise de plus en plus rarement des DBA.

A la place, la base de donnée est gérée par les développeurs. Ou, si on a un peu de chance, par des “data engineer” ou “data analyst”.

Après plusieurs années, alors que je baigne dedans, j’ai encore du mal à définir ces métiers.

Le constat : bonne connaissance du python, monte des pipelines, on assemble en quelque sorte des Legos avec pleins d’outils : airflow, dbt… Puis, on envoie ces données dans du Redshift, Biquery, Snowflake…

Cependant, j’ai l’impression que la connaissance du SQL s’appauvrit à cause des couches d’abstraction.

Du moment où on manipule de la donnée, la première des compétences à avoir, devrait être la maitrise du SQL.

Qu’est-ce qu’on oublie ?

J’ai le sentiment, qu’année après année, on oublie le métier de DBA.

Pour rappel, ce dernier va être à la croisée de plusieurs chemins :

Il a des compétences pures sur la base de données :
- Modélisation.
- Maitrise du SQL.
- Maitrise du SGBD : connait le fonctionnement du moteur (vacuum, checkpoint …). Comprend les mécanismes de verrouillages (MVCC, locks…).
- Conserve une veille technique : le Postgres que j’ai connu à mes débuts est très loin du Postgres actuel.
Mais également des compétences plus transverses :
- Avoir une bonne connaissance système pour investiguer sur les problèmes de performance, dimensionner les ressources.
- Un vernis en développement pour comprendre les besoins des développeurs et pouvoir les accompagner.
- De la culture “computer science”.

Oui, mais le cloud!

On pourrait penser que le cloud a rebattu les cartes et qu’on n’a plus besoin de DBA. Dans la liste que j’ai donnée ci-dessus, quelles compétences sont couvertes par le cloud ?

Le cloud résout une partie des besoins : hébergement, maintenance, réseau, monitoring (qu’il faut souvent compléter avec un APM ou un Datadog like). Et il rajoute d’autres problèmes :

Il faut rajouter un métier de pour maitriser et optimiser les dépenses.
C’est parfois une boite noire et il peut être difficile d’investiguer sur des problèmes de performance³.
Cet excellent article de Markus Winand présente aussi d’autres inconvénients :
- Changer de cloud provider est difficile. Je dirais même que c’est volontaire de leur part.
- Les coûts peuvent changer Just because it is cheap today doesn’t mean it will be cheap forever.
- Il faut prévoir un plan de sortie : éviter les services propriétaires, conserver un faible nombre de services.

Car une fois dans le cloud, qui s’occupe de : la modélisation, l’optimisation des requêtes, l’indexation, la veille technique sur le SGBD⁴, l’investigation sur les performances, comprendre les problèmes de verrouillages, l’accompagnement des développeurs ?

Ceci est confirmé dans mes audits, je vois régulièrement des problèmes très basiques :

Absence de clé primaire.
Pas d’index sur des cas très simples.
Aucun respect des formes normales, même les plus basiques. Le JSON n’a pas arrangé les choses.
Requêtes spaghetti.
Des jointures façon SQL-89 alors que ça fait plus de 30 ans que le mot clé JOIN existe.

S’il faut retenir une chose : Le cloud ne permet pas de s’affranchir du DBA. Ce n’est pas parce qu’on peut obtenir les clés d’un avion, qu’on sait le piloter.

Un article intéressant sur le nombre de DBA dont vous avez besoin : .

On oublie le métier de DBA

On pourrait naïvement penser qu’on confie ces tâches à des DBA experts, mais j’ai de plus en plus de doutes. J’ai l’impression “qu’on” est en train de perdre la connaissance d’un métier. J’ai déjà croisé des développeurs expérimentés qui ne savaient même pas que le métier de DBA existait. Des recruteurs qui me demandaient si en tant que DBA, je savais optimiser des requêtes et si je connaissais le SQL. C’est mon métier ! C’est un peu comme demander à un plombier s’il sait changer un robinet !

Ce qui est d’autant plus alarmant, c’est que je crains qu’il y ait aussi des CTO qui ont aussi cette méconnaissance de la donnée.

La conséquence est qu’en cas de problème de performance, on ne fait qu’augmenter les ressources des instances. Avec le cloud, la facture croît linéairement avec la taille de l’instance. Si la croissance de la charge est exponentielle, il faudra scaler la base et la facture qui va avec. On se retrouve avec une facture exponentielle.

Quand on n’arrive plus à s’en sortir, on va accuser l’outil ou le modèle, donc on va changer de SGBD ou aller vers du NoSQL. Spoiler : ça ne résoudra pas vos problèmes.

On oublie le passé

Pendant un temps, j’ai voulu écrire un livre pour parler optimisation de requête, des erreurs courantes que je rencontre, etc.

En regardant ma bibliothèque, elle est pleine de livres de ce genre. Ils ont pour la plupart entre 10 et 30 ans et le contenu est toujours d’actualité. A quoi servirait un énième livre s’il n’est pas connu ?

J’ai un autre exemple en tête : les data warehouse (DWH). Ce terme devient de plus en plus galvaudé. La construction d’un DWH est complexe, il faut passer par une phase de modélisation afin de stocker correctement les données. Cela permet de bonnes performances et facilite l’écriture des requêtes analytiques.

Maintenant, je croise régulièrement des “data warehouse” qui se résument à envoyer toutes les données dans un SGBD spécialisé (redshift, biquery …). Sans travail de modélisation et avec des requêtes très mal écrites, parfois générées, car les utilisateurs ne savent pas faire du SQL.

Ces services coûtent très cher et ne font pas de miracle s’il n’y a pas eu un travail approfondi de modélisation et d’optimisation.

Pourtant, les livres sur les DWH et le SQL ont entre 10 et 30 ans. A cette époque, le cloud n’existait pas, les SSD non plus, les CPU avec plusieurs coeurs non plus. Pourtant, on savait construire des DWH, faire des sites performants…

Il ne faudrait pas que le cloud nous fasse oublier tout cet héritage. Sinon, on risque de payer la dette technique et la perte de connaissance très cher, avec les intérêts en plus.

Il faut avoir en tête que même si le SQL a évolué, les SGBD gagnés en fonctionnalités, les principes fondateurs sont toujours justes.

Le code change, la donnée reste

J’ai eu un super manager, ancien DBA, qui expliquait aux développeurs : tu n’es pas ici pour “produire du code” => yeux écarquillés du développeur. “tu es là pour produire et manipuler de la donnée.”

Lorsqu’il y avait une décision compliquée. Par exemple, prendre plus de temps pour revoir le code applicatif, faire une migration plus compliquée, plutôt qu’une solution “quick win”. Ce même manager expliquait :"

D’ici 5-10 ans, ton code aura été réécrit plusieurs fois, peut-être même dans un autre langage. Nous, la donnée, dans 50 ans, elle sera toujours là. C’est notre devoir de nous assurer qu’elle sera toujours exploitable.

Il faut quelques minutes pour prendre une mauvaise décision sur une base de donnée

Et parfois plusieurs mois / années pour la corriger.

Il m’est arrivé de faire des audits où le modèle était catastrophique. Il avait évolué de solutions à court terme en d’autres solutions à court terme. “On corrigera plus tard, il faut faire passer cette fonctionnalité dans le sprint”.

Un DBA peut corriger le modèle de données à coup de grosses migrations (encore faut-il avoir un DBA, difficile si on ignore que ce métier existe…). Au-delà de ça, le problème va se poser autour : il faut réécrire une grosse partie du code applicatif (qui est souvent dans le même état que la base).

Parfois, la complexité est quadratique ou exponentielle. Il vaut mieux tout jeter pour tout recommencer.

On se retrouve face à plusieurs dilemmes :

Augmenter la taille des instances.
Parfois, cette solution n’est pas suffisante. J’explique : “là, vous pouvez faire encore fois dix sur la taille de l’instance, mais vous ne pourrez jouer cette carte qu’une fois”. Notez que cette solution est inutile si le traitement ne peut pas être parallélisé.
Tout jeter pour tout recommencer. Là aussi, le coût ou la perte peut être démentielle.

Alors qu’il aurait suffi des conseils d’un DBA à quelques moments de la vie du projet pour éviter de partir dans une mauvaise direction.

On ne bâtit pas un château sur du sable. J’ai une anecdote en tête, une personne de mon entourage m’a raconté une histoire d’un bâtiment qui avait été contrôlé au moment de la livraison :

Un prélèvement avait été fait dans les murs et il n’y avait pas assez de ciment, le bâtiment, neuf, pouvait s’écrouler. Il venait d’être totalement terminé, électricité, plomberie, menuiseries… Tout était terminé. Il a dû être rasé complètement. Autant il existe des assurances dans le bâtiment, mais pas pour le développement… Je pense que certaines sociétés ne survivent pas si la dette technique est trop importante.

L’usage du cloud

Le cloud a de nombreux avantages :

On peut rapidement obtenir des bases de données avec une installation relativement propre.
Le cloud provider vous obligera à rester sur des versions supportées.
“Écologiquement”, cela permet de mutualiser des ressources physiques. Mais c’est aussi une faiblesse. L’accès facile à ces ressources peut aussi entrainer un gaspillage. On peut facilement déployer une centaine d’instances. Là, où avec une infrastructure on-premise, il faut concilier avec les ressources physiques à disposition : puissance des serveurs, puissance électrique, espace dans les baies…
On paye ce qu’on consomme. On peut facilement identifier combien coute un service. Qu’une requête est responsable de 80% de la facture. Ce qui peut inciter à l’optimiser, le gain financier est immédiat. Encore faut-il qu’il y ait des personnes qui s’y intéressent. Je n’ai pas l’impression qu’il y ait beaucoup de FinOps. S’il y en a, est-ce que ces derniers pensent à optimiser la base ?

Mais il y a aussi de vrais inconvénients :

Perte de souveraineté numérique. A cela s’ajoute des risques juridiques. Comment garantir que vos données ne sont pas stockées ailleurs ? Si vous avez choisi un service managé, comment en sortir si la législation vous impose d’être sur le sol Français ou d’un autre pays ?
Perte de compétences.
Dépendance à un cloud provider : encore que sur ce point, on voit émerger de nouvelles offres “cloud agnostique” : Des sociétés créent un cloud par-dessus un autre cloud. Je pense notamment à , , et j’en oublie certainement…⁵
Les couts décollent quand l’infrastructure est importante. Certains commencent à quitter le cloud. Je pense notamment à Basecamp :

Ce qu’il faudrait changer

Redonner de la valeur à la donnée : des sociétés rechignent à faire appel à des DBA ou prendre des contrats de supports sur leur base. Quel est le cout d’une indisponibilité de service, d’une corruption de donnée, d’une perte de la base ?
Réinvestir le champ des compétences en base de donnée : SQL, modélisation⁶. A ce sujet, j’aime beaucoup le titre de Markus Winand :
S’attarder un peu plus sur l’usage des ressources : la consommation du numérique est importante, si les serveurs et l’électricité étaient plus chers, on serait contraint d’optimiser.
Surveiller les dépenses sur les bases. Que ça soit dans le cloud, mais également on-premise. Pour cela, il faut avoir des indicateurs de couts.
Penser pas à faire appel à des DBA pour anticiper les problèmes et investiguer sur les problèmes de performance : J’ai audité des bases dans un état catastrophique, ça aurait pu être évité si un DBA était intervenu dans la phase de modélisation. Sur les problèmes de performance, il m’est déjà arrivé de diviser des factures de cloud par 10 ou de baisser la charge moyenne de 80% à 5% avec un suivi régulier.
Il ne faut pas se résigner à payer de grosses factures cloud plutôt que d’investir dans de la compétence de DBA.

Pour conclure

C’est un article moins technique par rapport à ce que vous avez l’habitude de lire sur mon blog. Cependant, c’est un des plus importants que j’ai été amené à écrire. Ca fait plus de dix ans que je fais du Postgres et je réalise que la tendance ne va pas dans la bonne direction. J’espère qu’il y aura une prise de conscience pour un avenir plus durable des bases de données.

Ainsi que dans le public, il est dans le . ↩︎
↩︎
Ultimately, due to AWS’ opacity, there is simply no way to know how much throughput (from the physical disks and from the network that sits in-between) to expect for a given EBS volume. Provisioned IOPS only offer a partial solution to this issue, at a higher hourly cost.

↩︎
Le Postgres actuel est très loin du Postgres avec lequel j’ai débuté :
- Nouvelles fonctionnalités liées au standard SQL : JSONPath par exemple. est l’auteur d’un super site à ce sujet:
- Nouvelles fonctionnalités sur le moteur : parallélisme, partitionnement, nouveaux noeuds d’exécution, réplication logique…
- La conséquence est un nombre de paramètres qui augmente au fur et à mesure.
- De nouvelles extensions.
↩︎
Je n’ai pas travaillé avec ces offres, je n’ai pas de recul dessus. On peut néanmoins souligner que ces sociétés emploient des développeurs qui contribuent à Postgres. ↩︎
Il y a quelques années, un article était tiré d’une conférence.

Le titre est particulièrement juste : . Voici la vidéo de la conférence : et ses . ↩︎

Optimisation du GROUP BY

Fri, 26 Jan 2024 10:00:00 +0100

Un commit a attiré mon attention lors de ma veille technique :

 1commit 0452b461bc405e6d35d8a14c02813c15e28ae516
 2Author:     Alexander Korotkov <akorotkov@postgresql.org>
 3AuthorDate: Sun Jan 21 22:21:36 2024 +0200
 4Commit:     Alexander Korotkov <akorotkov@postgresql.org>
 5CommitDate: Sun Jan 21 22:21:36 2024 +0200
 6
 7    Explore alternative orderings of group-by pathkeys during optimization.
 8
 9    When evaluating a query with a multi-column GROUP BY clause, we can minimize
10    sort operations or avoid them if we synchronize the order of GROUP BY clauses
11    with the ORDER BY sort clause or sort order, which comes from the underlying
12    query tree. Grouping does not imply any ordering, so we can compare
13    the keys in arbitrary order, and a Hash Agg leverages this. But for Group Agg,
14    we simply compared keys in the order specified in the query. This commit
15    explores alternative ordering of the keys, trying to find a cheaper one.
16
17    The ordering of group keys may interact with other parts of the query, some of
18    which may not be known while planning the grouping. For example, there may be
19    an explicit ORDER BY clause or some other ordering-dependent operation higher up
20    in the query, and using the same ordering may allow using either incremental
21    sort or even eliminating the sort entirely.
22
23    The patch always keeps the ordering specified in the query, assuming the user
24    might have additional insights.
25
26    This introduces a new GUC enable_group_by_reordering so that the optimization
27    may be disabled if needed.
28
29    Discussion: https://postgr.es/m/7c79e6a5-8597-74e8-0671-1c39d124c9d6%40sigaev.ru
30    Author: Andrei Lepikhov, Teodor Sigaev
31    Reviewed-by: Tomas Vondra, Claudio Freire, Gavin Flower, Dmitry Dolgov
32    Reviewed-by: Robert Haas, Pavel Borisov, David Rowley, Zhihong Yu
33    Reviewed-by: Tom Lane, Alexander Korotkov, Richard Guo, Alena Rybakina

On remarque le message du commit assez explicite en mentionnant les personnes impliquées (12 relecteurs!) ainsi que le lien vers la discussion :

Les travaux ont commencé en 2018! Il aura fallu 5 ans et demi pour aboutir à ce commit. C’est le fruit de nombreux échanges afin de parvenir à un consensus en prenant en compte les multiples idées.

Pour tester ce patch, j’ai compilé Postgres depuis les sources. Prenons un exemple tout simple :

1create table t1 (c1 int, c2 int, c3 int);
2create index on t1 (c1,c2);
3insert into t1 SELECT i%100, i%1000, i from generate_series(1,10_000_000) i;
4vacuum analyze t1;

On obtient une table de 422Mo et un index de 66Mo. Vous noterez au passage que j’ai utilisé une nouveauté de Postgres 16 en utilisant des “underscore” dans le generate_series¹.

Si on fait un GROUP BY sur c1,c2, on obtient un parcours d’index :

 1explain (settings, analyze,buffers) select count(*),c1,c2 from t1 group by c1,c2 order by c1,c2;
 2                                                                    QUERY PLAN
 3--------------------------------------------------------------------------------------------------------------------------------------------------
 4 GroupAggregate  (cost=0.43..235342.27 rows=100000 width=16) (actual time=3.605..3501.887 rows=1000 loops=1)
 5   Group Key: c1, c2
 6   Buffers: shared hit=10447
 7   ->  Index Only Scan using t1_c1_c2_idx on t1  (cost=0.43..159340.96 rows=10000175 width=8) (actual time=0.070..1900.730 rows=10000000 loops=1)
 8         Heap Fetches: 0
 9         Buffers: shared hit=10447
10 Settings: enable_group_by_reordering = 'off', random_page_cost = '1.1', max_parallel_workers_per_gather = '0'
11 Planning:
12   Buffers: shared hit=1
13 Planning Time: 0.191 ms
14 Execution Time: 3502.036 ms

Vous remarquerez que j’ai volontairement désactivé la fonctionnalité dans un premier temps (enable_group_by_reordering=off). J’ai également désactivé la parallélisation pour plus de clarté.

On a le plan attendu, le moteur va lire 10447 blocs avec un parcours Index Only Scan. Le moteur va chercher le plan qui manipule le moins de blocs possible.

En revanche, si on change l’ordre du group by :

 1explain (settings, analyze,buffers) select count(*),c1,c2 from t1 group by c2,c1 order by c1,c2;
 2                                                          QUERY PLAN
 3------------------------------------------------------------------------------------------------------------------------------
 4 Sort  (cost=602422.32..602672.32 rows=100000 width=16) (actual time=5393.446..5393.503 rows=1000 loops=1)
 5   Sort Key: c1, c2
 6   Sort Method: quicksort  Memory: 79kB
 7   Buffers: shared hit=96 read=53959
 8   ->  HashAggregate  (cost=514992.50..594117.50 rows=100000 width=16) (actual time=5392.351..5392.894 rows=1000 loops=1)
 9         Group Key: c2, c1
10         Batches: 1  Memory Usage: 3217kB
11         Buffers: shared hit=96 read=53959
12         ->  Seq Scan on t1  (cost=0.00..154055.00 rows=10000000 width=8) (actual time=0.033..1186.171 rows=10000000 loops=1)
13               Buffers: shared hit=96 read=53959
14 Settings: enable_group_by_reordering = 'off', random_page_cost = '1.1', max_parallel_workers_per_gather = '0'
15 Planning:
16   Buffers: shared hit=1
17 Planning Time: 0.189 ms
18 Execution Time: 5394.566 ms

Dans ce cas, le moteur va lire toute la table (seqscan) et faire un tri, alors que le résultat est identique.

Le moteur lit 422Mo de données contre 80Mo, soit 5 fois plus. Le résultat peut être désastreux suivant les performances du stockage. Là, on a de la “chance”, mon instance est dans un ramdisk donc la requête n’est pas beaucoup plus lente. Avec du stockage mécanique ou des disques cloud, le temps de réponse peut augmenter drastiquement.

L’ordre des colonnes dans un group by est important, c’est une optimisation assez simple pour peu qu’on connaisse le schéma de la base et qu’on maitrise les requêtes exécutées sur le serveur.

Malheureusement, avec les ORM, on peut perdre cette maitrise ou rater des corrections. C’est là où cette fonctionnalité est intéressante. Voyons son effet :

 1postgres=# set enable_group_by_reordering to on;
 2SET
 3postgres=# explain (settings, analyze,buffers) select count(*),c1,c2 from t1 group by c2,c1 order by c1,c2;
 4                                                                    QUERY PLAN
 5--------------------------------------------------------------------------------------------------------------------------------------------------
 6 GroupAggregate  (cost=0.43..235338.33 rows=100000 width=16) (actual time=4.502..3658.168 rows=1000 loops=1)
 7   Group Key: c1, c2
 8   Buffers: shared hit=10447
 9   ->  Index Only Scan using t1_c1_c2_idx on t1  (cost=0.43..159338.33 rows=10000000 width=8) (actual time=0.081..1923.553 rows=10000000 loops=1)
10         Heap Fetches: 0
11         Buffers: shared hit=10447
12 Settings: random_page_cost = '1.1', max_parallel_workers_per_gather = '0'
13 Planning:
14   Buffers: shared hit=1
15 Planning Time: 0.230 ms
16 Execution Time: 3658.337 ms

On retrouve le premier plan bien plus performant.

C’est une fonctionnalité assez simple qui devrait améliorer les temps d’exécutions de certaines requêtes dont la clause group by n’a pas été optimisée.

C’est une demande assez récurrente d’améliorer le planificateur afin de gérer des cas en apparence simple. Il faut avoir en tête que le risque est de d’augmenter les opérations de calculs dans le planificateur. Or, on veut que cette étape soit la plus rapide possible La réponse est souvent résumée à : “on ne veut pas alourdir le planificateur alors qu’on peut corriger la requête”.

Cependant, ce type d’optimisation peut être acceptée si on sait que ça ne sera pas couteux pour le planificateur.

Il n’y a plus qu’à espérer que cette fonctionnalité ne soit pas retirée d’ici la sortie de Postgres 17 :)

Petite anecdote, pour ajouter cette fonctionnalité, l’auteur a fait évoluer le standard SQL : . ↩︎

PostgreSQL compression du TOAST et toast_tuple_target

Mon, 14 Feb 2022 09:00:00 +0200

Quelques rappels sur le TOAST et présentation d’un changement apparu avec PostgreSQL 11.

Table des matières

Qu’est-ce que le TOAST ?

Vous êtes-vous déjà posé la question sur comment Postgres fait pour stocker des lignes dépassant la taille d’un bloc? Pour rappel, la taille par défaut d’un bloc est de 8Ko.

Postgres utilise un mécanisme appelé TOAST pour .

Lorsqu’un enregistrement devient trop gros pour être stocké dans un bloc, le moteur va le stocker “à part”, dans une table de toast. L’enregistrement sera découpé en chunks, ainsi la table principale (appelée heap) contiendra un pointeur (chunk_id) pointant vers le bon chunk dans la table de toast.

Ce chunk sera stocké sur plusieurs lignes, pour un chunk_id on peut avoir plusieurs lignes dans cette table de toast. Ainsi, cette table de toast est composée de 3 colonnes:

chunk_id : Numéro du chunk référencé dans la heap
chunk_seq : Numéro de chaque segment d’un chunk
chunk_data : Partie données de chaque segment

La réalité est un peu plus complexe, en vrai le moteur va tenter d’éviter de stocker la donnée dans la table toast. Si la ligne dépasse TOAST_TUPLE_THRESHOLD (2Ko), il va tenter de compresser les colonnes pour essayer de faire rentrer la ligne dans le bloc. Plus précisément, il faut que la taille soit inférieure à TOAST_TUPLE_TARGET (2Ko par défaut, on va en reparler).

Si on a de la chance, la ligne compressée rentre dans la heap. Sinon, il va tenter de compresser les colonnes, de la plus grande à la plus petite et les stocker dans la partie toast jusqu’à ce que les colonnes restantes rentrent dans une ligne de la heap. ¹

A noter également que si le gain en compression est trop faible, il considère qu’il est inutile de dépenser de la ressource de calcul à tenter de compresser. Il stocke donc la donnée sans compression. ²

Avez-vous déjà prêté attention à la colonne “Storage” lorsque vous affichez les caractéristiques d’une table à l’aide de la méta commande \d+ table ?

1stackoverflow=# \d+ posts
2                   Table "public.posts"
3    Column     |  Type   | Collation | Nullable | Default | Storage  |
4---------------+---------+-----------+----------+---------+----------+
5 id            | integer |           | not null |         | plain    |
6 posttypeid    | integer |           | not null |         | plain    |
7 score         | integer |           |          |         | plain    |
8 viewcount     | integer |           |          |         | plain    |
9 body          | text    |           |          |         | extended |

Dans cet exemple, la colonne prend comme valeur plain ou extended. En réalité, il existe 4 valeurs possibles selon le type de donnée :

plain : la colonne est stockée dans la heap uniquement et sans compression.
extended : la colonne peut être compressée et stockée dans le toast si nécessaire.
external : la colonne peut être stockée dans le toast mais uniquement sans compression. Parfois on peut utiliser ce mode pour avoir un gain en performance (évite la compression/décompression) au prix d’une consommation plus importante de l’espace disque.
main : La colonne est stockée dans la heap uniquement mais contrairement au mode plain, on autorise la compression.

Au premier abord, on peut penser que l’intérêt est surtout sur la possibilité de stocker des lignes dépassant la taille d’un bloc et de compresser la donnée pour gagner de l’espace disque.

Il y a un autre intérêt : lors d’une mise à jour d’une ligne, si les colonnes “toastées” ne sont pas modifiées, le moteur n’a pas besoin de modifier la table toast. On va ainsi éviter de devoir décompresser et recompresser le toast et écrire tout ça dans des journaux de transaction.

Nous allons voir qu’un autre avantage est que le moteur peut éviter de lire le toast si ce n’est pas nécessaire.

Exemple avec le JSONB

Pour étudier ça, on va utiliser le type JSONB. De manière générale, je déconseille l’usage de ce type :

On perd les avantages d’avoir un schéma :
- vérification des types
- contraintes d’intégrité
- pas de clés étrangères
L’écriture des requêtes devient plus complexe
Absence des statistiques sur les clés d’un champ json
Perte d’efficacité du stockage vu qu’on stocke les clés pour chaque ligne
Pas de mise à jour partielle du JSONB. Si on modifie une clé on est obligé de detoaster et toaster tout le JSONB
Pas de detoast partiel : si on souhaite lire une seule clé du JSONB, on est contraint de detoaster tout le JSONB ³

Cependant, il y a quelques exceptions où le JSON peut être utile :

Lorsqu’on n’a pas besoin de chercher dans de multiples champs et qu’on récupère le json via une autre colonne. (Statistiques sur les clés du json inutiles).
Et, lorsqu’il serait très difficile de faire rentrer le json dans un schéma relationnel. Certains cas impliqueraient d’avoir énormément de colonnes et la plupart à NULL.

Par exemple, pour stocker des caractéristiques de produit où une version normalisée entrainerait l’usage de beaucoup de colonnes dont la plupart seraient à NULL. Imaginons que vous stockez des produits, une télévision aurait des caractéristiques spécifiques (type d’écran, taille etc). Une machine à laver aurait aussi d’autre caractéristiques spécifiques (vitesse essorage, poids accepté…).

On pourrait ainsi envisager d’avoir des colonnes “normales” comprenant le modèle, son prix, sa référence etc, et une colonne contenant toutes les caractéristiques. On accèderait à la ligne via la référence et ainsi on récupèrerait toutes les caractéristiques du produit stockées dans le json.

Je vais réutiliser la table des posts de Stackoverflow en déplaçant quelques colonnes dans une colonne de type jsonb (colonne jsonfield dans cet exemple):

 1\d posts
 2                            Unlogged table "public.posts"
 3        Column         |            Type             | Collation | Nullable | Default
 4-----------------------+-----------------------------+-----------+----------+---------
 5 id                    | integer                     |           | not null |
 6 posttypeid            | integer                     |           | not null |
 7 acceptedanswerid      | integer                     |           |          |
 8 parentid              | integer                     |           |          |
 9 creationdate          | timestamp without time zone |           | not null |
10 score                 | integer                     |           |          |
11 viewcount             | integer                     |           |          |
12 body                  | text                        |           |          |
13 owneruserid           | integer                     |           |          |
14 lasteditoruserid      | integer                     |           |          |
15 lasteditordisplayname | text                        |           |          |
16 lasteditdate          | timestamp without time zone |           |          |
17 lastactivitydate      | timestamp without time zone |           |          |
18 title                 | text                        |           |          |
19 tags                  | text                        |           |          |
20 answercount           | integer                     |           |          |
21 commentcount          | integer                     |           |          |
22 favoritecount         | integer                     |           |          |
23 closeddate            | timestamp without time zone |           |          |
24 communityowneddate    | timestamp without time zone |           |          |
25 jsonfield             | jsonb                       |           |          |

Voici une requête toute simple d’agrégation :

1SELECT
2  avg(viewcount),
3  avg(answercount),
4  avg(commentcount),
5  avg(favoritecount)
6FROM posts;

 1                                                          QUERY PLAN
 2-------------------------------------------------------------------------------------------------------------------------------
 3 Aggregate  (cost=10265135.77..10265135.78 rows=1 width=128) (actual time=170221.557..170221.558 rows=1 loops=1)
 4   Buffers: shared hit=1 read=9186137
 5   I/O Timings: read=138022.290
 6   ->  Seq Scan on posts  (cost=0.00..9725636.88 rows=53949888 width=16) (actual time=0.014..153665.913 rows=53949886 loops=1)
 7         Buffers: shared hit=1 read=9186137
 8         I/O Timings: read=138022.290
 9 Planning Time: 0.240 ms
10 Execution Time: 170221.627 ms
11(8 rows)

La requête lit 70 Go de données et met environ 2min 50s à s’exécuter.

Maintenant la même requête, mais cette fois en utilisant les clés présentes dans le json.

1SELECT
2  avg((jsonfield ->> 'ViewCount')::int),
3  avg((jsonfield ->> 'AnswerCount')::int),
4  avg((jsonfield ->> 'CommentCount')::int),
5  avg((jsonfield ->> 'FavoriteCount')::int)
6FROM posts;

 1                           QUERY PLAN
 2------------------------------------------------------------------------------
 3 Aggregate  (cost=11883632.41..11883632.42 rows=1 width=128)
 4            (actual time=520917.028..520917.030 rows=1 loops=1)
 5   Buffers: shared hit=241116554 read=13625756
 6   ->  Seq Scan on posts  (cost=0.00..9725636.88 rows=53949888 width=570)
 7                          (actual time=0.972..70569.365 rows=53949886 loops=1)
 8         Buffers: shared read=9186138
 9 Planning Time: 0.118 ms
10 Execution Time: 520945.395 ms
11(10 rows)

La requête met environ 8min 40s à s’exécuter. En revanche le nombre de blocs lus semble un peu délirant :

Le Seq Scan indique comme tout à l’heure 70Go. En revanche, le nœud parent indique plus de 1.9 To lus!

Voici la taille de la table avec le paramétrage par défaut. Il faut savoir que pour certains enregistrements, le moteur va, soit compresser la ligne dans la heap, soit la compresser et la placer dans le toast.

 1SELECT
 2  pg_size_pretty(pg_relation_size(oid)) table_size,
 3  pg_size_pretty(pg_relation_size(reltoastrelid)) toast_size
 4FROM pg_class
 5WHERE relname = 'posts';
 6
 7 table_size | toast_size
 8------------+-----------
 9 70 GB      | 33 GB
10(1 row)

Comment expliquer les 1.9 To lus ?

Par curiosité, j’ai fait la même requête, mais avec une seule agrégation et j’obtiens environ 538 Go.

On peut se poser plusieurs questions :

Comment savoir si le moteur va lire le toast ?
Pourquoi un tel écart de temps d’exécution entre la version “colonne standard” et champ jsonb?
A quoi correspondent les compteurs dans le nœud Aggregate ?

Pour répondre à la première question, il suffit de lire la vue pg_statio_user_tables.

Avant exécution de la requête :

1select relid,schemaname,relname,heap_blks_read,heap_blks_hit,toast_blks_read,toast_blks_hit from pg_statio_all_tables where relname in ('posts','pg_toast_26180851');
2  relid   | schemaname |      relname      | heap_blks_read | heap_blks_hit | toast_blks_read | toast_blks_hit
3----------+------------+-------------------+----------------+---------------+-----------------+----------------
4 26180851 | public     | posts             |      422018238 |      87673549 |       129785076 |      628153337
5 26180854 | pg_toast   | pg_toast_26180851 |      129785076 |     628153337 |                 |
6(2 rows)

Après :

1  relid   | schemaname |      relname      | heap_blks_read | heap_blks_hit | toast_blks_read | toast_blks_hit
2----------+------------+-------------------+----------------+---------------+-----------------+----------------
3 26180851 | public     | posts             |      431204376 |      87673549 |       134156898 |      686299551
4 26180854 | pg_toast   | pg_toast_26180851 |      134156898 |     686299551 |                 |
5(2 rows)

Ce qui nous fait :

 1SELECT
 2pg_size_pretty(
 3    ((431204376 + 87673549) - (422018238 + 87673549) ) * 8*1024::bigint
 4) heap_buffers,
 5pg_size_pretty(
 6    ((134156898 + 686299551) - (129785076 + 628153337) ) * 8*1024::bigint
 7) toast_buffers;
 8
 9 heap_buffers | toast_buffers
10--------------+---------------
11 70 GB        | 477 GB
12(1 row)

Le moteur va bien lire le toast. En revanche les compteurs laissent penser que le moteur va lire plusieurs fois le toast.

Si je fais le même calcul, mais cette fois en effectuant l’agrégation que sur un seul champ, j’obtiens 119 Go (~ 477 Go / 4) J’imagine que le moteur lit le toast pour chaque fonction.

Ensuite, l’écart du temps d’exécution s’explique par plusieurs facteurs :

Le moteur va devoir lire et detoaster (décompresser) le toast
Faire des opérations supplémentaires sur le jsonb pour accéder à la valeur

Avec la première requête, le moteur n’avait pas à lire le toast. D’une part, il a moins de données à lire, d’autre part, il n’a pas à manipuler le json pour identifier la clé et extraire la valeur à calculer.

Enfin, les compteurs du nœud aggregate doivent correspondre aux données décompressées pour chaque fonction qui va lire dans le json. En effet, si on prend le total moins le seqscan de la table, donc que la partie toast, on a :

468 Go pour un seul champ
936 Go, le double pour deux champs
1873 Go pour les 4 champs (donc environ 4 x 468 Go)

C’est ce qui explique pourquoi on obtient une valeur aussi élevée.

Paramétrage avancé

Maintenant, on va encourager Postgres à placer le maximum de données dans le toast grâce à l’option toast_tuple_target apparue avec la version 11 de Postgres.

Cette option permet de manipuler le seuil à partir duquel les données sont stockée dans le toast.

Par ailleurs, étant sous Postgres 14, j’en ai profité pour utiliser l’algorithme de compression lz4 (paramètre default_toast_compression). Cet algorithme offre un ratio de compression similaire à pglz, cependant, il est beaucoup plus rapide (Voir ).

1CREATE TABLE posts_toast
2  WITH (toast_tuple_target = 128) AS
3    SELECT *
4    FROM posts;

Voici la taille de la table obtenue.

1SELECT
2  pg_size_pretty(pg_relation_size(oid)) table_size,
3  pg_size_pretty(pg_relation_size(reltoastrelid)) toast_size
4FROM pg_class
5WHERE relname = 'posts_toast';
6
7 table_size | toast_size
8------------+------------
9 59 GB      | 52 GB

Au total, la table avec le toast fait grosso-modo la même taille. Dans l’exemple avec la première table, il faut savoir que le moteur compresse aussi les données dans la heap.

Rejouons notre requête d’agrégation :

1SELECT
2  avg(viewcount),
3  avg(answercount),
4  avg(commentcount),
5  avg(favoritecount)
6FROM posts_toast;

Cette fois la requête lit 59 Go de données et met 2min 17 secondes. On a gagné environ 20% de temps d’exécution sur cet exemple.

On pourrait gagner beaucoup plus si la partie stockée en toast était plus importante. Le volume de donnée à lire dans la heap serait beaucoup plus réduit.

Par curiosité, j’ai aussi exécuté la requête qui fait l’agrégation depuis les données du champ json. J’obtiens un temps d’exécution de 7min 17s.

Conclusion

Résumé en quelques chiffres :

Agrégation type standard, stockage standard : 2min 50s
Agrégation type jsonb, stockage standard : 8min 40s
Agrégation type standard, stockage avec toast_tuple_target = 128 : 2min 17s
Agrégation type jsonb, stockage avec toast_tuple_target = 128 : 7min 17s

On constate que l’usage du JSON est bien plus couteux que d’utiliser les types standards. Le moteur doit faire plus d’opérations pour accéder à la valeur d’une clé json.

Par ailleurs, il est obligé de décompresser les données dans le toast pour y accéder. Néanmoins, on peut aussi jouer avec le paramètre toast_tuple_target pour pousser plus d’informations dans le toast. Ainsi, dans certains cas, cela peut permettre de réduire la quantité de données lues en évitant de lire le toast.

Bonus

Comment souvent dans Postgres, tout évolue au fil des versions. Le TOAST n’échappe pas à cette règle. Ainsi, quelques nouveautés pourraient apparaitre dans les prochaines versions :

Un premier patch a été proposé pour avoir plus de statistiques sur le toast : . L’idée, est d’avoir des statistiques sur la compression : gain compression, stockage inline ou séparé dans le toast…
Un second patch appelé . Celui-ci est beaucoup plus important. Il propose d’étendre le “toaster”. L’idée serait de pouvoir proposer différents “toaster” selon le type de donnée (notamment le JSONB).

Voir ↩︎
Il existe deux algorithmes de compression supportés : pglz (historique et intégré dans Postgres) et lz4 (depuis Postgres 14).
- Pour pglz, voir et
- Pour lz4, il s’agit d’une librarie externe. Voir .
↩︎
Voir les slides de la conférence d’Oleg Bartunov et Nikita Glukhov : ↩︎

Cas d'usages du partitionnement natif dans PostgreSQL

Wed, 01 Sep 2021 09:00:00 +0200

Après une période d’inactivité, je reprends l’écriture d’articles techniques sur Postgres. C’est aussi pour moi l’occasion de vous annoncer mon changement d’activité. Depuis courant 2021 je suis passé freelance pour permettre aux entreprises de bénéficier de mon expérience sur Postgres.

Table des matières

Histoire du partitionnement dans PostgreSQL

PostgreSQL permet depuis très longtemps de partitionner des tables en exploitant l’héritage de table. Toutefois, cette méthode était assez lourde à mettre en oeuvre : elle impliquait de mettre en place soi-même des triggers pour rediriger les écritures (moins performant que le partitionnement natif), le temps de planification pouvait augmenter fortement au-delà d’une centaine de partitions…

Le partitionnement natif est arrivé avec la version 10. C’est depuis cette version que le moteur est capable (entre autres) de diriger lui-même les écritures vers les bonnes tables, lire seulement les tables concernées, d’utiliser des algorithmes exploitant le partitionnement etc. Il offre ainsi de meilleures performances et une facilité d’exploitation. On peut entre autres :

Partitionner :
- Par liste
- Par hashage
- Par intervalles
Faire des partitionnements à plusieurs niveaux
Partitionner sur plusieurs colonnes
Utiliser des clés primaires et clés étrangères

Toutes ces fonctionnalités sont intéressantes, mais on en vient à se poser une question toute bête : quand mettre en oeuvre le partitionnement?

Je vais vous présenter plusieurs cas d’usages que j’ai pu rencontrer. Mais avant, voici quelques erreurs courantes sur le partitionnement.

Erreurs courantes

“Il faut partitionner dès que la volumétrie est importante”

Déjà, qu’est-ce qu’une volumétrie “importante”?

Certains diront que c’est au-delà de plusieurs centaines de Go, d’autres au-delà du téraoctet, d’autres encore au-delà du pétaoctet…

Il n’existe pas vraiment de réponse à cette question et globalement ça va dépendre du type d’activité : ratio INSERT/UPDATE/DELETE, type de SELECT (OLTP, OLAP…). Ca dépendra également du matériel. Il y a 10 ans, quand les serveurs n’avaient que quelques Go de RAM avec des disques mécaniques, il était probable qu’une base de quelques centaines de Go soit perçue comme une grosse base. Maintenant il n’est pas rare de voir des serveurs avec plus d’un téraoctet de RAM, des disques NVMe.

Ainsi, une base de quelques centaines de Go n’est plus considérée comme une grosse base. Mais plutôt comme une base de taille modeste.

Petite anecdote, pour se rassurer, un client m’a questionné si Postgres était déjà utilisé pour des volumétries “importantes”. On parlait alors d’une base d’une quarantaine de Go sur un serveur qui disposait de 64Go de RAM. Toutes les lectures se faisaient depuis le cache… :). J’ai pu le rassurer sur la taille de sa base qui était relativement modeste.

Il peut tout à fait être superflu de partitionner une base de quelques To comme il peut être nécessaire de partitionner une base de quelques centaines de Go. Par exemple, si l’activité consiste juste à ajouter des lignes à des tables et que les requêtes se résument à de simple WHERE colonne = 4 qui retournent quelques lignes. Un simple Btree fera l’affaire. Et si la requête retourne un nombre assez important de lignes, il est possible d’utiliser les index BRIN ou les bloom filter.

Les index BRIN présentent des bénéfices proches du partitionnement ou sharding en évitant la complexité de mise en oeuvre¹.

“Il faut partitionner pour répartir les données sur plusieurs disques”

L’idée serait de créer des partitions et des tablespaces sur différents disques afin de répartir les opérations d’entrées/sorties.

Pour PostgreSQL, un tablespace n’est ni plus, ni moins qu’un chemin vers un répertoire. Il est tout à fait possible de gérer le stockage au niveau du système d’exploitation et d’agréger plusieurs disques (en RAID10) par exemple. Ensuite, il suffit de stocker la table sur le volume créé. Ainsi, on peut répartir les I/O sur un ensemble de disques.

Dans ce cas, il n’est donc pas nécessaire de mettre en oeuvre le partitionnement. Toutefois, nous verrons un cas où il pourrait avoir du sens.

Maintenant nous allons nous intéresser à des cas d’usage “légitimes” du partitionnement.

Cas d’usages du partitionnement

Partitionner pour gérer la rétention

A cause du modèle MVCC, la suppression massive de données entraine de la fragmentation dans les tables.

Un cas d’usage possible est de partitionner par date. Supprimer les anciennes données revient à supprimer une partition complète. L’opération sera rapide et les tables ne seront pas fragmentées

Partitionner pour contrôler la fragmentation des index

L’ajout et modification de données dans une table fragmente les index au fil du temps. Pour faire simple, on ne peut pas récupérer l’espace libre dans un bloc tant qu’il n’est pas vide. Avec le temps les splits d’index créent du “vide” dans ce dernier et le seul moyen de récupérer cet espace est de reconstruire l’index.

On appelle cela le “bloat”. Il y a eu de nombreuses améliorations sur les dernières versions de Postgres:

Version 12, on peut lire dans les :

Improve performance and space utilization of btree indexes with many duplicates (Peter Geoghegan, Heikki Linnakangas)

Previously, duplicate index entries were stored unordered within their duplicate groups. This caused overhead during index inserts, wasted space due to excessive page splits, and it reduced VACUUM’s ability to recycle entire pages. Duplicate index entries are now sorted in heap-storage order.

Version 13, on peut lire dans les :

More efficiently store duplicates in B-tree indexes (Anastasia Lubennikova, Peter Geoghegan)

This allows efficient B-tree indexing of low-cardinality columns by storing duplicate keys only once. Users upgrading with pg_upgrade will need to use REINDEX to make an existing index use this feature.

Version 14, on peut lire dans les :

Allow btree index additions to remove expired index entries to prevent page splits (Peter Geoghegan)

This is particularly helpful for reducing index bloat on tables whose indexed columns are frequently updated.

Pour contrôler le bloat, on pourrait reconstruire l’index à intervalles réguliers (merci REINDEX CONCURRENTLY arrivé en version 12). Cette solution serait contraignante, car il faudrait régulièrement reconstruire l’intégralité de l’index.

Si la majorité des modifications sont faites sur les données récentes, par exemple: table de logs, commandes clients, rendez-vous… On pourrait imaginer un partitionnement par mois. Ainsi, à chaque début de mois on part sur une table “neuve” et on peut ré-indexer la précédente table pour supprimer le bloat.

On peut aussi en profiter pour faire un CLUSTER sur la table pour avoir une bonne corrélation des données avec le stockage.

Partitionner pour faciliter l’exécution de requête lorsque la cardinalité est faible

Petit à petit on va voir des cas d’usages un peu plus compliqués :)

Prenons un exemple : une table de commande comprenant un statut de livraison, au bout de quelques années 99% des commandes sont livrées (on l’espère!) et très peu en cours de paiement ou livraison.

Imaginons qu’on souhaite récupérer 100 commandes en cours de livraison. On va créer un index sur le statut et l’utiliser pour récupérer les enregistrements. En étant un peu astucieux, on peut créer un index partiel sur ce statut particulier. Problème, cet index va se fragmenter assez vite au fur et à mesure que les commandes seront livrées.

Dans ce cas on pourrait faire un partitionnement sur le statut. Ainsi, récupérer 100 commandes en cours de livraison revient à lire 100 enregistrements de la partition.

Partitionner pour obtenir de meilleures statistiques

Pour déterminer le meilleur plan d’exécution, Postgres prend des décisions à partir des statistiques d’une table. Ces statistiques sont obtenues à partir d’un échantillon de la table (le default_statistic_target qui vaut 100 par défaut).

Par défaut le moteur va collecter 300 x default_statistic_target lignes, soit 30 000 lignes. Avec une table de plusieurs centaines de millions de lignes, cet échantillon est parfois trop petit.

On peut augmenter de manière drastique la taille de l’échantillon, mais cette approche présente quelques inconvénients:

Ca alourdis le temps de planification
Ca alourdis le ANALYZE
Parfois ce n’est pas suffisant si les données sont mal réparties. Par exemple si on prend quelques centaines de milliers de lignes sur une table qui comprend plusieurs centaines de millions, on peut rater les lignes dont le statut est en livraison.

Avec le partitionnement on pourrait avoir un même échantillon, mais par partition, ce qui permet de gagner en précision.

Ce serait également utile quand on a des données corrélées entre colonnes. Je vais reprendre l’exemple des commandes. On a une année entière de commandes: toutes les commandes qui ont plus d’un mois sont livrées, celles du dernier mois sont livrées à 90% (10% sont en cours de livraison).

Intuitivement, si je cherche une commande en cours de livraison il y a plus de 6 mois je ne devrais pas avoir de résultat. Inversement, si je cherche des commandes en cours de livraison sur le dernier mois, je devrais obtenir 10% de la table. Or, le moteur ne le sait pas, pour lui les commandes en cours de livraison sont réparties sur toute la table.

Avec un partitionnement par date, il peut estimer qu’il n’y a pas de commande en cours de livraisons de plus d’un mois. Ce type d’approche permet surtout de réduire une erreur d’estimation dans un plan d’exécution.

Voici un exemple avec cette table de commandes, orders_p est la version partitionnée par mois de la table orders. Les données étant identiques dans les deux tables.

On peut remarquer que l’estimation est bien meilleure dans le cas où la table est partitionnée, le moteur ayant des statistiques par partition.

EXPLAIN ANALYZE
SELECT *
FROM orders_p
WHERE
    state = 'pending'
    AND c1 BETWEEN '2021-01-01' AND '2021-01-31';

                                                  QUERY PLAN
--------------------------------------------------------------------------------------------------------------
 Index Scan using orders_13_state_idx on orders_13  (cost=0.42..4.45 rows=1 width=12) (actual rows=0 loops=1)
   Index Cond: (state = 'pending'::text)
   Filter: ((c1 >= '2021-01-01'::date) AND (c1 <= '2021-01-31'::date))
 Planning Time: 0.120 ms
 Execution Time: 0.059 ms
(5 rows)

EXPLAIN ANALYZE
SELECT *
FROM orders
WHERE
    state = 'pending'
    AND c1 BETWEEN '2021-01-01' AND '2021-01-31';
                                                  QUERY PLAN
---------------------------------------------------------------------------------------------------------------
 Index Scan using orders_state_idx on orders  (cost=0.44..13168.25 rows=3978 width=12) (actual rows=0 loops=1)
   Index Cond: (state = 'pending'::text)
   Filter: ((c1 >= '2021-01-01'::date) AND (c1 <= '2021-01-31'::date))
   Rows Removed by Filter: 100161
 Planning Time: 0.188 ms
 Execution Time: 141.571 ms
(6 rows)

Maintenant prenons la même requête sur le dernier mois:

EXPLAIN ANALYZE
SELECT *
FROM orders_p
WHERE
    state = 'pending'
    AND c1 BETWEEN '2021-07-01' AND '2021-07-31';

                                                       QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
 Index Scan using orders_19_state_idx on orders_19  (cost=0.43..2417.50 rows=19215 width=12) (actual rows=20931 loops=1)
   Index Cond: (state = 'pending'::text)
   Filter: ((c1 >= '2021-07-01'::date) AND (c1 <= '2021-07-31'::date))
 Planning Time: 0.297 ms
 Execution Time: 32.618 ms
(5 rows)

EXPLAIN ANALYZE
SELECT *
FROM orders
WHERE
    state = 'pending'
    AND c1 BETWEEN '2021-07-01' AND '2021-07-31';

                                                     QUERY PLAN
--------------------------------------------------------------------------------------------------------------------
 Index Scan using orders_state_idx on orders  (cost=0.44..13168.25 rows=15008 width=12) (actual rows=20931 loops=1)
   Index Cond: (state = 'pending'::text)
   Filter: ((c1 >= '2021-07-01'::date) AND (c1 <= '2021-07-31'::date))
   Rows Removed by Filter: 79230
 Planning Time: 0.173 ms
 Execution Time: 146.326 ms
(6 rows)

Ici aussi on peut remarquer que l’estimation est meilleure.

partitionwise join & partitionwise aggregate

Un autre intérêt du partitionnement est de bénéficier de meilleurs algorithmes pour les jointures et agrégation.

Le partitionwise aggregate permet de faire une agregation ou un regroupement partition par partition. Un exemple vaut mieux qu’un long discours:

explain (analyze,timing off) select count(*), c1 from orders_p group by c1;
                                                  QUERY PLAN
--------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=508361.80..508365.45 rows=365 width=12) (actual rows=365 loops=1)
   Group Key: orders_01.c1
   ->  Append  (cost=0.00..408317.35 rows=20008890 width=4) (actual rows=20000000 loops=1)
         ->  Seq Scan on orders_01  (cost=0.00..22.70 rows=1270 width=4) (actual rows=0 loops=1)
         ->  Seq Scan on orders_02  (cost=0.00..22.70 rows=1270 width=4) (actual rows=0 loops=1)
[...]
         ->  Seq Scan on orders_19  (cost=0.00..45308.04 rows=2941004 width=4) (actual rows=2941004 loops=1)
         ->  Seq Scan on orders_20  (cost=0.00..131708.21 rows=8549421 width=4) (actual rows=8549421 loops=1)
 Planning Time: 0.576 ms
 Execution Time: 5273.217 ms
(25 rows)

set enable_partitionwise_aggregate to on;

explain (analyze,timing off) select count(*), c1 from orders_p group by c1;
                                                  QUERY PLAN
--------------------------------------------------------------------------------------------------------------
 Append  (cost=29.05..408343.83 rows=1765 width=12) (actual rows=365 loops=1)
   ->  HashAggregate  (cost=29.05..31.05 rows=200 width=12) (actual rows=0 loops=1)
         Group Key: orders_01.c1
         ->  Seq Scan on orders_01  (cost=0.00..22.70 rows=1270 width=4) (actual rows=0 loops=1)
   ->  HashAggregate  (cost=29.05..31.05 rows=200 width=12) (actual rows=0 loops=1)
         Group Key: orders_02.c1
         ->  Seq Scan on orders_02  (cost=0.00..22.70 rows=1270 width=4) (actual rows=0 loops=1)
[...]
   ->  HashAggregate  (cost=60013.06..60013.37 rows=31 width=12) (actual rows=31 loops=1)
         Group Key: orders_19.c1
         ->  Seq Scan on orders_19  (cost=0.00..45308.04 rows=2941004 width=4) (actual rows=2941004 loops=1)
   ->  HashAggregate  (cost=174455.32..174455.55 rows=24 width=12) (actual rows=24 loops=1)
         Group Key: orders_20.c1
         ->  Seq Scan on orders_20  (cost=0.00..131708.21 rows=8549421 width=4) (actual rows=8549421 loops=1)
 Planning Time: 1.461 ms
 Execution Time: 4669.315 ms
(63 rows)

Dans le premier cas l’agrégation se fait une fois pour toutes les tables, alors que dans le second exemple, on fait l’agrégation par partition. On peut également remarquer que le coût total est inférieur dans le plan avec agrégation par partition.

Le partitionwise join fonctionne sur le même principe, on fait une jointure partition par partition. C’est utile pour joindre deux tables partitionnées.

Stockage avec tiering

Enfin, un autre cas d’usage serait de vouloir stocker une partie de la table sur un stockage différent:

On peut stocker une table partitionnée dans des tablespaces différents. Par exemple les données récentes sur un tablespace rapide sur SSD NVMe. Puis les données plus rarement accédées sur un autre tablespace, avec des disques mécaniques moins couteux.

Cette approche peut aussi avoir du sens à l’heure du cloud où le stockage est très onéreux.

Conclusion

Voilà, je pense avoir fait le tour des principaux cas d’usages qui me venaient en tête.

Evidemment, la mise en oeuvre du partitionnement implique une plus grande complexité (gestion des partitions…) et des limitations qu’il faudra étudier en amont.

“BRIN indexes provide similar benefits to horizontal partitioning or sharding but without needing to explicitly declare partitions.” - ↩︎

Bigdata Hebdo - Un elephant peut en cacher un autre

Fri, 08 Nov 2019 12:00:00 +0100

pg_sampletolog : Une extension permettant de loguer un échantillon de requêtes

Mon, 28 Jan 2019 08:00:00 +0200

Cet article va vous présenter une extension que j’ai développé dans le but de loguer un échantillon de requêtes.

Lorsqu’un DBA est confronté à un problème de performance, il aura pour réflexe d’inspecter les logs, mais également la vue pg_stat_statements. Une requête coûteuse apparaîtra dans pg_stat_statements et dans les logs si la requête dépasse log_min_duration_statement. On peut ainsi rejouer la requête, obtenir son plan d’exécution et investiguer.

Pour aller encore plus loin, il est possible d’activer l’extension auto_explain. Ainsi on aura directement le plan de la requête. Au passage, l’option auto_explain.log_analyze n’implique pas une double exécution de la requête. Ce paramètre peut être activé sans crainte. Néanmoins cela peut s’avérer coûteux car le moteur doit mettre en place l’instrumentation pour obtenir le timing des différents nœuds. Si on a beaucoup de trafic, il est également possible de faire un échantillonnage avec auto_explain.sample_rate. Cette option peut produire une quantité importante de logs ce qui peut être problématique sur une instance à fort trafic.

J’ai été confronté à un problème tout simple : comment investiguer sur une requête dont le temps d’exécution est très court? C’est très simple “Regardez pg_stat_statements!”.

Voici ce qu’on pourrait obtenir sur un test pgbench :

1query               | SELECT abalance FROM pgbench_accounts WHERE aid = $1
2calls               | 12000
3total_time          | 214.564185000001
4min_time            | 0.013751
5max_time            | 0.044711
6mean_time           | 0.0178803487499999

La requête est normalisée. Sans paramètre impossible d’obtenir son plan. choisir un paramètre au hasard n’est pas la bonne solution : ce n’est pas forcément représentatif du véritable trafic de production.

Il y a quelques mois, j’ai proposé un patch pour loguer un échantillon de requêtes. Celui-ci a été intégré dans la version 12 en cours de développement :

 1commit 88bdbd3f746049834ae3cc972e6e650586ec3c9d
 2Author:     Alvaro Herrera <alvherre@alvh.no-ip.org>
 3AuthorDate: Thu Nov 29 18:42:53 2018 -0300
 4Commit:     Alvaro Herrera <alvherre@alvh.no-ip.org>
 5CommitDate: Thu Nov 29 18:42:53 2018 -0300
 6
 7    Add log_statement_sample_rate parameter
 8
 9    This allows to set a lower log_min_duration_statement value without
10    incurring excessive log traffic (which reduces performance).  This can
11    be useful to analyze workloads with lots of short queries.
12
13    Author: Adrien Nayrat
14    Reviewed-by: David Rowley, Vik Fearing
15    Discussion: https://postgr.es/m/c30ee535-ee1e-db9f-fa97-146b9f62caed@anayrat.info

Dans le fil des échanges, Nikolay Samokhvalov a émis l’idée d’avoir ce même type fonctionnalité mais au niveau d’une transaction :

J’ai également proposé un patch en ce sens :

Tout ça est intéressant, mais il faudra attendre la version 12. Et encore, rien ne garanti que le second patch soit commité (ou que le premier ne soit pas reverté).

Tout ça m’a donné l’idée et l’envie de créer une extension, c’est ainsi qu’est née .

Cette extension permet de :

Loguer un échantillon de requêtes
Loguer un échantillon de transactions
Choisir de loguer avant ou après l’exécution (pour un usage futur avec pgreplay)
Choisir de loguer tous les ordres de type DDL ou qui impliquent une modification des donnée

Elle fonctionne sur toutes les versions supportées, de la 9.4 à la 11.

L’activation se fait soit dans une session en chargeant l’extension : LOAD 'pg_sampletolog';. Ou dans le fichier postgresql.conf pour qu’elle soit chargée lors de toute nouvelle connexion avec session_preload_libraries = 'pg_sampletolog'

Si l’extension est bien chargée, ces nouveaux paramètres apparaissent :

 1select name from pg_settings where name like 'pg_sampletolog%';
 2                 name
 3----------------------------------------
 4 pg_sampletolog.disable_log_duration
 5 pg_sampletolog.log_before_execution
 6 pg_sampletolog.log_level
 7 pg_sampletolog.log_statement
 8 pg_sampletolog.statement_sample_rate
 9 pg_sampletolog.transaction_sample_rate
10(6 rows)

Voici quelques exemples :

Loguer seulement 10% des requêtes : pg_sampletolog.statement_sample_rate = 0.1

pg_sampelog va loguer 10% des requêtes. Pour chaque requête, le moteur va faire un tirage aléatoire à l’aide de la fonction random(). Le coût de cette fonction est très faible, donc il ne devrait pas y avoir d’impact sur les performances. Après quelques requêtes vous devriez obtenir ce genre de message dans les logs :

12019-01-27 12:50:39.361 CET [27047] LOG:  Sampled query duration: 0.014 ms - SELECT 1;

pg_sampelog va loguer la requête ainsi que son temps d’exécution.

Loguer seulement 10% des transactions : pg_sampletolog.transaction_sample_rate = 0.1

Le fonctionnement est le même que précédemment, à la différence que le moteur va choisir de loguer ou non toutes les requêtes d’une même transaction. Cela peut s’avérer très utile pour comprendre ce que fait un applicatif. Par exemple lorsqu’on ne peut pas accéder au code de l’applicatif ou lorsque les requêtes sont générées par un ORM. Exemple avec une transaction toute simple BEGIN; SELECT 1; SELECT 1; COMMIT;

12019-01-27 12:51:40.562 CET [27069] LOG:  Sampled transaction duration: 0.008 ms - SELECT 1;
22019-01-27 12:51:40.562 CET [27069] LOG:  Sampled transaction duration: 0.005 ms - SELECT 1;

Les deux SELECT ont bien été logués. En adaptant le log_line_prefix, on peut voir qu’il s’agit de la même transaction (regardez le lxid):

12019-01-27 16:32:16 CET [18556]: lxid=3/177,db=postgres,user=anayrat LOG:  Sampled transaction - SELECT 1;
22019-01-27 16:32:16 CET [18556]: lxid=3/177,db=postgres,user=anayrat LOG:  Sampled transaction - SELECT 1;

Loguer tous les ordres DDL : pg_sampletolog.log_statement = 'ddl':

pg_sampletolog va loguer tous les ordres de type DDL (CREATE TABLE,CREATE INDEX,…). Ca peut être utile si on veut juste loguer un échantillon en lecture mais tous les ordres DDL.

12019-01-27 12:53:47.564 CET [27103] LOG:  Sampled ddl CREATE TABLE t1(c1 int);

Loguer tous les ordres modifiants des données : pg_sampletolog.log_statement = 'mod':

Exactement comme l’exemple précédent, mais cette fois on logue aussi tous les UPDATES, DELETE. Cela comprend aussi les ordres DDL.

12019-01-27 12:59:54.043 CET [27160] LOG:  Sampled query duration: 0.246 ms - INSERT INTO t1 VALUES(1);
22019-01-27 13:00:16.468 CET [27160] LOG:  Sampled ddl CREATE INDEX ON t1(c1);

Loguer la requête avant son exécution : pg_sampletolog.log_before_execution = on

Cette option pourrait être utile pour rejouer logs avec .

Bonus

L’extension fonctionne aussi sur les serveurs secondaires.

Deuxième bonus

Si pg_stat_statements est activée, le queryid est également logué. Ca peut être très utile si vous identifiez une requête dans pg_stat_statements et que vous souhaitez la retrouver dans les logs à l’aide de son queryid.

Conclusion

Je me suis régalé avec ce projet personnel. J’ai beaucoup appris sur ~~les segfaults~~ le code de postgres et ça montre également les possibilités d’extension du moteur.

A l’avenir j’aimerai rajouter la possibilité de loguer un échantillon de requête correspondant à tel queryid. Il faut également que je regarde pour supporter les requêtes préparées.

Enfin, j’aimerai tester cette extension avec pgreplay : En loguant tous les ordres MOD (afin d’assurer la cohérence lors du rejeu) ainsi qu’une fraction des requêtes en lecture. Puis, restaurer un backup PITR et d’un côté rejouer le trafic en écriture. De l’autre côté, rejouer une portion du trafic en lecture avec un speed_factor. Par exemple x10 en rejouant 10% du trafic. Même si ça ne sera jamais parfait (il manquera la cohérence des lectures), je serai curieux de voir les résultats qu’on peut obtenir. Surtout dans le cas où loguer toutes les requêtes s’avérerait trop coûteux.

Je suis preneur de tout retour à faire sur .

PostgreSQL et updates heap-only-tuples - partie 3

Mon, 26 Nov 2018 08:00:00 +0100

Voici une série d’articles qui va porter sur une nouveauté de la version 11.

Durant le développement de cette version, une fonctionnalité a attiré mon attention. On peut la retrouver dans les releases notes :

Allow heap-only-tuple (HOT) updates for expression indexes when the values of the expressions are unchanged (Konstantin Knizhnik)

J’avoue que ce n’est pas très explicite et cette fonctionnalité nécessite quelques connaissances sur le fonctionnement du moteur que je vais essayer d’expliquer à travers plusieurs articles :

Cette fonctionnalité a été désactivée en 11.1 car elle pouvait conduire à des crash d’instance¹. J’ai tout de même choisi de publier ces articles car ils permettent de comprendre le mécanisme des updates HOT et le gain que pourrait apporter cette fonctionnalité.

Je remercie au passage Guillaume Lelarge pour la relecture de cet article ;).

Impact sur les performances

Voici un test assez simple pour mettre en évidence l’intérêt de cette fonctionnalité. On pourrait s’attendre à des gains en performances car le moteur évite de mettre à jour les index, ainsi qu’en matière de taille d’index, comme vu précédemment, on évite la fragmentation.

 1CREATE TABLE t5 (c1 jsonb, c2 int,c3 int);
 2CREATE INDEX ON t5 ((c1->>'prenom')) ;
 3CREATE INDEX ON t5 (c2);
 4INSERT INTO t5 VALUES ('{ "prenom":"adrien" , "valeur" : "1"}'::jsonb,1,1);
 5INSERT INTO t5 VALUES ('{ "prenom":"guillaume" , "valeur" : "2"}'::jsonb,2,2);
 6\dt+ t5
 7                   List of relations
 8 Schema | Name | Type  |  Owner   | Size  | Description
 9--------+------+-------+----------+-------+-------------
10 public | t5   | table | postgres | 16 kB |
11(1 row)
12
13\di+ t5*
14                           List of relations
15 Schema |    Name     | Type  |  Owner   | Table | Size  | Description
16--------+-------------+-------+----------+-------+-------+-------------
17 public | t5_c2_idx   | index | postgres | t5    | 16 kB |
18 public | t5_expr_idx | index | postgres | t5    | 16 kB |
19(2 rows)

Puis ce test pgbench :

1\set id  random(1, 100000)
2\set id2  random(1, 100000)
3
4UPDATE t5 SET c1 = '{"valeur": ":id", "prenom": "guillaume"}' WHERE c2=2;
5UPDATE t5 SET c1 = '{"valeur": ":id2", "prenom": "adrien"}' WHERE c2=1;

Qu’on exécute pendant 60 secondes, avec recheck_on_update=on (par défaut) :

 1pgbench -f test.sql -n -c6 -T 120
 2transaction type: test.sql
 3scaling factor: 1
 4query mode: simple
 5number of clients: 6
 6number of threads: 1
 7duration: 120 s
 8number of transactions actually processed: 2743163
 9latency average = 0.262 ms
10tps = 22859.646914 (including connections establishing)
11tps = 22859.938191 (excluding connections establishing)
12
13 \dt+ t5*
14                    List of relations
15 Schema | Name | Type  |  Owner   |  Size  | Description
16--------+------+-------+----------+--------+-------------
17 public | t5   | table | postgres | 376 kB |
18(1 row)
19\di+ t5*
20                           List of relations
21 Schema |    Name     | Type  |  Owner   | Table | Size  | Description
22--------+-------------+-------+----------+-------+-------+-------------
23 public | t5_c2_idx   | index | postgres | t5    | 16 kB |
24 public | t5_expr_idx | index | postgres | t5    | 32 kB |
25(2 rows)
26
27SELECT * FROM pg_stat_user_tables WHERE relname = 't5';
28-[ RECORD 1 ]-------+------------------------------
29relid               | 8890622
30schemaname          | public
31relname             | t5
32seq_scan            | 4
33seq_tup_read        | 0
34idx_scan            | 7999055
35idx_tup_fetch       | 7999055
36n_tup_ins           | 4
37n_tup_upd           | 7999055
38n_tup_del           | 0
39n_tup_hot_upd       | 7998236
40n_live_tup          | 2
41n_dead_tup          | 0
42n_mod_since_analyze | 0
43last_vacuum         |
44last_autovacuum     | 2018-09-19 06:29:37.690575+00
45last_analyze        |
46last_autoanalyze    | 2018-09-19 06:29:37.719911+00
47vacuum_count        | 0
48autovacuum_count    | 5
49analyze_count       | 0
50autoanalyze_count   | 5

Et maintenant avec recheck_on_update=off. Donc même jeu de donnée que précédemment mais cette fois l’index est créé avec cet ordre : CREATE INDEX ON t5 ((c1->>'prenom')) WITH (recheck_on_update=off);

 1pgbench -f test.sql -n -c6 -T 120
 2transaction type: test.sql
 3scaling factor: 1
 4query mode: simple
 5number of clients: 6
 6number of threads: 1
 7duration: 120 s
 8number of transactions actually processed: 1065688
 9latency average = 0.676 ms
10tps = 8880.679565 (including connections establishing)
11tps = 8880.796478 (excluding connections establishing)
12
13\dt+ t5
14                    List of relations
15 Schema | Name | Type  |  Owner   |  Size   | Description
16--------+------+-------+----------+---------+-------------
17 public | t5   | table | postgres | 9496 kB |
18(1 row)
19
20\di+ t5*
21                           List of relations
22 Schema |    Name     | Type  |  Owner   | Table |  Size  | Description
23--------+-------------+-------+----------+-------+--------+-------------
24 public | t5_c2_idx   | index | postgres | t5    | 768 kB |
25 public | t5_expr_idx | index | postgres | t5    | 58 MB  |
26(2 rows)
27
28select * from pg_stat_user_tables where relname = 't5';
29-[ RECORD 1 ]-------+------------------------------
30relid               | 8890635
31schemaname          | public
32relname             | t5
33seq_scan            | 2
34seq_tup_read        | 0
35idx_scan            | 2131376
36idx_tup_fetch       | 2131376
37n_tup_ins           | 2
38n_tup_upd           | 2131376
39n_tup_del           | 0
40n_tup_hot_upd       | 19
41n_live_tup          | 2
42n_dead_tup          | 0
43n_mod_since_analyze | 0
44last_vacuum         |
45last_autovacuum     | 2018-09-19 06:34:42.045905+00
46last_analyze        |
47last_autoanalyze    | 2018-09-19 06:34:42.251183+00
48vacuum_count        | 0
49autovacuum_count    | 3
50analyze_count       | 0
51autoanalyze_count   | 3

recheck_on_update	on	off	Gain
TPS	22859	8880	157%
t5 size	376 kB	9496 kB	-96%
t5_c2_idx size	16 kB	768 kB	-98%
t5_expr_idx size	32 kB	58 MB	-99.9%

L’écart de performance est assez impressionnant de même que la taille des tables et index.

J’ai refait le premier test en désactivant l’autovacuum et voici le résultat :

 1pgbench -f test.sql -n -c6 -T 120
 2transaction type: test.sql
 3scaling factor: 1
 4query mode: simple
 5number of clients: 6
 6number of threads: 1
 7duration: 120 s
 8number of transactions actually processed: 2752479
 9latency average = 0.262 ms
10tps = 22937.271749 (including connections establishing)
11tps = 22937.545872 (excluding connections establishing)
12
13
14select * from pg_stat_user_tables where relname = 't5';
15-[ RECORD 1 ]-------+--------
16relid               | 8890643
17schemaname          | public
18relname             | t5
19seq_scan            | 2
20seq_tup_read        | 0
21idx_scan            | 5504958
22idx_tup_fetch       | 5504958
23n_tup_ins           | 2
24n_tup_upd           | 5504958
25n_tup_del           | 0
26n_tup_hot_upd       | 5504258
27n_live_tup          | 2
28n_dead_tup          | 2416
29n_mod_since_analyze | 5504960
30last_vacuum         |
31last_autovacuum     |
32last_analyze        |
33last_autoanalyze    |
34vacuum_count        | 0
35autovacuum_count    | 0
36analyze_count       | 0
37autoanalyze_count   | 0
38
39\di+ t5*
40List of relations
41-[ RECORD 1 ]------------
42Schema      | public
43Name        | t5_c2_idx
44Type        | index
45Owner       | postgres
46Table       | t5
47Size        | 16 kB
48Description |
49-[ RECORD 2 ]------------
50Schema      | public
51Name        | t5_expr_idx
52Type        | index
53Owner       | postgres
54Table       | t5
55Size        | 40 kB
56Description |
57
58\dt+ t5
59List of relations
60-[ RECORD 1 ]---------
61Schema      | public
62Name        | t5
63Type        | table
64Owner       | postgres
65Size        | 1080 kB
66Description |

Puis le second test :

 1pgbench -f test.sql -n -c6 -T 120
 2transaction type: test.sql
 3scaling factor: 1
 4query mode: simple
 5number of clients: 6
 6number of threads: 1
 7duration: 120 s
 8number of transactions actually processed: 881434
 9latency average = 0.817 ms
10tps = 7345.208875 (including connections establishing)
11tps = 7345.304797 (excluding connections establishing)
12
13select * from pg_stat_user_tables where relname = 't5';
14-[ RECORD 1 ]-------+--------
15relid               | 8890651
16schemaname          | public
17relname             | t5
18seq_scan            | 2
19seq_tup_read        | 0
20idx_scan            | 1762868
21idx_tup_fetch       | 1762868
22n_tup_ins           | 2
23n_tup_upd           | 1762868
24n_tup_del           | 0
25n_tup_hot_upd       | 23
26n_live_tup          | 2
27n_dead_tup          | 1762845
28n_mod_since_analyze | 1762870
29last_vacuum         |
30last_autovacuum     |
31last_analyze        |
32last_autoanalyze    |
33vacuum_count        | 0
34autovacuum_count    | 0
35analyze_count       | 0
36autoanalyze_count   | 0
37
38\di+ t5*
39List of relations
40-[ RECORD 1 ]------------
41Schema      | public
42Name        | t5_c2_idx
43Type        | index
44Owner       | postgres
45Table       | t5
46Size        | 600 kB
47Description |
48-[ RECORD 2 ]------------
49Schema      | public
50Name        | t5_expr_idx
51Type        | index
52Owner       | postgres
53Table       | t5
54Size        | 56 MB
55Description |
56
57\dt+ t5*
58List of relations
59-[ RECORD 1 ]---------
60Schema      | public
61Name        | t5
62Type        | table
63Owner       | postgres
64Size        | 55 MB
65Description |

recheck_on_update	on	off	Gain
TPS	22937	7345	212%
t5 size	1080 kB	55 MB	-98%
t5_c2_idx size	16 kB	600 kB	-97%
t5_expr_idx size	40 kB	56 MB	-99.9%

A nouveau, l’écart de performance est important, il en est de même pour la taille des tables et index. On note également l’importance de laisser l’autovacuum activé.

Pourquoi avons-nous un tel écart de taille sur les index et la table ?

Pour les index, c’est dû au mécanisme expliqué plus haut. Le moteur a pu chaîner les enregistrements en évitant de mettre à jour l’index. L’index a quand même légèrement augmenté de taille, il arrive que le moteur ne peut pas faire de HOT, par exemple quand il n’y a plus de place dans le bloc.

Pour ce qui est de la taille de la table, lors du test avec autovacuum activé, l’autovacuum avait plus de difficultés à passer sur la table avec le HOT désactivé. L’index grossissant, cela engendrait plus de “travail”. Lors du test sans autovacuum, l’écart s’explique par le fait que même un simple SELECT peut nettoyer des blocs².

Rappelons que cette fonctionnalité a été retirée avec la version 11.1. J’avais écrit ces articles peu après la sortie de la version 11.0 et j’ai tout de même choisit de les publier afin de présenter le fonctionnement des UPDATES HOT. Espérons que cette fonctionnalité sera corrigée dans les versions à venir.

PostgreSQL et updates heap-only-tuples - partie 2

Mon, 19 Nov 2018 08:00:00 +0100

Voici une série d’articles qui va porter sur une nouveauté de la version 11.

Durant le développement de cette version, une fonctionnalité a attiré mon attention. On peut la retrouver dans les releases notes :

Allow heap-only-tuple (HOT) updates for expression indexes when the values of the expressions are unchanged (Konstantin Knizhnik)

Je remercie au passage Guillaume Lelarge pour la relecture de cet article ;).

L’article précédent présentait le fonctionnement des UDATES heap-only-tuple. Dans cet article nous allons voir le cas où Postgres ne fait pas d’UPDATE heap-ony-tuple. Ce qui nous permettra d’aborder la fonctionnalité qui aurait du arriver dans la version 11.

Cas avec un index sur une colonne mise à jour

Reprenons l’exemple précédent et rajoutons une colonne indexée :

1ALTER TABLE t3 ADD COLUMN c3 int;
2CREATE INDEX ON t3(c3);

Les UPDATE précédents portaient sur une colonne non-indexée. Que se passe-t-il si l’UPDATE porte sur c3 ?

État de la table et des index avant UPDATE :

 1SELECT lp,lp_flags,t_data,t_ctid FROM  heap_page_items(get_raw_page('t3',0));
 2 lp | lp_flags |       t_data       | t_ctid
 3----+----------+--------------------+--------
 4  1 |        2 |                    |
 5  2 |        1 | \x0200000002000000 | (0,2)
 6  3 |        0 |                    |
 7  4 |        0 |                    |
 8  5 |        1 | \x0100000006000000 | (0,5)
 9(5 rows)
10
11SELECT * FROM  bt_page_items(get_raw_page('t3_c1_idx',1));
12 itemoffset | ctid  | itemlen | nulls | vars |          data
13------------+-------+---------+-------+------+-------------------------
14          1 | (0,1) |      16 | f     | f    | 01 00 00 00 00 00 00 00
15          2 | (0,2) |      16 | f     | f    | 02 00 00 00 00 00 00 00
16(2 rows)
17
18SELECT * FROM  bt_page_items(get_raw_page('t3_c3_idx',1));
19 itemoffset | ctid  | itemlen | nulls | vars | data
20------------+-------+---------+-------+------+------
21          1 | (0,1) |      16 | t     | f    |
22          2 | (0,2) |      16 | t     | f    |
23(2 rows)

Pas de changement sur la table car la colonne c3 ne contient que des nulls, on peut le constater en observant l’index t3_c3_idx où nulls est à true sur chaque ligne.

 1UPDATE t3 SET c3 = 7 WHERE c1=1;
 2SELECT * FROM  bt_page_items(get_raw_page('t3_c3_idx',1));
 3 itemoffset | ctid  | itemlen | nulls | vars |          data
 4------------+-------+---------+-------+------+-------------------------
 5          1 | (0,3) |      16 | f     | f    | 07 00 00 00 00 00 00 00
 6          2 | (0,1) |      16 | t     | f    |
 7          3 | (0,2) |      16 | t     | f    |
 8(3 rows)
 9
10SELECT lp,lp_flags,t_data,t_ctid FROM  heap_page_items(get_raw_page('t3',0));
11 lp | lp_flags |           t_data           | t_ctid
12----+----------+----------------------------+--------
13  1 |        2 |                            |
14  2 |        1 | \x0200000002000000         | (0,2)
15  3 |        1 | \x010000000600000007000000 | (0,3)
16  4 |        0 |                            |
17  5 |        1 | \x0100000006000000         | (0,3)
18(5 rows)
19
20SELECT * FROM  bt_page_items(get_raw_page('t3_c1_idx',1));
21 itemoffset | ctid  | itemlen | nulls | vars |          data
22------------+-------+---------+-------+------+-------------------------
23          1 | (0,3) |      16 | f     | f    | 01 00 00 00 00 00 00 00
24          2 | (0,1) |      16 | f     | f    | 01 00 00 00 00 00 00 00
25          3 | (0,2) |      16 | f     | f    | 02 00 00 00 00 00 00 00
26(3 rows)

On remarque bien la nouvelle entrée dans l’index portant sur c3. La table contient bien un nouvel enregistrement. En revanche, l’index t3_c1_idx a également été mis à jour. Entraînant l’ajout d’une troisième entrée, même si la valeur de la colonne c1 n’a pas changée.

Après un VACUUM :

 1VACUUM t3;
 2SELECT * FROM  bt_page_items(get_raw_page('t3_c1_idx',1));
 3 itemoffset | ctid  | itemlen | nulls | vars |          data
 4------------+-------+---------+-------+------+-------------------------
 5          1 | (0,3) |      16 | f     | f    | 01 00 00 00 00 00 00 00
 6          2 | (0,2) |      16 | f     | f    | 02 00 00 00 00 00 00 00
 7(2 rows)
 8
 9SELECT lp,lp_flags,t_data,t_ctid FROM  heap_page_items(get_raw_page('t3',0));
10 lp | lp_flags |           t_data           | t_ctid
11----+----------+----------------------------+--------
12  1 |        0 |                            |
13  2 |        1 | \x0200000002000000         | (0,2)
14  3 |        1 | \x010000000600000007000000 | (0,3)
15  4 |        0 |                            |
16  5 |        0 |                            |
17(5 rows)
18
19SELECT * FROM  bt_page_items(get_raw_page('t3_c3_idx',1));
20 itemoffset | ctid  | itemlen | nulls | vars |          data
21------------+-------+---------+-------+------+-------------------------
22          1 | (0,3) |      16 | f     | f    | 07 00 00 00 00 00 00 00
23          2 | (0,2) |      16 | t     | f    |
24(2 rows)

Le moteur a nettoyé les index et la table. La première ligne de la table n’a plus le flag REDIRECT.

Nouveauté de la version : 11 heap-only-tuple (HOT) avec index fonctionnels

Lorsqu’un index fonctionnel porte sur la colonne modifiée, il peut arriver que le résultat de l’expression reste inchangé malgré la mise à jour de la colonne. La clé dans l’index serait donc inchangée.

Prenons un exemple : un index fonctionnel sur une clé spécifique d’un objet JSON.

 1CREATE TABLE t4 (c1 jsonb, c2 int,c3 int);
 2CREATE INDEX ON t4 ((c1->>'prenom')) ;
 3CREATE INDEX ON t4 (c2);
 4INSERT INTO t4 VALUES ('{ "prenom":"adrien" , "ville" : "valence"}'::jsonb,1,1);
 5INSERT INTO t4 VALUES ('{ "prenom":"guillaume" , "ville" : "lille"}'::jsonb,2,2);
 6
 7-- changement qui ne porte pas sur prenom, on change que la ville
 8UPDATE t4 SET c1 = '{"ville": "valence (#soleil)", "prenom": "guillaume"}' WHERE c2=2;
 9SELECT pg_stat_get_xact_tuples_hot_updated('t4'::regclass);
10 pg_stat_get_xact_tuples_hot_updated
11-------------------------------------
12                                   0
13(1 row)
14
15UPDATE t4 SET c1 = '{"ville": "nantes", "prenom": "guillaume"}' WHERE c2=2;
16SELECT pg_stat_get_xact_tuples_hot_updated('t4'::regclass);
17 pg_stat_get_xact_tuples_hot_updated
18-------------------------------------
19                                   0
20(1 row)

La fonction pg_stat_get_xact_tuples_hot_updated indique le nombre de lignes mises à jour par le mécanisme HOT.

Les deux UPDATE n’ont fait que modifier la clé “ville” et pas la clé “prenom”. Ce qui n’entraîne pas de modification de l’index car il n’indexe que la clé “prenom”.

Le moteur n’a pas pu faire d’HOT. En effet, pour lui, l’UPDATE a porté sur la colonne et l’index doit être mis à jour.

Avec la version 11, le moteur est capable de constater que le résultat de l’expression ne change pas. Effectuons le même test sur la version 11 :

 1CREATE TABLE t4 (c1 jsonb, c2 int,c3 int);
 2-- CREATE INDEX ON t4 ((c1->>'prenom'))  WITH (recheck_on_update='false');
 3CREATE INDEX ON t4 ((c1->>'prenom')) ;
 4CREATE INDEX ON t4 (c2);
 5INSERT INTO t4 VALUES ('{ "prenom":"adrien" , "ville" : "valence"}'::jsonb,1,1);
 6INSERT INTO t4 VALUES ('{ "prenom":"guillaume" , "ville" : "lille"}'::jsonb,2,2);
 7
 8-- changement qui ne porte pas sur prenom
 9UPDATE t4 SET c1 = '{"ville": "valence (#soleil)", "prenom": "guillaume"}' WHERE c2=2;
10SELECT pg_stat_get_xact_tuples_hot_updated('t4'::regclass);
11 pg_stat_get_xact_tuples_hot_updated
12-------------------------------------
13                                   1
14(1 row)
15
16UPDATE t4 SET c1 = '{"ville": "nantes", "prenom": "guillaume"}' WHERE c2=2;
17SELECT pg_stat_get_xact_tuples_hot_updated('t4'::regclass);
18 pg_stat_get_xact_tuples_hot_updated
19-------------------------------------
20                                   2
21(1 row)

Cette fois, le moteur a bien utilisé le mécanisme HOT. On peut le vérifier en regardant le contenu physique de l’index avec pageinspect :

Version 10 :

1SELECT * FROM  bt_page_items(get_raw_page('t4_expr_idx',1));
2itemoffset | ctid  | itemlen | nulls | vars |                      data
3------------+-------+---------+-------+------+-------------------------------------------------
4         1 | (0,1) |      16 | f     | t    | 0f 61 64 72 69 65 6e 00
5         2 | (0,4) |      24 | f     | t    | 15 67 75 69 6c 6c 61 75 6d 65 00 00 00 00 00 00
6         3 | (0,3) |      24 | f     | t    | 15 67 75 69 6c 6c 61 75 6d 65 00 00 00 00 00 00
7         4 | (0,2) |      24 | f     | t    | 15 67 75 69 6c 6c 61 75 6d 65 00 00 00 00 00 00
8(4 rows)

Version 11 :

1SELECT * FROM  bt_page_items(get_raw_page('t4_expr_idx',1));
2itemoffset | ctid  | itemlen | nulls | vars |                      data
3------------+-------+---------+-------+------+-------------------------------------------------
4         1 | (0,1) |      16 | f     | t    | 0f 61 64 72 69 65 6e 00
5         2 | (0,2) |      24 | f     | t    | 15 67 75 69 6c 6c 61 75 6d 65 00 00 00 00 00 00
6(2 rows)

Ce comportement peut se contrôler grâce à une nouvelle option lors de la création de l’index : recheck_on_update.

Par défaut à on, le moteur effectue la vérification du résultat de l’expression pour faire un UPDATE HOT. On peut le paramétrer à off s’il y a de fortes chances pour que le résultat de l’expression change lors d’un UPDATE. Cela permet d’éviter d’exécuter l’expression inutilement.

A noter également que le moteur évite l’évaluation de l’expression si son coût est supérieur à 1000.

Dans le troisième et dernier article, nous verrons un cas un peu plus concret pour voir l’impact en terme de performance et de volumétrie.

↩︎

PostgreSQL et updates heap-only-tuples - partie 1

Mon, 12 Nov 2018 08:00:00 +0100

Voici une série d’articles qui va porter sur une nouveauté de la version 11.

Durant le développement de cette version, une fonctionnalité a attiré mon attention. On peut la retrouver dans les releases notes :

Allow heap-only-tuple (HOT) updates for expression indexes when the values of the expressions are unchanged (Konstantin Knizhnik)

Je remercie au passage Guillaume Lelarge pour la relecture de cet article ;).

Fonctionnement MVCC

Dans l’implémentation de Postgres, le moteur ne met pas à jour une ligne directement : il duplique l’enregistrement et renseigne des informations de visibilité.

Pourquoi ce fonctionnement?

Il y a une composante capitale à prendre en compte quand on travaille avec un SGBG : la concurrence d’accès.

La ligne que vous êtes en train de modifier est peut être utilisée par une transaction antérieure. Une sauvegarde en cours par exemple :)

Pour cela, les SGBD ont adopté différentes techniques :

Modifier l’enregistrement et stocker les versions antérieures sur un autre emplacement. C’est ce que fait oracle par exemple avec les undo logs.
Dupliquer l’enregistrement et stocker des informations de visibilité pour savoir quelle ligne est visible par telle ou telle transaction. Cela nécessite d’avoir un mécanisme de nettoyage des lignes qui ne sont plus visibles par personne. C’est l’implémentation dans Postgres et le vacuum a pour rôle d’effectuer ce nettoyage.

Prenons une table toute simple et regardons son contenu évoluer à l’aide de l’extension pageinspect :

 1CREATE TABLE t2(c1 int);
 2INSERT INTO t2 VALUES (1);
 3SELECT lp,t_data FROM  heap_page_items(get_raw_page('t2',0));
 4 lp |   t_data
 5----+------------
 6  1 | \x01000000
 7(1 row)
 8
 9UPDATE t2 SET c1 = 2 WHERE c1 = 1;
10SELECT lp,t_data FROM  heap_page_items(get_raw_page('t2',0));
11 lp |   t_data
12----+------------
13  1 | \x01000000
14  2 | \x02000000
15(2 rows)
16
17VACUUM t2;
18SELECT lp,t_data FROM  heap_page_items(get_raw_page('t2',0));
19 lp |   t_data
20----+------------
21  1 |
22  2 | \x02000000
23(2 rows)

On peut voir que le moteur a dupliqué la ligne et le vacuum a nettoyé l’emplacement pour un usage futur.

Mécanisme d’update heap-only-tuple

Prenons un autre cas, un peu plus compliqué, une table avec deux colonnes et un index sur une des deux colonnes :

 1CREATE TABLE t3(c1 int,c2 int);
 2CREATE INDEX ON t3(c1);
 3INSERT INTO t3(c1,c2) VALUES (1,1);
 4INSERT INTO t3(c1,c2) VALUES (2,2);
 5SELECT ctid,* FROM t3;
 6 ctid  | c1 | c2
 7-------+----+----
 8 (0,1) |  1 |  1
 9 (0,2) |  2 |  2
10(2 rows)

De la même façon qu’il est possible de lire les blocs d’une table, il est possible de lire les blocs d’un index avec pageinspect :

1SELECT * FROM  bt_page_items(get_raw_page('t3_c1_idx',1));
2 itemoffset | ctid  | itemlen | nulls | vars |          data
3------------+-------+---------+-------+------+-------------------------
4          1 | (0,1) |      16 | f     | f    | 01 00 00 00 00 00 00 00
5          2 | (0,2) |      16 | f     | f    | 02 00 00 00 00 00 00 00
6(2 rows)

Jusque-là, c’est assez simple, ma table contient deux enregistrements et l’index contient également deux enregistrements pointant vers les blocs correspondants de la table (colonne ctid).

Si je mets à jour la colonne c1, avec la nouvelle valeur 3 par exemple, l’index devra être mis à jour.

Maintenant, si je mets à jour la colonne c2, est-ce que l’index portant sur c1 sera mis à jour ?

Au premier abord, on pourrait se dire non car c1 n’est pas modifiée.

Mais à cause du modèle MVCC présenté plus haut, en théorie, la réponse sera oui : nous venons de voir que le moteur va dupliquer la ligne, son emplacement physique sera donc différent (le ctid suivant sera (0,3)).

Vérifions le :

 1UPDATE t3 SET c2 = 3 WHERE c1=1;
 2SELECT lp,t_data,t_ctid FROM  heap_page_items(get_raw_page('t3',0));
 3 lp |       t_data       | t_ctid
 4----+--------------------+--------
 5  1 | \x0100000001000000 | (0,3)
 6  2 | \x0200000002000000 | (0,2)
 7  3 | \x0100000003000000 | (0,3)
 8(3 rows)
 9
10
11SELECT * FROM  bt_page_items(get_raw_page('t3_c1_idx',1));
12 itemoffset | ctid  | itemlen | nulls | vars |          data
13------------+-------+---------+-------+------+-------------------------
14          1 | (0,1) |      16 | f     | f    | 01 00 00 00 00 00 00 00
15          2 | (0,2) |      16 | f     | f    | 02 00 00 00 00 00 00 00
16(2 rows)

La lecture du bloc de la table confirme bien que la ligne a été dupliquée. En observant attentivement le champ t_data, on arrive à distinguer le 1 de la colonne c1 et le 3 de la colonne c2.

En lisant le bloc de l’index, on constate que son contenu n’a pas bougé ! Si je cherche la ligne WHERE c1 = 1, l’index m’oriente vers l’enregistrement (0,1) qui correspond à l’ancienne ligne !

Que s’est-il passé ?

En réalité, nous venons de mettre en évidence un mécanisme un peu particulier appelé heap-only-tuple alias HOT. Lorsqu’une colonne est mise à jour, qu’aucun index ne pointe vers cette colonne et qu’on peut insérer l’enregistrement dans le même bloc, le moteur va se contenter de faire un pointeur entre l’ancien enregistrement le nouveau.

Cela permet au moteur d’éviter d’avoir à mettre à jour l’index. Avec tout ce que cela entraîne :

Des opérations en lecture/écriture évitées
Réduction de la fragmentation de l’index et donc de sa taille (il est difficile de réutiliser les anciens emplacements d’un index)

Si vous observez le bloc de la table, la colonne t_ctid de la première ligne pointe vers (0,3). Si la ligne était à nouveau mise à jour, la première ligne de la table pointerait vers la ligne (0,3) et la ligne (0,3) pointerait vers (0,4), formant ce qu’on appelle une chaîne. Un vacuum nettoierait les espaces libres mais conserverait toujours la première ligne qui pointerait vers le dernier enregistrement.

On modifie une ligne et l’index ne change toujours pas :

 1UPDATE t3 SET c2 = 4 WHERE c1=1;
 2SELECT * FROM  bt_page_items(get_raw_page('t3_c1_idx',1));
 3 itemoffset | ctid  | itemlen | nulls | vars |          data
 4------------+-------+---------+-------+------+-------------------------
 5          1 | (0,1) |      16 | f     | f    | 01 00 00 00 00 00 00 00
 6          2 | (0,2) |      16 | f     | f    | 02 00 00 00 00 00 00 00
 7(2 rows)
 8
 9SELECT lp,t_data,t_ctid FROM  heap_page_items(get_raw_page('t3',0));
10 lp |       t_data       | t_ctid
11----+--------------------+--------
12  1 | \x0100000001000000 | (0,3)
13  2 | \x0200000002000000 | (0,2)
14  3 | \x0100000003000000 | (0,4)
15  4 | \x0100000004000000 | (0,4)
16(4 rows)

Vacuum nettoie les emplacements disponibles :

1VACUUM t3;
2SELECT lp,t_data,t_ctid FROM  heap_page_items(get_raw_page('t3',0));
3 lp |       t_data       | t_ctid
4----+--------------------+--------
5  1 |                    |
6  2 | \x0200000002000000 | (0,2)
7  3 |                    |
8  4 | \x0100000004000000 | (0,4)
9(4 rows)

Un update va réutiliser le second emplacement et l’index reste inchangé. Observez la valeur de la colonne t_ctid pour reconstituer la chaîne :

 1UPDATE t3 SET c2 = 5 WHERE c1=1;
 2SELECT lp,t_data,t_ctid FROM  heap_page_items(get_raw_page('t3',0));
 3 lp |       t_data       | t_ctid
 4----+--------------------+--------
 5  1 |                    |
 6  2 | \x0200000002000000 | (0,2)
 7  3 | \x0100000005000000 | (0,3)
 8  4 | \x0100000004000000 | (0,3)
 9(4 rows)
10
11
12SELECT * FROM  bt_page_items(get_raw_page('t3_c1_idx',1));
13 itemoffset | ctid  | itemlen | nulls | vars |          data
14------------+-------+---------+-------+------+-------------------------
15          1 | (0,1) |      16 | f     | f    | 01 00 00 00 00 00 00 00
16          2 | (0,2) |      16 | f     | f    | 02 00 00 00 00 00 00 00
17(2 rows)

Euh, la première ligne est vide et le moteur a réutilisé le troisième emplacement ?

En fait, une information n’apparaît pas dans pageinspect. Allons lire directement le bloc avec :

Note : Il faut demander un CHECKPOINT au préalable. Dans le cas contraire, le bloc pourrait ne pas encore être écrit sur le disque.

 1pg_filedump  11/main/base/16606/8890510
 2
 3*******************************************************************
 4* PostgreSQL File/Block Formatted Dump Utility - Version 10.1
 5*
 6* File: 11/main/base/16606/8890510
 7* Options used: None
 8*
 9* Dump created on: Sun Sep  2 13:09:53 2018
10*******************************************************************
11
12Block    0 ********************************************************
13<Header> -----
14 Block Offset: 0x00000000         Offsets: Lower      40 (0x0028)
15 Block: Size 8192  Version    4            Upper    8096 (0x1fa0)
16 LSN:  logid     52 recoff 0xc39ea148      Special  8192 (0x2000)
17 Items:    4                      Free Space: 8056
18 Checksum: 0x0000  Prune XID: 0x0000168b  Flags: 0x0001 (HAS_FREE_LINES)
19 Length (including item array): 40
20
21<Data> ------
22 Item   1 -- Length:    0  Offset:    4 (0x0004)  Flags: REDIRECT
23 Item   2 -- Length:   32  Offset: 8160 (0x1fe0)  Flags: NORMAL
24 Item   3 -- Length:   32  Offset: 8096 (0x1fa0)  Flags: NORMAL
25 Item   4 -- Length:   32  Offset: 8128 (0x1fc0)  Flags: NORMAL

La première ligne contient Flags: REDIRECT. Ceci indique que cette ligne correspond à une redirection HOT. C’est documenté dans src/include/storage/itemid.h :

1/*
2 * lp_flags has these possible states.  An UNUSED line pointer is available
3 * for immediate re-use, the other states are not.
4 */
5#define LP_UNUSED       0       /* unused (should always have lp_len=0) */
6#define LP_NORMAL       1       /* used (should always have lp_len>0) */
7#define LP_REDIRECT     2       /* HOT redirect (should have lp_len=0) */
8#define LP_DEAD         3       /* dead, may or may not have storage */

Il est AUSSI possible de le voir avec pageinspect en affichant la colonne lp_flags:

1SELECT lp,lp_flags,t_data,t_ctid FROM  heap_page_items(get_raw_page('t3',0));
2 lp | lp_flags |       t_data       | t_ctid
3----+----------+--------------------+--------
4  1 |        2 |                    |
5  2 |        1 | \x0200000002000000 | (0,2)
6  3 |        1 | \x0100000005000000 | (0,3)
7  4 |        1 | \x0100000004000000 | (0,3)
8(4 rows)

Si on refait un UPDATE, puis VACUUM, suivi d’un CHECKPOINT pour écrire le bloc sur disque :

 1SELECT lp,lp_flags,t_data,t_ctid FROM  heap_page_items(get_raw_page('t3',0));
 2 lp | lp_flags |       t_data       | t_ctid
 3----+----------+--------------------+--------
 4  1 |        2 |                    |
 5  2 |        1 | \x0200000002000000 | (0,2)
 6  3 |        0 |                    |
 7  4 |        0 |                    |
 8  5 |        1 | \x0100000006000000 | (0,5)
 9(5 rows)
10
11CHECKPOINT;
12
13pg_filedump  11/main/base/16606/8890510
14
15*******************************************************************
16* PostgreSQL File/Block Formatted Dump Utility - Version 10.1
17*
18* File: 11/main/base/16606/8890510
19* Options used: None
20*
21* Dump created on: Sun Sep  2 13:16:12 2018
22*******************************************************************
23
24Block    0 ********************************************************
25<Header> -----
26 Block Offset: 0x00000000         Offsets: Lower      44 (0x002c)
27 Block: Size 8192  Version    4            Upper    8128 (0x1fc0)
28 LSN:  logid     52 recoff 0xc39ea308      Special  8192 (0x2000)
29 Items:    5                      Free Space: 8084
30 Checksum: 0x0000  Prune XID: 0x00000000  Flags: 0x0005 (HAS_FREE_LINES|ALL_VISIBLE)
31 Length (including item array): 44
32
33<Data> ------
34 Item   1 -- Length:    0  Offset:    5 (0x0005)  Flags: REDIRECT
35 Item   2 -- Length:   32  Offset: 8160 (0x1fe0)  Flags: NORMAL
36 Item   3 -- Length:    0  Offset:    0 (0x0000)  Flags: UNUSED
37 Item   4 -- Length:    0  Offset:    0 (0x0000)  Flags: UNUSED
38 Item   5 -- Length:   32  Offset: 8128 (0x1fc0)  Flags: NORMAL
39
40
41*** End of File Encountered. Last Block Read: 0 ***

Le moteur a conservé la première ligne (flag REDIRECT) et écrit une nouvelle ligne à l’emplacement 5.

Il y a cependant quelques cas où le moteur ne peut pas utiliser ce mécanisme :

Lorsqu’il n’y a plus de place dans le bloc et qu’il doit écrire un autre bloc. On peut en déduire que la fragmentation de la table est ici bénéfique pour bénéficier du HOT.
Un index porte sur la colonne mise à jour. Dans ce cas le moteur doit mettre à jour l’index. Le moteur peut détecter s’il y a eu un changement en effectuant une comparaison binaire entre la nouvelle valeur et la précédente ².

Dans le prochain article nous verrons justement un exemple où le moteur ne peut pas employer le mécanisme HOT. Puis, la nouveauté de la version 11 où le moteur peut utiliser se mécanisme.

Les évolutions de PostgreSQL pour le traitement des fortes volumétries

Mon, 16 Apr 2018 09:00:00 +0200

Introduction

Depuis quelques années, PostgreSQL s’est doté de nombreuses améliorations pour le traitement des grosses volumétries.

Ce premier article va tenter de les lister, nous verrons qu’elles peuvent être de différents ordres :

Parallélisation
Amélioration intrinsèque du traitement des requêtes
Partitionnement
Méthodes d’accès
Tâches de maintenance
Ordres SQL

Afin de conserver de la clarté, l’explication de chaque fonctionnalité restera succincte.

Note : cet article a été écrit durant la phase de développement de la version 11. J’ai intégré des nouveautés de la version 11. Tant que celle-ci n’est pas sortie, ces nouveautés peuvent être retirées.

Je remercie au passage Guillaume Lelarge pour la relecture de cet article ;).

Table des matières

SQL

TABLESAMPLE (9.5)

L’ordre TABLESAMPLE (apparu avec la version 9.5) permet de faire une requête sur un échantillon. Cela permet d’avoir un aperçu du résultat. Comme en statistique, plus l’échantillon sera important, plus le résultat sera proche du résultat réel.

GROUPING SETS (9.5)

Toujours avec la version 9.5, PostgreSQL dispose de nouvelles clauses permettant de faire des agrégations multiples appelées . Les nouveaux agrégats sont : GROUPING SETS, ROLLUP, CUBE.

Voir cet article de Depesz :

À noter que la version 10 apporte des gains très significatifs grâce à l’amélioration des fonctions de hachage.

Héritage sur les foreign tables (9.5)

Depuis la version 9.5, il est possible de déclarer des foreign tables comme tables enfants. Il est ainsi possible de distribuer les données sur différents serveurs et d’y accéder depuis une seule instance. Cette technique s’apparente à du sharding.

Voir cet article de Michael Paquier :

Parallélisation

PostgreSQL étant multi-processus, le traitement d’une requête ne se faisait que sur un coeur. On retrouve de nombreux posts où les utilisateurs se plaignent de ce fonctionnement :

Depuis la version 9.6, le moteur est capable de mobiliser plusieurs processus (appelé workers) pour le traitement d’une requête. Cette avancée majeure a été l’aboutissement de plusieurs années de travail. Il a fallu mettre en place toute une infrastructure pour permettre au moteur d’utiliser plusieurs processus. Voir cet article de Robert Haas :

Parcours séquentiel (9.6)

Depuis la version 9.6, PostgreSQL est capable d’utiliser plusieurs processus pour paralléliser l’opération de lecture d’une table. Cette opération correspond au noeud Parallel Seq Scan.

Parcours d’index (10)

La version 10 a permis d’étendre la parallélisation aux parcours d’index.

Ainsi le moteur est maintenant capable d’utiliser plusieurs processus pour ces types de parcours (uniquement pour les index de type BTree) :

Index Scan
Bitmap heap scan
Index Only Scan

Jointures (9.6, 10, 11)

En plus de la parallélisation des parcours séquentiels, la version 9.6 apportait la possibilité de paralléliser les opérations de jointure aux noeuds suivants :

Nested-loop
Hash join

La version 10 a permis d’étendre la parallélisation au noeud de type merge join.

Enfin, la version 11 apporte un gros changement avec le parallel hash join. Avec les versions précédentes, chaque worker devait construire sa propre table de hachage. Il y avait une grosse perte d’efficacité :

Plusieurs workers faisaient en réalité la même opération (donc utilisation de plus de ressources de type CPU)
Une même table de hachage existait plusieurs fois en mémoire (donc utilisation de plus de ressources de type IO)

Le parallel hash join permet aux workers de paralléliser le remplissage d’une seule table de hachage, partagée.

L’auteur principal de cette fonctionnalité a écrit un excellent article :

Agrégation (9.6)

Toujours avec la version 9.6, le moteur est capable d’utiliser plusieurs workers pour réaliser des opérations d’agrégation (COUNT, SUM…).

En réalité, chaque worker fait une agrégation partielle (Partial Aggregate), puis un noeud parent se charge de faire l’agrégation finale (Finalize Aggregate).

Union d’ensembles (11)

La version 11 apporte la possibilité de paralléliser les opérations d’union d’ensemble (noeud append), par exemple lors de l’utilisation d’un UNION ou lorsque des tables sont héritées.

Méthodes d’accès

On confond souvent index et méthodes d’accès en employant régulièrement le terme “index”.

En réalité, au sens large, dans le domaine des bases de données, un index est une méthode d’accès.

Index BRIN (9.5)

Depuis la version 9.5, PostgreSQL propose un type d’index particulier : BRIN pour Block Range INdexes.

Ce type d’index contient le résumé d’un ensemble de blocs. Ils sont donc très compacts et tiennent facilement en mémoire.

Ils sont particulièrement adaptés aux fortes volumétries avec des requêtes manipulant un gros volume de données. Attention, il est très important qu’il y ait une forte corrélation entre les données et leur emplacement pour que leur efficacité soit optimale.

J’ai présenté le fonctionnement de ce type d’index lors du PGDay France 2016 à Lille :

BLOOM filters (9.6)

Depuis la version 9.6, il est possible d’utiliser des . Sans rentrer dans les détails, ce type de structure de donnée permet d’affirmer avec certitude que l’information recherchée ne se trouve pas un ensemble. Inversement, l’information peut (avec une certaine probabilité) se trouver dans un autre ensemble.

L’intérêt des filtres bloom, c’est qu’ils sont très compacts et permettent de répondre à des recherches multi-colonnes à partir d’un seul index.

Voir cet article de Depesz :

Partionnement

La partitionnement existait sous forme d’héritage de table. Cependant, cette approche avait l’inconvénient de nécessiter la mise en place de triggers pour router les écritures dans les bonnes tables. L’impact sur les performances était important.

La version 10 intègre une gestion native du partitionnement. Ainsi, il n’est plus nécessaire de mettre en place des triggers. Les opérations de maintenance sont facilitées et les performances sont améliorées.

Types de partitionnement (10, 11)

PostgreSQL supporte le partitionnement par :

Liste - LIST (10)
Intervalle - RANGE (10)
Hachage - HASH (11)

Voir ces articles de Depesz :

Index (11)

La version 11 apporte également une gestion plus facilitée des index. La création d’un index sur une table partitionnée entraîne sa création sur toutes les partitions. De même, il est possible d’avoir un index unique (à condition qu’il porte sur la clé de partitionnement). Il est également possible d’avoir une clé étrangère sur une table partitionnée.

Exclusion de partition (11)

Le partition pruning consiste à exclure les partitions inutiles. Postgres s’appuie sur les contraintes d’exclusion pour écarter des partitions à la planification.

L’algorithme n’a pas été prévu pour gérer un nombre important de partitions. Sa complexité est linéaire en fonction du nombre de partitions ( )

Pour y remédier, la version 11 intègre un nouveau algorithme de recherche bien plus performant : Faster Partition Pruning.

Enfin, le moteur ne pouvait exclure des partitions que lors de la planification. Avec la version 11, le moteur est capable d’exclure une partition durant l’exécution. Cette fonctionnalité s’appelle Runtime Partition Pruning.

Jointures et agrégations (11)

La version 11 apporte de nouveaux algorithmes de jointure et d’agrégation. L’idée est de réaliser les opérations de jointures et d’agrégation partition par partition lors d’une jointure entre deux tables partitionnées (Voir ).

Améliorations intrinsèques

Fonctions de hachage (10)

Les fonctions de hachage ont été améliorées dans la version 10. Ainsi, les opérations d’agrégat (GROUP BY, GROUPING SETS, CUBE…) ainsi que les noeuds type bitmap scans bénéficient de ces améliorations. Le temps d’exécution de certaines requêtes a été divisé par deux!

Amélioration de l’exécuteur (10)

L’exécuteur a été amélioré dans la version 10, il est maintenant plus performant pour le traitement des expressions. Ce thread mentionne des gains très significatifs :

Voir cet extrait du livre de Guillaume Lelarge et Julien Rouhaud.

Amélioration des tris

Abbreviated keys (9.5)

L’algorithme de tri a été revu avec la version 9.5, celui-ci exploite mieux le cache des processeurs. Les gains annoncés étaient entre 40 et 70% (voir ).

Amélioration des tris externes (10)

La version 10 apporte également des gains très significatifs lorsqu’ils sont réalisés sur disque. Certaines requêtes ont vu leur temps d’exécution divisé par deux.

Just-In-time (11)

La version 11 intègre une infrastructure pour le Just-In-Time (JIT) ou littéralement “ ”. Le JIT consiste à compiler la requête pour générer un qui sera exécuté.

À nouveau, les gains annoncés sont impressionnants comme en témoignent ces slides de conférence :

Taches de maintenance

VACUUM FREEZE (9.6)

Avant la version 9.6, un VACUUM FREEZE entraînait la lecture de l’intégralité de la table, même si des lignes avaient déjà été “freezées”. La version 9.6 ajoute une information supplémentaire dans la visibility map afin de savoir si un bloc a déjà été freezé. Cette information permet au moteur de sauter les blocs déjà freezés.

Réduction des parcours d’index lors des opérations de VACUUM (11)

Lors d’une opération de vacuum simple (où le moteur va nettoyer les lignes périmées), le moteur était capable de sauter les blocs où il savait qu’il n’y avait aucune ligne à traiter. Néanmoins il devait quand même parcourir l’index, ce qui peut s’avérer coûteux avec une table volumineuse. La version 11 permet d’éviter ce phénomène.

Un nouveau paramètre fait son apparition : vacuum_cleanup_index_scale_factor.

Le moteur peut éviter le parcours de l’index si deux conditions sont réunies :

Aucun bloc ne doit être supprimé
Les statistiques sont bien à jour

Le moteur considère que les statistiques ne sont pas à jour si plus de : [nombre de lignes insérées] > vacuum_cleanup_index_scale_factor * [nombre de lignes dans la table]

Création d’index parallélisée (11)

Lors de la création d’un index, le moteur peut utiliser plusieurs processus pour réaliser l’opération de tri. En fonction du nombre de processus, le temps de création de l’index peut être divisé de 2 à 4 environ.

Pushdown dans les Foreign Data Wrapper (9.6, 10)

Petit rappel, les Foreign Data Wrapper permettent d’accéder à des données externes. C’est l’implémentation dans PostgreSQL de la norme SQL/MED (pour “Management of External Data”).

Un FDW permet d’accéder à tout type de donnée externe pour peu qu’un FDW existe (voir ).

La communauté maintient un FDW permettant de se connecter à une instance PostgreSQL : postgres_fdw. Mais ce n’est pas tout, certaines opérations peuvent être “poussées” au serveur distant. C’est ce qu’on appelle le pushdown.

Avant la version 9.6, une opération de tri ou une jointure se traduisait par le rapatriement de toutes les données et le serveur effectuait le tri et/ou la jointure en local.

La version 9.6 inclut le “sort pushdown” et le “join pushdown”. Ainsi, l’opération de tri ou de jointure peut être réalisée par le serveur distant. D’une part, cela décharge le serveur exécutant la requête, d’autre part, le serveur distant va pouvoir utiliser l’algorithme de jointure adéquat ou un index pour le tri des données.

Enfin, la version 10 inclut aussi l’exécution des agrégations et jointures de type FULL JOIN sur le serveur distant.

Futur

Le feature freeze de la version 11 s’est terminé le 7 Avril :

Cela signifie que certaines fonctionnalités n’ont pas été implémentées, certaines étant jugées pas assez matures pour être intégrées. D’autres ne sont encore qu’à l’état de discussion ou de démonstration.

À noter que certaines fonctionnalités peuvent être retirées après le feature freeze si les développeurs considèrent qu’elles ne sont pas suffisamment stables ou que l’implémentation doit être revue.

Par chance, les développeurs des différentes sociétés qui contribuent au développement de Postgres, communiquent sur leur travaux en cours. Cela donne un aperçu des tendances des futures fonctionnalités.

Extension du système de stockage

La communauté travaille pour rendre le système de stockage modulaire ( ). Ainsi, le moteur pourrait avoir différents moteurs de stockage. Dans les travaux en cours, on peut compter :

Le stockage colonne (associé à la vectorisation)
La compression des tables
Le stockage en mémoire (In-memory)
: ce moteur permettrait de mettre à jour les enregistrements directement dans les tables. Sans dupliquer les données dans les tables selon le modèle MVCC. Et ainsi, s’affranchir de la fragmentation et des vacuum.

Extension du JIT

L’auteur du JIT prévoit de l’étendre au reste du moteur (agrégation, hachage, tris…).

Dans les pistes évoquées, il y aurait aussi la mise en cache et le partage du bytecode entre toutes les sessions. Cela permettrait d’utiliser le JIT même dans le cas d’un traffic OLTP.

Vectorisation

L’idée de la vectorisation serait de traiter les données par batch afin d’exploiter des des processeurs.

Couplé à un stockage colonne, les gains peuvent être impressionnants :

FDW et exécution asynchrone

Le sujet du sharding revient régulièrement. D’une certaine façon, l’usage des FDW répond en partie à ce besoin. Néanmoins, PostgreSQL a encore des progrès à faire dans ce domaine. Par exemple, s’il effectue une requête d’agrégation portant sur plusieurs tables distantes, le moteur doit requêter chaque serveur distant de manière séquentielle. Une piste d’amélioration serait de requêter tous les serveurs distants de manière asynchrone. Ainsi, l’opération serait parallélisée sur tous les serveurs distants. Voir cette présentation .

Conclusion

PostgreSQL rocks!

– Guillaume Lelarge

Cet article nous a permis de voir les différentes avancées de PostgreSQL dans le monde des grosses volumétries. Il reste évidemment encore du travail, mais ce qui a déjà été réalisé est important et permet de gérer des bases imposantes.

Replication Logique Fonctionnement Interne

Sat, 10 Mar 2018 12:19:41 +0100

Table des matières

Introduction

J’ai présenté la réplication à travers plusieurs articles :

Cet article va creuser un peu plus le sujet. Nous verrons plus en détail son fonctionnement. Pour mieux l’appréhender, j’ai rajouté des graphes dans Netdata que j’ai présenté dans un précédent article. Je vous invite à cliquer sur les images pour les agrandir, elles seront plus lisibles 😄

Je remercie au passage qui a joué le rôle de relecteur pour cet article.

Sérialisation des changements sur disque

J’ai remarqué que lors d’une grosse transaction, des fichiers apparaissaient dans le répertoire pg_replslot de chaque slot de réplication. C’est ce qui m’a poussé à chercher à comprendre à quoi servaient ces fichiers.

PostgreSQL doit réordonner les modifications pour qu’elles soient appliquées dans le bon ordre. Pour ce faire, les processus wal sender procèdent au décodage logique et réordonnent les changements en mémoire.

Cependant, si la transaction comprend beaucoup de changements, cela consommerait beaucoup de mémoire. Ils écrivent donc ces changements sur disque.

Après une exploration dans le code, on arrive dans le fichier src/backend/replication/logical/reorderbuffer.c :

 1 139 /*
 2 140  * Maximum number of changes kept in memory, per transaction. After that,
 3 141  * changes are spooled to disk.
 4 142  *
 5 143  * The current value should be sufficient to decode the entire transaction
 6 144  * without hitting disk in OLTP workloads, while starting to spool to disk in
 7 145  * other workloads reasonably fast.
 8 146  *
 9 147  * At some point in the future it probably makes sense to have a more elaborate
10 148  * resource management here, but it's not entirely clear what that would look
11 149  * like.
12 150  */
13 151 static const Size max_changes_in_memory = 4096;

À partir de 4096 modifications, le moteur écrit les changements sur disque :

 12048 /*
 22049  * Check whether the transaction tx should spill its data to disk.
 32050  */
 42051 static void
 52052 ReorderBufferCheckSerializeTXN(ReorderBuffer *rb, ReorderBufferTXN *txn)
 62053 {
 72054     /*
 82055      * TODO: improve accounting so we cheaply can take subtransactions into
 92056      * account here.
102057      */
112058     if (txn->nentries_mem >= max_changes_in_memory)
12[...]
132065 /*
142066  * Spill data of a large transaction (and its subtransactions) to disk.
152067  */
162068 static void
172069 ReorderBufferSerializeTXN(ReorderBuffer *rb, ReorderBufferTXN *txn)
182070 {
192071     dlist_iter  subtxn_i;
202072     dlist_mutable_iter change_i;
212073     int         fd = -1;
222074     XLogSegNo   curOpenSegNo = 0;
232075     Size        spilled = 0;
242076     char        path[MAXPGPATH];
252077
262078     elog(DEBUG2, "spill %u changes in XID %u to disk",
272079          (uint32) txn->nentries_mem, txn->xid);

En plaçant le paramètre log_min_messages sur debug2, on peut arriver à mettre en évidence ce comportement. Le but est d’afficher le message correspondant à la ligne 2078.

Sans activité particulière, voici le contenu du répertoire pg_replslot :

 1ls pg_replslot/* -alh
 2pg_replslot/mysub:
 3total 4,0K
 4drwx------ 2 postgres postgres  19 févr. 18 15:46 .
 5drwx------ 4 postgres postgres  33 févr. 18 11:51 ..
 6-rw------- 1 postgres postgres 176 févr. 18 15:46 state
 7
 8pg_replslot/mysub3:
 9total 4,0K
10drwx------ 2 postgres postgres  19 févr. 18 15:46 .
11drwx------ 4 postgres postgres  33 févr. 18 11:51 ..
12-rw------- 1 postgres postgres 176 févr. 18 15:46 state

J’ai deux répertoires, correspondants à deux slots de réplication. En effet, j’ai créé une publication et deux instances ont souscrit à la même publication. Elles ont chacune leur slot de réplication : mysub et mysub3.

Cas avec une seule transaction

Ajoutons des lignes à une table appartenant à une publication.

 1begin;
 2BEGIN
 3postgres=# select count(*) from t1;
 4 count
 5-------
 6     0
 7(1 ligne)
 8
 9postgres=#  insert into t1 (select  i, md5(i::text) from generate_series(1,1000) i);
10INSERT 0 1000
11postgres=#  insert into t1 (select  i, md5(i::text) from generate_series(1,1000) i);
12INSERT 0 1000
13postgres=#  insert into t1 (select  i, md5(i::text) from generate_series(1,1000) i);
14INSERT 0 1000
15postgres=#  insert into t1 (select  i, md5(i::text) from generate_series(1,1000) i);
16INSERT 0 1000
17postgres=#  insert into t1 (select  i, md5(i::text) from generate_series(1,95) i);
18INSERT 0 95
19select count(*) from t1;
20 count
21-------
22  4095
23(1 ligne)

Jusqu’ici, nous n’avons pas atteint le seuil de 4096. Le répertoire ne contient encore que le fichier state :

 1ls pg_replslot/* -alh
 2pg_replslot/mysub:
 3total 4,0K
 4drwx------ 2 postgres postgres  19 févr. 18 15:52 .
 5drwx------ 4 postgres postgres  33 févr. 18 11:51 ..
 6-rw------- 1 postgres postgres 176 févr. 18 15:52 state
 7
 8pg_replslot/mysub3:
 9total 4,0K
10drwx------ 2 postgres postgres  19 févr. 18 15:52 .
11drwx------ 4 postgres postgres  33 févr. 18 11:51 ..
12-rw------- 1 postgres postgres 176 févr. 18 15:52 state

Rajoutons une ligne :

1insert into t1 (select  i, md5(i::text) from generate_series(1,1) i);
2INSERT 0 1
3postgres=# select count(*) from t1;
4 count
5-------
6  4096
7(1 ligne)

Cette fois, le seuil est atteint (if (txn->nentries_mem >= max_changes_in_memory). Les processus wal sender vont écrire sur disque les changements à appliquer.

On retrouve dans les logs ces messages (avec log_min_messages = debug2) :

1[1977] postgres@postgres DEBUG:  spill 4096 changes in XID 51689068 to disk
2[2061] postgres@postgres DEBUG:  spill 4096 changes in XID 51689068 to disk

Correspondant aux deux processus wal sender :

1ps faux |grep -E '(1977|2061)'
2postgres  1977  3.3  0.3 390496 37984 ?        Ss   11:38   8:54  \_ postgres: 10/main: wal sender process postgres 192.168.1.26(44188) idle
3postgres  2061  3.4  0.3 390496 37932 ?        Ss   11:38   9:10  \_ postgres: 10/main: wal sender process postgres 192.168.1.26(44192) idle

Dans le même temps, si on regarde le contenu du répertoire pg_replslot, on remarque que de nouveaux fichiers sont apparus :

 1ls pg_replslot/* -alh
 2pg_replslot/mysub:
 3total 660K
 4drwx------ 2 postgres postgres   60 févr. 18 15:53 .
 5drwx------ 4 postgres postgres   33 févr. 18 11:51 ..
 6-rw------- 1 postgres postgres  176 févr. 18 15:53 state
 7-rw------- 1 postgres postgres 656K févr. 18 15:53 xid-51689068-lsn-92-98000000.snap
 8
 9pg_replslot/mysub3:
10total 660K
11drwx------ 2 postgres postgres   60 févr. 18 15:53 .
12drwx------ 4 postgres postgres   33 févr. 18 11:51 ..
13-rw------- 1 postgres postgres  176 févr. 18 15:53 state
14-rw------- 1 postgres postgres 656K févr. 18 15:53 xid-51689068-lsn-92-98000000.snap

Chaque wal sender a dû sérialiser les changements sur disque.

On remarque également que la notion de changement correspond à une ligne et non un ordre. Par exemple, un seul insert de 4096 lignes entrainera l’écriture d’un fichier *.snap.

Edit : Les développeurs de Postgres ont changé l’extension snap pour spill pour Postgres 12 :

 1commit ba9d35b8eb8466cf445c732a2e15ca5790cbc6c6
 2Author:     Jeff Davis <jdavis@postgresql.org>
 3AuthorDate: Sat Aug 25 22:45:59 2018 -0700
 4Commit:     Jeff Davis <jdavis@postgresql.org>
 5CommitDate: Sat Aug 25 22:52:46 2018 -0700
 6
 7    Reconsider new file extension in commit 91f26d5f.
 8
 9    Andres and Tom objected to the choice of the ".tmp"
10    extension. Changing to Andres's suggestion of ".spill".
11
12    Discussion: https://postgr.es/m/88092095-3348-49D8-8746-EB574B1D30EA%40anarazel.de

Cas avec deux transactions

Deuxième exemple, avec deux transactions modifiant la table t1.

Le xid de la première transaction :

1select txid_current();
2 txid_current
3--------------
4     51689070
5(1 ligne)

Celui de la seconde transaction :

1select txid_current();
2 txid_current
3--------------
4     51689071
5(1 ligne)

Si on insère 4096 lignes dans la première transaction :

 1ls pg_replslot/* -alh
 2pg_replslot/mysub:
 3total 660K
 4drwx------ 2 postgres postgres   60 févr. 18 16:08 .
 5drwx------ 4 postgres postgres   33 févr. 18 11:51 ..
 6-rw------- 1 postgres postgres  176 févr. 18 16:08 state
 7-rw------- 1 postgres postgres 656K févr. 18 16:07 xid-51689070-lsn-92-98000000.snap
 8
 9pg_replslot/mysub3:
10total 660K
11drwx------ 2 postgres postgres   60 févr. 18 16:08 .
12drwx------ 4 postgres postgres   33 févr. 18 11:51 ..
13-rw------- 1 postgres postgres  176 févr. 18 16:08 state
14-rw------- 1 postgres postgres 656K févr. 18 16:07 xid-51689070-lsn-92-98000000.snap

Ensuite, si on insère 4096 lignes dans la seconde transaction, nous obtenons deux nouveaux fichiers *.snap :

 1ls pg_replslot/* -alh
 2pg_replslot/mysub:
 3total 1,3M
 4drwx------ 2 postgres postgres  101 févr. 18 16:08 .
 5drwx------ 4 postgres postgres   33 févr. 18 11:51 ..
 6-rw------- 1 postgres postgres  176 févr. 18 16:08 state
 7-rw------- 1 postgres postgres 656K févr. 18 16:07 xid-51689070-lsn-92-98000000.snap
 8-rw------- 1 postgres postgres 656K févr. 18 16:08 xid-51689071-lsn-92-98000000.snap
 9
10pg_replslot/mysub3:
11total 1,3M
12drwx------ 2 postgres postgres  101 févr. 18 16:08 .
13drwx------ 4 postgres postgres   33 févr. 18 11:51 ..
14-rw------- 1 postgres postgres  176 févr. 18 16:08 state
15-rw------- 1 postgres postgres 656K févr. 18 16:07 xid-51689070-lsn-92-98000000.snap
16-rw------- 1 postgres postgres 656K févr. 18 16:08 xid-51689071-lsn-92-98000000.snap

J’ai essayé en insérant 3000 lignes dans chaque transaction, aucun fichier snap n’est écrit. Ce n’est que lorsque chaque transaction dépasse 4096 changements que ceux-ci sont écrits sur disque.

Commitons la première transaction :

 1ls pg_replslot/* -alh
 2pg_replslot/mysub:
 3total 660K
 4drwx------ 2 postgres postgres   60 févr. 18 16:15 .
 5drwx------ 4 postgres postgres   33 févr. 18 11:51 ..
 6-rw------- 1 postgres postgres  176 févr. 18 16:15 state
 7-rw------- 1 postgres postgres 656K févr. 18 16:08 xid-51689071-lsn-92-98000000.snap
 8
 9pg_replslot/mysub3:
10total 660K
11drwx------ 2 postgres postgres   60 févr. 18 16:15 .
12drwx------ 4 postgres postgres   33 févr. 18 11:51 ..
13-rw------- 1 postgres postgres  176 févr. 18 16:15 state
14-rw------- 1 postgres postgres 656K févr. 18 16:08 xid-51689071-lsn-92-98000000.snap

Le fichier snap correspondant est supprimé par chaque wal sender. Si on commite la deuxième transaction, le second fichier est également supprimé.

Il est à noter que ces fichiers apparaissent pour toute modification (DELETE, UPDATE…).

Que se passe t’il pour une grosse transaction?

Dans cet exemple, nous allons insérer une grande quantité d’enregistrements dans une transaction qui sera commitée plus tard, afin de mettre en évidence le fonctionnement de la réplication logique.

Voici les requêtes qui ont été exécutées :

1BEGIN.
2INSERT INTO t1 (select  i, md5(i::text) FROM generate_series(1,10000000) i); --16h27min13s
3-- attente de plusieurs minutes
4COMMIT; --16h33min46s

Pour information, la requête d’insertion a été lancée peu après 16h27min13s et s’est terminée à 16h28min16s.

Le commit n’a été fait que bien plus tard, à 16h33min46s.

Nous constatons que les deux processus wal sender vont sérialiser les changements sur disque :

1[1977] postgres@postgres DEBUG:  spill 4096 changes in XID 51689075 to disk
2[2061] postgres@postgres DEBUG:  spill 4096 changes in XID 51689075 to disk
3[1977] postgres@postgres DEBUG:  spill 4096 changes in XID 51689075 to disk
4[2061] postgres@postgres DEBUG:  spill 4096 changes in XID 51689075 to disk
5[1977] postgres@postgres DEBUG:  spill 4096 changes in XID 51689075 to disk
6[2061] postgres@postgres DEBUG:  spill 4096 changes in XID 51689075 to disk

Ce qui produit une grosse quantité de fichiers :

 1[...]
 2pg_replslot/mysub3:
 3total 1,6G
 4drwx------ 2 postgres postgres 8,0K févr. 18 16:28 .
 5drwx------ 4 postgres postgres   33 févr. 18 11:51 ..
 6-rw------- 1 postgres postgres  176 févr. 18 16:28 state
 7-rw------- 1 postgres postgres 1,1M févr. 18 16:27 xid-51689075-lsn-92-98000000.snap
 8-rw------- 1 postgres postgres  15M févr. 18 16:27 xid-51689075-lsn-92-99000000.snap
 9-rw------- 1 postgres postgres  16M févr. 18 16:27 xid-51689075-lsn-92-9A000000.snap
10-rw------- 1 postgres postgres  16M févr. 18 16:27 xid-51689075-lsn-92-9B000000.snap
11-rw------- 1 postgres postgres  16M févr. 18 16:27 xid-51689075-lsn-92-9C000000.snap
12[...]

Voici quelques graphes issus de Netdata :

CPU

On constate une forte charge CPU, jusqu’à 16h28min16s où elle baisse un peu. Puis à 16h28min48s la charge redescend à 0. On retrouve une hausse de la charge à 16h33min46s.

Comment expliquer ces résultats?

Lors du premier pic de charge, il y avait plusieurs processus qui consommait de la ressource :

le backend qui insérait les données
les deux processus wal sender

La machine dispose de 8 coeurs logiques, chaque processus n’exploite qu’un seul coeur. Soit environ 13% par processus.

A 16h28min16s, le backend venait de terminer l’insertion. Cependant, les processus wal sender continuaient d’être actifs. Le décodage des journaux et la sérialisation des transactions sont assez coûteux.

Enfin, à 16h33min46s, la transaction est commitée. Ca n’a eu aucune incidence sur la charge du backend. En revanche, les processus wal sender se sont mis à lire les fichiers snap produits sur disque pour transmettre les modifications aux souscripteurs.

À noter que les changements n’ont été visibles côté souscripteur que vers 16h35min40s, une fois que les changements ont été rejoués. Le rejeu est plus long que l’insertion. Cela dépend beaucoup des performances des processeurs.

Statistiques sur les enregistrements

tuple inserted

On constate un pic d’insertion à 16h33min46s. Cela correspond bien au moment où la transaction a été commitée.

Réseau

On constate un important trafic réseau entre 16h33min46s et 16h35min40s. On peut en déduire que les changements ne sont transmis qu’après le commit.

Les changements ne sont pas transmis “au fil de l’eau”. Cela présente l’avantage d’éviter d’envoyer des changements qui ne seraient pas commités. En revanche, cela rajoute du délai dans l’application des changements.

Thomas Vondra a soumis un patch afin d’améliorer ce cas d’usage :

Pour le moment le patch n’a pas encore été accepté. Il nécessite de rajouter des informations dans les journaux de transaction. La communauté est très prudente en ce qui concerne tout ce qui peut avoir un impact sur les performances.

Réplication

Réplication delta

On peut noter que les graphes “Streaming replication delta” mesurant le delta de réplication à partir de la vue pg_stat_replication sont difficiles à expliquer. Normalement, ils présentent le retard de réplication de serveurs secondaires. Or nous venons de voir que l’application des changements ne se fait que lors du commit, soit à 16h33min46s. Or les graphes semblent indiquer que les serveurs secondaires avaient du retard jusqu’à 16h28min48s.

Les courbes “write delta”, “flush delta” et “replay delta” se confondent. La courbe “sent delta” est assez différente.

Ma compréhension de ces graphes est que “write delta”, “flush delta” et “replay delta” correspondent au retard de décodage logique par rapport aux données envoyées “sent delta”.

A 16h28min16s, la requête s’est terminée, le “sent delta” arrête de croître. Puis, décroit au fur et à mesure de l’avancée du décodage logique.

On peut confirmer cela grâce aux graphes “replication slot files”, la courbe “pg_replslot files” correspond au nombre de fichiers présents dans le répertoire “pg_replslot” de chaque slot de réplication. Celle-ci est croissante et s’arrête de croitre au même moment où les courbes “write delta”, “flush delta” et “replay delta” redescendent à 0.

On constate également que le moteur est contraint de conserver les journaux de transaction tant que la transaction n’a pas été commitée. C’est assez logique, si un crash survenait, il faudrait pouvoir aller lire les journaux de transaction pour procéder à nouveau au décodage logique.

Enfin, à 16h35min40s les changements ont bien été transmis côté souscripteur, le moteur peut enfin nettoyer les journaux de transaction et les fichiers snaps.

Trafic OLTP

Et avec un trafic OLTP? Pour ce test, j’ai utilisé pgbench lancé pendant 10 minutes sur une base dont toutes les tables sont répliquées.

Charge CPU

Activité réseau

Activité transactions

Réplication delta

On remarque que le trafic réseau chute au même moment que nous observons un retard de réplication qui augmente. Cela correspondait à des périodes où le secondaire saturait côté CPU (malheureusement je n’ai pas de graphe Netdata sur le secondaire).

Cela peut s’expliquer par le fait que le rejeu ne se fait que grâce à un seul processus bgworker qui avait du mal à supporter la charge (machine moins puissante). D’ailleurs, on peut voir que le secondaire rattrape le retard quelques dizaines de secondes après la fin du bench.

Autre point important, on constate qu’il n’y a aucun fichier snap écrit sur disque. Cela confirme le commentaire dans le code, indiquant qu’en cas de trafic OLTP, les changements sont conservés en mémoire et non sur disque.

Bilan

On peut constater que la réplication logique s’applique assez bien dans le cas d’un trafic OLTP pour peu que le secondaire arrive à suivre l’application des changements. Cela implique que le trafic en écriture ne peut être trop important au risque d’avoir un secondaire qui a du mal à encaisser la charge, l’application des changements s’effectuant par un seul processus.

En revanche, dans les cas où le trafic est différent (OLAP), où des requêtes entraînent des changements importants, le moteur devra sérialiser les changements sur disque. Les opérations de décodage logique, puis de transfert réseau induisent un délai qui peut être non négligeable.

Postgres et Netdata : application à autovacuum et pg_stat_bgwriter

Tue, 20 Feb 2018 18:35:22 +0100

Table des matières

Il y a quelque temps, j’ai découvert . Cet outil permet de collecter de nombreuses métriques (cpu, réseau etc).

La force de Netdata est d’être assez léger et simple d’utilisation. Il effectue une mesure toutes les secondes, tout est stocké en mémoire. Il n’y a pas vraiment d’historique. Le but est d’avoir accès à un ensemble de métrique en temps réel. ¹

J’ai rajouté plusieurs graphiques pour PostgreSQL, en m’inspirant largement de ce qui existe dans .

Voici la présentation et les explications de quelques graphes. Certains, permettent de mettre en évidence le comportement de PostgreSQL.

Pour information, les graphes présentés ici ne correspondent pas à la version finale. Plusieurs graphes ont été séparés afin de distinguer les différentes opérations (lecture, écrites) et les processus (backend, checkpointer, bgwriter). ²

Je remercie au passage qui a joué le rôle de relecteur pour cet article.

Autovacuum

Autovacuum workers

Ce graphe présente l’activité des processus lancés par “l’autovacuum launcher”. Leur rôle est d’effectuer des tâches de maintenance afin de :

Nettoyer les lignes mortes
Mettre à jour les statistiques des données (voir )
“Geler” les lignes anciennes afin d’éviter un wraparound (Voir )

Normalement, il n’y a pas à s’inquiéter, la configuration par défaut suffit dans la plupart des situations. Cependant, il peut arriver qu’il soit nécessaire d’affiner la configuration de l’autovacuum.

Par exemple, si l’activité est très soutenue et que le nombre de processus lancés atteint régulièrement l’autovacuum_max_workers. Dans ce cas, il peut être nécessaire :

soit d’augmenter le nombre de processus (s’il y a beaucoup de tables à traiter)
soit de rendre les processus plus aggressifs (lorsque les tables sont volumineuses). En effet, leur activité est bridée via les paramètres autovacuum_vacuum_cost_delay et autovacuum_vacuum_cost_limit afin que cette tâche se fasse en arrière plan pour impacter le moins possible les autres processus en charge de traiter les requêtes.

Bgwriter

Ce graphe s’appelle Bgwriter en référence à la vue qui permet d’obtenir les statistiques

Le rôle du “bgwriter” est de synchroniser des blocs “sales”. Ce sont des blocs qui ont été modifiés dans la mémoire partagée mais pas encore écrits dans les fichiers de données (rassurez-vous ils sont bien écrits sur disque dans les journaux de transaction).

Le “checkpointer” est également en charge de synchroniser ces blocs. Les écritures sont lissées en arrière plan (cela dépend du paramètre checkpoint_completion_target). Le bgwriter intervient lorsque des backends ont besoin de libérer des blocs en mémoire partagée, contrairement au checkpointer qui le fait lors d’un checkpoint.

Pour en revenir au graphe, la courbe bleue correspond au nombre de blocs qui ont dû être alloués en mémoire partagée. Le graphe a cette forme car il correspond à un test de charge avec pgbench alors que le serveur venait d’être démarré.

On voit assez nettement l’effet du cache qui se charge progressivement. C’est assez visible, car la collecte se fait à chaque seconde.

On peut voir cet effet de chargement du cache sur plusieurs graphes :

Accès disque

Au debut du graphe on peut constater une activité très soutenue en lecture. Les pics en écriture correspondent aux checkpoints.

IOWait

Ici, c’est la zone rose qui est intéressante. On peut voir qu’au démarrage du test, les processeurs étaient en attente d’accès disque.

Lectures disques - Transaction par seconde

Ici on peut voir que le moteur a dû lire les blocs depuis le disque. Le graphe décroit, car les lectures suivantes se font depuis la mémoire partagée.

On peut également voir que le nombre de transactions par seconde augmente, puis se stabilise une fois que les données sont chargées en mémoire partagée.

On observe le même phénomène sur ce graphe :

Statistiques base bench

On peut ainsi constater qu’il a fallu une 1min30 pour charger le cache.

Voir : ↩︎
La Pull Request a été mergée récemment : ↩︎

Tour d'horizon des fonctionnalités de PostgreSQL

Thu, 25 Jan 2018 19:00:00 +0100

PostgreSQL - JSONB et Statistiques

Sun, 26 Nov 2017 21:11:38 +0100

Table des matières

Rappels statistiques, cardinalité, sélectivité

Le SQL est un language dit “déclaratif”. C’est un language où l’utilisateur demande ce qu’il souhaite. Sans préciser comment l’ordinateur doit procéder pour obtenir les résultats.

C’est le SGBD qui doit trouver “comment” réaliser l’opération en s’assurant de :

Retourner le résultat juste
Idéalement, le plus vite possible

“Le plus vite possible” se traduit par :

Réduire au maximum les accès disques
Privilégier les lectures séquentielles (praticulièrement important pour les disques mécaniques)
Réduire le nombre d’opérations CPU
Réduire l’empreinte mémoire

Pour se faire, un SGBD possède ce que l’on appèle un optimiseur dont le rôle est de trouver le meilleur plan d’exécution.

PostgreSQL possède un optimiseur basé sur un mécanisme de coût. Sans rentrer dans les détails, chaque opération a un cout unitaire (lecture d’un bloc séquentiel, traitement CPU d’un enregistrement…). Le moteur calcule le coût de plusieurs plans d’exécution (si la requête est simple) et choisi le moins couteux.

Comment le moteur peut estimer le coût d’un plan? En estimant le coût de chaque noeud du plan en se basant sur des statistiques. PostgreSQL analyse les tables pour d’obtenir un échantillon statistique (opération normalement réalisée par l’autovacuum).

Quelques mots de vocabulaire :

Cardinalité : Dans la théorie des ensemble, c’est le nombre d’éléments dans un ensemble. Dans les bases de données, ça sera le nombre de lignes d’une table ou après application d’un prédicat.

Sélectivité : Fraction d’enregistrements retournés après application d’un prédicat. Par exemple, une table contenant des personnes et dont environ un tier correspond à des enfants. La sélectivité du prédicat personne = 'enfant' sera de 0.33.

Si cette table contient 300 personnes (c’est la cardinalité de l’ensemble “personnes”), on peut estimer le nombre d’enfants car on sait que le prédicat personne = 'enfant' est de 0.33 :

300 * 0.33 = 99

On peut obtenir ces estimations avec EXPLAIN qui affiche le plan d’exécution.

Exemple (simplifié) :

1explain (analyze, timing off) select * from t1 WHERE c1=1;
2                                  QUERY PLAN
3------------------------------------------------------------------------------
4 Seq Scan on t1  (cost=0.00..5.75 rows=100 ...) (actual rows=100 ...)
5   Filter: (c1 = 1)
6   Rows Removed by Filter: 200

(cost=0.00..5.75 rows=100 …) : Indique le coût estimé et le nombre d’enregistrements estimé (rows).

(actual rows=100 …) : Indique le nombre d’enregistrement réellement obtenu.

La documentation de PostgreSQL fourni des exemples de calculs d’estimation :

Il est assez facile de comprendre comment obtenir des estimations à partir de types de données scalaires.

Comment ça se passe pour des types particuliers? Par exemple le JSON?

Recherche sur du JSONB

Jeu de données

Comme dans les précédents articles, j’ai utilisé le jeu de données de stackoverflow. J’ai créé une nouvelle table en aggrégeant les données de plusieurs tables dans un objet JSON :

 1CREATE TABLE json_stack AS
 2SELECT t.post_id,
 3       row_to_json(t,
 4                   TRUE)::jsonb json
 5FROM
 6  (SELECT posts.id post_id,
 7          posts.owneruserid,
 8          users.id,
 9          title,
10          tags,
11          BODY,
12          displayname,
13          websiteurl,
14          LOCATION,
15          aboutme,
16          age
17   FROM posts
18   JOIN users ON posts.owneruserid = users.id) t;

Le traitement est assez long car les deux tables concernées totalisent près de 40Go.

J’obtiens donc une table de 40Go qui ressemble à ça :

 1 \dt+ json_stack
 2                      List of relations
 3 Schema |    Name    | Type  |  Owner   | Size  | Description
 4--------+------------+-------+----------+-------+-------------
 5 public | json_stack | table | postgres | 40 GB |
 6(1 row)
 7
 8
 9\d json_stack
10             Table "public.json_stack"
11 Column  |  Type   | Collation | Nullable | Default
12---------+---------+-----------+----------+---------
13 post_id | integer |           |          |
14 json    | jsonb   |           |          |
15
16
17select post_id,jsonb_pretty(json) from json_stack
18    where json_displayname(json) = 'anayrat' limit 1;
19 post_id  |
20----------+-----------------------------------------------------------------------------------------
21 26653490 | {
22          |     "id": 4197886,
23          |     "age": null,
24          |     "body": "<p>I have an issue with date filter. I follow [...]
25          |     "tags": "<java><logstash>",
26          |     "title": "Logstash date filter failed parsing",
27          |     "aboutme": "<p>Sysadmin, Postgres DBA</p>\n",
28          |     "post_id": 26653490,
29          |     "location": "Valence",
30          |     "websiteurl": "https://blog.anayrat.info",
31          |     "displayname": "anayrat",
32          |     "owneruserid": 4197886
33          | }

Opérateurs et indexation sur du JSONB

PostgreSQL propose plusieurs opérateurs pour interroger du JSONB ¹. Nous allons utiliser l’opérateur @>.

Il est également possible d’indexer du JSONB grâce aux index GIN :

1create index ON json_stack using gin (json );

Enfin, voici un exemple de requête :

 1explain (analyze,buffers)  select * from json_stack
 2    where json @>  '{"displayname":"anayrat"}'::jsonb;
 3                                  QUERY PLAN
 4---------------------------------------------------------------------------------------
 5 Bitmap Heap Scan on json_stack
 6                (cost=286.95..33866.98 rows=33283 width=1011)
 7                (actual time=0.099..0.102 rows=2 loops=1)
 8   Recheck Cond: (json @> '{"displayname": "anayrat"}'::jsonb)
 9   Heap Blocks: exact=2
10   Buffers: shared hit=17
11   ->  Bitmap Index Scan on json_stack_json_idx
12                          (cost=0.00..278.62 rows=33283 width=0)
13                          (actual time=0.092..0.092 rows=2 loops=1)
14         Index Cond: (json @> '{"displayname": "anayrat"}'::jsonb)
15         Buffers: shared hit=15
16 Planning time: 0.088 ms
17 Execution time: 0.121 ms
18(9 rows)

En lisant ce plan on constate que le moteur se trompe complètement. Il estime obtenir 33 283 lignes, or la requête retourne seulement deux enregistrements. Le facteur d’erreur est d’environ 15 000!

Sélectivité sur du JSONB

Quelle est la cardinalité de la table? L’information est contenue dans le catalogue système :

1select reltuples from pg_class where relname = 'json_stack';
2  reltuples
3-------------
4 3.32833e+07

Quelle est la sélectivité estimée?

1select 33283 / 3.32833e+07;
2        ?column?
3------------------------
4 0.00099999098647069251

En gros 0.001.

Plongée dans le code

Je me suis amusé à sortir le débugueur GDB pour trouver d’où pouvait venir ce chiffre. J’ai fini par arriver dans cette fonction :

 1[...]
 279 /*
 380  *  contsel -- How likely is a box to contain (be contained by) a given box?
 481  *
 582  * This is a tighter constraint than "overlap", so produce a smaller
 683  * estimate than areasel does.
 784  */
 885
 986 Datum
1087 contsel(PG_FUNCTION_ARGS)
1188 {
1289     PG_RETURN_FLOAT8(0.001);
1390 }
14[...]

Le calcul de la sélectivité dépend du type de l’opérateur. Regardons dans le catalogue système :

 1select oprname,typname,oprrest from pg_operator op
 2    join pg_type typ ON op.oprleft= typ.oid where oprname = '@>';
 3 oprname | typname  |   oprrest
 4---------+----------+--------------
 5 @>      | polygon  | contsel
 6 @>      | box      | contsel
 7 @>      | box      | contsel
 8 @>      | path     | -
 9 @>      | polygon  | contsel
10 @>      | circle   | contsel
11 @>      | _aclitem | -
12 @>      | circle   | contsel
13 @>      | anyarray | arraycontsel
14 @>      | tsquery  | contsel
15 @>      | anyrange | rangesel
16 @>      | anyrange | rangesel
17 @>      | jsonb    | contsel

On retrouve plusieurs types, en effet l’opérateur @>signifie (en gros) : “Est-ce que l’objet de gauche contient l’élément de droite?”. Il est utilisé pour différents types : géométrie, tableaux…

Dans notre cas, est-ce que l’objet JSONB de gauche contient l’élément '{"displayname":"anayrat"}' ?

Un objet JSON est un type particulier. Déterminer la sélectivité d’un élément serait assez complexe. Le commentaire est assez explicite :

 1 25 /*
 2 26  *  Selectivity functions for geometric operators.  These are bogus -- unless
 3 27  *  we know the actual key distribution in the index, we can't make a good
 4 28  *  prediction of the selectivity of these operators.
 5 29  *
 6 30  *  Note: the values used here may look unreasonably small.  Perhaps they
 7 31  *  are.  For now, we want to make sure that the optimizer will make use
 8 32  *  of a geometric index if one is available, so the selectivity had better
 9 33  *  be fairly small.
10[...]

Il n’est donc pas possible (actuellement) de déterminer la sélectivité sur des objets JSONB.

Mais tout n’est pas perdu 😉

Index fonctionnels

PostgreSQL permet de créer des index dits fonctionnels. On crée un index à partir d’une fonction.

Vous allez me dire : “Oui mais on n’en a pas besoin. Dans ton exemple, postgres utilise déjà un index”.

C’est vrai, la différence, c’est que le moteur collecte des statistiques à propos de cet index. Comme si le résultat de la fonction était une nouvelle colonne.

Création de la fonction et de l’index

C’est très simple :

1CREATE or replace FUNCTION json_displayname (jsonb )
2RETURNS text
3AS $$
4select $1->>'displayname'
5$$
6LANGUAGE SQL IMMUTABLE PARALLEL SAFE
7;
8
9create index ON json_stack (json_displayname(json));

Recherche en utilisant une fonction

Pour utiliser l’index que nous venons de créer, il faut l’utiliser dans la requête :

 1explain (analyze,verbose,buffers) select * from json_stack
 2        where json_displayname(json) = 'anayrat';
 3                        QUERY PLAN
 4----------------------------------------------------------------------------
 5 Index Scan using json_stack_json_displayname_idx on public.json_stack
 6            (cost=0.56..371.70 rows=363 width=1011)
 7            (actual time=0.021..0.023 rows=2 loops=1)
 8   Output: post_id, json
 9   Index Cond: ((json_stack.json ->> 'displayname'::text) = 'anayrat'::text)
10   Buffers: shared hit=7
11 Planning time: 0.107 ms
12 Execution time: 0.037 ms
13(6 rows)

Cette fois le moteur estime obtenir 363 lignes, ce qui est bien plus proche du résultat final (2).

Autre exemple et calcul de sélectivité

Cette fois nous allons effectuer une recherche sur le champ “age” de l’objet JSON :

 1explain (analyze,buffers)  select * from json_stack
 2      where json @>  '{"age":27}'::jsonb;
 3                      QUERY PLAN
 4---------------------------------------------------------------------
 5 Bitmap Heap Scan on json_stack
 6        (cost=286.95..33866.98 rows=33283 width=1011)
 7        (actual time=667.411..12723.906 rows=804630 loops=1)
 8   Recheck Cond: (json @> '{"age": 27}'::jsonb)
 9   Rows Removed by Index Recheck: 2211190
10   Heap Blocks: exact=391448 lossy=344083
11   Buffers: shared hit=576350 read=881510
12   I/O Timings: read=2947.458
13   ->  Bitmap Index Scan on json_stack_json_idx
14        (cost=0.00..278.62 rows=33283 width=0)
15        (actual time=562.648..562.648 rows=804644 loops=1)
16         Index Cond: (json @> '{"age": 27}'::jsonb)
17         Buffers: shared hit=9612 read=5140
18         I/O Timings: read=11.195
19 Planning time: 0.073 ms
20 Execution time: 12809.392 ms
21(12 lignes)
22
23set work_mem = '100MB';
24
25explain (analyze,buffers)  select * from json_stack
26      where json @>  '{"age":27}'::jsonb;
27                      QUERY PLAN
28---------------------------------------------------------------------
29 Bitmap Heap Scan on json_stack
30        (cost=286.95..33866.98 rows=33283 width=1011)
31        (actual time=748.968..5720.628 rows=804630 loops=1)
32   Recheck Cond: (json @> '{"age": 27}'::jsonb)
33   Rows Removed by Index Recheck: 14
34   Heap Blocks: exact=735531
35   Buffers: shared hit=123417 read=780542
36   I/O Timings: read=1550.124
37   ->  Bitmap Index Scan on json_stack_json_idx
38        (cost=0.00..278.62 rows=33283 width=0)
39        (actual time=545.553..545.553 rows=804644 loops=1)
40         Index Cond: (json @> '{"age": 27}'::jsonb)
41         Buffers: shared hit=9612 read=5140
42         I/O Timings: read=11.265
43 Planning time: 0.079 ms
44 Execution time: 5796.219 ms
45(12 lignes)

Dans cet exemple on constate que le moteur estime toujours obtenir 33 283 enregistrements. Or il en obtient 804 644. Cette fois il est beaucoup trop optimiste.

PS : Dans mon exemple vous verrez que j’ai joué la même requête en modifiant la work_mem. C’est pour éviter que le bitmap ne soit lossy ²

Comme vu ci-dessus nous pouvons créer une fonction :

1CREATE or replace FUNCTION json_age (jsonb )
2RETURNS text
3AS $$
4select $1->>'age'
5$$
6LANGUAGE SQL IMMUTABLE PARALLEL SAFE
7;
8
9create index ON json_stack (json_age(json));

A nouveau l’estimation est bien meilleure:

 1explain (analyze,buffers)   select * from json_stack
 2      where json_age(json) = '27';
 3                         QUERY PLAN
 4------------------------------------------------------------------------
 5 Index Scan using json_stack_json_age_idx on json_stack
 6  (cost=0.56..733177.05 rows=799908 width=1011)
 7  (actual time=0.042..2355.179 rows=804630 loops=1)
 8   Index Cond: ((json ->> 'age'::text) = '27'::text)
 9   Buffers: shared read=737720
10   I/O Timings: read=1431.275
11 Planning time: 0.087 ms
12 Execution time: 2410.269 ms

Le moteur estime obtenir 799 908 enregistrements. nous allons le vérifier.

Comme je l’ai précisé, le moteur possède des informations de statistiques basées sur un échantillon de données. Ces informations sont stockées dans un catalogue système lisible grâce à la vue pg_stats. Avec un index fonctionnel, le moteur le voit comme une nouvelle colonne.

1schemaname             | public
2tablename              | json_stack_json_age_idx
3attname                | json_age
4[...]
5most_common_vals       | {28,27,29,31,26,30,32,25,33,34,36,24,[...]}
6most_common_freqs      | {0.0248,0.0240333,0.0237333,0.0236333,0.0234,0.0229333,[...]}
7[...]

La colonne most_common_vals contient les valeurs les plus fréquentes et la colonne most_common_freqs la sélectivité correspondante.

Donc pour age=27 on a une sélectivité de 0.0240333.

Ensuite il suffit de multiplier la sélectivité par la cardinalité de la table :

 1select n_live_tup from pg_stat_all_tables where relname ='json_stack';
 2 n_live_tup
 3------------
 4   33283258
 5
 6
 7select 0.0240333 * 33283258;
 8    ?column?
 9----------------
10 799906.5244914

D’accord, l’estimation est bien meilleure. Mais est-ce grave si le moteur se trompe? Dans les deux requêtes ci-dessus on constate que le moteur exploite bien un index et que le résultat est obtenu rapidement.

Conséquences d’une mauvaise estimation

En quoi une mauvaise estimation peut poser problème?

Quand ça entraine le choix d’un mauvais plan.

Par exemple cette requête d’aggregation qui compte le nombre de posts par age:

 1explain (analyze,buffers)  select json->'age',count(json->'age')
 2                          from json_stack group by json->'age' ;
 3                             QUERY PLAN
 4--------------------------------------------------------------------------------------
 5 Finalize GroupAggregate
 6  (cost=10067631.49..14135810.84 rows=33283256 width=40)
 7  (actual time=364151.518..411524.862 rows=86 loops=1)
 8   Group Key: ((json -> 'age'::text))
 9   Buffers: shared hit=1949354 read=1723941, temp read=1403174 written=1403189
10   I/O Timings: read=155401.828
11   ->  Gather Merge
12        (cost=10067631.49..13581089.91 rows=27736046 width=40)
13        (actual time=364151.056..411524.589 rows=256 loops=1)
14         Workers Planned: 2
15         Workers Launched: 2
16         Buffers: shared hit=1949354 read=1723941, temp read=1403174 written=1403189
17         I/O Timings: read=155401.828
18         ->  Partial GroupAggregate
19            (cost=10066631.46..10378661.98 rows=13868023 width=40)
20            (actual time=363797.836..409187.566 rows=85 loops=3)
21               Group Key: ((json -> 'age'::text))
22               Buffers: shared hit=5843962 read=5177836,
23                        temp read=4212551 written=4212596
24               I/O Timings: read=478460.123
25               ->  Sort
26                  (cost=10066631.46..10101301.52 rows=13868023 width=1042)
27                  (actual time=299775.029..404358.743 rows=11094533 loops=3)
28                     Sort Key: ((json -> 'age'::text))
29                     Sort Method: external merge  Disk: 11225392kB
30                     Buffers: shared hit=5843962 read=5177836,
31                              temp read=4212551 written=4212596
32                     I/O Timings: read=478460.123
33                     ->  Parallel Seq Scan on json_stack
34                        (cost=0.00..4791997.29 rows=13868023 width=1042)
35                        (actual time=0.684..202361.133 rows=11094533 loops=3)
36                           Buffers: shared hit=5843864 read=5177836
37                           I/O Timings: read=478460.123
38 Planning time: 0.080 ms
39 Execution time: 411688.165 ms

Le moteur s’attend à obtenir 33 283 256 d’enregistrement au lieu de 86. Il a également effectué un tri très couteux puisqu’il a généré plus de 33Go (11GO * 3 loops) de fichiers temporaires.

La même requête en utilisant la fonction json_age :

 1explain (analyze,buffers)   select json_age(json),count(json_age(json))
 2                              from json_stack group by json_age(json);
 3                                             QUERY PLAN
 4--------------------------------------------------------------------------------------
 5 Finalize GroupAggregate
 6  (cost=4897031.22..4897033.50 rows=83 width=40)
 7  (actual time=153985.585..153985.667 rows=86 loops=1)
 8   Group Key: ((json ->> 'age'::text))
 9   Buffers: shared hit=1938334 read=1736761
10   I/O Timings: read=106883.908
11   ->  Sort
12      (cost=4897031.22..4897031.64 rows=166 width=40)
13      (actual time=153985.581..153985.598 rows=256 loops=1)
14         Sort Key: ((json ->> 'age'::text))
15         Sort Method: quicksort  Memory: 37kB
16         Buffers: shared hit=1938334 read=1736761
17         I/O Timings: read=106883.908
18         ->  Gather
19            (cost=4897007.46..4897025.10 rows=166 width=40)
20            (actual time=153985.264..153985.360 rows=256 loops=1)
21               Workers Planned: 2
22               Workers Launched: 2
23               Buffers: shared hit=1938334 read=1736761
24               I/O Timings: read=106883.908
25               ->  Partial HashAggregate
26                  (cost=4896007.46..4896008.50 rows=83 width=40)
27                  (actual time=153976.620..153976.635 rows=85 loops=3)
28                     Group Key: (json ->> 'age'::text)
29                     Buffers: shared hit=5811206 read=5210494
30                     I/O Timings: read=320684.515
31                     ->  Parallel Seq Scan on json_stack
32                     (cost=0.00..4791997.29 rows=13868023 width=1042)
33                     (actual time=0.090..148691.566 rows=11094533 loops=3)
34                           Buffers: shared hit=5811206 read=5210494
35                           I/O Timings: read=320684.515
36 Planning time: 0.118 ms
37 Execution time: 154086.685 ms

Ici le moteur effectue le tri plus tard sur beaucoup moins de lignes. Le temps d’exécution est nettement réduit et on s’épargne surtout 33Go de fichiers temporaires.

Mot de la fin

Les statistiques sont indispensables pour choisir les meilleurs plan d’exécution. Actuellement Postgres dispose de fonctionnalités avancées pour le JSON ³ Malheureusement il n’y a pas encore de possibilité d’ajouter de statistiques sur le type JSONB. A noter que PostgreSQL 10 apporte l’infrastructure pour . Espérons que dans le futur il sera possible de les étendre pour des types spéciaux.

En attendant il est possible de contourner cette limitation en utilisant les index fonctionnels.

↩︎
Un noeud bitmap devient lossy lorsque le moteur ne peut pas faire un bitmap de tous les enregistrements. Il passe donc en mode dit “lossy” où le bitmap ne se fait plus sur l’enregistrement mais pour le bloc entier. Ce qui nécessite de lire plus de blocs et de faire un “recheck” qui consiste à filter les enregistrements obtenus. ↩︎
La est très complète et fournie de nombreux exemples : usage des opérateurs, indexation. ↩︎

PostgreSQL 10 : ICU & Abbreviated Keys

Sun, 19 Nov 2017 15:30:00 +0100

A peu près tout le monde a entendu parler du partitionnement et de la réplication logique dans PostgreSQL 10. Avez-vous entendu parler du support des règles de collation ICU (International Components for Unicode)?

Cet article va présenter en quoi consiste cette nouvelle fonctionnalité mais également les gains possibles en exploitant les abbreviated keys.

Table des matières

Court rappel sur le collationnement

En base de données, le collationnement correspond à des règles de classement de caractères.

Voici quelques exemples :

1create table t1 (c1 text);
2insert into t1 values ('cote'),('coté'),('côte'),('côté');

Deux exemples de tris en fonctions de deux locales : française et allemande

 1select * from t1 order by c1 collate "de_DE";
 2  c1
 3------
 4 cote
 5 coté
 6 côte
 7 côté
 8
 9select * from t1 order by c1 collate "fr_FR";
10  c1
11------
12 cote
13 côte
14 coté
15 côté

Observez bien l’ordre de tri, en langue française le tri se fait sur le dernier accent ce qui n’est pas le cas de l’allemand.

Par défaut, Postgres utilise le collationnement de l’environnement. Il est possible de spécifier le collationnement à la création de l’instance, d’une base, d’une table… Même au niveau d’une colonne.

Il existe aussi un collationnement particulier “C” où postgres effectue le tri selon l’ordre de codage des caractères.

La table pg_collation du catalogue système énumère les différentes collations. La colonne collprovider indique la source :

c: libc
i: ICU

Par exemple :

 1-[ RECORD 1 ]-+-----------------------
 2collname      | en-US-x-icu
 3collnamespace | 11
 4collowner     | 10
 5collprovider  | i
 6collencoding  | -1
 7collcollate   | en-US
 8collctype     | en-US
 9collversion   | 153.64
10-[ RECORD 4 ]-+-----------------------
11collname      | en_US
12collnamespace | 11
13collowner     | 10
14collprovider  | c
15collencoding  | 6
16collcollate   | en_US.utf8
17collctype     | en_US.utf8
18collversion   |

Collations ICU

Postgres s’appuie sur les librairies du système d’exploitation pour effectuer les opérations de tri. Sous linux, il s’appuie sur la très connue glibc.

L’intérêt majeur de s’appuyer sur cette librairie est de ne pas avoir à réécrire et maintenir tout un ensemble de règles de tri.

Cependant, cette approche peut présenter un inconvénient:

On doit faire “confiance” à cette librairie. Au sein d’une même distribution (et même release), la libc retournera toujours les mêmes résultats. Les choses peuvent se corser si on doit comparer les résultats obtenus depuis des libcs différentes. Par exemple, en utilisant une distribution différente ou une release différente. C’est pourquoi il est déconseillé de mettre des serveurs en streaming replication avec des distributions différentes : les index pourraient ne pas être cohérents. Cf :

Les collations ICU sont plus riches. Il est possible de changer l’ordre des tris. Par exemple les mascules avant les minuscules: . Peter Geoghegan a donné quelques exemples sur la mailing list hackers :

Histoire des abbreviated keys dans PostgreSQL

Petit tour dans le passé :) La version 9.5 améliorait l’algorithme de tri grâce aux abbreviated keys. Les gains annoncés étaient vraiment important, ici entre 40 et 70% :

En gros, les abbreviated keys permettent de mieux exploiter le cache des processeurs. Peter Geoghegan, qui est l’auteur du patch, apporte une explication sur son blog :

Malheureusement cette fonctionnalité a dû être désactivée dans la version 9.5.2:

La raison? Un bug dans certaines version de la libc! Ce bug entrainait une corruption de l’index:

Quel est le lien avec les collations ICU? C’est tout simple, avec une collation ICU le moteur ne s’appuie plus sur la libc. Il est donc possible d’utiliser les Abbreviated keys.

On peut aller le vérifier dans le code :

 1src/backend/utils/adt/varlena.c
 21876     /*
 31877      * Unfortunately, it seems that abbreviation for non-C collations is
 41878      * broken on many common platforms; testing of multiple versions of glibc
 51879      * reveals that, for many locales, strcoll() and strxfrm() do not return
 61880      * consistent results, which is fatal to this optimization.  While no
 71881      * other libc other than Cygwin has so far been shown to have a problem,
 81882      * we take the conservative course of action for right now and disable
 91883      * this categorically.  (Users who are certain this isn't a problem on
101884      * their system can define TRUST_STRXFRM.)
111885      *
121886      * Even apart from the risk of broken locales, it's possible that there
131887      * are platforms where the use of abbreviated keys should be disabled at
141888      * compile time.  Having only 4 byte datums could make worst-case
151889      * performance drastically more likely, for example.  Moreover, macOS's
161890      * strxfrm() implementation is known to not effectively concentrate a
171891      * significant amount of entropy from the original string in earlier
181892      * transformed blobs.  It's possible that other supported platforms are
191893      * similarly encumbered.  So, if we ever get past disabling this
201894      * categorically, we may still want or need to disable it for particular
211895      * platforms.
221896      */
231897 #ifndef TRUST_STRXFRM
241898     if (!collate_c && !(locale && locale->provider == COLLPROVIDER_ICU))
251899         abbreviate = false;
261900 #endif

Quelques tests

Quand j’ai préparé ma présentation sur le , j’ai souhaité travailler sur un jeu de donnée “réel”: la base de donnée de stackoverflow.

Voici les résultats de la création de 3 index sur la colonne “title” de la table posts (38Go):

Un ignorant la collation: collate "C"
Un utilisant la collation en_US de la libc: collate "en_US"
Un utilisant la collation en_US de la librairie ICU collate "en-US-x-icu"

J’active quelques options pour avoir la durée d’exécution de la requête et des informations sur le tri:

1\timing
2set client_min_messages TO log;
3set trace_sort to on;

 1create index idx1 on posts (title collate  "C");
 2LOG:  begin index sort: unique = f, workMem = 6291456, randomAccess = f
 3LOG:  varstr_abbrev: abbrev_distinct after 160: 56.532166 (key_distinct: 59.707363, norm_abbrev_card: 0.353326, prop_card: 0.200000)
 4LOG:  varstr_abbrev: abbrev_distinct after 321: 110.782140 (key_distinct: 121.985752, norm_abbrev_card: 0.345116, prop_card: 0.200000)
 5[...]
 6LOG:  varstr_abbrev: abbrev_distinct after 10485760: 523091.461475 (key_distinct: 4215367.096361, norm_abbrev_card: 0.049886, prop_card: 0.002693)
 7LOG:  varstr_abbrev: abbrev_distinct after 20971522: 852125.989455 (key_distinct: 8800364.815018, norm_abbrev_card: 0.040633, prop_card: 0.001750)
 8LOG:  performsort starting: CPU: user: 21.88 s, system: 17.27 s, elapsed: 104.98 s
 9LOG:  performsort done: CPU: user: 43.55 s, system: 17.27 s, elapsed: 126.65 s
10LOG:  internal sort ended, 3519559 KB used: CPU: user: 48.14 s, system: 18.40 s, elapsed: 142.19 s
11CREATE INDEX
12Time: 142380.670 ms (02:22.381)

Ici, postgres exploite les abbreviated keys car il n’y a pas de règles de collation. Il a juste à trier selon le codage des caractères. Le tri ne tient donc pas compte des règles de collationnement.

1create index idx2 on posts (title collate  "en_US");
2LOG:  begin index sort: unique = f, workMem = 6291456, randomAccess = f
3LOG:  performsort starting: CPU: user: 20.10 s, system: 17.32 s, elapsed: 104.80 s
4LOG:  performsort done: CPU: user: 137.52 s, system: 17.32 s, elapsed: 222.25 s
5LOG:  internal sort ended, 3519559 KB used: CPU: user: 142.41 s, system: 18.10 s, elapsed: 237.97 s
6CREATE INDEX
7Time: 238159.675 ms (03:58.160)

Postgres utilise la libc, il ne peut donc pas exploiter les abbreviated keys.

 1create index idx3 on posts (title collate  "en-US-x-icu");
 2LOG:  begin index sort: unique = f, workMem = 6291456, randomAccess = f
 3LOG:  varstr_abbrev: abbrev_distinct after 160: 55.475952 (key_distinct: 59.707363, norm_abbrev_card: 0.346725, prop_card: 0.200000)
 4LOG:  varstr_abbrev: abbrev_distinct after 321: 110.782140 (key_distinct: 121.985752, norm_abbrev_card: 0.345116, prop_card: 0.200000)
 5[...]
 6LOG:  varstr_abbrev: abbrev_distinct after 10485760: 337228.120654 (key_distinct: 4215367.096361, norm_abbrev_card: 0.032161, prop_card: 0.002693)
 7LOG:  varstr_abbrev: abbrev_distinct after 20971522: 521498.943210 (key_distinct: 8800364.815018, norm_abbrev_card: 0.024867, prop_card: 0.001750)
 8LOG:  performsort starting: CPU: user: 30.22 s, system: 16.78 s, elapsed: 105.65 s
 9LOG:  performsort done: CPU: user: 66.86 s, system: 16.78 s, elapsed: 142.31 s
10LOG:  internal sort ended, 3519559 KB used: CPU: user: 71.23 s, system: 18.04 s, elapsed: 157.79 s
11CREATE INDEX
12Time: 157979.957 ms (02:37.980)

Postgres utilise la librairie ICU, il peut exploiter les abbreviated keys. Le gain est de l’ordre de 34%. Contrairement au premier exemple, le tri tient compte des règles de collationnement en_US.

Note : Si comme moi il vous manquait des collations système (lors de l’initdb), il est possible d’importer les nouvelles collations grâce à la fonction pg_import_system_collations. Par exemple :

1select pg_import_system_collations('pg_catalog');
2 pg_import_system_collations
3-----------------------------
4                           6

PostgreSQL 10 : Amélioration des performances

Wed, 04 Oct 2017 09:51:44 +0000

La sortie de la version 10 approche à grands pas, elle est prévue pour demain :

Cette nouvelle version inclue des fonctionnalités très attendues comme :

La réplication logique
Le partitionnement natif
Amélioration du parallélisme
Statistiques multi-colonnes
…

Pour une liste exhaustive voir :

Dans cet article je vais vous présenter des améliorations sur les performances qui ne sont pas listées dans les releases notes! Aussi surprenant que cela puisse paraître, la communauté ne liste pas ce genre d’améliorations : elles ne représentent pas un changement significatif du point de vue de l’utilisateur.

Bruce Momjian me l’a gentiment rappelé quand j’ai demandé s’il était possible d’indiquer ces améliorations :

Réécriture d’une partie de l’exécuteur

Andres Freund a réécris une partie de l’exécuteur :

 1commit b8d7f053c5c2bf2a7e8734fe3327f6a8bc711755
 2Author: Andres Freund <andres@anarazel.de>
 3AuthorDate: Tue Mar 14 15:45:36 2017 -0700
 4Commit: Andres Freund <andres@anarazel.de>
 5CommitDate: Sat Mar 25 14:52:06 2017 -0700
 6
 7Faster expression evaluation and targetlist projection.
 8
 9This replaces the old, recursive tree-walk based evaluation, with
10 non-recursive, opcode dispatch based, expression evaluation.
11 Projection is now implemented as part of expression evaluation.
12
13This both leads to significant performance improvements, and makes
14 future just-in-time compilation of expressions easier.
15
16The speed gains primarily come from:
17 - non-recursive implementation reduces stack usage / overhead
18 - simple sub-expressions are implemented with a single jump, without
19 function calls
20 - sharing some state between different sub-expressions
21 - reduced amount of indirect/hard to predict memory accesses by laying
22 out operation metadata sequentially; including the avoidance of
23 nearly all of the previously used linked lists
24 - more code has been moved to expression initialization, avoiding
25 constant re-checks at evaluation time
26...

Comme vous pouvez le lire, ce commit apporte un gain sur les performances mais facilitera la mise en œuvre du « JIT » pour « Just In Time » : ) dans les futures versions.

Le thread mentionne des gains significatifs :

Améliorations sur les tri externes

Les commits suivants améliorent très significativement les tris externes :

 1commit e94568ecc10f2638e542ae34f2990b821bbf90ac
 2Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
 3Date: Mon Oct 3 13:37:49 2016 +0300
 4
 5Change the way pre-reading in external sort's merge phase works.
 6
 7 Don't pre-read tuples into SortTuple slots during merge. Instead, use the
 8 memory for larger read buffers in logtape.c. We're doing the same number
 9 of READTUP() calls either way, but managing the pre-read SortTuple slots
10 is much more complicated. Also, the on-tape representation is more compact
11 than SortTuples, so we can fit more pre-read tuples into the same amount
12 of memory this way. And we have better cache-locality, when we use just a
13 small number of SortTuple slots.
14...

 1commit 24598337c8d214ba8dcf354130b72c49636bba69
 2Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
 3Date: Sun Sep 11 16:27:27 2016 +0300
 4
 5Implement binary heap replace-top operation in a smarter way.
 6
 7 In external sort's merge phase, we maintain a binary heap holding the next
 8 tuple from each input tape. On each step, the topmost tuple is returned,
 9 and replaced with the next tuple from the same tape. We were doing the
10 replacement by deleting the top node in one operation, and inserting the
11 next tuple after that. However, you can do a "replace-top" operation more
12 efficiently, in one "sift-up". A deletion will always walk the heap from
13 top to bottom, but in a replacement, we can stop as soon as we find the
14 right place for the new tuple. This is particularly helpful, if the tapes
15 are not in completely random order, so that the next tuple from a tape is
16 likely to land near the top of the heap.

Pour faire simple, les algorithmes ont été revus et permettent de mieux exploiter les caches. Là aussi les gains sont très significatifs, on a constaté des tris deux fois plus rapides sur certaines plateformes (le résultat peut dépendre de beaucoup de paramètres, notamment la taille du cache du processeur etc).

Ainsi les tris qui ne peuvent pas tenir en mémoire et qui doivent donc être effectués sur disque devraient être beaucoup plus rapides. Par exemple, lors de la création d’un index sur une table volumineuse 🙂

Améliorations sur les fonctions de hashages

Andreus Freund (encore!) a revu les fonctions de hashage et à nouveau les gains sont impressionnants.

Peter Geoghegan en fait mention dans cette conférence :

(Voir le slide 52)

Andres Freund a mis en place une infrastructure :

 1commit b30d3ea824c5ccba43d3e942704f20686e7dbab8
 2Author: Andres Freund ><andres@anarazel.de>
 3Date:   Fri Oct 14 16:05:30 2016 -0700
 4
 5    Add a macro templatized hashtable.
 6
 7    dynahash.c hash tables aren't quite fast enough for some
 8    use-cases. There are several reasons for lacking performance:
 9    - the use of chaining for collision handling makes them cache
10      inefficient, that's especially an issue when the tables get bigger.
11    - as the element sizes for dynahash are only determined at runtime,
12      offset computations are somewhat expensive
13    - hash and element comparisons are indirect function calls, causing
14      unnecessary pipeline stalls
15    - it's two level structure has some benefits (somewhat natural
16      partitioning), but increases the number of indirections
17    to fix several of these the hash tables have to be adjusted to the
18    individual use-case at compile-time. C unfortunately doesn't provide a
19    good way to do compile code generation (like e.g. c++'s templates for
20    all their weaknesses do).  Thus the somewhat ugly approach taken here is
21    to allow for code generation using a macro-templatized header file,
22    which generates functions and types based on a prefix and other
23    parameters.
24
25    Later patches use this infrastructure to use such hash tables for
26    tidbitmap.c (bitmap scans) and execGrouping.c (hash aggregation,
27    ...). In queries where these use up a large fraction of the time, this
28    has been measured to lead to performance improvements of over 100%.
29...

Oui vous lisez bien « improvements of over 100% » :)

Ensuite il a utilisé cette infrastructure pour améliorer les bitmap scan et les jointures par hash join :

1commit 75ae538bc3168bf44475240d4e0487ee2f3bb376
2Author: Andres Freund <andres@anarazel.de>
3Date:   Fri Oct 14 16:05:30 2016 -0700
4
5    Use more efficient hashtable for tidbitmap.c to speed up bitmap scans.
6
7    Use the new simplehash.h to speed up tidbitmap.c uses. For bitmap scan
8    heavy queries speedups of over 100% have been measured. Both lossy and
9    exact scans benefit, but the wins are bigger for mostly exact scans.

Encore un gain de 100% :)

Enfin, cette même infrastructure a été utilisée pour améliorer les performances sur les GROUPING SETS (ça, c’est bien mentionné dans les releases notes):

1commit 5dfc198146b49ce7ecc8a1fc9d5e171fb75f6ba5
2Author: Andres Freund <andres@anarazel.de>
3Date:   Fri Oct 14 17:22:51 2016 -0700
4
5    Use more efficient hashtable for execGrouping.c to speed up hash aggregation.
6
7    The more efficient hashtable speeds up hash-aggregations with more than
8    a few hundred groups significantly. Improvements of over 120% have been
9    measured.

Ici le commit mentionne un gain de 120% :)

Globalement, il faut se dire que chaque nouvelle version apporte des gains en performance même s’ils ne sont pas mentionnés dans les Releases Notes. Ainsi, je vous encourage vivement à faire vos propres tests pour comparer les performances.

La version 10 marque un vrai tournant, PostgreSQL devient vraiment taillé pour s’attaquer aux grosses volumétries (et ce n’est pas fini :) ).

PGDay : Comment fonctionne la recherche plein texte dans PostgreSQL?

Sat, 02 Sep 2017 11:04:58 +0000

Lors du dernier j’ai fait une présentation sur le fonctionnement de la recherche plein texte (Full Text Search - FTS) dans PostgreSQL.

Cette fonctionnalité est malheureusement trop peu connue. Je vois plusieurs raisons à cela :

Complexité : Le FTS fait appels à des notions inconnues d’un DBA : lemmatisation, représentation vectorielle d’un document…
La tendance à utiliser un outil dédié à la recherche plein texte : Elasticsearch, SOLR …
Ignorance des fonctionnalités avancées de PostgreSQL

Pourtant, il y a plusieurs avantages à utiliser le FTS de PostgreSQL :

On conserve un seul et même langage : le SQL
Pas de duplication des données entre la base de donnée et le moteur d’indexation
On conserve une certaine cohérence :
- Pas besoin de faire des synchronisations entre les données contenues dans votre base de donnée et le moteur d’indexation
- Un document supprimé de la base de donnée ne sera pas oublié dans le moteur d’indexation
On bénéficie de toutes les fonctionnalités avancées de PostgreSQL, notamment des index performants.
Le moteur est extensible, on peut personnaliser la configuration FTS

Quand j’ai commencé à me plonger dans le FTS j’ai vite été rebuté par des termes qui m’était inconnus, des syntaxes particulières avec de nouveaux opérateurs. Au lieu de faire une présentation sur l’étendue des possibilités du FTS, je me suis donc attaché à présenter son fonctionnement par « la base ». C’est à dire toute la « mécanique » qui se cache derrière.

Voici la vidéo de la conférence :

Ainsi que les .

PostgreSQL 10 et la réplication logique – Restrictions

Sun, 27 Aug 2017 16:48:22 +0000

Cet article est la suite d’une série d’articles sur la réplication logique dans la version 10 de PostgreSQL

Celui-ci va porter sur les restrictions de la réplication logique.

Restrictions

La documentation de postgreSQL est très bien faite. Il y a toute une page sur les .

Ordres DDL

Le schéma et les ordres DDL ne sont pas répliqués. Il faudra donc veiller à bien reporter toute modification de schéma. Dans le cas contraire un conflit de réplication pourrait se produire ce qui bloque toute réplication. Une fois la correction apportée la réplication peut reprendre. Pour éviter toute erreur il est préférable d’appliquer les changements de schéma sur le “secondaire” en premier.

Séquences

Les séquences ne sont pas répliquées. Les données d’une colonne serial seront bien répliquées mais le compteur de la séquence ne sera pas incrémenté. Si le “secondaire” est seulement utilisé en lecture seule ça ne posera pas de problème. En revanche, en cas de bascule il faudra mettre à jour la séquence ou la placer à une valeur supérieure à la valeur la plus haute présente dans la table.

Ordre TRUNCATE

Les ordres TRUNCATE ne sont pas répliqués. Il peut être utile de révoquer le droit de TRUNCATE sur les tables répliquées avec : REVOKE TRUNCATE ON TABLE matable FROM utilisateur.

Large Objects

Les Large Objets ne sont pas répliqués

Schéma et tables

La réplication logique ne réplique que des tables, il n’est pas possible de répliquer des vues, vues matérialisées, partition racine, foreign tables… Les schéma « source » et « destination » doivent être identiques. Il n’est pas possible de répliquer la table t1 du schéma s1 dans un schéma s2 sur un secondaire.

Replica Identity

Pour les opérations UPDATE et DELETE, la table doit avoir une . Dans le cas contraire le moteur remontera une erreur. Par défaut c’est la clé primaire qui est utilisée.

PostgreSQL 10 et la réplication logique – Mise en oeuvre

Sat, 05 Aug 2017 11:13:43 +0000

Cet article est la suite d’une série d’articles sur la réplication logique dans la version 10 de PostgreSQL

Celui-ci va porter sur la mise en œuvre de la réplication logique.

Table des matières

Installation

Lors de la rédaction de cet article la version 10 n’est pas encore sortie. Cependant la communauté met à disposition les paquets des versions bêtas. Bien entendu, à ne pas utiliser en production.

Installation du dépôt pgdg (PostgreSQL Developpement Group)

Il suffit d’aller sur le site puis « download » -> « debian ». Sur cette page, le site vous indique la marche à suivre pour installer le dépôt du pgdg. Cependant il ne va vous proposer que les versions stables. Mais, le site vous renvoie vers une page du wiki :

For more information about the apt repository, including answers to frequent questions, please see the apt page on .

Sur la page wiki vous trouverez :

For packages of development/alpha/beta versions of PostgreSQL, see the .

Qui vous indique :

To use packages of postgresql-10, you need to add the 10 component to your /etc/apt/sources.list.d/pgdg.list entry, so the 10 version of libpq5 will be available for installation

Donc pour debian, les commandes se résument à :

1wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
2sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -cs)-pgdg main 10" > /etc/apt/sources.list.d/pgdg.list'
3sudo apt-get update

Installation des paquets

1sudo apt install postgresql-10

Création des instances

Une première instance est créée lors de l’installation. Nous allons installer une seconde instance. Ainsi l’une sera le « publisher » et l’autre sera « subscriber ».

 1# pg_lsclusters
 2Ver Cluster Port Status Owner Data directory Log file
 310 main 5432 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
 4
 5# pg_createcluster 10 sub
 6Creating new PostgreSQL cluster 10/sub ...
 7/usr/lib/postgresql/10/bin/initdb -D /var/lib/postgresql/10/sub --auth-local peer --auth-host md5
 8The files belonging to this database system will be owned by user "postgres".
 9This user must also own the server process.
10
11The database cluster will be initialized with locale "en_US.UTF-8".
12The default database encoding has accordingly been set to "UTF8".
13The default text search configuration will be set to "english".
14
15Data page checksums are disabled.
16
17fixing permissions on existing directory /var/lib/postgresql/10/sub ... ok
18creating subdirectories ... ok
19selecting default max_connections ... 100
20selecting default shared_buffers ... 128MB
21selecting dynamic shared memory implementation ... posix
22creating configuration files ... ok
23running bootstrap script ... ok
24performing post-bootstrap initialization ... ok
25syncing data to disk ... ok
26
27Success. You can now start the database server using:
28
29/usr/lib/postgresql/10/bin/pg_ctl -D /var/lib/postgresql/10/sub -l logfile start
30
31Ver Cluster Port Status Owner Data directory Log file
3210 sub 5433 down postgres /var/lib/postgresql/10/sub /var/log/postgresql/postgresql-10-sub.log
33
34# pg_ctlcluster 10 sub start
35
36# pg_lsclusters
37Ver Cluster Port Status Owner Data directory Log file
3810 main 5432 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
3910 sub 5433 online postgres /var/lib/postgresql/10/sub /var/log/postgresql/postgresql-10-sub.log

Mise en place de la réplication logique

Prérequis

Il y a très peu de changements à apporter à la configuration par défaut. La plupart des paramètres sont déjà positionnés pour mettre en place la réplication logique. Toutefois il y a un paramètre à modifier sur l’instance qui « publie » : le wal_level. Celui-ci est à “replica” , il doit être placé à “logical” .

Ca se passe dans /etc/postgresql/10/main/postgresql.conf

1wal_level = logical

Pour appliquer le changement il faut redémarrer l’instance :

1pg_ctlcluster 10 main restart

Publication

Créons une base b1 qui contient une table t1.

 1postgres=# create database b1;
 2CREATE DATABASE
 3postgres=# \c b1
 4You are now connected to database "b1" as user "postgres".
 5
 6b1=# create table t1 (c1 text);
 7CREATE TABLE
 8b1=# insert into t1 values ('un');
 9INSERT 0 1
10b1=# select * from t1;
11 c1
12----
13 un
14(1 row)

Ensuite nous allons jouer l’ordre pour créer la publication :

1b1=# CREATE PUBLICATION pub1 FOR TABLE t1 ;

Et c’est tout! Notez qu’il est possible d’utiliser le mot clé « FOR ALL TABLES » pour que le PostgreSQL ajoute toutes les tables présentes et futures à la publication.

On peut vérifier que la publication a bien été créée avec la méta-commande psql suivante :

1b1=# \dRp+
2 Publication pub1
3 All tables | Inserts | Updates | Deletes
4------------+---------+---------+---------
5 f | t | t | t
6Tables:
7 "public.t1"

Souscription

La réplication logique ne réplique pas les ordres DDL, nous devons donc créer la table sur l’instance « sub ». Il n’est pas nécessaire d’avoir le même nom de base, nous allons donc créer une base b2.

 1postgres@blog:~$ psql -p 5433
 2psql (10beta2)
 3Type "help" for help.
 4
 5postgres=# CREATE DATABASE b2;
 6CREATE DATABASE
 7postgres=# \c b2
 8You are now connected to database "b2" as user "postgres".
 9b2=# create table t1 (c1 text);
10CREATE TABLE

Comme pour la publication, la souscription se crée avec un ordre SQL :

1b2=# CREATE SUBSCRIPTION sub1 CONNECTION 'host=/var/run/postgresql port=5432 dbname=b1' PUBLICATION pub1;
2NOTICE: created replication slot "sub1" on publisher
3CREATE SUBSCRIPTION
4b2=# select * from t1;
5 c1
6----
7 un
8(1 row)

La partie la plus importante est : CONNECTION 'host=/var/run/postgresql port=5432 dbname=b1'

En effet, on indique au « subscriber » comment se connecter à la publication. Dans mon exemple les deux instances sont sur la même machine et écoutent sur une socket locale. Si vous avez des instances sur différentes machines il faudra spécifier l’adresse IP. Ensuite le port et ne surtout pas oublier la base où a été créée la publication.

Comme vous pouvez le voir, le moteur s’est automatiquement chargé de rapatrier les données qui étaient déjà présentes dans la table t1.

Maintenant si j’ajoute des lignes dans la table t1, elles seront automatiquement répliquées sur l’instance « sub » :

 1postgres@blog:~$ psql b1
 2psql (10beta2)
 3Type "help" for help.
 4
 5b1=# insert into t1 values ('deux');
 6INSERT 0 1
 7postgres=# \q
 8postgres@blog:~$ psql -p 5433 b2
 9psql (10beta2)
10Type "help" for help.
11b2=# select * from t1;
12 c1
13------
14 un
15 deux
16(2 rows)

Comme pour la publication, il existe une méta-commande pour afficher les souscriptions :

1\dRs+
2 List of subscriptions
3 Name | Owner | Enabled | Publication | Synchronous commit | Conninfo
4------+----------+---------+-------------+--------------------+----------------------------------------------
5 sub1 | postgres | t | {pub1} | off | host=/var/run/postgresql port=5432 dbname=b1
6(1 row)

C’est tout pour cet article, dans un prochain article nous verront les restrictions d’usage.

PostgreSQL 10 et la réplication logique – Fonctionnement

Sat, 29 Jul 2017 20:53:37 +0000

Certains d’entre vous sont déjà au courant, la nouvelle version majeure de PostgreSQL approche à grands pas. Elle devrait sortir dans le courant du mois de septembre.

Comme chaque nouvelle version la liste de nouveautés est assez impressionnante :

partitionnement
amélioration des performances sur les tris et fonctions d’agrégation
extension du parallélisme : parcours d’index parallélisé, jointure parallélisée, parallélisation des sous-requêtes…
statistiques étendues
support des collations ICU : va permettre d’exploiter les « abbreviated keys » qui avaient dû être désactivées en 9.5 à cause d’un bug dans la libc. Les « abbreviated keys » permettaient un gain de l’ordre de 20-30% sur les tris et créations d’index.
et je m’arrête là, vous pouvez avoir un aperçu des nouveautés sur la page ou dans les .

Une grande nouveauté de la version 10 que je vais présenter dans une série d’articles est la réplication logique.

Rappel

La réplication existe déjà dans PostgreSQL ¹. Elle reposait sur la réplication dite « physique » : le moteur ne réplique pas des requêtes mais le résultat de la requête. Plus précisément les modifications des blocs de données.

Le serveur secondaire se contente de rejouer les journaux de transaction. Cette technique est assez simple et est particulièrement efficace et fiable.

Néanmoins elle présente quelques limitations :

il n’existe aucune granularité, on est obligé de répliquer l’intégralité de l’instance
il n’est pas possible de faire une réplication entre différentes architecture (x86, ARM…).
le secondaire n’accepte aucune requête en écriture. Il n’est dont pas possible de créer des vues personnalisées ou des index.

Fonctionnement

Contrairement à la réplication physique, la réplication logique ne réplique pas les blocs de données. Elle décode le résultat des requêtes qui est transmis au secondaire. Celui-ci applique les modifications SQL issues du flux de réplication logique.

Le serveur secondaire est en réalité un serveur primaire, dans le sens où il s’agît d’un serveur qui accepte des requêtes en écritures comme n’importe quel instance primaire.

Il sera ainsi possible de choisir les tables à répliquer, de rajouter des vues et index sur le serveur secondaire etc…

Schéma réplication logique

Une « publication » est créée sur le serveur primaire (« publieur »), celle-ci comprend les tables appartenant à la publication.
Le secondaire souscrit à cette publication, c’est un « souscripteur ».
Ensuite un processus spécial est lancé : le « bgworker logical replication ». Il va se connecter à un slot de réplication sur le serveur primaire.
Le serveur primaire va procéder à un décodage logique des journaux de transaction pour extraire les résultats des ordres SQL.
Le flux logique est transmis au secondaire qui les applique sur les tables.

La mise en oeuvre dans un prochain article…

Par transfert de journaux de transaction depuis la version 8.2 sortie en 2006 et en flux depuis la version 9.0 sortie en 2010. ↩︎

Comment fonctionne la recherche plein texte ?

Thu, 08 Jun 2017 15:55:00 +0000

PostgreSQL : Retarder la vérification des contraintes

Sat, 13 Aug 2016 20:42:53 +0000

Retarder la vérification des contraintes

Remarque : Cet article a été rédigé durant le cadre de mon activité chez ]

Postgres respecte le modèle , ainsi il garantie la cohérence de la base : une transaction amène la base d’un état stable à un autre.

Les données dans les différentes tables ne sont pas indépendantes mais obéissent à des règles sémantiques mises en place au moment de la conception du modèle conceptuel des données. Les contraintes d’intégrité ont pour principal objectif de garantir la cohérence des données entre elles, et donc de veiller à ce qu’elles respectent ces règles sémantiques. Si une insertion, une mise à jour ou une suppression viole ces règles, l’opération est purement et simplement annulée.

Le moteur effectue la vérification des contraintes à chaque modification (lorsque des contraintes ont été définies). Il est également possible de retarder la vérification des contraintes à la fin de la transaction, au moment du commit. Ainsi, les vérifications ne seront produites que sur les changements effectifs entre les opérations de delete, update et insert de la transaction.

Exemple :

1CREATE TABLE t1 (c1 INT PRIMARY KEY, c2 text);
2 CREATE TABLE t2 (c1 INT REFERENCES t1(c1), c2 text);
3
4INSERT INTO t1  VALUES(1,'a');
5 INSERT INTO t1  VALUES(2,'b');
6
7INSERT INTO t2  VALUES(3,'a');
8 ERROR:  INSERT OR UPDATE ON TABLE "t2" violates FOREIGN KEY CONSTRAINT "t2_c1_fkey"
9 DETAIL:  KEY (c1)=(3) IS NOT present IN TABLE "t1".

La ligne insérée dans t2 doit respecter la contrainte d’intégrité référentielle, la table t1 ne contient aucune ligne où c1=3. Insérons une ligne correcte :

 1INSERT INTO t2  VALUES(1,'a');
 2
 3SELECT * FROM t1;
 4 c1 | c2
 5 ----+----
 6 1 | a
 7 2 | b
 8 (2 ROWS)
 9
10SELECT * FROM t2;
11 c1 | c2
12 ----+----
13 1 | a
14 (1 ROW)

Que se passe t-il si on souhaite modifier la clé primaire de t1?

1BEGIN;
2 UPDATE t1 SET c1=3 WHERE c1=1;
3 ERROR:  UPDATE OR DELETE ON TABLE "t1" violates FOREIGN KEY CONSTRAINT "t2_c1_fkey" ON TABLE "t2"
4 DETAIL:  KEY (c1)=(1) IS still referenced FROM TABLE "t2".

La vérification de la contrainte se fait lors de l’UPDATE et déclenche une erreur. Il est possible de demander au moteur d’effectuer la vérification des contraintes à la fin de la transaction avec l’ordre SET CONSTRAINTS ALL DEFERRED;. A noter également que le mot clef ALL peut-être remplacé par le nom d’une contrainte (si elle est nommée et est DEFERRABLE)

1BEGIN;
2 SET CONSTRAINTS ALL DEFERRED;
3 UPDATE t1 SET c1=3 WHERE c1=1;
4 ERROR:  UPDATE OR DELETE ON TABLE "t1" violates FOREIGN KEY CONSTRAINT "t2_c1_fkey" ON TABLE "t2"
5 DETAIL:  KEY (c1)=(1) IS still referenced FROM TABLE "t2".

Ça ne fonctionne toujours pas, en effet il faut préciser que que l’application de la contrainte peut être retardée avec le mot clé DEFERRABLE

 1ALTER TABLE t2 ALTER CONSTRAINT t2_c1_fkey DEFERRABLE;
 2
 3BEGIN;
 4 SET CONSTRAINTS ALL DEFERRED;
 5 UPDATE t1 SET c1=3 WHERE c1=1;
 6 UPDATE t2 SET c1=3 WHERE c1=1;
 7 commit;
 8
 9SELECT * FROM t1;
10 c1 | c2
11 ----+----
12 2 | b
13 3 | a
14 (2 ROWS)
15
16SELECT * FROM t2;
17 c1 | c2
18 ----+----
19 3 | a
20 (1 ROW)

Dans ce cas le moteur accepte de faire la vérification en fin de transaction.

Autre intérêt, si une ligne est effacée et réinsérée dans la même transaction, les vérifications sur cette ligne ne sont pas exécutées (car inutiles).

Exemple, on vide les tables puis on insère 1 million de lignes.

1TRUNCATE t1 cascade;
2 NOTICE:  TRUNCATE cascades TO TABLE "t2"
3 TRUNCATE TABLE
4
5EXPLAIN analyse INSERT INTO T1 (c1,c2) (SELECT  *,md5(i::text) FROM (SELECT * FROM generate_series(1,1000000)) i);

Ensuite on insère 100 000 lignes, puis on les supprime pour les réinsérer à nouveau (sans indiquer au moteur de différer la vérification de contraintes).

 1BEGIN;
 2
 3EXPLAIN analyse  INSERT INTO T2 (c1,c2) (SELECT  *,md5(i::text) FROM (SELECT * FROM generate_series(1,1000000)) i);
 4
 5QUERY PLAN
 6 ------------------------------------------------------------------------------------------------------------------------------------
 7 INSERT ON t2  (cost=0.00..17.50 ROWS=1000 width=36) (actual TIME=3451.308..3451.308 ROWS=0 loops=1)
 8 ->  FUNCTION Scan ON generate_series  (cost=0.00..17.50 ROWS=1000 width=36) (actual TIME=170.218..1882.406 ROWS=1000000 loops=1)
 9 Planning TIME: 0.054 ms
10 TRIGGER FOR CONSTRAINT t2_c1_fkey: TIME=16097.543 calls=1000000
11 Execution TIME: 19654.595 ms
12 (5 ROWS)
13
14TIME: 19654.971 ms
15
16DELETE FROM t2 WHERE c1 <= 1000000;
17 DELETE 1000000
18 TIME: 2088.318 ms
19
20EXPLAIN analyse  INSERT INTO T2 (c1,c2) (SELECT  *,md5(i::text) FROM (SELECT * FROM generate_series(1,1000000)) i);
21 QUERY PLAN
22 ------------------------------------------------------------------------------------------------------------------------------------
23 INSERT ON t2  (cost=0.00..17.50 ROWS=1000 width=36) (actual TIME=3859.265..3859.265 ROWS=0 loops=1)
24 ->  FUNCTION Scan ON generate_series  (cost=0.00..17.50 ROWS=1000 width=36) (actual TIME=169.826..1845.421 ROWS=1000000 loops=1)
25 Planning TIME: 0.054 ms
26 TRIGGER FOR CONSTRAINT t2_c1_fkey: TIME=14600.258 calls=1000000
27 Execution TIME: 18558.108 ms
28 (5 ROWS)
29
30TIME: 18558.386 ms
31 commit;
32 COMMIT
33 TIME: 8.563 ms

Le moteur va effectuer les vérifications à chaque insertion (environ 18 secondes à chaque insertion).

Effectuons la même opération en retardant la vérification des contraintes :

 1BEGIN;
 2 BEGIN
 3 TIME: 0.130 ms
 4
 5SET CONSTRAINTS ALL deferred ;
 6 SET CONSTRAINTS
 7
 8EXPLAIN analyse  INSERT INTO T2 (c1,c2) (SELECT  *,md5(i::text) FROM (SELECT * FROM generate_series(1,1000000)) i);
 9
10QUERY PLAN
11 ------------------------------------------------------------------------------------------------------------------------------------
12 INSERT ON t2  (cost=0.00..17.50 ROWS=1000 width=36) (actual TIME=3241.172..3241.172 ROWS=0 loops=1)
13 ->  FUNCTION Scan ON generate_series  (cost=0.00..17.50 ROWS=1000 width=36) (actual TIME=169.770..1831.893 ROWS=1000000 loops=1)
14 Planning TIME: 0.096 ms
15 Execution TIME: 3269.624 ms
16 (4 ROWS)
17
18TIME: 3270.018 ms
19
20DELETE FROM t2 WHERE c1 <= 1000000;
21 DELETE 2000000
22 TIME: 2932.070 ms
23
24EXPLAIN analyse  INSERT INTO T2 (c1,c2) (SELECT  *,md5(i::text) FROM (SELECT * FROM generate_series(1,1000000)) i);
25 QUERY PLAN
26 ------------------------------------------------------------------------------------------------------------------------------------
27 INSERT ON t2  (cost=0.00..17.50 ROWS=1000 width=36) (actual TIME=3181.294..3181.294 ROWS=0 loops=1)
28 ->  FUNCTION Scan ON generate_series  (cost=0.00..17.50 ROWS=1000 width=36) (actual TIME=170.137..1811.889 ROWS=1000000 loops=1)
29 Planning TIME: 0.055 ms
30 Execution TIME: 3209.712 ms
31 (4 ROWS)
32
33TIME: 3210.067 ms
34
35commit;
36 COMMIT
37 TIME: 16630.155 ms

Les insertions sont plus rapides, en revanche le commit est plus long car le moteur effectue la vérification des contraintes. Au final, le moteur effectue une seule vérification à la fin de la transaction (commit). L’opération est donc plus rapide.

Il est possible de créer la contrainte avec un autre attribut DEFERRABLE INITIALLY DEFERRED qui permet de s’affranchir du SET CONSTRAINTS ALL DEFERRED. A noter également que le mot clef ALL peut-être remplacé par le nom d’une contrainte (si elle est nommée et est DEFERRABLE)

Si les enregistrements modifiés ne respectent pas les contraintes, la transaction est annulée au moment du commit :

 1SELECT * FROM t1;
 2 c1 | c2
 3 ----+----
 4 1 | un
 5 (1 ROW)
 6
 7BEGIN;
 8 SET constraints ALL deferred ;
 9 SET CONSTRAINTS
10 anayrat=# INSERT INTO t2 VALUES ('2','un');
11 INSERT 0 1
12 anayrat=# commit;
13 ERROR:  INSERT OR UPDATE ON TABLE "t2" violates FOREIGN KEY CONSTRAINT "t2_c1_fkey"
14 DETAIL:  KEY (c1)=(2) IS NOT present IN TABLE "t1".

D’autre part, la solution de désactivation des contraintes peut effectivement poser des problèmes si on souhaite les réactiver et que les données ne le permettent pas (contrainte effectivement rompue), cette solution reste possible, au sein d’une transaction, toutefois cela provoque un verrouillage exclusif sur la table modifiée pendant toute la transaction ce qui peut poser de sérieux problèmes de performance.

Il est également possible de déclarer la contrainte en NOT VALID. La création de la contrainte sera quasi immédiate, les données actuellement présentes ne seront pas validées. Cependant, toutes les données insérées ou mises à jour par la suite seront validées vis à vis de ces contraintes.

Ensuite on peut demander au moteur de faire la vérification des contraintes pour l’intégralité des enregistrements avec l’ordre VALIDATE CONSTRAINT. Cet ordre entraîne un verrou exclusif sur la table. A partir de la version 9.4 le verrou est plus léger : SHARE UPDATE EXCLUSIVE sur la table modifiée. Si la contrainte est une clé étrangère, le verrou est de type ROW SHARE sur la table référente.

 1ALTER TABLE t2 DROP CONSTRAINT t2_c1_fkey ;
 2 ALTER TABLE
 3 SELECT * FROM t1;
 4 c1 | c2
 5 ----+----
 6 1 | un
 7 (1 ROW)
 8
 9SELECT * FROM t2;
10 c1 | c2
11 ----+----
12 (0 ROWS)
13
14INSERT INTO t2 VALUES (2,'deux');
15 INSERT 0 1
16 SELECT * FROM t2;
17 c1 |  c2
18 ----+------
19 2 | deux
20 (1 ROW)
21
22ALTER TABLE t2 ADD CONSTRAINT t2_c1_fkey FOREIGN KEY (c1) REFERENCES t1(c1) NOT VALID;
23 ALTER TABLE

La table t2 contient un enregistrement ne respectant pas la contrainte t2_c1_fkey. Aucune erreur n’est remontée car la vérification se fait seulement pour les nouvelles modifications :

1INSERT INTO t2 VALUES (3,'trois');
2 ERROR:  INSERT OR UPDATE ON TABLE "t2" violates FOREIGN KEY CONSTRAINT "t2_c1_fkey"
3 DETAIL:  KEY (c1)=(3) IS NOT present IN TABLE "t1".

De même, une erreur est bien remontée lors de la vérification de contrainte :

1ALTER TABLE t2 VALIDATE CONSTRAINT t2_c1_fkey ;
2 ERROR:  INSERT OR UPDATE ON TABLE "t2" violates FOREIGN KEY CONSTRAINT "t2_c1_fkey"
3 DETAIL:  KEY (c1)=(2) IS NOT present IN TABLE "t1".

En supprimant l’enregistrement posant problème, les contraintes peuvent être validées :

1DELETE FROM t2 WHERE t2.c1 NOT IN (SELECT c1 FROM t1);
2 DELETE 1
3 ALTER TABLE t2 VALIDATE CONSTRAINT t2_c1_fkey ;
4 ALTER TABLE

Index BRIN - Fonctionnement et usages possibles

Tue, 31 May 2016 16:00:00 +0000

Index BRIN – Performances

Thu, 21 Apr 2016 20:58:55 +0000

La version 9.5 de PostgreSQL sortie en Janvier 2016 propose un nouveau type d’index : les Index BRIN pour Bloc Range INdex. Ces derniers sont recommandés pour les tables volumineuses et corrélées avec leur emplacement. J’ai décidé de consacrer une série d’article sur ces index :

Pour information, je serai présent au à Lille le mardi 31 mai pour présenter cet index. Il y aura également plein d’autres !

Cet article est la dernier de la série, il sera consacré aux performances (maintenance, lecture, insertion…)

Performances

Les articles précédents ont abordé le fonctionnement et les spécificités des index BRIN. Cet article sera plutôt consacré aux performances. Les exemples précédents portaient sur de petites volumétries. Maintenant nous allons voir ce que peuvent apporter ces index sur une volumétrie plus importante.

Les tests ont été effectués sur un PC portable, les journaux de transaction, la table et les index sont stockés sur un disque mécanique. Les résultats seront différents suivant la matériel utilisé. Ces chiffres sont purement indicatifs et servent surtout à se donner un ordre d’idée.

Exemple

Dans un premier temps il est nécessaire de créer une table avec une volumétrie importante.

Par exemple : un système de mesure avec 100 sondes et une mesure toutes les secondes. Nous allons donc obtenir 100*365*24*3600 mesures => un peu plus de 3 milliards de lignes.

 1-- Utilisation d'une fonction pour générer du texte aléatoire.
 2-- Trouvée ici : http://stackoverflow.com/questions/3970795/how-do-you-create-a-random-string-in-postgresql
 3
 4CREATE OR REPLACE FUNCTION random_string(LENGTH INTEGER) RETURNS text AS
 5$$
 6DECLARE
 7  chars text[] := '{0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z}';
 8  RESULT text := '';
 9  i INTEGER := 0;
10BEGIN
11  IF LENGTH < 0 THEN
12    raise exception 'Given length cannot be less than 0';
13  END IF;
14  FOR i IN 1..LENGTH loop
15    RESULT := RESULT || chars[1+random()*(array_length(chars, 1)-1)];
16  END loop;
17  RETURN RESULT;
18END;
19$$ LANGUAGE plpgsql;
20-- Creation de la table contenant les sondes
21CREATE TABLE probe (id serial PRIMARY KEY, name text);
22INSERT INTO probe (name ) SELECT random_string(5) FROM generate_series(1,100);
23
24CREATE TABLE data AS
25WITH generation AS (
26SELECT '2015-01-01'::TIMESTAMP + i * INTERVAL '1 second' AS date_metric,sonde::text,random() AS metric
27FROM generate_series(0, 3600*24*365) i,
28LATERAL (SELECT name FROM probe) sonde)
29SELECT * FROM generation;

La table obtenue fait un peu plus de 150Go, elle ne rentre donc pas dans la RAM de la machine hébergeant l’instance et encore moins dans la mémoire partagée de PostgreSQL.

Maintenance

On crée plein d’index pour comparer leur taille :

1CREATE INDEX metro_btree_idx ON data USING btree (date_metric);
2CREATE INDEX metro_brin_idx_8 ON data USING brin (date_metric) WITH (pages_per_range = 8);
3CREATE INDEX metro_brin_idx_16 ON data USING brin (date_metric) WITH (pages_per_range = 16);
4CREATE INDEX metro_brin_idx_32 ON data USING brin (date_metric) WITH (pages_per_range = 32);
5CREATE INDEX metro_brin_idx_64 ON data USING brin (date_metric) WITH (pages_per_range = 64);
6CREATE INDEX metro_brin_idx_128 ON data USING brin (date_metric);
7CREATE INDEX metro_brin_idx_256 ON data USING brin (date_metric) WITH (pages_per_range = 256);

Voici les résultats obtenus pour la durée de création des index et leurs tailles :

La création de l’index a été 4 fois plus rapide pour les index BRIN. Il est possible que leur création aurait été plus rapide avec un stockage plus performant.

La taille des index est également frappante, l’index b-tree fait 66 Go alors que l’index BRIN avec le pages_per_range par défaut fait seulement 5 Mo.

On peut tout suite constater le gain sur l’espace utilisé et la rapidité de création des index. Les opérations de maintenances (REINDEX) seront grandement facilitées.

Performances en lecture

Nous allons effectuer plusieurs tests, l’idée est d’essayer de mettre en valeur les différences de comportements entre les index BRIN et b-tree.

La requête utilisée sera tout simple :

1EXPLAIN (ANALYSE,BUFFERS,VERBOSE) SELECT date_metric,sonde,metric FROM DATA WHERE date_metric = 'xxx';

Pour obtenir un résultat avec peu de lignes :

1WHERE date_metric = '2015-05-01 00:00:00'::TIMESTAMP

Pour obtenir plus de résultat on prendra un intervalle avec :

1WHERE date_metric BETWEEN 'xxx'::TIMESTAMP AND 'xxx'::TIMESTAMP;

Voici les résultats obtenus :

<th class="col1" colspan="2">
  BRIN
</th>

<th class="col3" colspan="2">
  Btree
</th>

<th class="col5" colspan="2">
  Gain
</th>

<th class="col1">
  Blocs lus
</th>

<th class="col2">
  Durée
</th>

<th class="col3">
  Blocs lus
</th>

<th class="col4">
  Durée
</th>

<th class="col5">
  Volume données lues
</th>

<td class="col1">
  24ms
</td>

<td class="col2">
  697
</td>

<td class="col3">
  0.06ms
</td>

<td class="col4">
  7
</td>

<td class="col5">
  Btree (x400)
</td>

<td class="col6">
  Btree (x100)
</td>

<td class="col1">
  170s
</td>

<td class="col2">
  13Go
</td>

<td class="col3">
  228s
</td>

<td class="col4">
  18Go
</td>

<td class="col5">
  BRIN (x1.3)
</td>

<td class="col6">
  BRIN (x1.4)
</td>

<td class="col1">
  8min
</td>

<td class="col2">
  38Go
</td>

<td class="col3">
  11min
</td>

<td class="col4">
  54Go
</td>

<td class="col5">
  BRIN (x1.37)
</td>

<td class="col6">
  BRIN (x1.4)
</td>

<td class="col1">
  13min
</td>

<td class="col2">
  63Go
</td>

<td class="col3">
  32min (seqscan)<br /> 18min
</td>

<td class="col4">
  153 Go (seqscan)<br /> 90 Go
</td>

<td class="col5 leftalign">
  BRIN (x2) vs seqscan<br /> BRIN (1.4x) vs Btree
</td>

<td class="col6">
  BRIN (x2.4) vs seqscan<br /> BRIN (1.4x) vs Btree
</td>

lignes
Durée
100
267 millions
777 millions
1.3 milliard

Pour comparer le volume de données lues et la durée d’exécution nous pouvons désactiver les index dans une transaction :

1BEGIN;
2DROP index ...;
3explain (analyse,verbose,buffers) SELECT ...
4rollback;

Pour le 1er test, le moteur choisit l’index-btree. En supprimant l’index b-tree il choisit l’index BRIN.

Pour les tests 2 et 3, le moteur choisit l’index BRIN, en supprimant l’index BRIN il choisit l’index b-tree.

Pour le dernier test j’ai rajouté d’autres mesures. En effet, en supprimant l’index BRIN le moteur va effectuer un seqscan (parcours de toute la table). Pour obtenir les mêmes comparaisons que les résultats précédents j’ai donc supprimé l’index BRIN et désactivé les parcours séquentiels (set enable_seqscan to 'off';)

Globalement on peut constater un gain de 30-40% dans les cas où beaucoup de résultats sont demandés. Le moteur lit moins de blocs lorsqu’il utilise les index BRIN, l’index b-tree étant volumineux, ses lectures sont coûteuses.

En revanche l’index b-tree s’avère particulièrement performant lorsque la requête est très sélective et que peu de résultats sont retournés. En effet, en utilisant un index BRIN, le moteur commence par lire l’intégralité de l’index. Puis il va lire un ensemble de blocs qui contiennent la valeur recherchée, certains ne contenants aucun résultat. Ces lectures supplémentaires se ressentent sur la durée d’exécution de la requête.

Performances en insertion

Vu que les index BRIN sont plus petits et leur durée de création plus courte, on peut se demander ce qu’il advient du surcoût de cet index lors d’insertion de données. Pour cela on va créer une table et mesurer l’insertion de 10 millions de lignes en fonction des index déjà présents sur la table. Afin de cibler le surcoût dû à la mise à jour des index, la table est non-journalisée, ceci permet d’éviter les écritures dans les journaux de transaction. L’autovacuum est également désactivé.

 1CREATE UNLOGGED TABLE brin_demo_2 (c1 INT);
 2INSERT INTO brin_demo_2 SELECT * FROM generate_series(1,10000000);
 3TRUNCATE brin_demo_2;
 4
 5CREATE INDEX brin_demo_2_brin_idx ON brin_demo_2 USING brin (c1);
 6INSERT INTO brin_demo_2 SELECT * FROM generate_series(1,10000000);
 7DROP INDEX brin_demo_2_brin_idx;
 8TRUNCATE brin_demo_2;
 9 
10CREATE INDEX brin_demo_2_brin_idx ON brin_demo_2 USING brin (c1) WITH (pages_per_range = 256);
11INSERT INTO brin_demo_2 SELECT * FROM generate_series(1,10000000);
12DROP INDEX brin_demo_2_brin_idx;
13TRUNCATE brin_demo_2;
14...

Voici les résultats obtenus :

Cependant on peut constater qu’il est moins coûteux d’insérer des données dans une table avec un index BRIN qu’avec un index b-tree. On constate également qu’il n’y a pas d’écart significatif entre les différents types d’index BRIN.

Conclusion

Cette série d’articles a permis de présenter les principes des index BRIN. puis leur fonctionnement à travers des exemples simples.

Ensuite nous avons vu l’importance de la corrélation pour exploiter pleinement ces index. Enfin, nous avons essayé de mesurer le gain que pouvait apporter cet index sur de multiples aspect (maintenance, performance en lecture et insertion).

Décrire le fonctionnement d’un index en simplifiant sa représentation est un exercice compliqué. On peut vite sacrifier le fond à la forme. Présenter des chiffres est également délicat tellement ils peuvent dépendre du contexte. J’ai fait l’effort de détailler comment je les ai obtenu afin que chacun puisse reproduire ses propres tests. L’idée est de donner un aperçu des cas d’utilisation de ce type d’index.

Globalement il faut retenir que les index BRIN sont utiles pour les tables volumineuses et où la corrélation avec l’emplacement des données est importante. Ils seront plus lents que les index b-tree lorsque la recherche nécessite de parcourir peu de blocs. Ils seront un peu plus rapide que les index b-tree dans les situations où le moteur doit lire beaucoup de blocs (moins de blocs à lire dans l’index).

L’étude de cet index ouvre d’autres pistes de réflexion. Comme la prise en compte de la corrélation dans le calcul du coût. J’avais également pensé à la possibilité d’utiliser un index pour créer un autre index.

Dans l’exemple avec la table volumineuse (150Go). Si on souhaite créer un index partiel sur le mois précédent, le moteur va parcourir l’intégralité de la table pour créer d’index. On pourrait envisager créer l’index b-tree en utilisant l’index BRIN pour ne parcourir que les lignes correspondant au moins précédent.

Index BRIN – Corrélation

Wed, 20 Apr 2016 20:57:31 +0000

Pour information, je serai présent au à Lille le mardi 31 mai pour présenter cet index. Il y aura également plein d’autres !

Dans ce troisième article nous verrons pourquoi la corrélation des données avec leur emplacement est importante pour les index BRIN.

Données corrélées

Ces premiers exemples étaient volontairement simples voire simplistes afin de faciliter la compréhension. Les enregistrements avaient une particularité importante : les valeurs étaient croissantes.

Ce qui signifie qu’il y a une forte corrélation entre les enregistrements et leur emplacement.

Pour information, le moteur stocke des statistiques sur les tables afin de choisir le meilleur plan d’exécution. Lançons un ANALYSE sur notre table brin_demo et consultons la vue pg_stats, notamment la colonne « correlation » :

1SELECT tablename,attname,correlation from pg_stats where tablename='brin_demo';
2 tablename | attname | correlation
3-----------+---------+-------------
4 brin_demo | c1 | 1

Essayons avec des données aléatoires :

1CREATE TABLE brin_random (c1 INT);
2INSERT INTO brin_random SELECT trunc(random() * 90 + 1) AS i FROM generate_series(1,100000);
3CREATE INDEX brin_random_brin_idx_16 ON brin_random USING brin (c1) WITH (pages_per_range = 16);
4ANALYZE brin_random;
5SELECT tablename,attname,correlation from pg_stats where tablename='brin_random';
6 tablename | attname | correlation
7-------------+---------+-------------
8 brin_random | c1 | 0.0063248

=> La vue pg_stats nous indique que les données ne sont pas corrélées avec leur emplacement.

Que contient notre index?

 1SELECT * FROM brin_page_items(get_raw_page('brin_random_brin_idx_16', 2), 'brin_random_brin_idx_16');
 2 itemoffset | blknum | attnum | allnulls | hasnulls | placeholder | value
 3------------+--------+--------+----------+----------+-------------+-----------
 4 1 | 0 | 1 | f | f | f | {1 .. 90}
 5 2 | 16 | 1 | f | f | f | {1 .. 90}
 6 3 | 32 | 1 | f | f | f | {1 .. 90}
 7 4 | 48 | 1 | f | f | f | {1 .. 90}
 8 5 | 64 | 1 | f | f | f | {1 .. 90}
 9 6 | 80 | 1 | f | f | f | {1 .. 90}
10 7 | 96 | 1 | f | f | f | {1 .. 90}
11 8 | 112 | 1 | f | f | f | {1 .. 90}
12 9 | 128 | 1 | f | f | f | {1 .. 90}
13 10 | 144 | 1 | f | f | f | {1 .. 90}
14 11 | 160 | 1 | f | f | f | {1 .. 90}
15 12 | 176 | 1 | f | f | f | {1 .. 90}
16 13 | 192 | 1 | f | f | f | {1 .. 90}
17 14 | 208 | 1 | f | f | f | {1 .. 90}
18 15 | 224 | 1 | f | f | f | {1 .. 90}
19 16 | 240 | 1 | f | f | f | {1 .. 90}
20 17 | 256 | 1 | f | f | f | {1 .. 90}
21 18 | 272 | 1 | f | f | f | {1 .. 90}
22 19 | 288 | 1 | f | f | f | {1 .. 90}
23 20 | 304 | 1 | f | f | f | {1 .. 90}
24 21 | 320 | 1 | f | f | f | {1 .. 90}
25 22 | 336 | 1 | f | f | f | {1 .. 90}
26 23 | 352 | 1 | f | f | f | {1 .. 90}
27 24 | 368 | 1 | f | f | f | {1 .. 90}
28 25 | 384 | 1 | f | f | f | {1 .. 90}
29 26 | 400 | 1 | f | f | f | {1 .. 90}
30 27 | 416 | 1 | f | f | f | {1 .. 90}
31 28 | 432 | 1 | f | f | f | {1 .. 90}
32(28 lignes)

L’index nous indique que tous les blocs contiennent des valeurs comprises entre 1 et 90.

Que donne une recherche des valeurs comprises entre 10 et 20?

 1EXPLAIN (ANALYZE,BUFFERS,VERBOSE) SELECT c1 FROM brin_random WHERE c1> 10 AND c1<20;
 2 QUERY PLAN
 3-----------------------------------------------------------------------------------------------------------------------------------------
 4 Bitmap Heap Scan on public.brin_random (cost=118.46..717.27 rows=10387 width=4) (actual time=0.068..10.241 rows=10240 loops=1)
 5 Output: c1
 6 Recheck Cond: ((brin_random.c1 > 10) AND (brin_random.c1 < 20))
 7 Rows Removed by Index Recheck: 89760
 8 Heap Blocks: lossy=443
 9 Buffers: shared hit=445
10 -> Bitmap Index Scan on brin_random_brin_idx_16 (cost=0.00..115.87 rows=10387 width=0) (actual time=0.052..0.052 rows=4480 loops=1)
11 Index Cond: ((brin_random.c1 > 10) AND (brin_random.c1 < 20))
12 Buffers: shared hit=2

=> Le moteur lit l’intégralité de la table ainsi que 2 blocs d’index.

Il est légitime de se demander quel est l’intérêt d’utiliser l’index si on sait que les données ne sont pas corrélées. Et qu’au final le moteur sera contraint de lire toute la table.

Allons faire un tour dans le code source. :

 1/*
 2 * BRIN indexes are always read in full; use that as startup cost.
 3 *
 4 * XXX maybe only include revmap pages here?
 5 */
 6 *indexStartupCost = spc_seq_page_cost * numPages * loop_count;
 7
 8 /*
 9 * To read a BRIN index there might be a bit of back and forth over
10 * regular pages, as revmap might point to them out of sequential order;
11 * calculate this as reading the whole index in random order.
12 */
13 *indexTotalCost = spc_random_page_cost * numPages * loop_count;
14
15 *indexSelectivity =
16 clauselist_selectivity(root, indexQuals,
17 path->indexinfo->rel->relid,
18 JOIN_INNER, NULL);
19 *indexCorrelation = 1;
20
21 /*
22 * Add on index qual eval costs, much as in genericcostestimate.
23 */
24 qual_arg_cost = other_operands_eval_cost(root, qinfos) +
25 orderby_operands_eval_cost(root, path);
26 qual_op_cost = cpu_operator_cost *
27 (list_length(indexQuals) + list_length(indexOrderBys));
28
29 *indexStartupCost += qual_arg_cost;
30 *indexTotalCost += qual_arg_cost;
31 *indexTotalCost += (numTuples * *indexSelectivity) * (cpu_index_tuple_cost + qual_op_cost);

On peut voir « *indexCorrelation = 1; ». En réalité le moteur ignore la corrélation… pour le moment. Une discussion est en cours pour prendre en compte la corrélation dans le coût de l’index :

Trions notre table en utilisant l’ordre CLUSTER et un index b-tree :

1CREATE INDEX brin_random_btree_idx ON brin_random USING btree (c1);
2CLUSTER brin_random USING brin_random_btree_idx;
3DROP INDEX brin_random_btree_idx ;
4ANALYZE brin_random ;

Vérifions la corrélation :

1SELECT tablename,correlation FROM pg_stats WHERE tablename='brin_random';
2 tablename | correlation
3-------------+-------------
4 brin_random | 1
5(1 ligne)

Rejouons notre requête :

 1EXPLAIN (ANALYZE,BUFFERS,VERBOSE) SELECT c1 FROM brin_random WHERE c1> 10 AND c1<20;
 2 QUERY PLAN
 3----------------------------------------------------------------------------------------------------------------------------------------
 4 Bitmap Heap Scan on public.brin_random (cost=115.08..708.94 rows=10057 width=4) (actual time=0.113..3.166 rows=9999 loops=1)
 5 Output: c1
 6 Recheck Cond: ((brin_random.c1 > 10) AND (brin_random.c1 < 20))
 7 Rows Removed by Index Recheck: 849
 8 Heap Blocks: lossy=48
 9 Buffers: shared hit=50
10 -> Bitmap Index Scan on brin_random_brin_idx_16 (cost=0.00..112.57 rows=10057 width=0) (actual time=0.053..0.053 rows=480 loops=1)
11 Index Cond: ((brin_random.c1 > 10) AND (brin_random.c1 < 20))
12 Buffers: shared hit=2
13 Planning time: 0.086 ms
14 Execution time: 3.849 ms

Cette fois le moteur a lu moins de blocs, regardons ce que contient notre index :

 1SELECT * FROM brin_page_items(get_raw_page('brin_random_brin_idx_16', 2), 'brin_random_brin_idx_16');
 2 itemoffset | blknum | attnum | allnulls | hasnulls | placeholder | value
 3------------+--------+--------+----------+----------+-------------+------------
 4 1 | 0 | 1 | f | f | f | {1 .. 4}
 5 2 | 16 | 1 | f | f | f | {4 .. 7}
 6 3 | 32 | 1 | f | f | f | {7 .. 10}
 7 4 | 48 | 1 | f | f | f | {10 .. 14}
 8 5 | 64 | 1 | f | f | f | {14 .. 17}
 9 6 | 80 | 1 | f | f | f | {17 .. 20}
10 7 | 96 | 1 | f | f | f | {20 .. 23}
11 8 | 112 | 1 | f | f | f | {23 .. 27}
12 9 | 128 | 1 | f | f | f | {27 .. 30}
13 10 | 144 | 1 | f | f | f | {30 .. 33}
14 11 | 160 | 1 | f | f | f | {33 .. 36}
15 12 | 176 | 1 | f | f | f | {36 .. 39}
16 13 | 192 | 1 | f | f | f | {39 .. 43}
17 14 | 208 | 1 | f | f | f | {43 .. 46}
18 15 | 224 | 1 | f | f | f | {46 .. 49}
19 16 | 240 | 1 | f | f | f | {49 .. 52}
20 17 | 256 | 1 | f | f | f | {52 .. 56}
21 18 | 272 | 1 | f | f | f | {56 .. 59}
22 19 | 288 | 1 | f | f | f | {59 .. 62}
23 20 | 304 | 1 | f | f | f | {62 .. 65}
24 21 | 320 | 1 | f | f | f | {65 .. 69}
25 22 | 336 | 1 | f | f | f | {69 .. 72}
26 23 | 352 | 1 | f | f | f | {72 .. 75}
27 24 | 368 | 1 | f | f | f | {75 .. 78}
28 25 | 384 | 1 | f | f | f | {78 .. 82}
29 26 | 400 | 1 | f | f | f | {82 .. 85}
30 27 | 416 | 1 | f | f | f | {85 .. 88}
31 28 | 432 | 1 | f | f | f | {88 .. 90}

Cette fois le moteur savait qu’il n’avait à parcourir que les blocs de 48 à 96.

Index BRIN – Fonctionnement

Wed, 20 Apr 2016 06:00:40 +0000

Pour information, je serai présent au à Lille le mardi 31 mai pour présenter cet index. Il y aura également plein d’autres !

Dans ce 2eme volet nous allons voir en détail le fonctionnement d’un index BRIN.

Fonctionnement

L’index va contenir la valeur minimale et maximale ¹ d’un attribut sur un ensemble de blocs : range (dans le cas d’un index sur une seule colonne)

La taille du range par défaut est de 128 blocs (128 x 8Ko => 1Mo).

Prenons l’exemple suivant, une table de 100 000 lignes contenant une colonne id incrémentée de 1. Schématiquement ma table sera stockée de cette façon (un bloc pouvant contenir plusieurs lignes) :

Bloc	id
0	1
0	2
…	…
1	227
…	…
128	28929
…	…
255	57856
256	57857
…	…

1CREATE TABLE t1 (c1) AS (SELECT * FROM generate_series(1,100000));
2SELECT ctid,c1 from t1;

Si on cherche les valeurs comprises entre 28929 et 57856 le moteur devra parcourir l’intégralité de la table. Il ne sait pas qu’il n’est pas nécessaire de lire avant le bloc 128 et après le bloc 255.

Le premier réflexe serait de créer un index b-tree. Sans rentrer dans les détails, ce type d’index permet un parcours plus efficace de la table. Il contiendra l’emplacement de chaque valeur de la table.

Schématiquement, en omettant la présentation en arborescence, l’index contiendrait :

id	Emplacement
1	0
2	0
…
227	1
…	…
57857	256

Intuitivement on peut déjà en déduire que si notre table est volumineuse, l’index sera également volumineux.

Un index BRIN contiendrait les lignes suivantes :

Range (128 blocs)	min	max	allnulls	hasnulls
1	1	28928	non	non
2	28929	57856	non	non
3	57857	86784	non	non
4	86785	115712	non	non

1create index ON t1 using brin(c1) ;
2create extension pageinspect;
3SELECT * FROM brin_page_items(get_raw_page('t1_c1_idx', 2), 't1_c1_idx');

Ainsi en cherchant les valeurs comprises entre 28929 et 57856 le moteur sait qu’il devra parcourir les blocs 128 à 255.

En comparant par rapport à un index B-tree j’ai pu représenter en 4 lignes ce qui m’aurait pris plus de 100 000 lignes dans un B-tree. Bien entendu la réalité est bien plus complexe, néanmoins, cette simplification permet déjà d’avoir un aperçu de la compacité de ce type d’index.

Influence taille du range

Par défaut la taille du range est de 128 blocs, ce qui correspond à 1Mo (1 bloc fait 8Ko). Par curiosité on va tester différentes tailles de range grâce à l’option pages_per_range.

Prenons un jeu de données plus conséquent, avec 100 millions de lignes :

1CREATE TABLE brin_large (c1 INT);
2INSERT INTO brin_large SELECT * FROM generate_series(1,100000000);

Notre table fait presque 3,5Go :

1\dt+ brin_large
2                       List OF relations
3 Schema |    Name    | TYPE  |  Owner   |  SIZE   | Description
4--------+------------+-------+----------+---------+-------------
5 public | brin_large | TABLE | postgres | 3458 MB |

Activons l’option « \timing » de psql afin de mesurer le temps de créations des index. Commençons par les index BRIN avec une valeur pages_per_range différente :

1CREATE INDEX brin_large_brin_idx ON brin_large USING brin (c1);
2CREATE INDEX brin_large_brin_idx_8 ON brin_large USING brin (c1) WITH (pages_per_range = 8);
3CREATE INDEX brin_large_brin_idx_16 ON brin_large USING brin (c1) WITH (pages_per_range = 16);
4CREATE INDEX brin_large_brin_idx_32 ON brin_large USING brin (c1) WITH (pages_per_range = 32);
5CREATE INDEX brin_large_brin_idx_64 ON brin_large USING brin (c1) WITH (pages_per_range = 64);

Créons également un index b-tree :

1CREATE INDEX brin_large_btree_idx ON brin_large USING btree (c1);

Comparons les tailles :

 1\di+ brin_large*
 2                                    List OF relations
 3 Schema |          Name          | TYPE  |  Owner   |   TABLE    |  SIZE   | Description
 4--------+------------------------+-------+----------+------------+---------+-------------
 5 public | brin_large_brin_idx    | INDEX | postgres | brin_large | 128 kB  |
 6 public | brin_large_brin_idx_16 | INDEX | postgres | brin_large | 744 kB  |
 7 public | brin_large_brin_idx_32 | INDEX | postgres | brin_large | 392 kB  |
 8 public | brin_large_brin_idx_64 | INDEX | postgres | brin_large | 216 kB  |
 9 public | brin_large_brin_idx_8  | INDEX | postgres | brin_large | 1448 kB |
10 public | brin_large_btree_idx   | INDEX | postgres | brin_large | 2142 MB |

Voici les résultats obtenus sur les durées de création des index et leur tailles :

La création d’index est bien plus rapide. Il y a quasiment un facteur x10 entre les deux types d’index. J’ai obtenu ces chiffres avec la version 9.5.1 sur une configuration assez basique (pc portable et disque mécanique). Je vous conseille de mener vos propres tests avec votre matériel.

Pour information j’ai positionné la maintenance_work_mem à 1GB, malgré cette valeur élevée cela n’a pas empêché la création de fichiers temporaires pour l’index b-tree.

Pour les tailles d’index la différence est bien plus importante, j’ai du utiliser une échelle logarithmique pour représenter l’écart. L’index BRIN avec un pages_per_range par défaut fait 128Ko alors que le b-tree fait plus de 2Go!

Qu’en est-il des requêtes ?

Essayons cette requête qui récupère les valeurs comprises entre 10 et 2000. Pour étudier en détail ce que fait le moteur nous allons utiliser EXPLAIN avec les options (ANALYZE,VERBOSE,BUFFERS).

Enfin, pour faciliter l’analyse nous allons utiliser un jeu de données plus petit :

1CREATE TABLE brin_demo (c1 INT);
2INSERT INTO brin_demo SELECT * FROM generate_series(1,100000);

 1EXPLAIN (ANALYZE,BUFFERS,VERBOSE) SELECT c1 FROM brin_demo WHERE c1> 1 AND c1<2000;
 2 QUERY PLAN
 3-------------------------------------------------------------------------------------------------------------------
 4 Seq Scan on public.brin_demo (cost=0.00..2137.47 rows=565 width=4) (actual time=0.010..11.311 rows=1998 loops=1)
 5 Output: c1
 6 Filter: ((brin_demo.c1 > 1) AND (brin_demo.c1 < 2000))
 7 Rows Removed by Filter: 98002
 8 Buffers: shared hit=443
 9 Planning time: 0.044 ms
10 Execution time: 11.412 ms

Sans index le moteur parcourt toute la table (seq scan) et lit 443 blocs.

La même requête avec un index BRIN :

 1CREATE INDEX brin_demo_brin_idx ON brin_demo USING brin (c1);
 2EXPLAIN (ANALYZE,BUFFERS,VERBOSE) SELECT c1 FROM brin_demo WHERE c1> 1 AND c1<2000;
 3 QUERY PLAN
 4---------------------------------------------------------------------------------------------------------------------------------
 5 Bitmap Heap Scan on public.brin_demo (cost=17.12..488.71 rows=500 width=4) (actual time=0.034..3.483 rows=1998 loops=1)
 6 Output: c1
 7 Recheck Cond: ((brin_demo.c1 > 1) AND (brin_demo.c1 < 2000))
 8 Rows Removed by Index Recheck: 26930
 9 Heap Blocks: lossy=128
10 Buffers: shared hit=130
11 -> Bitmap Index Scan on brin_demo_brin_idx (cost=0.00..17.00 rows=500 width=0) (actual time=0.022..0.022 rows=1280 loops=1)
12 Index Cond: ((brin_demo.c1 > 1) AND (brin_demo.c1 < 2000))
13 Buffers: shared hit=2
14 Planning time: 0.074 ms
15 Execution time: 3.623 ms

Le moteur lit 2 blocs d’index puis 128 blocs de la table.

Essayons avec un pages_per_range plus petit, à 16 par exemple :

 1CREATE INDEX brin_demo_brin_idx_16 ON brin_demo USING brin (c1) WITH (pages_per_range = 16);
 2EXPLAIN (ANALYZE,BUFFERS,VERBOSE) SELECT c1 FROM brin_demo WHERE c1> 10 AND c1<2000;
 3 QUERY PLAN
 4-----------------------------------------------------------------------------------------------------------------------------------
 5 Bitmap Heap Scan on public.brin_demo (cost=17.12..488.71 rows=500 width=4) (actual time=0.053..0.727 rows=1989 loops=1)
 6 Output: c1
 7 Recheck Cond: ((brin_demo.c1 > 10) AND (brin_demo.c1 < 2000))
 8 Rows Removed by Index Recheck: 1627
 9 Heap Blocks: lossy=16
10 Buffers: shared hit=18
11 -> Bitmap Index Scan on brin_demo_brin_idx_16 (cost=0.00..17.00 rows=500 width=0) (actual time=0.033..0.033 rows=160 loops=1)
12 Index Cond: ((brin_demo.c1 > 10) AND (brin_demo.c1 < 2000))
13 Buffers: shared hit=2
14 Planning time: 0.114 ms
15 Execution time: 0.852 ms

La encore le moteur lit 2 blocs dans l’index, en revanche il ne va lire que 16 blocs dans la table.

Un index avec un pages_per_range plus petit sera plus sélectif et permettra de lire moins de blocs.

Utilisons l’extension pageinspect pour observer le contenu des index :

 1CREATE extension pageinspect;
 2SELECT * FROM brin_page_items(get_raw_page('brin_demo_brin_idx_16', 2),'brin_demo_brin_idx_16');
 3 itemoffset | blknum | attnum | allnulls | hasnulls | placeholder | value
 4------------+--------+--------+----------+----------+-------------+-------------------
 5 1 | 0 | 1 | f | f | f | {1 .. 3616}
 6 2 | 16 | 1 | f | f | f | {3617 .. 7232}
 7 3 | 32 | 1 | f | f | f | {7233 .. 10848}
 8 4 | 48 | 1 | f | f | f | {10849 .. 14464}
 9 5 | 64 | 1 | f | f | f | {14465 .. 18080}
10 6 | 80 | 1 | f | f | f | {18081 .. 21696}
11 7 | 96 | 1 | f | f | f | {21697 .. 25312}
12 8 | 112 | 1 | f | f | f | {25313 .. 28928}
13 9 | 128 | 1 | f | f | f | {28929 .. 32544}
14 10 | 144 | 1 | f | f | f | {32545 .. 36160}
15 11 | 160 | 1 | f | f | f | {36161 .. 39776}
16 12 | 176 | 1 | f | f | f | {39777 .. 43392}
17 13 | 192 | 1 | f | f | f | {43393 .. 47008}
18 14 | 208 | 1 | f | f | f | {47009 .. 50624}
19 15 | 224 | 1 | f | f | f | {50625 .. 54240}
20 16 | 240 | 1 | f | f | f | {54241 .. 57856}
21 17 | 256 | 1 | f | f | f | {57857 .. 61472}
22 18 | 272 | 1 | f | f | f | {61473 .. 65088}
23 19 | 288 | 1 | f | f | f | {65089 .. 68704}
24 20 | 304 | 1 | f | f | f | {68705 .. 72320}
25 21 | 320 | 1 | f | f | f | {72321 .. 75936}
26 22 | 336 | 1 | f | f | f | {75937 .. 79552}
27 23 | 352 | 1 | f | f | f | {79553 .. 83168}
28 24 | 368 | 1 | f | f | f | {83169 .. 86784}
29 25 | 384 | 1 | f | f | f | {86785 .. 90400}
30 26 | 400 | 1 | f | f | f | {90401 .. 94016}
31 27 | 416 | 1 | f | f | f | {94017 .. 97632}
32 28 | 432 | 1 | f | f | f | {97633 .. 100000}
33(28 lignes)
34
35SELECT * FROM brin_page_items(get_raw_page('brin_demo_brin_idx', 2),'brin_demo_brin_idx');
36 itemoffset | blknum | attnum | allnulls | hasnulls | placeholder | value
37------------+--------+--------+----------+----------+-------------+-------------------
38 1 | 0 | 1 | f | f | f | {1 .. 28928}
39 2 | 128 | 1 | f | f | f | {28929 .. 57856}
40 3 | 256 | 1 | f | f | f | {57857 .. 86784}
41 4 | 384 | 1 | f | f | f | {86785 .. 100000}
42(4 lignes)

Avec l’index brin_demo_brin_idx_16 on remarque bien que les valeurs qui nous intéressent sont présentes dans le premier ensemble de blocs (0 à 15). En revanche avec l’index brin_demo_brin_idx, celui-ci est moins sélectif. Les valeurs qui nous intéressent sont comprises les blocs 0 à 127 ce qui explique pourquoi il y a plus de blocs lus dans le premier exemple.

L’index contient également deux booléens indiquant si l’ensemble contient des valeurs NULL (hasnulls ) ou s’il ne contient que des valeurs NULL (allnulls) ↩︎

Index BRIN – Principe

Tue, 19 Apr 2016 06:00:21 +0000

Pour information, je serai présent au à Lille le mardi 31 mai pour présenter cet index. Il y aura également plein d’autres !

Introduction

PostgreSQL propose déjà différents type d’index : B-Tree, GIN, GiST, SP-GiST, Hash ¹

Les discussions ont commencées en 2008 :

Suivi de ce RFC en 2008 qui propose les « » qui sera renommé plus tard en BRIN.

Physiquement, une table est composée de blocs de 8Ko et chaque bloc contient des enregistrements ². L’idée des index BRIN est de stocker dans un index la valeur minimale et maximale d’un attribut d’un ensemble de bloc (range) ³. Ainsi il est possible d’exclure un ensemble de bloc si vous recherchez une valeur qui n’est pas comprise dans l’intervalle.

Note : Les index BRIN sont similaires aux storage indexes d’Oracle ( ).

Voici les types supportés :

 1abstime
 2bigint
 3bit
 4bit varying
 5box
 6bytea
 7character
 8"char"
 9date
10double precision
11inet
12inet
13integer
14interval
15macaddr
16name
17numeric
18pg_lsn
19oid
20any range type
21real
22reltime
23smallint
24text
25tid
26timestamp without time zone
27timestamp with time zone
28time without time zone
29time with time zone
30uuid

Il est également possible d’indexer plusieurs colonnes. Notez que la documentation actuelle ne le mentionne pas, c’est corrigé dans la version en cours de développement :

SELECT amname FROM pg_am; ou encore ↩︎
Si un enregistrement ne tient pas dans un bloc il est stocké séparément dans ce qu’on appelle le TOAST (The Oversized-Attribute Storage Technique). Plus exactement, si un enregistrement dépasse 2ko. ↩︎
L’index contient également deux booléens indiquant si l’ensemble contient des valeurs NULL (hasnulls ) ou s’il ne contient que des valeurs NULL (allnulls) ↩︎

Partition xlogs pleine

Mon, 18 May 2015 20:00:46 +0000

Cette semaine j’ai été confronté à un incident sur une instance postgres. La partition xlogs était pleine :

1PANIC: could not write to file "pg_xlog/xlogtemp.12352": No space left on device
2LOG: startup process (PID 12352) was terminated by signal 6: Aborted
3LOG: aborting startup due to startup process failure

Cette instance est répliquée sur un autre serveur et archive ses journaux de transaction sur un troisième serveur. Ce dernier était plein, Postgres est intelligent et a conservé ses journaux de transaction en attendant de pouvoir les archiver… Jusqu’à ce que la partition des journaux se retrouve pleine entraînant l’arrêt de Postgres.

Le nettoyage sur le serveur d’archivage n’était pas suffisant, il fallait libérer de la place sur la partition. La solution qui vient en tête est d’agrandir la partition. Je ne souhaitais pas agrandir la partition. J’ai donc fait un truc tout simple : Déplacer un fichier journal et faire un lien symbolique vers celui-ci. Postgres est reparti et j’ai lancé un « CHECKPOINT » immédiatement ce qui a libéré de la place. Ensuite il faut penser à supprimer le fichier car Postgres a juste supprimé le lien.

C’est plus rapide à mettre en place que d’agrandir la partition.

En fouillant sur google je suis tombé sur ce site :

L’auteur nous donne une astuce toute simple : Créer un fichier plein de vide. Si un jour la partition est pleine il suffit de le supprimer pour faire repartir l’instance :

dd if=/dev/zero of=DO_NOT_MOVE_THIS_FILE bs=1MB count=100

Bilan : Il faut bien penser à superviser l’archivage de Postgres!

Restauration PITR – Part 7

Sun, 22 Mar 2015 12:25:41 +0000

Je profite d’un week end de mauvais temps (m’empêchant de retourner en falaise 🙁 ) pour poursuivre mes articles sur Postgres.

Dans le précédent article : J’ai évoqué la restauration PITR pour Point In Time Recovery. Je vous encourage vivement à mettre en place ce qui va suivre afin de réduire la perte de données en cas de modification accidentelle sur des enregistrements : Un drop table par exemple.

Pour la mettre en place il vous faut :

Une instance Postgres maître.
Archivage des WAL, externalisé de préférence.

Je ne vais pas revenir sur la mise en place de l’archivage, je l’ai déjà détaillé dans les précédents articles. Pour vous expliquer cette restauration je vais utiliser un scénario « catastrophe ».

Il est 12H30 et on vous informe qu’une table a été supprimée par erreur sur un serveur de production.

La réplication que vous avez mis en place ne vous est d’aucune aide car l’opération a été reportée sur le réplicat.

Remarque : Avec la version 9.4 il est possible d’avoir un réplicat avec du retard. Avec un peu de chance l’opération de suppression de la table n’est peut être pas encore réalisée sur le réplicat.

Par chance, vous effectuez un backup full toutes les nuits à 1H00 et vous avez mis en place l’archivage des journaux. Leur nettoyage se fait après le backup full grâce à >pg_archivecleanup.

Pour être tranquille vous effectuez un checkpoint afin que les derniers journaux soient archivés. Ensuite vous stoppez votre instance Postgres et déplacez le répertoire (au cas où).

Vous restaurez les fichiers du backup full. Il ne vous reste plus qu’a configurer correctement la restauration via le fichier recovery.conf.

Celui-ci devra contenir le paramètre restore_command afin que Postgres récupére les journaux de transactions archivés.

Il devra également contenir un paramètre pour la cible de récupération, Si on ne le spécifie pas le moteur va rejouer les journaux de transaction dans leur totalité, jusqu’au « drop table » fatal. Il est possible de demander la restauration jusqu’à un point de restauration, une date ou un identifiant de transaction.

Pour approfondir :

Revenons à notre scénario, imaginons que nous souhaitons revenir à la dernière transaction jouée avant le drop fatal. En grattant un peu, on peut utiliser l’outil pour lire les journaux de transaction.

 1/usr/lib/postgresql/9.3/bin/pg_xlogdump 000000010000000300000066
 2rmgr: Heap        len (rec/tot):     21/   197, tx:    1213547, lsn: 3/66000028, prev 3/650000F0, bkp: 1000, desc: insert: rel 1663/16486/16519; tid 0/2
 3rmgr: Transaction len (rec/tot):     12/    44, tx:    1213547, lsn: 3/660000F0, prev 3/66000028, bkp: 0000, desc: commit: 2015-03-22 12:23:35.834785 CET
 4rmgr: Standby     len (rec/tot):     16/    48, tx:    1213548, lsn: 3/66000120, prev 3/660000F0, bkp: 0000, desc: AccessExclusive locks: xid 1213548 db 16486 rel 16519
 5rmgr: Standby     len (rec/tot):     16/    48, tx:    1213548, lsn: 3/66000150, prev 3/66000120, bkp: 0000, desc: AccessExclusive locks: xid 1213548 db 16486 rel 16522
 6rmgr: Standby     len (rec/tot):     16/    48, tx:    1213548, lsn: 3/66000180, prev 3/66000150, bkp: 0000, desc: AccessExclusive locks: xid 1213548 db 16486 rel 16524
 7rmgr: Heap        len (rec/tot):     26/  6642, tx:    1213548, lsn: 3/660001B0, prev 3/66000180, bkp: 1000, desc: delete: rel 1663/16486/11774; tid 7/35 KEYS_UPDATED
 8rmgr: Heap        len (rec/tot):     26/  3270, tx:    1213548, lsn: 3/66001BA8, prev 3/660001B0, bkp: 1000, desc: delete: rel 1663/16486/11903; tid 46/44 KEYS_UPDATED
 9rmgr: Heap        len (rec/tot):     26/  4774, tx:    1213548, lsn: 3/66002888, prev 3/66001BA8, bkp: 1000, desc: delete: rel 1663/16486/11821; tid 2/26 KEYS_UPDATED
10rmgr: Heap        len (rec/tot):     26/  5730, tx:    1213548, lsn: 3/66003B30, prev 3/66002888, bkp: 1000, desc: delete: rel 1663/16486/11786; tid 42/37 KEYS_UPDATED
11rmgr: Heap        len (rec/tot):     26/    58, tx:    1213548, lsn: 3/660051B0, prev 3/66003B30, bkp: 0000, desc: delete: rel 1663/16486/11786; tid 42/38 KEYS_UPDATED
12rmgr: Heap        len (rec/tot):     26/  7902, tx:    1213548, lsn: 3/660051F0, prev 3/660051B0, bkp: 1000, desc: delete: rel 1663/16486/11797; tid 0/80 KEYS_UPDATED

C’est un extrait du résultat de la commande, le première ligne indique un insert avec la transaction N° 1213547, la ligne ne dessous indique un commit. En revanche à la troisième ligne on est passé à la transaction 1213548 avec un lock suivi de plusieurs lignes indiquant un delete. Il s’agit du drop fatal.

On va donc revenir à la transaction N°1213547. Voici le contenu de mon fichier recovery.conf :

1restore_command = 'rsync "192.168.1.128:/var/lib/postgresql/9.3/wal_archive/%f" "%p"'
2
3recovery_target_xid = '1213547'
4recovery_target_inclusive = 'true'

La directive recovery_target_inclusive indique au moteur s’il inclue la transaction correspondant au N°1213547 ou s’il s’arrête juste avant. Ainsi j’aurais pu spécifier un xid de 1213548 et un target_inclusive à « false » pour obtenir le même résultat.

Ensuite il suffit de redémarrer postgres, voici ce qu’on peut observer dans les logs :

 12015-03-22 12:41:17 CET LOG:  database system was interrupted; last known up at 2015-03-22 12:22:59 CET
 22015-03-22 12:41:17 CET LOG:  creating missing WAL directory "pg_xlog/archive_status"
 32015-03-22 12:41:17 CET LOG:  starting point-in-time recovery to XID 1213547
 42015-03-22 12:41:17 CET LOG:  connection received: host=[local]
 52015-03-22 12:41:17 CET LOG:  incomplete startup packet
 62015-03-22 12:41:18 CET LOG:  connection received: host=[local]
 72015-03-22 12:41:18 CET FATAL:  the database system is starting up
 82015-03-22 12:41:18 CET LOG:  restored log file "000000010000000300000065" from archive
 92015-03-22 12:41:18 CET LOG:  redo starts at 3/65000028
102015-03-22 12:41:18 CET LOG:  consistent recovery state reached at 3/650000F0
112015-03-22 12:41:18 CET LOG:  connection received: host=[local]
122015-03-22 12:41:18 CET FATAL:  the database system is starting up
132015-03-22 12:41:19 CET LOG:  connection received: host=[local]
142015-03-22 12:41:19 CET FATAL:  the database system is starting up
152015-03-22 12:41:19 CET LOG:  restored log file "000000010000000300000066" from archive
162015-03-22 12:41:19 CET LOG:  recovery stopping after commit of transaction 1213547, time 2015-03-22 12:23:35.834785+01
172015-03-22 12:41:19 CET LOG:  redo done at 3/660000F0
182015-03-22 12:41:19 CET LOG:  last completed transaction was at log time 2015-03-22 12:23:35.834785+01
19rsync: link_stat "/var/lib/postgresql/9.3/wal_archive/00000002.history" failed: No such file or directory (2)
20rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [Receiver=3.0.9]
212015-03-22 12:41:19 CET LOG:  selected new timeline ID: 2
22rsync: link_stat "/var/lib/postgresql/9.3/wal_archive/00000001.history" failed: No such file or directory (2)
232015-03-22 12:41:19 CET LOG:  connection received: host=[local]
242015-03-22 12:41:19 CET FATAL:  the database system is starting up
25rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [Receiver=3.0.9]

On remarque que le moteur créée le répertoire des journaux de transaction, ensuite la ligne suivante est assez explicite : « starting point-in-time recovery to XID 1213547 ». Quelques lignes plus bas on remarque qu’il rejoue les journaux de transaction (« restored log file « 000000010000000300000065 » from archive »).

Il arrête la restauration jusqu’à la transaction spécifiée :

1recovery stopping after commit of transaction 1213547, time 2015-03-22 12:23:35.834785+01

On remarque quelques lignes d’erreur correspondant à la sortie de rsync. Visiblement il cherche à copier plusieurs fichiers en « x.history ». En regardant dans le répertoire d’archivage on constate que le moteur a créé un fichier 00000002.history contenant :

1 3/66000120 after transaction 1213547

Point important également, on constate que la numérotation des journaux de transaction a changée :

1-rw------- 1 postgres postgres 16777216 mars  22 12:23 000000010000000300000065
2-rw------- 1 postgres postgres      305 mars  22 12:23 000000010000000300000065.00000028.backup
3-rw------- 1 postgres postgres 16777216 mars  22 12:41 000000010000000300000066
4-rw------- 1 postgres postgres 16777216 mars  22 12:46 000000020000000300000066
5-rw------- 1 postgres postgres       39 mars  22 12:41 00000002.history

Le fichier « 000000010000000300000065 » correspond au wal lors du pg_basebackup, « 000000010000000300000066 » correspond au checkpoint que j’ai lancé après l’incident. Après la restauration on peut voir le fichier « 000000020000000300000066 ». Le huitième caractère est passé de 1 à 2.

En retournant dans les logs du moteur on peut lire la ligne suivante un peu plus bas : “selected new timeline ID: 2” En fait, lors de la restauration, Postgres créée une nouvelle . C’est un concept que j’aborderai plus tard, en attendant je vous invite à voir cette présentation sur le fonctionnement des timeline après une restauration PITR :

Bien entendu comme tout système de sauvegarde vous devez jouer la procédure afin de valider qu’il y a pas eu d’erreur ou oubli.

Backup, restauration – Part 6

Thu, 26 Feb 2015 17:30:51 +0000

J’ai consacré les précédents articles aux différents mécanismes de réplications. Le principe est à chaque fois le même, on utilise une copie d’une instance Postgres puis la réplication se fait par rejeu des journaux de transaction (soit par transfert de fichier ou par flux).

Cet article va aborder les différentes technique de sauvegarde … ainsi que la restauration. On ne pense pas assez à la restauration : « la priorité est la sauvegarde, la restauration on verra quand on aura un peu de temps ».

Sauvegarde fichier d’une instance (manuelle + pg_base_backup)
Sauvegarde par dump des bases avec pg_dump
Restauration (manuelle + pg_restore)
Restauration PITR

Sauvegarde fichier d’une instance

La sauvegarde la plus simple et la plus basique est la sauvegarde à froid des fichier d’une instance. Il suffit d’arrêter postgres et de faire une copie du dossier data de postgres. Cette solution a l’inconvénient majeur de devoir arrêter Postgres. Nous allons voir d’autres solutions plus élaborées qui évitent d’éteindre le moteur.

Sauvegarde par dump des bases avec pg_dump et pg_dumpall

Pour éviter d’éteindre le serveur on peut tout simplement faire un dump de la base de donnée avec pg_dump. Je ne vais pas recopier la page de documentation de pg_dump ici mais me contenter de vous présenter les options utiles de l’outil.

L’inconvénient ou l’avantage de cet outil est qu’il ne sauvegarde pas toutes les bases d’une instance, il faut donc scripter le tout pour qu’il sauvegarde base par base. J’ai écrit « inconvénient ou avantage », en effet vous pouvez décider de ne restaurer qu’une seule base ou avoir des politique de sauvegarde différentes en fonction des bases. Si vous souhaitez sauvegarder toutes les bases d’un coup vous pouvez utiliser pg_dumpall. Attention, avec pg_dump vous ne sauvegardez pas les rôles donc en cas de restauration vous devriez recréer les rôles. Pour y remédier vous pouvez utiliser -roles-only.

Par défaut, pg_dump va sauvegarder les tables, les données de schéma. Il est possible de les sélectionner avec les options : --data-only ou --schema-only

Petite astuce, à partir de la version 9.3 pg_dump peut paralléliser la sauvegarde des tables avec l’option --jobs=njobs

Pour approfondir :

Restauration depuis un dump

pgsql

La technique la plus simple consiste à envoyer à psql les commandes issues du dump. Voici mon dump :

 1pg_dump -h /var/run/postgresql/ test
 2
 3--
 4-- PostgreSQL database dump
 5--
 6
 7SET statement_timeout = 0;
 8SET lock_timeout = 0;
 9SET client_encoding = 'UTF8';
10SET standard_conforming_strings = on;
11SET check_function_bodies = false;
12SET client_min_messages = warning;
13
14--
15-- Name: plpgsql; Type: EXTENSION; Schema: -; Owner:
16--
17
18CREATE EXTENSION IF NOT EXISTS plpgsql WITH SCHEMA pg_catalog;
19
20
21--
22-- Name: EXTENSION plpgsql; Type: COMMENT; Schema: -; Owner:
23--
24
25COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language';
26
27
28SET search_path = public, pg_catalog;
29
30SET default_tablespace = '';
31
32SET default_with_oids = false;
33
34--
35-- Name: films; Type: TABLE; Schema: public; Owner: postgres; Tablespace:
36--
37
38CREATE TABLE films (
39    code character(5),
40    title character varying(40),
41    did integer,
42    date_prod date,
43    kind character varying(10),
44    len interval hour to minute
45);
46
47
48ALTER TABLE public.films OWNER TO postgres;
49
50--
51-- Data for Name: films; Type: TABLE DATA; Schema: public; Owner: postgres
52--
53
54COPY films (code, title, did, date_prod, kind, len) FROM stdin;
55bla     rambo   12      2014-12-01      action  01:00:00
56\.
57
58
59--
60-- Name: production; Type: CONSTRAINT; Schema: public; Owner: postgres; Tablespace:
61--
62
63ALTER TABLE ONLY films
64    ADD CONSTRAINT production UNIQUE (date_prod);
65
66
67--
68-- Name: public; Type: ACL; Schema: -; Owner: postgres
69--
70
71REVOKE ALL ON SCHEMA public FROM PUBLIC;
72REVOKE ALL ON SCHEMA public FROM postgres;
73GRANT ALL ON SCHEMA public TO postgres;
74GRANT ALL ON SCHEMA public TO PUBLIC;
75
76
77--
78-- PostgreSQL database dump complete
79--

Comme vous pouvez le constater, pg_dump utilise des « copy » plutôt que des « insert ». La commande copy est bien plus rapide pour l’import en masse de données.

Pour restaurer le dump :

 1psql -h /var/run/postgresql/ test -f dump.sql
 2SET
 3SET
 4SET
 5SET
 6SET
 7SET
 8CREATE EXTENSION
 9COMMENT
10SET
11SET
12SET
13CREATE TABLE
14ALTER TABLE
15ALTER TABLE
16REVOKE
17REVOKE
18GRANT
19GRANT

Pour approfondir :

pg_restore

Cette restauration est assez simple, postgres fourni l’utilitaire pg_restore qui offre des fonctionnalités intéressantes telles que :

Parallélisation
Sélection des sections à restaurer. Très utile si vous ne souhaitez restaurer qu’une seule table.

Pour pouvoir utiliser pg_restore il faut spécifier le format « custom » à pg_dump: « -format=custom » ou « -F c ». En effet si vous fournissez un fichier au format « à plat » vous aurez le message suivant :

1pg_restore: [archiveur] Le fichier en entrée semble être une sauvegarde au format texte. Merci d'utiliser psql.

Je ne vais pas recopier la documentation de pg_restore mais juste vous fournir les options les plus intéressantes :

Parallélisation :

1-j number-of-jobs
2--jobs=number-of-jobs

Lister les sections du dump :

1-l
2 --list

Exemple :

 1; Archive created at Sun Jan 11 12:40:21 2015
 2;     dbname: test
 3;     TOC Entries: 11
 4;     Compression: -1
 5;     Dump Version: 1.12-0
 6;     Format: CUSTOM
 7;     Integer: 4 bytes
 8;     Offset: 8 bytes
 9;     Dumped from database version: 9.3.5
10;     Dumped by pg_dump version: 9.3.5
11;
12;
13; Selected TOC Entries:
14;
151939; 1262 16486 DATABASE - test postgres
166; 2615 2200 SCHEMA - public postgres
171940; 0 0 COMMENT - SCHEMA public postgres
181941; 0 0 ACL - public postgres
19171; 3079 11756 EXTENSION - plpgsql
201942; 0 0 COMMENT - EXTENSION plpgsql
21170; 1259 16502 TABLE public films postgres
221934; 0 16502 TABLE DATA public films postgres
231826; 2606 16506 CONSTRAINT public production postgres

Si je souhaite supprimer quelques sections du dump il me suffit de commenter la ligne avec un point-virgule, de sauvegarder le fichier (db.list) puis de lancer pg_restore avec l’option « -L » :

1pg_restore -L db.list db.dump

Pour approfondir :

Nous venons de voir les différentes technique pour restaurer des données. Cette façon de faire présente quelques inconvénients. Il faut faire des backups régulier. On peut avoir une perte de données conséquente depuis le dernier le backup.

En mettant en place une réplication on peut penser que le problème est réglé. Cependant la réplication nous protège d’une perte du maître mais pas d’une erreur humaine. Un DROP TABLE sur une mauvaise base par exemple! Ainsi le correspond au temps qui s’est écoulé depuis le dernier backup.

Archivage des WAL + restauration PITR

A venir dans un prochain article.

Edit : Le voici :

Le travail, qualité et collectif

Thu, 29 Jan 2015 19:08:55 +0000

J’ai publié beaucoup d’articles techniques ces derniers temps, hors je ne souhaite pas que ce blog soit exclusivement technique. Le travail dans l’informatique ce n’est pas que de la technique, c’est aussi de la collaboration avec différents acteurs : Collaborateurs, supérieurs, clients, prestataires …

Chaque acteur a ses contraintes et son organisation du travail. A l’heure où on ne cesse d’entendre les mot « compétitivité », « rendements » … je déplore qu’on n’entende pas plus souvent des mots comme : qualité, collectif…

Qualité

Qualité, parce qu’il ne suffit pas que le travail soit fait. Il faut qu’il soit bien fait. Pour ça il faut bien analyser les besoins, anticiper le futur, documenter.

Le travail ça serait un développeur qui fait un bout de programme (qui fonctionne) dans son coin.

Le travail bien fait, c’est le développeur qui a analysé le besoin avec le donneur d’ordre, qui a prévu que son code soit évolutif ou réutilisé et qui a documenté son code.

Dans les deux cas « ça fonctionne », le travail bien fait prendra « a priori » plus de temps. Cette « perte » est à mettre en parallèle au temps passé à reprendre le code quand il faut le faire évoluer, qu’il n’y a aucune documentation ou que le code a été mal pensé et qu’il faut le revoir en profondeur.

Collectif

Dès lors que des personnes travaillent ensemble il y a une intelligence collective qui se met en place. Cette intelligence n’est pas quantifiable et pourtant elle existe. Il faut savoir mettre en place une organisation du travail qui permette de faire fructifier cette intelligence. Je vais vous citer quelques lignes qui sont de Christophe Déjours sur ce sujet :

La coopération dans le travail relève d’une forme d’intelligence collective, capable de faire se conjuguer des points de vue différents, des expériences différentes. De surcroît, cette intelligence au travail n’est pas une sommation d’intelligences individuelles ; il y a des performances dont la coopération est porteuse qu’on ne peut pas obtenir par la somme des compétences individuelles. Ce qui est incomparable dans la coopération, c’est le regard croisé des gens qui travaillent ensemble, qui permet aux uns et aux autres de se corriger, de s’avertir, de prévenir les choses. Quand vous prenez en considération cette intelligence collective qu’on appelle la coopération, vous vous rendez compte qu’on n’est plus seulement dans le registre de la poïésis, du travail comme production, on est dans le registre de l’action sur le monde, dans la catégorie de la praxis au sens aristotélicien du terme. C’est-à-dire qu’il y a un espace de délibération et de décisions à prendre, un espace où il faut à la fois dire son opinion et avoir la capacité d’écouter celle des autres. Et cet espace de la coopération, en tant que cristallisation de l’intelligence collective, porte en lui la question de l’émancipation.

Christophe Déjours a beaucoup travaillé sur le rapport entre les Hommes et le travail. J’aime beaucoup cet auteur, conférencier… Ses textes ne sont pas facile à lire mais sont très enrichissant. Je trouve ses analyses sur le travail très pertinentes et je ne manquerai pas de vous partager d’autres textes/vidéos.

« Le bonheur au travail »

Thu, 15 Jan 2015 19:06:43 +0000

Je vous avais annoncé que ce blog ne traiterait pas que de technique mais également du travail, du rapport entre l’homme et le travail, du rapport entre les hommes au travail.

Suite à l’annonce d’une offre d’emploi sur un des membre vers la bande annonce du documentaire « Le bonheur au travail » :

from on .

Vivement sa sortie sur ARTE le 24 Fevrier!

Introduction à Postgres – Part1

Mon, 22 Dec 2014 23:00:05 +0000

Cet article a pour but de présenter quelques principes de Postgres. Il n’est pas exhaustif, néanmoins si vous souhaitez approfondir j’ai agrémenté l’article de quelques liens que j’ai trouvé pertinents. Pour ceux qui veulent vraiment creuser je vous recommande la lecture des ouvrages de Greg Smith et les articles de Dalibo parus dans Linux Mag.

Quelques rappels sur Postgres. PostgreSQL est un moteur de base de données relationnel. Il respecte les propriétés ACID et la gestion MVCC des données. Juste un petit mot sur MVCC, Multiversion Concurrency Control est un mécanisme très puissant de Postgres. Je ne rentrerai pas dans les détails mais ce mécanisme permet entre autre les accès concurrents à une base de donnée.

Plutôt que de réinventer la roue voici les articles de Wikipédia qui abordent ACID et MVCC :

Propriétés ACID

Atomicité

La propriété d’atomicité assure qu’une transaction se fait au complet ou pas du tout : si une partie d’une transaction ne peut être faite, il faut effacer toute trace de la transaction et remettre les données dans l’état où elles étaient avant la transaction. L’atomicité doit être respectée dans toutes situations, comme une panne d’électricité, une défaillance de l’ordinateur, ou une panne d’un disque magnétique.

Cohérence

La propriété de cohérence assure que chaque transaction amènera le système d’un état valide à un autre état valide. Tout changement à la base de données doit être valide selon toutes les règles définies, incluant mais non limitées aux contraintes d’intégrité, aux rollbacks en cascade, aux déclencheurs de base de données, et à toutes combinaisons d’évènements.

Isolation

La propriété d’isolation assure que l’exécution simultanée de transactions produit le même état que celui qui serait obtenu par l’exécution en série des transactions. Chaque transaction doit s’exécuter en isolation totale : si T1 et T2 s’exécutent simultanément, alors chacune doit demeurer indépendante de l’autre.

Durabilité

La propriété de durabilité assure que lorsqu’une transaction a été confirmée, elle demeure enregistrée même à la suite d’une panne d’électricité, d’une panne de l’ordinateur ou d’un autre problème. Par exemple, dans une base de données relationnelle, lorsqu’un groupe d’énoncés SQL ont été exécutés, les résultats doivent être enregistrés de façon permanente, même dans le cas d’une panne immédiatement après l’exécution des énoncés.

Source :

Multiversion Concurrency Control

Multiversion concurrency control (abrégé en MCC ou MVCC), est une méthode informatique de contrôle des accès concurrents fréquemment utilisée dans les systèmes de gestion de base de données et les langages de programmation concernant la gestion de la mémoire.

À cet effet, une base de données ne mettra pas en œuvre des mises à jour par écrasement des anciennes données par les nouvelles, mais plutôt en indiquant que les anciennes données sont obsolètes et en ajoutant une nouvelle « version ». Ainsi, plusieurs versions sont stockées, dont l’une seule d’entre elle est la plus récente. Cela évite en outre à la base de données d’avoir à gérer le remplissage des « trous » en mémoire ou sur le disque mais nécessite (généralement) une purge régulière des données obsolètes. Dans le cas des bases de données orientées document comme CouchDB, cela a aussi pour incidence de réécrire une version complète du document à chaque mise à jour, plutôt que de gérer des mises à jour incrémentales constituées de petits morceaux de document liés entre eux et rangés de manière non contigüe.

MVCC autorise aussi la création de prise de vue « à un instant donné ». En réalité, les transactions avec MVCC utilisent un marqueur temporel (timestamp en anglais) ou un identifiant de transaction pour déterminer l’état de la base à lire. Ce mécanisme permet d’éviter l’usage de verrous dans les transactions car les écritures peuvent être virtuellement isolées des opérations de lecture sur les anciennes versions de la base qui ont été maintenues. Ainsi, considérant une requête en lecture ayant un identifiant de transaction donné, toutes ses valeurs sont consistantes car les opérations d’écriture disposent d’un identifiant de transaction plus élevé.

En d’autres mots, MVCC permet à chaque utilisateur connecté de voir une capture de la base. Les modifications apportées ne seront pas visibles par les autres utilisateurs avant que la transaction ne soit validée (commit).

Source :

Architecture de Postgres

Après avoir installé et lancé Postgres voici les processus lancés par celui-ci :

 1processus de postgres
 2 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
 3    1  2179  2175  2175 ?           -1 S      104   0:00 /usr/lib/postgresql/9.3/bin/postgres -D /var/lib/postgresql/9.3/main -c config_file=/etc/postgresql/9.3/main/postgresql.conf
 4 2179  2180  2180  2180 ?           -1 Ss     104   0:00  \_ postgres: logger process
 5 2179  2182  2182  2182 ?           -1 Ss     104   0:00  \_ postgres: checkpointer process
 6 2179  2183  2183  2183 ?           -1 Ss     104   0:00  \_ postgres: writer process
 7 2179  2184  2184  2184 ?           -1 Ss     104   0:00  \_ postgres: wal writer process
 8 2179  2185  2185  2185 ?           -1 Ss     104   0:00  \_ postgres: autovacuum launcher process
 9 2179  2186  2186  2186 ?           -1 Ss     104   0:00  \_ postgres: stats collector process
10 2179  2703  2703  2703 ?           -1 Ss     104   0:00  \_ postgres: postgres postgres 192.168.1.10(60043) idle
11 2179  2704  2704  2704 ?           -1 Ss     104   0:00  \_ postgres: postgres tiny 192.168.1.10(60044) idl

Pour illustrer l’auteur de ce blog m’a aimablement autorisé à utiliser son schéma. Je vous recommande la lecture de son blog celui-ci contient des articles très intéressants sur Postgres :

Que nous indique ce schéma?

Il y a un process principal : Postmaster. C’est sur lui que se fait fait la connexion.
Lors de la connexion il crée un autre processus backend qui va traiter la requête. Si votre client a tendance à initier beaucoup d’ouverture et fermeture de connexion il peut être intéressant de mettre en place un mécanisme de maintien de la connexion type pooler.
Dans la mémoire on peut distinguer deux zones : La shared memory et per-backend memory. Comme leur nom l’indique la shared-memory sera utilisée par tous les process alors que la « per backend memory » sera dédiée à chaque processus postgres traitant une requête (backend).
Un ensemble de processus d’arrière plan nécessaire au bon fonctionnement de postgres : bgwriter (renomé en writer depuis postgres 9.2), wal writer, autovacuum, stats collector, logger, archiver…
Le dossier de l’instance postgres contient les fichiers de configuration (ça dépend de la distribution), les fichiers pid et lock et un ensemble de répertoires. Les plus essentiels sont :
- base : contient les fichiers de la base de donnée
- pg_xlog : Contient les journaux de transaction
- pg_stat_tmp : Contient des données temporaires nécessaire au collecteur de statistique. Les données dans ce répertoire ne sont pas utile pour la base, si on les perd ce n’est pas grave. Il est recommandé de placer cet espace sur un petit ramdisk.
- pg_log : Contient les logs de postgres

Pour approfondir sur les processus Postgres :

Principe des journaux de transaction

Afin de garantir l’atomicité d’une transaction il faut être sûr que la transaction ait bien été réalisée. Que ce soit un insert, un update, un delete … On peut simplement penser que le SGBD écrit les informations sur le disque avant d’indiquer au client que la transaction s’est bien déroulée. Comment se comporterait un tel système avec des accès concurrents ou un seul accès mais effectuant de nombreuses requêtes? Il faut se rapprocher au plus près du matériel : les disques durs. Les têtes d’enregistrement doivent se déplacer pour lire et écrire les données, s’il y a plusieurs demandes il y a une file d’attente. Pendant que le disque écrit il ne peut pas lire et inversement, les performances seraient désastreuses. Pour éviter ces files d’attentes il y a le journal de transaction. Postgres écrit d’abord les informations dans son journal (pg_xlog) avant d’indiquer au client que la requête a bien été réalisée.

L’écriture de ce journal se fait de manière séquentielle et synchrone, permettant à Postgres de supporter une charge importante de modifications des données. On comprend facilement pourquoi il est important de séparer les journaux de transaction du reste des fichiers de bases et en quoi il est important de leur consacrer un ensemble de disques dédiés (RAID 10 par exemple).

Un processus de Postgres (writer) se charge d’écrire les journaux de transactions dans la base (répertoire base). Ceci permet une rotation des journaux. Par ailleurs en cas de crash Postgres doit rejouer les journaux de transaction. Il faut savoir que les fichiers de bases de Postgres peuvent ne pas être cohérents. C’est l’association des fichiers de base et des journaux de transaction qui rend la base cohérente.Attention, je parle de cohérence et non d’intégrité. Exemple, après un crash, votre base de donnée peut être intègre (pas de corruption de données) mais démarrer à un état antérieur (si le serveur ne peut pas rejouer les journaux). Sous entendu vous avez perdu des transactions.

Le writer ne supprime pas les données en base, pour faire simple, il se contente juste d’ajouter une ligne avec un numéro de transaction. Comme un système de versionning, il garde en base tous les enregistrements même ceux qui ont été modifiés. Il existe un mécanisme de nettoyage qui va permettre de libérer l’espace utilisé par les anciennes versions des enregistrements (vacuum). Attention, c’est une explication très schématique, en réalité le système est bien plus compliqué c’est pourquoi j’ai indiqué des liens à la fin de ce paragraphe pour ceux qui veulent approfondir le sujet.

Pour résumer :

Fichier de base de Postgres : Peuvent ne pas être cohérent, les accès ne sont pas nécessairement séquentiels (Postgres essaie privilégier les accès séquentiels), les écritures sont asynchrones.
Journaux de transaction : Écriture séquentielle, inutiles sans les fichiers de base. Sont nécessaires pour retrouver une cohérence de la base, Postgres peut les rejouer.

Pour approfondir :

Shared buffers

Postgres est multi-processus et non multithread. Ses processus accèdent à une zone de mémoire partagée, dite « Shared Buffers ». Si un processus doit accéder à une donnée, il le fait depuis le shared buffer. Si la donnée n’est pas présente il va la chercher sur le disque et la place dans le cache. On voit vite l’optimisation, si deux processus doivent accéder à une donnée un seul fera la lecture, le second aura déjà l’information dans le cache. Bien entendu Postgres intègre des mécanismes de nettoyage de ce cache sinon il serait vite rempli.

Tout d’abord, si un processus a besoin d’une donnée en cache il peut la verrouiller afin d’éviter qu’un autre processus modifie le tampon. Imaginons que ce processus modifie la donnée (lors d’un update par exemple). La donnée ne sera présente que dans le cache, lors du commit la donnée sera écrite dans le journal de transaction mais la donnée présente dans les fichier de base sera toujours l’ancienne donnée. Le tampon est dit « sale » dirty ce n’est que lors de l’écriture dans les fichier de base que ce tampon redevient « propre ».

En installant l’extension pg_buffercache on peut avoir un aperçu du cache :

1CREATE EXTENSION pg_buffercache;
2SELECT * FROM pg_buffercache LIMIT 3;
3 bufferid | relfilenode | reltablespace | reldatabase | relforknumber | relblocknumber | isdirty | usagecount
4----------+-------------+---------------+-------------+---------------+----------------+---------+------------
5        1 |      229643 |          1663 |       16385 |             0 |             91 | t       |          5
6        2 |      229331 |          1663 |       16385 |             0 |             17 | f       |          5
7        3 |       11805 |          1663 |       12043 |             0 |              0 | t       |          5

Sans rentrer dans les détails on peut voir la valeur « isdirty », certain buffer sont à true. On remarque la présence d’un compteur « usagecount ». Si des processus accèdent souvent à la même donnée il est important de la conserver en mémoire. Postgres intègre un mécanisme de nettoyage du cache où il décrémente ce compteur. Quand celui-ci arrive à zéro il peut être a nouveau affecté.

Quelque minutes plus tard :

1SELECT * FROM pg_buffercache LIMIT 3;
2 bufferid | relfilenode | reltablespace | reldatabase | relforknumber | relblocknumber | isdirty | usagecount
3----------+-------------+---------------+-------------+---------------+----------------+---------+------------
4        1 |      229643 |          1663 |       16385 |             0 |             91 | f       |          5
5        2 |      229331 |          1663 |       16385 |             0 |             17 | f       |          5
6        3 |       11805 |          1663 |       12043 |             0 |              0 | f       |          5

On constate que tous les buffers son clean, les données ont été écrites dans les fichiers de base.

Il y a plusieurs moyens pour écrire les données en base. Le principal étant le processus writer qui se lance régulièrement pour nettoyer les buffers. Il y a aussi le checkpointer qui a intervalle régulier va vider tous les buffers dirty. Enfin, le processus en charge d’une requête peut être amené à nettoyer un buffer.

Qu’est-ce qu’il se passe lorsque le shared buffer arrive à saturation? Si un processus a besoin d’un buffer et qu’il n’y en a plus de disponible (ils sont tous sales « dirty »). Le processus en charge de la requête va déclencher les écritures sur le disque pour nettoyer les buffers. Le cout de cette opération est énorme, les écritures sur disque sont lentes d’autant plus que celles-ci se font de manière aléatoires sur le disque. Il faut éviter à tout prix cette situation.

Il existe une vue assez pratique pour voir comment sont écris les buffer : pg_stat_bgwriter :

1select * from pg_stat_bgwriter;
2 checkpoints_timed | checkpoints_req | checkpoint_write_time | checkpoint_sync_time | buffers_checkpoint | buffers_clean | maxwritten_clean | buffers_backend | buffers_backend_fsync | buffers_alloc |          stats_reset
3-------------------+-----------------+-----------------------+----------------------+--------------------+---------------+------------------+-----------------+-----------------------+---------------+-------------------------------
4             11494 |              16 |            1048822079 |              2927551 |           10497060 |             0 |                0 |           88433 |                     0 |         77381 | 2014-10-01 23:30:04.259356+02

Les checkpoints peuvent être déclenché à l’issue d’une timeout (checkpoint_timeout) ou « à la demande » : par la commande CHECKPOINT ou si on a atteint le nombre max de journaux de transaction entre deux checkpoint défini par le paramètre : checkpoint_segments. Si le nombre checkpoints_req augmente rapidement ça signifie qu’il y a beaucoup d’écritures, les journaux se remplissent plus vite qu’ils ne se vident du coup postgres déclenche des checkpoints.

buffers_checkpoint nous indique le nombre buffers écrit par le checkpointer, buffers_clean le nombre de buffers écrit par le processus d’écriture en arrière plan (bgwriter). Il est préférable que les buffers soient écrit par ces deux processus. Les valeurs suivantes buffers_backend et buffers_backend_fsync indiquent respectivement les buffers écrit par les processus en charge des requêtes et les écritures ayant nécessitées un fsync. Ce dernier cas est à éviter à tout prix. Ça peut arriver quand tous les buffers sont utilisés et que processus en charge d’une requête doivent forcer le vidage des buffers.

Cette zone mémoire est très importante, elle permet d’éviter les accès disques qui sont très couteux même avec le meilleur ssd du monde les accès RAM seront toujours beaucoup plus rapide.

Pour approfondir :

Vacuum

Comme expliqué au paragraphe sur les journaux de transaction, Postgres ne supprime pas les données sur le disque. Il indique juste qu’une nouvelle version de la donnée existe, les différentes versions s’accumulent et la base grossit petit à petit. il existe donc un système de nettoyage, dit vacuum. De base, le vacuum va marquer les enregistrements périmés, les emplacements pourront être libéré pour les futures écritures. Point important : Un vacuum simple ne libère pas l’espace disque, sauf si les enregistrement périmés étaient en fin de disque. Au fil du temps la base va se fragmenter sur le disque, ce qui va générer des accès aléatoires pour les têtes d’écriture.

Note : Il n’y a pas besoin de lancer manuellement le vacuum, celui-ci se déclenche automatiquement grâce à l’autovacuum. Sur certains forum on voit des sysadmin qui ne savent pas à quoi correspond ce vacuum et recommandent de le désactiver. Dans la plupart des situations il faut laisser faire postgres. L’autovacuum procède également à un ANALYZE des tables, cette opération permet à Postgres d’avoir des statistiques sur les tables et d’améliorer le fonctionnement de l’optimiseur de requêtes.

Pour remédier à la fragmentation et à « la non libération des espaces vides » il existe le vacuum full. Celui-ci va défragmenter les tables en réécrivant tous les enregistrements de manière séquentielle et effectue un reindex des tables (les données ont été déplacées sur le disque). Cette opération a un impact sur les performances mais aussi sur l’utilisation de la base : Le vacuum full va poser un verrou exclusif sur les tables au moment de la réécriture. Suivant la taille des tables ce verrou peut durer plus ou moins longtemps. Il est recommandé de lancer un vacuum full lors de taches de maintenance. Après un vacuum full on peut observer un gain sur les performances, notamment sur les accès séquentiels.

Pour approfondir

J’espère que cet article vous aura éclairé sur le fonctionnement de Postgres. C’est assez difficile de ne pas sacrifier le fond à la forme. J’ai essayé d’expliquer certains mécanismes sans aller trop loin dans le détails, néanmoins je vous laisse la possibilité d’approfondir vos connaissances en citant mes sources. Maintenant nous allons faire un grand saut et je vous invite à lire l’article suivant traitant de la réplication par transfert de journaux de transaction.

Les dérives de l’intelligence collective

Sun, 30 Nov 2014 09:20:24 +0000

J’ai lu un article très intéressant dans la revue Sciences Humaines sur « Les dérives de l’intelligence collective ».

L’intelligence collective produit régulièrement des décisions complètement erronées ou stupides, par exemple l’autorisation en 1986 de lancer la navette Challenger, alors que les décideurs savent qu’elle souffre d’un grave défaut et que certains d’entre eux sont convaincus qu’elle va s’écraser. Pourtant ces décisions ont fait préalablement l’objet de nombreuses délibérations entre individus haut placés, dont le rang en phase avec les capacités intellectuelles. Elles sont prises dans le cadre d’organisations structurées et ont été alimentées par une grande quantité d’informations. Or, ces trois éléments – les délibérations, l’organisation et l’information – sont susceptibles d’être affectés par de puissants dysfonctionnements, qui vont égarer collectivement des acteurs individuellement rationnels.

C’est assez intéressant, alors qu’on pourrait penser que nous prenons de meilleures décisions à plusieurs, des recherches montrent que ce n’est pas toujours le cas. Je pense qu’il est toujours important de connaître les « faiblesses » de l’esprit humain afin de prendre de meilleures décisions.

Liens vers l’article :

Lien vers le numéro en question :