Mise à niveau en un clic de votre PostgreSQL vers la version 10.1 maintenant disponible !

Scalingo offre des addons de base de données à jour avec une mise à niveau simple. Nous venons d'activer la capacité de mettre à niveau vos bases de données PostgreSQL vers la version 10.1. Dans cet article, nous explorerons les nouvelles fonctionnalités offertes par cette grande version.

Processus de mise à niveau

En préambule, jetons un coup d'œil à la manière de mettre à niveau votre base de données sur Scalingo. Comme d'habitude, le processus de mise à niveau sur Scalingo est aussi simple que de cliquer sur un bouton dans le tableau de bord de la base de données. L'image suivante montre le message que vous verrez sur le tableau de bord de votre base de données si vous utilisez la version 9.6 la plus récente (c'est-à-dire PostgreSQL v9.6.5):

Cette mise à niveau peut prendre du temps pour les plus grandes bases de données. Pendant le processus, votre base de données sera mise hors ligne. Vous devrez d'abord mettre à niveau vers la dernière version 9.6.5-2 avant de pouvoir passer à 10.1.

Comme d'habitude, vous pouvez trouver les images Docker correspondantes sur notre référentiel Docker Hub.

Nous vous conseillons fortement de tester que votre code fonctionne toujours avec la nouvelle version de la base de données. Pour faciliter cette tâche, vous pouvez récupérer la version PostgreSQL dont vous avez besoin à partir de notre référentiel Docker Hub public et tester votre code localement. Vous pouvez également obtenir le même conteneur que nous avons construit pour votre application et qui fonctionne sur notre infrastructure en utilisant notre addon d'image Docker.

Nous pouvons maintenant jeter un œil aux nouvelles fonctionnalités introduites dans PostgreSQL 10.1.

Quoi de neuf dans PostgreSQL 10.1

Après un an de développement, le PostgreSQL Global Development Group vient de publier la version 10 de sa base de données. Cette version annonce d'excellentes fonctionnalités dans le domaine de la haute disponibilité et des performances.

Haute disponibilité PostgreSQL

Les bases de données PostgreSQL ont eu une capacité de haute disponibilité pendant longtemps. Cette dernière version de PostgreSQL ajoute une fonctionnalité de "Réplication logique" pour faciliter la réplication d'une partie seulement du serveur principal et ajoute la possibilité d'écrire sur le serveur secondaire.

Vous pouvez obtenir une explication plus détaillée sur cette fonctionnalité dans cet article de blog de Petr Jelinek.

En parlant de haute disponibilité, bénéficiant des travaux sur MongoDB replica set, nous travaillons sur la haute disponibilité pour PostgreSQL. Restez à l'écoute!

Performances PostgreSQL

PostgreSQL 9.6 a introduit des requêtes parallèles pour une exécution plus rapide. Dans la version 10, l'équipe a continué à travailler sur cette fonctionnalité. Une plus grande partie du processus d'exécution des requêtes est parallélisée, ce qui entraîne encore plus de performances lors de l'utilisation de cette fonctionnalité.

L'exemple simple suivant montre comment paralléliser l'exécution d'une requête. Commencez par exécuter une requête sans paralléliser l'exécution de la requête :

accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 group by bid;
...
Time: 324.903

accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 group by bid;
...
Time: 324.903

accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 group by bid;
...
Time: 324.903

accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 group by bid;
...
Time: 324.903

Nous allons maintenant définir le nombre maximum de travailleurs parallèles à 4 et observer le résultat éclatant :

accounts=# set max_parallel_workers_per_gather=4;
SET
Time: 0.822 ms
accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 GROUP BY bid;
...
Time: 72.864

accounts=# set max_parallel_workers_per_gather=4;
SET
Time: 0.822 ms
accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 GROUP BY bid;
...
Time: 72.864

accounts=# set max_parallel_workers_per_gather=4;
SET
Time: 0.822 ms
accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 GROUP BY bid;
...
Time: 72.864

accounts=# set max_parallel_workers_per_gather=4;
SET
Time: 0.822 ms
accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 GROUP BY bid;
...
Time: 72.864

De 324 ms à 72 ms, pas mal!

Pour plus de détails techniques sur cette remarquable amélioration, vous pouvez lire cet article de blog.

Numérotation des versions

Enfin, sur un plan non technique, PostgreSQL n'utilise plus de numéros de version à 3 chiffres mais passe à une numérotation à 2 chiffres. Cela signifie que la prochaine version majeure sera 11 et 10.1 est le premier correctif pour PostgreSQL 10.

Pour une liste complète de ce qui est nouveau dans PostgreSQL 10, veuillez vous référer à cet article de blog du site officiel.

La version 10.1 est déjà en production chez Scalingo. Elle contient trois importantes corrections de sécurité comme indiqué dans cet article de blog officiel.