스크립트
00:00:00Il s'avère donc que tous les développeurs qui disent « oh mec, utilise Postgres pour tout » ont encore plus raison
00:00:04avec la sortie prochaine de Postgres 19 qui inclut la prise en charge native des requêtes par graphe.
00:00:10C'est une fonctionnalité vraiment géniale. Dans la vidéo d'aujourd'hui, je veux passer en revue les principales nouveautés
00:00:16de Postgres 19 et me pencher plus en détail sur les requêtes par graphe, car je pense que cela
00:00:21peut fondamentalement changer notre façon de concevoir nos requêtes et d'utiliser Postgres.
00:00:30La première nouveauté s'appelle "on conflict do select". Si vous voulez insérer une ligne uniquement si elle
00:00:35n'existe pas encore et que, dans les deux cas, vous souhaitez récupérer cette ligne en résultat, il vous faut habituellement
00:00:40deux requêtes : un insert et un select. C'est un flux de travail très courant. Dans l'exemple ici,
00:00:45nous disons que nous allons insérer dans users l'e-mail et le nom, puis nous fournissons ces valeurs, et à la
00:00:50fin, nous disons "on conflict for email do nothing returning star". "Do nothing" ne renvoie rien quand la ligne
00:00:56existe déjà, vous devez donc faire suivre d'un select, mais ensemble, ce n'est pas atomique. Avec la version 19, vous pouvez faire cela
00:01:03en une seule requête : insérer dans users en fournissant l'e-mail et le nom, puis "on conflict email do select
00:01:11returning star". Et si vous voulez modifier dans la même requête, nous pouvons dire insert into users, puis nous fournissons
00:01:16à nouveau les valeurs, on conflict for the email do select for update returning id and name. Et comme c'est une seule
00:01:23instruction, c'est atomique : vous l'insérez ou vous la sélectionnez à chaque fois. C'est un cas d'usage tellement
00:01:29courant que ça va être vraiment utile. Passons ensuite aux graphes, mais si vous aimez ce contenu,
00:01:34pourquoi ne pas vous abonner à Better Stack pour rester à jour sur les dernières actus tech ? Comme je le disais, c'est
00:01:39la fonctionnalité phare à mon sens. Disons que vous avez le schéma habituel pour une boutique : vous avez des clients,
00:01:44des commandes et des produits, plus les deux tables de jointure qui les relient, et vous voulez savoir quel
00:01:50produit un client donné a réellement acheté. En SQL, c'est une chaîne de jointures à travers les cinq tables, et c'est
00:01:56plutôt gérable ici, mais ça devient vite assez moche pour des relations plus complexes. Eh bien, maintenant nous
00:02:02pouvons interroger tout cela sous forme de graphe, de sorte que cette syntaxe de jointure complexe devient une nouvelle syntaxe de graphe. Et
00:02:08avec les jointures complexes en particulier, vous allez voir un très gros avantage. Nous sommes donc dans notre visualiseur
00:02:14de base de données ici, et vous pouvez voir que nous avons toutes nos tables : les produits, les commandes, les événements, nous avons
00:02:20aussi les clients, puis les tables de pivot pour connecter toutes ces données. Nous avons donc les articles commandés
00:02:25et les commandes clients. Essayons maintenant d'exécuter une requête sur toutes ces tables. Supposons par exemple
00:02:30que j'aie cet utilisateur ici nommé Alice, et je veux déterminer tout ce qu'Alice a commandé. Pour
00:02:35faire cela, je devrais passer par un tas de requêtes de jointure différentes pour relier toutes ces tables. Je lancerais donc cette
00:02:41requête qui contient quatre instructions de jointure distinctes, et bien que ce ne soit pas forcément difficile
00:02:46à écrire, c'est très moche. Mais si nous l'exécutons, vous pouvez voir que nous voyons tout ce qu'Alice a
00:02:51commandé : le clavier mécanique et la souris ergonomique. Maintenant, nous pouvons utiliser la syntaxe de graphe pour simplifier
00:02:57considérablement tout cela. Nous allons remplacer tout ça par la nouvelle syntaxe de graphe et l'exécuter à nouveau, et vous
00:03:03pouvez voir que nous obtenons les mêmes résultats. Si nous alignons tout cela, ça devient plus facile à lire : vous voyez
00:03:07que nous allons simplement des clients aux commandes clients, puis aux commandes, aux articles commandés et enfin aux produits. Vous pouvez
00:03:13donc fondamentalement suivre ce flux simple pour parcourir tout le graphe, ce qui, à mon avis, est bien, bien
00:03:19plus facile à lire. Si vous voulez sélectionner plusieurs colonnes également, nous pouvons le faire : nous avons la même
00:03:23requête de graphe en haut, mais nous pouvons définir des colonnes en bas, puis sélectionner toutes les
00:03:27colonnes que nous voulons afficher. En l'exécutant, nous obtenons les résultats en bas. Rien de tout cela
00:03:32ne fonctionnera à moins que nous n'ayons créé le graphe au préalable. La requête que j'ai utilisée pour
00:03:37générer ce graphe est ici : nous disons "create property graph", nous lui donnons un nom, "my shop", puis
00:03:42nous définissons les tables de sommets (vertex tables), qui vont être les clients, les commandes et les produits. Ce sont
00:03:47les éléments qui contiennent réellement les données, et ensuite nous avons les tables d'arêtes (edge tables), qui sont les éléments qui
00:03:52établissent les connexions, c'est-à-dire les tables de pivot. Dans notre cas, ce serait "customer orders" et "order
00:03:57items". La syntaxe est on ne peut plus simple : pour "customer orders", la source est "customers" et la
00:04:02destination est "orders", et pour "order items", la source est "orders" et la destination est "products". Avec
00:04:08cela en place, Postgres saura désormais, chaque fois que nous exécutons une requête de graphe, comment ces relations
00:04:14sont définies. Pour que cela fonctionne, vous devez créer un graphe, mais cela ne crée pas de nouvelles tables ou quoi que ce soit,
00:04:19vous pointez simplement vers les cinq tables que vous avez déjà : les trois qui détiennent les données deviennent
00:04:23des sommets et les deux tables de jointure deviennent des arêtes. Cela fonctionne un peu plus comme une vue, donc votre schéma précédent
00:04:29reste totalement inchangé, vous obtenez simplement cette fonctionnalité supplémentaire par-dessus. Ici, nous allons
00:04:35donc dire "create property graph", nous l'appellerons "my shop", puis nous commencerons à décrire comment cette relation
00:04:40fonctionne réellement. C'est là que nous faisons tout le travail pour le graphe, ce qui signifie que les requêtes
00:04:45peuvent être beaucoup, beaucoup plus légères que la syntaxe de jointure respective. Est-ce un remplacement pour Neo4j ? Eh bien, si vous voulez une
00:04:52base de données de graphes parce que vous avez besoin de performances de stockage et de parcours de graphes, alors non, une base de données de graphes
00:04:58dédiée reste probablement le meilleur choix. Mais si vous voulez cela parce qu'écrire des jointures de 10 tables en
00:05:03SQL est pénible et moche, alors cela va définitivement vous avantager et ce sera beaucoup plus agréable
00:05:09en comparaison. La troisième nouvelle fonctionnalité est "repack", qui permet de récupérer de l'espace disque. Postgres
00:05:15ne met jamais à jour une ligne sur place : il écrit une nouvelle version et laisse l'ancienne derrière lui, et "vacuum" ne fait que
00:05:21marquer cet espace mort comme réutilisable, de sorte que l'utilisation de votre disque ne diminue jamais réellement. "Repack" réécrit la totalité
00:05:27de la table dans un nouveau fichier sans aucun espace gaspillé, et c'est ce qui rend l'espace au système
00:05:33d'exploitation. Vous pouviez déjà le faire avec "vacuum full", mais cela verrouille la table pendant
00:05:38toute la réécriture, donc pour tout ce qui est massif, vous ne le faites jamais. C'est pourquoi les gens installaient
00:05:42des extensions comme pg_repack, mais maintenant c'est intégré directement dans Postgres. Utilisez le mot-clé "concurrently" avec
00:05:49cela, et la table reste lisible et inscriptible pendant que repack travaille. Une chose à surveiller cependant :
00:05:54vous avez besoin de suffisamment d'espace disque libre pour une seconde copie de la table et de tous ses index, il vous faut donc
00:06:00cet espace libre pour pouvoir récupérer de l'espace. Ce n'est donc pas un remplacement exact de pg_repack, mais pour
00:06:06une table normale, ça fait le travail sans l'extension. Bien, nous allons maintenant faire un tour d'horizon rapide
00:06:11des fonctionnalités restantes dans la version 19. Tout d'abord, les indices de requête (query hints) : Postgres décide comment exécuter
00:06:17votre requête et peut changer d'avis au fil du temps. Ainsi, une requête qui fonctionnait bien pendant un an devient soudainement lente
00:06:22sans qu'aucun changement n'ait été fait dans votre code. Un nouveau module appelé "pg_plan_advice" vous permet de capturer le plan tant qu'il est
00:06:28encore rapide et de le verrouiller pour qu'il le reste toujours. JIT est désormais désactivé par défaut : Postgres compile les requêtes lourdes
00:06:36en code machine, mais décidait quand s'en préoccuper à partir de l'estimation de coût du planificateur, et les notes de version
00:06:41indiquent que ce calcul de coût était en fait peu fiable, ce qui déclenchait JIT sur des requêtes qui n'en avaient pas vraiment
00:06:46besoin. De plus, "vacuum" peut désormais nettoyer vos index avec plusieurs processus en parallèle, ce qui réduit le temps
00:06:52passé à nettoyer une grosse table. Vous devez toutefois l'activer vous-même. Vous savez, quand vous ajoutez une colonne pour
00:06:58faire un select, puis que vous devez ajouter cette même colonne au group by également ? Cela fait tout cela pour vous.
00:07:03Et le mot-clé "copy" peut désormais exporter directement en JSON : si vous exportiez en CSV pour le convertir
00:07:09ensuite, vous pouvez arrêter de le faire. C'était donc Postgres 19 bêta 2 sorti en juillet, et la version finale est
00:07:15attendue vers septembre ou octobre. Si vous utilisez une version plus ancienne, cela vaut la peine de récupérer la bêta
00:07:21et de tester avec dès maintenant. Et si vous voulez en voir plus sur Postgres, vous pouvez jeter un œil à
00:07:25une présentation de PG Durable, qui intègre des flux de travail durables directement dans Postgres. C'était Warren de
00:07:31Better Stack, merci d'avoir regardé et à bientôt dans la prochaine !