PostgreSQL 12 , 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 correspond au calendrier habituel - une nouvelle version avec beaucoup de nouvelles fonctionnalités sort une fois par an, et, franchement, c'est impressionnant. Par conséquent, je suis devenu un membre actif de la communauté PostgreSQL.
À mon avis, contrairement aux versions précédentes, PostgreSQL 12 ne contient pas une ou deux fonctions révolutionnaires (comme le partitionnement ou la simultanéité des requêtes). J'ai plaisanté une fois que la principale caractéristique de PostgreSQL 12 est plus de stabilité. N'est-ce pas ce dont vous avez besoin lorsque vous gérez des données commerciales critiques?
Mais PostgreSQL 12 ne se limite pas à cela: avec de nouvelles fonctionnalités et améliorations, les applications fonctionneront mieux et il vous suffit de mettre à niveau!
(Eh bien, peut-être même reconstruire les indices, mais dans cette version, ce n'est pas aussi effrayant qu'avant.)
Ce sera formidable de mettre à niveau PostgreSQL et de profiter immédiatement d'améliorations significatives sans gestes inutiles. Il y a quelques années, j'ai analysé la mise à niveau de PostgreSQL 9.4 vers PostgreSQL 10 et vu comment l'application s'est accélérée en raison de l'amélioration du parallélisme des requêtes dans PostgreSQL 10. Et, plus important encore, presque rien n'était requis de moi (il suffit de définir le max_parallel_workers configuration max_parallel_workers ).
D'accord, c'est pratique lorsque, juste après la mise à niveau, les applications fonctionnent mieux. Et nous essayons très fort de plaire aux utilisateurs, car PostgreSQL en a plus.
Et comment une simple mise à niveau vers PostgreSQL 12 vous fait-elle plaisir? Je vais te le dire maintenant.
Améliorations majeures de l'indexation
Sans indexation, la base de données n'ira pas loin. Et comment trouver rapidement des informations autrement? Le système d'indexation fondamental de PostgreSQL est appelé B-tree . Ce type d'index est optimisé pour les systèmes de stockage.
Nous utilisons simplement l' CREATE INDEX ON some_table (some_column) , et PostgreSQL fait un excellent travail pour maintenir l'index à jour pendant que nous insérons, mettons à jour et CREATE INDEX ON some_table (some_column) constamment des valeurs. Tout fonctionne par lui-même, comme par magie.
Mais les index PostgreSQL ont un problème: ils gonflent et prennent de l'espace disque supplémentaire, et les performances de récupération et de mise à jour des données sont réduites. Par «ballonnement», j'entends le maintien inefficace de la structure de l'indice. Cela peut ou non être dû à des tuples d'ordures que VACUUM supprime (merci pour l'info à Peter Geoghegan ). 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 tests tels que TPC-C ont montré que l'espace est désormais utilisé, en moyenne, de 40% de moins. Maintenant, nous passons moins de temps non seulement à maintenir les index B-tree (c'est-à-dire à écrire des opérations), mais aussi à extraire des données, car les index sont devenus beaucoup plus petits.
Les applications qui mettent activement à jour leurs tables, généralement les applications OLTP ( traitement des transactions en temps réel ), sont beaucoup plus efficaces pour utiliser le disque et traiter les demandes. Plus il y a d'espace disque, plus la base de données dispose d'espace de croissance sans mettre à niveau l'infrastructure.
Certaines stratégies de mise à niveau nécessitent la reconstruction d'index B-tree pour en tirer parti (par exemple, pg_upgrade ne reconstruira pas automatiquement les index). Dans les versions précédentes de PostgreSQL, la reconstruction de grands index dans les tables entraînait des temps d'arrêt importants, car à ce moment-là, il était impossible d'apporter des modifications. Mais PostgreSQL 12 a une autre astuce intéressante: vous pouvez maintenant reconstruire des index en parallèle avec la commande REINDEX CONCURRENTLY pour éviter complètement les temps d'arrêt.
PostgreSQL 12 a d'autres améliorations à l'infrastructure d'indexation. Une autre chose qui ne pourrait pas se passer de magie est le journal d'écriture anticipée, qui est également WAL (journal d'écriture anticipée). Un journal d'écriture anticipée enregistre chaque transaction dans PostgreSQL en cas d'échec et de réplication. Les applications l'utilisent pour la sauvegarde et la restauration à un moment donné . Bien sûr, le journal d'écriture anticipée est écrit sur le disque, ce qui peut affecter les performances.
PostgreSQL 12 a réduit les frais généraux des 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 reproduites plus rapidement, par exemple, lors d'une récupération après une défaillance ou d'une récupération à un moment donné. Si vous utilisez de tels index dans vos applications (par exemple, les applications géospatiales basées sur PostGIS utilisent beaucoup l'index GiST), c'est une autre fonctionnalité qui améliorera considérablement les performances sans aucun effort de votre part.
Partitionnement - Plus grand, meilleur, plus rapide
PostgreSQL 10 a introduit le partitionnement déclaratif . PostgreSQL 11 l'a rendu beaucoup plus facile à utiliser. Dans PostgreSQL 12, vous pouvez modifier l'échelle des sections.
Dans PostgreSQL 12, les performances du système de partitionnement sont bien meilleures, surtout s'il y a des milliers de sections dans le tableau. Par exemple, si une requête affecte seulement quelques sections d'une table, où il y en a des milliers, elle s'exécutera beaucoup plus rapidement. Les performances ont été améliorées non seulement pour ces types de requêtes. Vous remarquerez également comment les opérations INSERT se sont accélérées dans les tables avec de nombreuses partitions.
Écrire des données à l'aide de COPY - en passant, c'est un excellent moyen de charger des données en bloc et voici un exemple de réception de JSON - dans des tables partitionnées dans PostgreSQL 12 est également devenu plus efficace. Avec COPY, tout était si rapide, mais dans PostgreSQL 12 ça vole.
Grâce à ces avantages, PostgreSQL peut stocker des ensembles de données encore plus volumineux et faciliter la récupération. Et aucun effort de votre part. Si l'application comporte de nombreuses sections, par exemple, elle enregistre des données de séries chronologiques, une simple mise à niveau améliorera considérablement ses performances.
Bien que cette amélioration ne soit pas entièrement de la catégorie «mise à niveau et réjouissance», dans PostgreSQL 12, vous pouvez créer des clés étrangères qui référencent des tables partitionnées afin que travailler avec le partitionnement soit un plaisir.
AVEC les requêtes sont bien mieux
Lorsque le correctif a été appliqué aux expressions de table généralisées intégrées (elles sont CTE, elles sont également AVEC des requêtes), j'étais impatient d'écrire un article sur la façon dont les développeurs d'applications avec PostgreSQL étaient ravis . C'est l'une de ces fonctionnalités qui accélèrera l'application. Sauf si, bien sûr, vous utilisez CTE.
Je remarque souvent que les nouveaux venus dans SQL aiment utiliser CTE: si vous les écrivez d'une certaine manière, vous sentez directement que vous écrivez un programme impératif. Personnellement, j'ai adoré réécrire ces requêtes afin de me passer de CTE et d'augmenter les performances. Maintenant, tout est différent.
PostgreSQL 12 vous permet d'incorporer 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 conservais des statistiques de demandes avec des CTE que j'ai réécrites, la plupart d'entre elles tomberaient dans cette catégorie. Cela aide les développeurs à écrire du code compréhensible qui fonctionne désormais aussi rapidement.
De plus, PostgreSQL 12 optimise l'exécution de SQL lui-même, vous n'avez rien à faire. Et même si maintenant, probablement, je n'aurai pas besoin d'optimiser de telles requêtes, il est formidable que PostgreSQL continue de travailler sur l'optimisation des requêtes.
Just-in-Time (JIT) - maintenant par défaut
Sur les systèmes PostgreSQL 12 avec prise en charge LLVM , la compilation JIT est activée par défaut. Premièrement, vous obtenez le support JIT pour certaines opérations internes, et deuxièmement, des requêtes avec des expressions (l'exemple le plus simple est x + y) dans les listes de sélection (que vous avez après SELECT), des agrégats, des expressions avec des clauses WHERE et autres peut utiliser JIT pour améliorer les performances.
Étant donné que JIT est inclus dans PostgreSQL 12 par défaut, les performances s'amélioreront par elles-mêmes, mais je recommande de tester l'application dans PostgreSQL 11, où JIT vient d'apparaître pour mesurer les performances des requêtes et voir si vous devez régler quelque chose.
Mais qu'en est-il des autres nouvelles fonctionnalités de PostgreSQL 12?
PostgreSQL propose 12 tonnes 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 clientcert=verify-full avec le clientcert=verify-full , les colonnes créées et bien plus encore. Assez pour un poste séparé.
Comme PostgreSQL 10, PostgreSQL 12 améliorera les performances globales juste après la mise à niveau. Bien sûr, vous pouvez avoir votre propre méthode - tester l'application dans des conditions similaires dans le système de travail 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 pour tester la qualité des applications, avant de les mettre en production.