Contributeur de longue date au projet PostgreSQL, Dimitri Fontaine a publié il y a quelques mois un ouvrage consacré au développement d’applications et au « SGBD libre de référence » : Mastering PostgreSQL in Application Development. On s’est dit que cela pourrait être une bonne occasion pour avoir sa vision sur l’évolution de PostgreSQL et des rapports entre développeurs et bases de données.
Pour ceux qui ne te connaissent pas, et ceux qui te connaissent mais n’ont jamais eu l’occasion de te poser la question : comment as‐tu été en contact avec PostgreSQL ?
Cela a commencé il y a vingt ans quand, à l’école, il nous fallait un SGBD sur HP-UX : PostgreSQL était le seul disponible et fonctionnait très bien. Ce n’est que bien plus tard que j’ai appris que Tom Lane (de la core team de PostgreSQL), était un ancien ingénieur kernel de HP-UX et qu’il veillait à la qualité de PostgreSQL sur cette plate‐forme.
Un élément clef qui m’a incité à continuer à m’intéresser à Postgres, c’est la conformité entre la documentation et le produit : tout marche comme indiqué dans la documentation et, si ce n’est pas le cas, c’est considéré comme un bogue et rapidement corrigé.
Comment as‐tu été amené à y contribuer ?
Ma première contribution a été déclenchée par la frustration que j’ai ressentie face à la complexité des procédures de sauvegarde et restauration lorsque des modules externes étaient employés. À l’époque, il n’y avait pas de système d’extension. Alors, j’ai décidé d’en implémenter un. Cela m’a pris plus de deux ans et cela m’a permis d’être reconnu comme major contributor au projet.
En tant que projet Open Source, PostgreSQL a plus un fonctionnement « cathédrale » que « bazar » [N. D. M. : référence à La Cathédrale et le Bazar , d’Eric Raymond], avec un nombre de « commiteurs » réduit (une dizaine actifs actuellement). Une grande importance est attachée à la reconnaissance individuelle : le nom de chaque auteur apparaît dans les notes de publication de chaque version, même si, pour des raisons techniques, il n’apparaît pas dans le champ author de git mais dans les commentaires.
Ma contribution suivante a porté sur les Event triggers. Sur la liste de diffusion, Jan Wieck avait indiqué que ça devait être assez facile à mettre au point : à la lecture de son message, je me suis dit qu’il devait avoir raison et j’ai commencé le développement. Ça m’a pris 18 mois.
Tu as aussi été mainteneur Debian de PostgreSQL ?
Non, j’ai aidé à créer la solution apt.postgresql.org. Debian ne maintient dans Debian stable qu’une seule version de PostgreSQL, pour ne pas se trouver dans la situation où ils auraient à maintenir une version de PostgreSQL que nous aurions cessé de maintenir : les deux projets ont des gouvernances libres et ont des cycles de publication indépendants. PostgreSQL, de son côté, maintient cinq versions stables en parallèle : l’idée derrière apt.postgresql.org est de fournir des paquets Debian pour ces différentes versions.
Aujourd’hui, c’est principalement Christoph Berg (credativ) qui s’en occupe et il fait vraiment un excellent travail.
À côté du cœur de PostgreSQL, tu as écrit l’outil PGloader : pourquoi ?
Cela a commencé en 2005, à l’occasion de migrations d’Informix vers PostgreSQL. À force de refaire à peu près les mêmes opérations à la main, je me suis rendu compte que la partie de migration des données était complètement automatisable et c’est ce que permet un outil comme PGLoader. Parallèlement, j’ai affiné une méthodologie de migration continue, adaptée aux migrations de projets complexes.
Elle comporte quatre étapes majeures :
- on met en place une architecture de production PostgreSQL ;
- on migre automatiquement les données de production toutes les nuits ;
- on branche une intégration continue sur l’environnement Postgres qui contient les données de production ;
- une fois que tous les tests sont OK sur l’intégration continue, on pense à basculer l’application en production.
PGLoader permet de réaliser l’étape deux. Pour ceux que cela intéresse, la méthodologie est détaillée dans un livre blanc, disponible sur le site de PGLoader.
La version 10 de PostgreSQL est sortie en fin d’année dernière, quelles en ont été les nouveautés les plus marquantes ?
Il y en a trois principales, qui sont assez bien couvertes dans la presse, donc ce sera sans surprise :
- la réplication logique : elle permet de nouvelles architectures PostgreSQL ; ce ne sont pas des choses entièrement nouvelles, mais elles sont désormais beaucoup plus simples et on peut les mettre en œuvre avec bien plus de souplesse ; alors qu’on avait pour la réplication une granularité au niveau de l’installation PostgreSQL (un cluster), on a désormais une granularité au niveau de la table ;
-
le partitionnement : on pouvait également le faire auparavant, mais c’est désormais plus simple et surtout mieux intégré avec les autres fonctionnalités de PostgreSQL, comme les requêtes parallèles ; sur cet aspect, PostgreSQL a été un peu en retard par rapport à d’autres solutions, mais l’implémentation est vraiment robuste. C’est un peu le même phénomène que l’on a constaté pour UPSERT : la fonctionnalité est arrivée très tardivement dans PostgreSQL et s’intègre bien avec l’ensemble du SGBD. De plus,
INSERT … ON CONFLICT …résout le vrai problème qui motive la commande, en permettant de spécifier la contrainte d’unicité à prendre en compte ; - l’intégration de la haute disponibilité côté client : côté client, on fournit une liste de serveurs auxquels se connecter. C’est simple techniquement et simplifie beaucoup les déploiements. Cela a d’abord été implémenté côté serveur et, une fois que cela a atteint un niveau de maturité satisfaisant, on l’a implémenté côté client.
Les prochains changements que l’on peut attendre ?
Les nouvelles fonctionnalités de PostgreSQL sont systématiquement construites sur ce qu’on a déjà : on va donc avoir un prolongement des dernières évolutions, comme une granularité au niveau des colonnes pour la réplication logique, par exemple.
Pour avoir une idée de ce qui va arriver dans PostgreSQL avec un an d’avance, le mieux est de suivre des sources comme https://planet.postgresql.org/ ou https://postgresweekly.com.
Et les sujets que tu aimerais personnellement voir progresser ?
Le partitionnement, c’est un sujet compliqué et j’aimerais bien qu’on le termine. Ensuite, les vues matérialisées en ligne : actuellement, il est encore nécessaire de mettre à jour le cache manuellement ; l’idée serait de mettre à jour le cache automatiquement quand les données changent.
Au niveau des outils externes à PostgreSQL, y a‐t‐il des nouveautés intéressantes parues récemment ?
Il y a toujours une actualité fournie sur les outils autours de PostgreSQL. Deux outils me viennent à l’esprit en particulier : Patroni et pgBackRest.
Patroni, développé par Zalando, permet de créer des systèmes PostgreSQL haute disponibilité sur mesure, qui fonctionnent bien en combinaison avec Kubernetes.
pgBackRest est une solution d’automatisation de sauvegarde et de restauration de données. On a tendance à se focaliser sur la partie sauvegarde, alors que c’est la restauration de données qui compte. C’est une alternative sérieuse à Barman de 2nd Quadrant.
Y a‐t‐il des manques importants en termes d’outils externes par rapport à d’autres SGBD, comme Oracle ?
Il y a certains outils pour Oracle ou DB2, qui n’ont de sens que dans leur contexte spécifique et pas avec PostgreSQL, qui inclut beaucoup de choses par défaut (hot standby, etc.). Après, il y a des outils qui apportent un vrai confort d’utilisation, dont certains peuvent encore manquer à PostgreSQL.
Il ne faut toutefois pas tomber dans le piège de la reproduction à l’identique. Prenons le cas des hints dans Oracle, par exemple. Cela permet à un DBA de modifier les plans d’exécution des requêtes écrites par les développeurs, sans toucher à l’application. Cela permet de corriger certains défauts de l’application, sans parler avec les développeurs, ce qui, au final, n’est pas forcément une bonne chose, car c’est une occasion perdue d’échanger avec eux, de les faire monter en compétence sur les sujets liés à l’utilisation de la base de données. Et puis, surtout, d’une version à l’autre de votre SGBD les hints peuvent changer de manière assez drastique, obligeant à revoir l’ensemble des requêtes arrangées.
Vu de l’extérieur, PostgreSQL semble connaître une adoption en croissance forte : c’est aussi l’impression que vous avez au sein du projet ?
C’est ce que l’on constate. On distingue notamment deux causes fortes favorisant son adoption : d’une part, les pratiques commerciales d’Oracle (aussi bien les audits que le mode de tarification) et, d’autre part, la montée en maturité des DSI vis‐à‐vis de l’Open Source. Par ailleurs, il est extrêmement rare de voir une start‐up employer des SGBD propriétaires.
Avez-vous des indicateurs chiffrés spécifiques ?
On n’a pas de suivi du nombre de téléchargements ou autre et c’est de toute façon assez difficile à suivre, car le projet est vraiment libre. Il y a aussi plusieurs forks dans le Cloud comme Amazon RDS, ou des extensions comme Citus, où je travaille actuellement… L’écosystème est vaste et complexe à cerner.
Le Groupe de Travail Inter‐Entreprises (PGGTIE) de PostgreSQL-FR réunit des entreprises utilisatrices pour pousser l’adoption de PostgreSQL par les éditeurs et mutualiser des financements pour le développement de PostgreSQL. Tu en penses quoi ?
C’est une excellente initiative : il y a plusieurs années, certains de nos clients avaient déjà cette démarche individuellement vis‐à‐vis des petits éditeurs. La fédération autour de cette question devrait permettre de toucher des éditeurs plus importants.
Pourquoi écrire un livre sur PostgreSQL ?
Il y a des années que j’avais ce livre en tête : je me suis rendu compte que les développeurs gagneraient vraiment à mieux appréhender certaines des idées fondamentales sur les bases de données et en particulier celle‐ci : le rôle principal de la base de données, c’est de gérer la concurrence d’accès aux données. Le stockage et la durabilité, c’est un problème beaucoup plus facile à résoudre, pas besoin de SGBD relationnel pour cela. L’application se concentre typiquement sur le workflow de l’utilisateur, et la base de données maintient une vue globale et cohérente du système d’information. On peut gérer la concurrence d’accès au niveau applicatif, au risque alors de réécrire un SGBD.
À qui s’adresse ton livre ?
Aux développeurs d’applications, comme le titre l’indique (Mastering PostgreSQL in Application Development). L’idée est de les accompagner dans l’écriture de SQL de qualité, dans son intégration avec le reste du code, dans l’écriture des tests et dans les processus de revue de code sur du SQL. L’objectif final est de permettre aux développeurs d’applications d’utiliser le langage SQL avec le même niveau de professionnalisme dont ils ont aujourd’hui l’habitude avec leurs autres langages de développement.
L’écriture a pris longtemps ?
C’est le fruit d’années de réflexions et de contacts avec les développeurs. L’écriture en elle‐même a été assez rapide : environ trois mois ; il y avait déjà des éléments sur mon blog.
Tu l’as écrit avec quels outils ?
Je rédige sous Emacs en Markdown, que je transforme avec Pandoc et des templates Latex ; le tout géré dans un dépôt git.
Merci Dimitri !
Aller plus loin
- Le blog de Dimitri Fontaine (351 clics)
- Planet PostgreSQL (119 clics)
- Le Groupe de Travail Inter‐Entreprises de PostgreSQL-FR (186 clics)
- Le site du livre Mastering PostgreSQL in Application Development (203 clics)
# N'importe quoi !
Posté par Kangs . Évalué à -2.
Les grosses applications en entreprise sont basées sur SAP, SIEBEL, PEOPLESOFT (pour les plus connus) et sont très critiques, beaucoup de logiciels de niches sont développés par des startups et sont très critiques, beaucoup d'applications propres à une entreprise sont basées sur des frameworks qui génèrent le code SQL et sont plus ou moins critiques.
LE point commun de toutes ces applications : ON S'EN BRANLE DU SGBDR !
Donc aujourd'hui le strict minimum que doit apporter un SGBDR aux DBA, c'est de pouvoir ajouter des hints à la volée, interdire des plans, stabiliser un ensemble de plans & co. Ces entreprises (SAP étant une exception) ne vont pas faire beaucoup d'efforts et les startups n'en font presque pas voir pas du tout.
J'ai vécu un enfer avec une base spatiale (d'une startup) pour les réseaux ferrés en Oracle 9i, le CBO n'intervenait pas dans les requêtes spatiales (le plan était produit uniquement à partir d'heuristiques), il fallait donc les aider avec des hints, mais en 9i seul les développeurs pouvaient les ajouter ! Et ils nous ont menés en bateau pendant des mois et n'ont jamais rien fait. Aujourd'hui j'aurais pu résoudre, je pense, les problèmes de performance avec les outils disponibles.
Il faut arrêter avec ce pseudo dialogue avec les développeurs, il existe très peu et est juste parfois impossible à cause des outils utilisés.
Aujourd'hui ont (les DBA mais tout type d'administrateurs) gère des parcs de 100 à 2000 serveurs de productions avec j'aimais plus de 18 DBA, on est évalué sur le temps passé à résoudre un problème pas à discuter avec les équipes de devs. Le SQL et le SGBDR ne sont pas le langage et outil préférés (ou maîtrisés) des développeurs. Beaucoup voient un SGBDR comme un système de fichier portable (d'ailleurs sur ce site de nombreuse dépêches et commentaire vont dans se sens). Donc le jour ou les écoles (peu importe le niveau) enseigneront les principes fondamentaux comme les transactions (résumées par ACID), ce qu'est une 3NF et le W.A.L modes cela pourra peut-être évolué, mais pour l'instant c'est le SGBDR qui s'adaptent aux pratiques majoritaires des développeurs et à leur déchargent chaque SGBDR va se comporter différemment (le CBO ne serra jamais parfais) ! Donc c'est aux SGBDR de fournir des outils pour adapter le code, le dév ne pourra pas faire une version par SGBDR.
[^] # Re: N'importe quoi !
Posté par Anonyme . Évalué à 7. Dernière modification le 25 février 2018 à 21:14.
ca se défend mais l'histoire montre que tu as tord. Je me souviens du meme genre de poste au début de mozilla qui ne reprenais pas le rendu d'IE6.
dans ton cas l'usage de pstgrsql imposerais le dialogue, tu n'es pas concerné car tu utilise une bouse (traduction libre de l'avis de dimitri sur oracle :) )
il faut regarder par dela l'horizon, les courtes vues sont priées d'aller pleurnicher ailleurs
[^] # Re: N'importe quoi !
Posté par Ontologia (site web personnel) . Évalué à 10.
Je ne suis pas sûr qu'il faille rejeter son poste a priori : la plupart des SGBD sont utilisés via des ORM et autres couches d'abstractions qui font qu'effectivement le développeur ne sait pas ce que fais le SGBDR, c'est juste une brique de la stack pour lui.
De plus, la plupart des développeurs en SSII sont incapables d'écrire une requête SQL, avec une jointure n'y pensons même pas, et de toutes façons, ça les gonflent.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: N'importe quoi !
Posté par claudex . Évalué à 10.
Vu le ton très agressif, si. On est là pour discuter, pas pour s'engueuler.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: N'importe quoi !
Posté par Kangs . Évalué à 3.
J'ai même abandonné d'essayer d'expliquer la différence entre une jointure et un filtre.
Cela étant dit, je le répète, c'est aux SGBDR de s'adapter aux pratiques majoritaires. C'est comme ça que l'informatique évolue.
Aujourd’hui on doit gérer des applications dont le moyen de persistance est une abstractions. Je ne sais pas si c'est bien ou non, mais la masse fait que l'on va dans se sens. C'est aux éditeurs de s'adapter (et c'est ce qu'il font) de proposer des solutions "génériques" qui correspondent à ce que la majorité fait.
Entendre en développeur tenir un discourt datant des années 90 en 2018 me consterne.
[^] # Re: N'importe quoi !
Posté par djano . Évalué à 4.
Je pense que c'est là que le bat blaisse.
Je ce cas, je ne donne pas cher de l'application qu'ils développent…
[^] # Re: N'importe quoi !
Posté par Moonz . Évalué à 5.
Je suis désolé, mais pour moi c’est ça qui est à courte vue.
La plupart des développeurs n’ont que des besoins extrêmement basiques de persistance. Demander d’avoir à maîtriser SQL pour ça n’est pas raisonnable. On ne demande pas à un développeur de savoir rebalancer un RB+-tree pour utiliser un système de fichier, ou de connaitre en détails comment fonctionne la couche MAC du wifi pour faire une requête HTTP.
Le progrès en ingénierie informatique, c’est le développement d’abstractions simples d’utilisation (système de fichier, TCP) adaptées à un besoin précis et répandu. Si le « monde BDD » (j’inclus là dedans SGBDR et ORM) n’est pas capable de fournir une telle abstraction pour des besoins de persistance basique, le problème vient du monde BDD, pas des développeurs.
[^] # Re: N'importe quoi !
Posté par djano . Évalué à 10.
Pour des besoins basiques les ORM marchent tres bien. Besoins basiques = c'est possible d'avoir des perfs suffisantes sans trop se casser la tete. Je pense que 90% des applications sont dans ce cas.
J'ai meme entendu dire que ca marchait dans des cas compliques, mais a mon avis les gars qui codaient connaissaient tres bien l'ORM et la base de donnees sous jascente.
Maintenant, le jour ou les volumes augmentent, tu ne peux pas faire l'economie d'avoir:
1. des gars qui savent bien comment marchent la BD
1. le temps et les resources pour travailler sur les performances
1. une entreprise qui valorise le travail sur les performances
Sinon l'application et l'equipe fonce droit dans le mur. (C'est du vecu)
Tu peux developper toutes les abstractions que tu veux, si les developpeurs ne font pas l'effort de comprendre comment fonctionne chaque brique de l'application et comment en tirer le maximum, rien ne pourra les sauver. Bien sur ils vont blamer la technologie, mais la verite, c'est qu'ils peuvent changer de technologie, mais ils continuerons toujours a avoir les memes problemes.
Je n'ai jamais vu les problemes disparaitre en cachant sa tete dans le sable et se regardant le nombril.
[^] # Re: N'importe quoi !
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
A l'inverse, la complexité du SQL vient du fait qu'il essaye de cacher que parfois que l'accès se fait avec une table de hash, et parfois, il parcourt entièrement les tables.
Avec la mode des µservices, dont il est possible de tout réécrire entre 2 versions d'un logiciel ( ce qui est un impossible pour un gros monolithe et qui rend douloureux tout changement de technologie), il y a un peu de code avec une BDD (genre un modèle DDD persisté, et qui sort en API REST HTTP JSON ou XML ou en protobuf ou les 3).
Est-ce qu'il serait délirant d'avoir un vrai langage classique lié avec une BDD dans le but de faire un microservice complet ? L'API devrait être simplifié pour fournir les garanties ACID, mais on pourrait éviter les acrobaties dés qu'il faut faire un truc un peu compliqué.
On éviterait ainsi la communication réseau.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi !
Posté par freem . Évalué à 6.
J'ai eu le désagrément de travailler avec powerbuilder, qui embarquait le sql dans le code. Je recommande chaudement à tout développeur de se tenir loin de ce truc.
Je crois que ce type de fonctionnalités est aussi mis en avant par windev, et il me semble que C# possède des outils dans ce sens.
Donc, non, je ne crois pas que ce soit délirant de le faire. Le problème, c'est de le faire correctement, de faire un langage dont la syntaxe permette de mélanger le paradigme des SGBDR avec à minima du procédural voire de la POO ou du fonctionnel. Et ça ne (me, du moins) semble pas trivial.
[^] # Re: N'importe quoi !
Posté par djano . Évalué à 3.
Il y a JOOQ dans le monde Java qui est proche de ce que j'aurais aimé utiliser.
Mais je ne l'ai jamais testé, ça m'a juste l'air top moumoute :)
https://www.jooq.org
[^] # Re: N'importe quoi !
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Je ne comprend pas trop ou est le problème. Il n'est pas possible de faire des fonctions get/set ou de proposer un map/fold sur les tables dans n'importe quel langage ? Je parle bien sûr d'un code type "12 principes" de heroku sans aucun état conservé par le programme lui-même entre 2 requêtes extérieurs.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi !
Posté par freem . Évalué à 4.
Hum. Un Get/Set tu dis? Oui, on peut. Enfin, on peut au moins dans les bonnes BDD lister les schémas, les tables d'un schéma, les champs et les lignes de ces tables…
Par contre, de mon point de vue, c'est sale. Une BDD faite correctement ne devrais pas exposer son modèle physique, juste une liste de procédures stockées, une API en fait. Et ça, ben je pense pas que ça colle très bien avec la notion de faire des gros get/set de goret sur des champs aléatoires.
Parce que, ben, le jour ou une table se voit modifiée pour une raison X ou Y, on risque de péter un nombre aléatoire d'applicatifs basés sur la-dite BDD, et ça, c'est pas bien.
Et ce, y compris sur de petites BDD, parce qu'un jour elles finissent grosses.
[^] # Re: N'importe quoi !
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je crois que l'on s'est mal compris. Je parle du même genre d'api sous entendu dans le code SQL mais écrit dans un langage moins tordu. Je parle bien d'API de haut niveau. Mais pour du code mis en tant que module ajouté à la BDD, pour suivre la mode de µservice qui lie un peu de code avec une BDD.
Donc, on aurait toujours les garanties ACID, le code ne stock rien en dehors de la BDD, et fonctionne de façon parallélisable, et propose au monde extérieur une API web (JSON, XML, gRPC).
On peut me dire que la scalabilité sera plus limitée, si on ne peut pas multiplier les front-end de code, mais je répondrais que la limite va vite se déplacer sur la scalabilité de la base elle-même.
"La première sécurité est la liberté"
[^] # Re: N'importe quoi !
Posté par Kangs . Évalué à 0.
J'ai essayé de l'expliquer 1 000 fois, on m'a systématiquement répondu trop de boulot…
[^] # Re: N'importe quoi !
Posté par Kangs . Évalué à 1.
Je ne suis pas d'accord avec toi. Tu exprimes un besoins et tu as un résulta. Le moyen technique pour y parvenir, en tant que développeur, tu t'en fou à partir du moment ou tu respectes les contraintes d'utilisation du SGDB/R, qui peuvent être de faire du vaccum pour un oui ou non.
[^] # Re: N'importe quoi !
Posté par Kangs . Évalué à -10.
Tu racontes vraiment n'importe quoi.
[^] # Re: N'importe quoi !
Posté par ll0zz (Mastodon) . Évalué à 4.
[^] # Re: N'importe quoi !
Posté par djano . Évalué à 5.
Oui, j'ai étudié ces choses là et ça ne m'a pas aidé pour parler à mon SGBD que je considérais comme une boîte noire magique. Depuis que je suis passé de l'autre côté (Je travaille sur une base de données non relationnelle), mon point de vue à beaucoup changé. La boîte noire n'est plus magique du tout, et je n'écris plus du tout mes requêtes de la même manière.
[^] # Re: N'importe quoi !
Posté par freem . Évalué à 6.
Avant ça, j'aimerai qu'elles enseignent correctement l'objet et cessent de présenter l'héritage et même la POO (pure) comme une solution à tous les problèmes. Entres autres.
ACID, je pense que les devs connaissent (en tout cas, l'acronyme me parle, et une rapide lecture semble indiquer que c'est assez proche de ma façon d'écrire), par contre le reste, je veux bien à minima une explication rapide. Ou, au pire, un lien vers une explication qui soit relativement accessible au dev que je suis.
[^] # Re: N'importe quoi !
Posté par Kangs . Évalué à 1. Dernière modification le 28 février 2018 à 11:35.
La forme normale est une façon de concevoir un schéma transactionnel, le but étant par exemple d'éviter les 'deadlock', faciliter la concurrence etc. La plus connue et la plus utilisée étant la 3iéme forme normale (3NF) il y en a d'autre, mais je ne pense pas les avoir vus implémentées.
Write Ahead Mode, quand tu fais des insert, update, delete ils ne sont pas faits sur le disque mais en mémoire (sous Oracle et je pense les autres éditeurs aussi, il y a des cas particulier comme pour les LOB), mais toutes les instructions d'une transaction sont loguées dans un journal de transaction, le coût de l'IO tu l'as uniquement au commit, car avant de rendre la main le moteur doit te garantir qu'il pourra rejouer les instructions s'il y a un plantage. Bien sur les blocs mémoire sont écrits sur le disque, mais de façon asynchrone, d’où l'importance de la taille du cache pour les bases OLTP s’il y a beaucoup de transactions concurrentes.
[^] # Re: N'importe quoi !
Posté par gregolak . Évalué à 0.
Réaction un peu énervée, mais que je comprends.
Certes dans un monde idéal, les DBA et les dév devraient se causer davantage. Mais dans le monde réel, avec ses contraintes de coûts, de délais voire techniques (utilisation des ORM comme évoqué dans d'autres commentaires), il est bon de pouvoir disposer de ce genre de fonctionnalités sur un SGBD.
Les condamner comme une mauvaise pratique est un peu exagéré.
[^] # Re: N'importe quoi !
Posté par Kangs . Évalué à 1.
Le plus gros de l'énervement est qu'il ne semble pas connaître le monde de la production, en production une défaillance (les dégradations de performance en font partie) ont un coût. Quand on est DBA de production on a pour objectif de rendre le service optimal le plus vite possible. On peut éventuellement donner des avis/conseilles mais ils ne seront pas entendus.
Le manager ne va pas financer une correction si le problème est résolu par des options du SGBDR. Il pensera que c'était un problème du SGBDR mais pas du code. Si le problème devient récurrent et pèse financièrement, que ma hiérarchie est convaincue par mes arguments alors une discussion devient possible. Mes boss parlent avec les autres boss, s'ils sont convaincus (et il y a de gros lourd) alors on pourra (les DBA) discuter avec les dev.
Ensuite faut pas rêver, je fais partie de la génération ou avant d'être admin de quoi que ce soit il fallait avoir été développeur, donc je peux facilement discuter et coder si je connais le langage. Beaucoup de mes jeunes collègues sont directement arrivés en production, ils ne connaissent rien au dev. Certain apprennent vite les principes fondamentaux du SQL, d'autres ne supportent même pas l'idée de devoir coder (même du ksh).
Le gros énervement vient donc du fait qu'il pense que les DBA et les dev devraient plus discuter, mais vu ces arguments j'ai l'impression qu'il n'a jamais essayé de discuter avec des DBA de productions pour connaître leurs attentes principales d'un SGBDR. J'ai l'impression qu'il développe un logiciel destiner à la production sans savoir ce qu'est une production.
[^] # Re: N'importe quoi !
Posté par pgphil . Évalué à 10.
Absolument pas d'accord. Les ORM produisent essentiellement du code SQL-92 et des requêtes transactionnelles relativement basiques. Il y a moins de risques que l'optimiseur se plante, à part si, paradoxalement, il est trop riche. L'optimiseur d'Oracle est le cas typique. Il produit des plans allant du catastrophique à l'excellent là où le planner de PostgreSQL se situe plus souvent entre le bon et le très bon.
Je me suis rendu compte au fil du temps que les gadgets fournis par Oracle servent essentiellement à compenser les cas catastrophiques. Depuis 3 ans, je compare les plans d'exécutions produits avec Oracle et PostgreSQL, entre autres pour les requêtes nécessitant un SQL profile ou autre fonctionnalité exotique. Ma conclusion est que le planner de PostgreSQL se plante bien moins souvent par défaut que l'optimiseur d'Oracle, ce qui rend inutile les gadgets. Dans les rares cas où il se plante, il y a toujours moyen de le faire rentrer dans le droit chemin sans modifier le code SQL applicatif en jouant sur les statistiques, les paramètres de niveau session etc.
De manière générale, les outils et évolutions d'Oracle Database servent surtout à compenser les énormes problèmes générés par Oracle Database lui-même. Le meilleur exemple est la shared pool, la zone de partage des plans. Sur le papier c'est génial mais dans les faits ça consomme une quantité énorme de RAM qui n'est plus disponible pour mettre en cache les données. Cette zone est un poison et Oracle tente d'introduire des contrepoisons au fil des versions : bind peeking, adaptive cursor sharing…qui ne font que consommmer davantage de RAM et ajouter à la complexité.
Oracle pleure à ce sujet en disant qu'il faut développer en pensant à leur architecture. Cela signifie quoi ? Qu'Oracle admet qu'Oracle Database est un très mauvais choix lorsqu'on se "branle du SGBD". C'est LE SGBD le plus dépendant de ses DBA, ce qui le rend au départ peu éligible pour être une base de données dans le cloud. Larry Ellison & Co en ont d'ailleurs bien conscience avec la 18c présentée comme "autonome".
[^] # Re: N'importe quoi !
Posté par Kangs . Évalué à -10. Dernière modification le 11 mars 2018 à 23:30.
Je n'aurais jamais cru pouvoir lire de tels de conneries de ma vie. Le prochain dîner de cons je t'invite.
[^] # Re: N'importe quoi !
Posté par claudex . Évalué à 9.
Merci de rester poli et courtois dans les commentaires, conformément aux règles de modération.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: N'importe quoi !
Posté par Kangs . Évalué à -2.
En quoi je n'ai pas été poli et courtois ?
[^] # Re: N'importe quoi !
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 1.
Tu l'as traité de con.
# Typo
Posté par Sylvestre Ledru (site web personnel) . Évalué à 6.
s/apt.postgresl.org/apt.postgresql.org/g
Le premier renvoi vers une url incorrecte.
A noter que ça utilise la même infrastructure que https://apt.llvm.org/ (jenkins avec https://jenkins-debian-glue.org/)
(coucou Dimitri)
[^] # Re: Typo
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 4.
Corrigé, merci !
# Version pour les francophone ?
Posté par Mimoza . Évalué à 8.
Bonjour,
Pour ceux qui ne se sentent pas assez à l'aise avec l'Anglais pour lire un tel livre, une version en Français est elle prévue ?
[^] # Re: Version pour les francophone ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
Comme beaucoup, je me débrouille assez bien en anglais mais cela me demande un petit effort que je préfèrerais éviter afin de me consacrer totalement à la compréhension du sujet.
Un ouvrage en français serait à mon avis le gage d'une pénétration encore meilleure de postgresql dans les écoles et les entreprises.
[^] # Re: Version pour les francophone ?
Posté par freem . Évalué à 8.
Peut-être qu'un document en LaTeX pourrait aider?
(j'ai honte du fait que ça me fasse rire)
[^] # Re: Version pour les francophone ?
Posté par Thomas Douillard . Évalué à 4.
Tu devrais surtout avoir honte de rire de tes propres blagues /o\
[^] # Re: Version pour les francophone ?
Posté par freem . Évalué à 3.
Pour certaines je n'ai pas honte, mais celle-la oui, comme précisé :)
# Yay, bisous à l'équipe Postgres !
Posté par small_duck (site web personnel) . Évalué à 10.
Merci à l'équipe Postgres pour leur travail d'une qualité peu commune. J'avais poussé mon équipe à utiliser Postgres plutôt que MySQL il y a de cela quelques années, et malgré des DBAs peu chauds au début nous avons aujourd'hui une douzaine de bases et des terra-octets de données pour des applications très critiques, et tout cela fonctionne plutôt bien.
Notre équipe est peut-être un peu particulière en cela que nous n'utilisons pas d'ORM, et sommes donc plutôt près du métal. Cela permet d'utiliser à fond les spécificités du SGBDR, pour les performances (COPY) comme pour les fonctionnalités (type tableau).
Je vais rajouter le bouquin à ma liste du Père Noël.
[^] # Re: Yay, bisous à l'équipe Postgres !
Posté par windu.2b . Évalué à 9.
Merci pour ce retour.
Pourrais-tu nous dire quels furent les points bloquants/compliqués de la migration MySQL => Postgres ? À la fois d'un point de vue techniques (types de données, …), mais aussi humain (habitudes, méconnaissance des possibilités offertes par Postgres) ?
Ou même mieux : tu voudrais pas nous faire un journal à ce sujet ?
(j'en demande trop ?)
# Big up à PostgreSQL et pour le livre peut-être attendre la deuxième édition...
Posté par weierstrass01 . Évalué à 8.
Je rejoins les autres commentaires vantant les mérites de PostgreSQL. Subissant (BDD "embarquées" dans certains logiciels fournis clés-en-main) du Oracle/MS-SQL sur certains applicatifs critiques avec en plus la joie de se retrouver limité par la licence à disposition, je pousse le développement des applications "maison" avec PostgreSQL comme SGBD.
La qualité de la documentation en ligne (notamment pour les fonctionnalités "non triviales"), un peu de réflexion au moment d'arrêter le modèle de données et l'obligation faite aux dev de bâtir les applications autour de celui-ci et non pas l'inverse, permet d'obtenir de bons résultats dans notre contexte.
Par contre, pour avoir reçu le livre il y a quelques jours et en être quasiment au bout, autant le fond du livre est appréciable (même si à titre personnel je trouve que certains passages auraient mérité d'être approfondis), autant la forme laisse assez régulièrement à désirer : pas mal de typos, des tournures de phrases souvent très "franglaises" qui obscurcissent le propos de l'auteur…
Certains passages piquent quand même pas mal les yeux et je me suis retrouvé à plusieurs reprises à me demander ce que l'auteur avait bien pu vouloir dire.
Gageons que cela sera corrigé dans une future seconde édition. Je ne regrette pas l'achat du livre mais j'ai trouvé cela un peu surprenant compte tenu de la qualité de rédaction de la documentation PostgreSQL "officielle", à laquelle Dimitri doit je suppose également contribuer.
[^] # Re: Big up à PostgreSQL et pour le livre peut-être attendre la deuxième édition...
Posté par freem . Évalué à 3.
Contribuer ce n'est pas faire parfait, mais faire OU corriger ce qui à déjà été fait (ok… et rapporter les problèmes, mais ce n'est pas le point sur lequel je voulais insister).
[^] # Re: Big up à PostgreSQL et pour le livre peut-être attendre la deuxième édition...
Posté par Dimitri Fontaine (site web personnel) . Évalué à 10.
Merci pour le commentaire globalement sympa pour le contenu du bouquin. Désolé si la qualité de la forme n'est pas au niveau attendu, j'ai pourtant bien évidemment fait relire le livre par un pro afin d'éviter… ce que tu décris… Pour les passages difficiles à comprendre, si tu avais le temps de me faire un mail avec une petite liste, je reprendrai cela pour la prochaine révision !
Note : vous pouvez acheter le livre maintenant, toutes les prochaines révisions contenant des correctifs vous seront distribuées gratuitement en version électronique, évidemment!
Pour la documentation officielle de PostgreSQL, à laquelle j'ai contribué, on dispose d'excellents relecteurs dans la communauté, en particulier Bruce avait l'habitude de passer 3 à 4 semaines chaque été à relire la documentation de bout en bout pour s'assurer que le document est cohérent dans son ensemble… et corriger toutes les broutilles qu'il peut trouver.
dim
[^] # Re: Big up à PostgreSQL et pour le livre peut-être attendre la deuxième édition...
Posté par weierstrass01 . Évalué à 5.
C'est noté. Le temps de finir le livre et je le reparcourrai pour relever les passages qui m'ont le plus marqué de ce point de vue.
Y a-t-il un intérêt à relever les typos également ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.