, la dernière version de « la meilleure base de données relationnelle open source au monde », sortira dans quelques semaines (si tout se passe comme prévu). Cela suit le calendrier habituel de sortie d'une nouvelle version avec une tonne de nouvelles fonctionnalités une fois par an, et franchement, c'est impressionnant. C'est pourquoi je suis devenu membre actif de la communauté PostgreSQL.
À mon avis, contrairement aux versions précédentes, PostgreSQL 12 ne contient pas une ou deux fonctionnalités révolutionnaires (comme le partitionnement ou le parallélisme des requêtes). J'ai plaisanté un jour en disant que la principale caractéristique de PostgreSQL 12 était une plus grande stabilité. N'est-ce pas ce dont vous avez besoin lorsque vous gérez les données critiques de votre entreprise ?
Mais PostgreSQL 12 ne s'arrête pas là : avec de nouvelles fonctionnalités et améliorations, les applications seront plus performantes, et tout ce que vous avez à faire est de mettre à niveau !
(Eh bien, peut-être reconstruire les index, mais dans cette version, ce n'est pas aussi effrayant qu'avant.)
Ce sera formidable de mettre à niveau PostgreSQL et de bénéficier immédiatement d'améliorations significatives sans complications inutiles. Il y a quelques années, j'ai examiné une mise à niveau de PostgreSQL 9.4 vers PostgreSQL 10 et j'ai vu comment l'application s'est accélérée grâce au parallélisme amélioré des requêtes dans PostgreSQL 10. Et, plus important encore, presque rien ne m'était demandé (il suffit de définir un paramètre de configuration max_parallel_workers).
D’accord, c’est pratique lorsque les applications fonctionnent mieux immédiatement après une mise à niveau. Et nous essayons très fort de plaire aux utilisateurs, car PostgreSQL en compte de plus en plus.
Alors, comment une simple mise à niveau vers PostgreSQL 12 peut-elle vous rendre heureux ? Je vais vous le dire maintenant.
Améliorations majeures de l'indexation
Sans indexation, une base de données n’ira pas loin. Sinon, comment pouvez-vous trouver rapidement des informations ? Le système d'indexation fondamental de PostgreSQL s'appelle . Ce type d'index est optimisé pour les systèmes de stockage.
On utilise simplement l'opérateur CREATE INDEX ON some_table (some_column), et PostgreSQL fait beaucoup de travail pour maintenir l'index à jour pendant que nous insérons, mettons à jour et supprimons constamment des valeurs. Tout fonctionne tout seul, comme par magie.
Mais les index PostgreSQL ont un problème : ils et occupent de l'espace disque supplémentaire et réduisent les performances de récupération et de mise à jour des données. Par « ballonnement », j'entends le maintien inefficace de la structure de l'index. Cela peut - ou non - être lié aux tuples de déchets qu'il supprime (merci à Peter Gaghan pour l'information))). Le gonflement de l’index est particulièrement visible dans les charges de travail où l’index change activement.
PostgreSQL 12 améliore considérablement les performances des index B-tree, et des expériences avec des benchmarks comme TPC-C ont montré qu'en moyenne 40 % d'espace en moins est désormais utilisé. Désormais, nous consacrons moins de temps non seulement à la maintenance des index B-tree (c'est-à-dire aux opérations d'écriture), mais également à la récupération des données, car les index sont beaucoup plus petits.
Applications qui mettent activement à jour leurs tables - généralement les applications OLTP () - utilisera le disque et traitera les requêtes beaucoup plus efficacement. Plus il y a d'espace disque, plus la base de données doit croître sans mettre à niveau l'infrastructure.
Certaines stratégies de mise à niveau nécessitent de reconstruire les index B-tree pour profiter de ces avantages (par ex. ne reconstruira pas automatiquement les index). Dans les versions précédentes de PostgreSQL, la reconstruction d'index volumineux sur des tables entraînait des temps d'arrêt importants car les modifications ne pouvaient pas être apportées entre-temps. Mais PostgreSQL 12 a une autre fonctionnalité intéressante : vous pouvez désormais reconstruire les index en parallèle avec la commande pour éviter complètement les temps d'arrêt.
Il existe d'autres améliorations de l'infrastructure d'indexation dans PostgreSQL 12. Une autre chose où il y avait un peu de magie - , alias WAL (journal à écriture anticipée). Un journal à écriture anticipée enregistre chaque transaction dans PostgreSQL en cas d'échec et de réplication. Les applications l'utilisent pour l'archivage et . Bien entendu, le journal d’écriture anticipée est écrit sur le disque, ce qui peut avoir un impact sur les performances.
PostgreSQL 12 a réduit la surcharge des enregistrements WAL créés par les index GiST, GIN et SP-GiST lors de la construction de l'index. Cela offre plusieurs avantages tangibles : les enregistrements WAL occupent moins d'espace disque et les données sont relues plus rapidement, comme lors d'une récupération après sinistre ou d'une récupération à un moment précis. Si vous utilisez de tels index dans vos applications (par exemple, les applications géospatiales basées sur PostGIS utilisent beaucoup l'index GiST), il s'agit d'une autre fonctionnalité qui améliorera considérablement l'expérience sans aucun effort de votre part.
Partitionnement : plus grand, meilleur, plus rapide
PostgreSQL 10 introduit . Dans PostgreSQL 11, il est devenu beaucoup plus facile à utiliser. Dans PostgreSQL 12, vous pouvez modifier l'échelle des sections.
Dans PostgreSQL 12, les performances du système de partitionnement se sont nettement améliorées, surtout s'il y a des milliers de partitions dans la table. Par exemple, si une requête n’affecte que quelques partitions d’une table qui en contient des milliers, elle s’exécutera beaucoup plus rapidement. Les performances ne sont pas seulement améliorées pour ces types de requêtes. Vous remarquerez également à quel point les opérations INSERT sont plus rapides sur les tables comportant plusieurs partitions.
Enregistrement de données à l'aide - au fait, c'est une excellente façon et voici un exemple — les tables partitionnées dans PostgreSQL 12 sont également devenues plus efficaces. Avec COPY, tout était déjà rapide, mais dans PostgreSQL 12, cela vole absolument.
Grâce à ces avantages, PostgreSQL vous permet de stocker des ensembles de données encore plus volumineux et de les rendre plus faciles à récupérer. Et aucun effort de votre part. Si l'application comporte de nombreuses partitions, telles que l'enregistrement de données de séries chronologiques, une simple mise à niveau améliorera considérablement ses performances.
Bien qu'il ne s'agisse pas exactement d'une amélioration « mettre à niveau et profiter », PostgreSQL 12 vous permet de créer des clés étrangères faisant référence à des tables partitionnées, ce qui rend le partitionnement un plaisir à travailler.
Les requêtes AVEC sont devenues bien meilleures
Quand (alias CTE, alias AVEC requêtes), j'avais hâte d'écrire un article sur . C'est l'une de ces fonctionnalités qui accéléreront l'application. À moins bien sûr que vous utilisiez CTE.
Je trouve souvent que les débutants en SQL adorent utiliser les CTE ; si vous les écrivez d’une certaine manière, vous avez vraiment l’impression d’écrire un programme impératif. Personnellement, j'aimais réécrire ces requêtes pour contourner sans CTE et augmentation de la productivité. Maintenant, tout est différent.
PostgreSQL 12 vous permet d'intégrer un type spécifique de CTE sans effets secondaires (SELECT), qui n'est utilisé qu'une seule fois vers la fin de la requête. Si je gardais une trace des requêtes CTE que j'ai réécrites, la plupart d'entre elles entreraient dans cette catégorie. Cela aide les développeurs à écrire du code clair qui s’exécute désormais également rapidement.
De plus, PostgreSQL 12 optimise lui-même l'exécution de SQL, sans que vous ayez à faire quoi que ce soit. Et même si je n'aurai probablement pas besoin d'optimiser de telles requêtes maintenant, c'est formidable que PostgreSQL continue de travailler sur l'optimisation des requêtes.
Juste à temps (JIT) - désormais par défaut
Sur les systèmes PostgreSQL 12 avec prise en charge La compilation JIT est activée par défaut. Tout d'abord, vous bénéficiez d'un accompagnement pour certaines opérations internes, et deuxièmement, les requêtes avec des expressions (l'exemple le plus simple est x + y) dans des listes de sélection (que vous avez après SELECT), des agrégats, des expressions avec des clauses WHERE et d'autres peuvent utiliser JIT pour améliorer les performances.
Étant donné que JIT est activé par défaut dans PostgreSQL 12, les performances s'amélioreront d'elles-mêmes, mais je recommande de tester l'application dans PostgreSQL 11, qui a introduit JIT, pour mesurer les performances des requêtes et voir si vous devez régler quelque chose.
Qu’en est-il du reste des nouvelles fonctionnalités de PostgreSQL 12 ?
PostgreSQL 12 propose une tonne de nouvelles fonctionnalités intéressantes, de la possibilité d'examiner les données JSON à l'aide d'expressions de route SQL/JSON standard à l'authentification multifacteur avec un paramètre. clientcert=verify-full, colonnes créées et bien plus encore. Assez pour un article séparé.
Comme PostgreSQL 10, PostgreSQL 12 améliorera les performances globales immédiatement après la mise à niveau. Vous pouvez bien sûr avoir votre propre chemin - tester l'application dans des conditions similaires sur le système de production avant d'activer les améliorations, comme je l'ai fait avec PostgreSQL 10. Même si PostgreSQL 12 est déjà plus stable que prévu, ne soyez pas paresseux dans les tests soigneusement les applications avant de les lancer en production.
Source: habr.com